Battery monitors and programing

marine-10

Various battery powered devices for monitoring communicate among other things the state of the inserted battery. The battery status can be clearly shown and / or actively monitored. For devices without their own battery status, you have to “retrofit” them. With the help of some programs, an overview of all devices with “battery” -Reading can be created.
To detect failures at an early stage, you can be notified by

e-mail as soon as a battery message is sent with something other than “ok” (e.g., “low”). In addition, the code creates an entry in the logfile. Caution: For users of a HM-CC-RT-DN the code has to look different because this thermostat sends the current voltage value of the battery for the first time. FB mail requires the installation on a FritzBox. For other hardware / OS platforms, the procedure is diffferent. Testing can be done e.g. With trigger heating the battery. One should also pay attention that the event to which one triggers is not repeated too frequently (for example, by the attribute event-on-change-reading).
More https://www.simarine.net/

Devices without battery status

For devices without reading for the battery status, you can estimate it in various ways and enter it as a reading. This works however only, of course, if the device sends – with a purely receiving actuator like the FHT actuator does not work so …

 

Expansion of the device by battery-reading

With the help of some programs you can easily monitor and estimate a battery status and provide it as a reading. Then the evaluation described also takes place directly.

The idea is to monitor and compare the time interval of the current timestamp with the last logged timestamp and to close it from the battery status – for example distance> 10min = battery low. For this only the following userReading has to be created for each battery-driven device (without battery status) (to set “low” at> 10min). If the device has not answered, the function produces a log entry. Note: This battery test also suggests, of course, if the devices still work, but the CUL does not work to receive the signals. In that case, all batteries are supposedly empty. In order to intercept this at least partially, you could still test the state of the CUL before generating the log entry, that this is not “disconnected”.

The links section provides a reference on how to view the battery status visually. This works with the suggested function with some additions even if the device itself does not indicate a battery status on the monitor.

 

 

 

A readingsgroup is always set up line by line, for example. Each device into a new line. The values of the devices you are monitoring are then displayed in the columns. If you have a readingsgroup for only one device with many readings (eg allergy), you can align the display horizontally or vertically by defining the readingsgroup in detail.

 

It is possible that readings are displayed which should not exist – for example, if you renamed a reading in an HTTPMOD, the old readings name can still be displayed. Such readings can be deleted with the global deletereading function. In the corresponding ReadingGroup, both variants are displayed consistently – even after all the old entries were removed from the logs.