I have a few different devices (some zwave, some zigbee - different drivers, different manufacturers) that the battery % never changes. Just stays 100% all the time. All in-box drivers.
This is really hard to troubleshoot, as the battery reports are not a state change, and thus don't log any events unless the value changes - which as I already indicated, it is not.
Since no events are being generated I don't know if the device isn't reporting battery % at all (association issue, or other), or if it is reporting battery but it is reporting 100% each time.
I can turn on debug logging, but on most drivers it auto-turns off after 30 minutes. Battery reports typically are very infrequent - hours between. So the chances of catching a battery report in the 30 minute debug window are slim.
All of that to say that I think battery reports NEED to be state changes.
If not all of them, then at least one battery report per fixed time period (8 hours?) should be a state change.
Funny, I'm having a discussion with @ritchierich about this right now as we are trying to work around this "feature" to properly generate reports in Node-red. We are forced to use the Maker Api call to extract the last ACTIVITY info. It would be a lot easier if every battery report generated an event instead. Hopefully this can be done without affecting hub performance.
I completely agree with your frustration. My zigbee hub was offline intermittently for 3 days this week while I was on business travel and trying to find time to fix it remotely. Some battery devices died and now I am having to go into each device to see the last time it reported anything to understand if it died to do the hub not being available.
It would be awesome if HE included an out of the box dashboard/table view that showed Device along with Battery %, Last Battery Timestamp, and Last Event Timestamp. This way I could easily scan it to understand if one has fallen off. @patrick
I will be working to come up with something via websocket/NodeRed and an external database for now given I already have those setup. But given the importance of batteries it would be nice if this was baked into the hub functionality out of the box.
@JasonJoel as a temporary workaround you might be able to force a battery event log by hitting configure. That's what I do with my zigbee devices when I'm testing my code. Not sure if the same occurs with zwave devices though.
You could create a "simple" app that periodically calls a local MakerAPI endpoint parses the response of this request. Then you can filter by date and send yourself a report with devices that haven't reported in a while
@dan.t, that's exactly how I'm doing it in node red. However, these Maker calls seem to put quite a load on the hub especially when you have a lot of battery operated devices. I do my Device Activity Report once a week at 5am for this very reason. In cases where you would want more up to date data, you would need to perform the call quite often and that is where having all battery events be a state change would come in handy.
I use node-red too, but not with MakerAPI. I just use the eventsocket to post the information to an InfluxDB and then use Grafana to display the last time a battery event was received. No need for the MakerAPI call, it was just one way of doing it. Here is how it looks in Grafana
Lol..I should copy and paste my discussion with @ritchierich as we went over this and he shared an almost exact screenshot.
The problem is that for those of use that use grafana for graphing etc, we need to use another flow that reinserts stale battery data into the db. I'm trying to figure out a way to distinguish between actual events and "fake" events so that both can be accomplished....but that is for another thread. Don't want to steer this one off course. I do that enough already.
Last response on that in this thread:
Hmmmm, how do you get stale data???? Eventsocket not listening????
Here is an idea (back to MakerAPI)
You have the event data in a DB (Influx, Maria DB, etc...)
Create a node-red flow that selects the device IDs that haven't reported in a while and issue a refresh/configure command via MakerAPI for these devices.... Or you just get the events for these devices, removing the load of MakerAPI since you do it for select devices and not for all
That would/could trigger a re-capturing of the data and make it fresh again
Battery reports in the Hubitat drivers not generating events unless the percentage changes is based on the assumption that devices are correctly reporting battery level and/or the hub is correctly receiving those reports.
The receipt of battery reports is not always the equivalent of a device "check in" - it is dependent on the characteristics of each device.
If a device isn't correctly reporting battery level and/or the hub isn't correctly receiving battery reports, users should be able to fall back to the timing of the device's most recent activity as a way to indicate the device's battery may have died. (I use "may" because no recent activity could also be due to a dropped network connection).
There are a number of apps available which aggregate most recent battery level event data and/or most recent activity time/date data and generate an easy to read report, which can be filtered by user-set thresholds like battery level below XX% and/or last activity more than XXX hours ago.
There is a group of Hubitat users who have been quite vocal about wanting to reduce the overall number of events generated by devices in order to lower the time it takes for the hub to present event lists in the hub's web UI. Superfluous battery level events have been pointed out as one of a number of things that make for unnecessarily long device event logs. Changing the behavior of battery reports in all Hubitat device drivers to generate events regardless of value change would be antithetical to those user's needs. So adding an preference option to toggle forcing all battery events to generate events would help to make everyone "happy".
You can't just use last activity to know if the battery status has updated - it may have been a completely different parameter. In my case the core readings work well, but the battery % never changes. In those cases the last activity helps ZERO.
I am fine if not every battery update is a state change, but my position is that there should be a minimum # of events that ARE state changes so a user knows for a fact the device is communicating the value to the hub, and there isn't another issue. Daily? 8 hours? Whatever - but it can't be none of the same values are state changes.
Not a dev and the subject seems very complex, but is there a need to see the battery decline over time? We all know that’s the life cycle of a battery. I suppose if you want to see how fast a devices battery is declining then yes, that would be useful. But really, isn’t viewing a battery state at a moment in time the most valuable thing here?
So couldn’t you poll the state of all devices manually or on a timed (e.g. once every few days at a user definable time) schedule, then record those results?
Agreed. For most devices, last activity is best used as an indicator that the device is still operating and connected. It won't tell you anything about a device's battery reporting.
I am just trying to understand how an unchanging 100% battery level is a problem that needs troubleshooting. If the devices have a battery level/voltage to percentage conversion curve applied in the driver (I've seen this in many ST device handlers), then the reported percentage can remain at 100% for quite a while before it begins to report lower percentages.
It seems that the concern here is that in absence of battery level events, perhaps devices' battery reporting isn't working correctly, or the hub isn't receiving those reports.
So do you not trust that your devices are correctly reporting battery level / the hub is correctly receiving battery level messages?
Thats exactly it. I know something is wrong, and am having a hell of a time figuring out if it is the devices, the meshes, the driver, or the hub.
I've had at least a dozen times now that a perfectly good working device all the sudden stopped working. I pull the batteries out and check them with a meter and they're completely dead, but it still shows 100% in hubitat.
I look at the events and see that there hasn't been a battery event since the device was originally paired. So was the device reporting 100% continuously, or did that 100% get populated on device pairing and there were no reports ever since then? I have no way of telling.
But I will say it is across multiple different devices, some zwave and some zigbee, with various different drivers. There is no obvious common theme other than the hub itself...
This thread got me looking at my battery reports; frankly something I only tend do after a device pairing or battery replacement unless something has failed. I never had battery reports with X10; SmartThings battery reporting was generally not accurate so I became trained not to rely on it and have never been surprised to find a battery dead when the day before it reported 80%. Nevertheless I can't believe I never noticed this before (I've been using this hub since February 2018), but battery reporting doesn't seem to be happening at all for most of my devices.
The only devices I have that have appeared to generate any periodic battery reports are my Xiaomi buttons, Aeon Z-Wave Water Sensor, one (of two identical) Ecolink Z-Wave contact sensors, and my First Alert ZCombo smoke/CO detectors. These devices generate battery reports regularly, as would be expected.
But with one exception, none of my Zigbee MCT340 contact sensors, Iris V2 motion sensors, Iris V2 contact sensors, Ecolink Z-Wave motion sensor, Ecolink contact sensor, or ST motion sensors have apparently reported any battery value (other than logging a single '100%') since the date of their last battery replacement. All indicate 100%, including a couple of motion sensors that had batteries replaced back in the Spring of 2018. The lone exception is one Iris V2 motion sensor that I paired with a new battery back in Feb. 2018 when I first installed Hubitat-- it generated one more final report 18 days later, on Feb 23, 2018, that reported 77% where it still sits.
I assume that this is not a pervasive problem (not everyone can be as oblivious to this issue as I was, though in my defense if I can't get close to a year of battery life out of a device I won't use it) and it is curious that it isn't confined to a single device technology (or even device type-- one of my two identical Ecolink contact sensors reports battery normally, one doesn't report at all). No unusual Z-Wave or Zigbee issues in my setup to report. Very strange!
After you pair your devices, do you go into the device and press the configure button? It almost sounds like that the battery reporting didn’t get configured correctly. Here is what I would try:
go into a device page and press the configure button
wake the device up, e.g. for a contact sensor open/close the contact
I do that (force of habit), although you should never have to. Any of the inbox drivers, and any other well written user driver, should run through the configuration on initial pairing.
Definitely should do it if you switch drivers after pairing though.
Actually after a battery replacement (as opposed to initial pairing) I just pop in the battery and verify and it reads 100%. I'll give it a shot though and see if it makes any difference.
I just went through a few of my Iris V2 motion sensors and hit configure followed by 'save device' (otherwise nothing happens)-- again something I do only on initial pairing-- and several of them did within seconds cough up a battery report (unlike quirky Z-Wave, sleepy Zigbee devices don't need to be manually activated when doing this). My driveway motion sensor (battery replaced last October) went from 100 to 87% which seems reasonable. It will be interesting to see if they continue to report; really don't know why this would be necessary after routine battery replacement as @JasonJoel says (generic drivers are in use for all of these).
Even the lone Iris device which had generated two additional battery reports after its initial pairing back in February 2018 (and hasn't reported its battery level since 2/23/18) produced a report, taking its battery percentage back up to 87% from77%. Not surprised about the rising voltage level as battery reporting just works poorly in general, but the intermittent nature of the reporting doesn't seem right.
I also hit configure/save device on the Ecolink Z-Wave contact sensor and had it generate an close event; it did not generate any battery report but I will keep an eye on it to see if it does.
