From time to time, what HE thinks is the current state of something (e.g. a switch being on) is not the real state (e.g. the switch is actually off). I've noticed this a number of times after doing a C7 -> C8-Pro migration, but I've seen it happen once in a while with the C7.
I suppose one way this can happen is if a switch is turned on or off while the hub is in the middle of a update or reboot. Executing a refresh or configure on the device gets things back in sync. However, I don't know something is amiss until something doesn't work right.
And in virtually all cases, it's 1 am when the errant behavior is noticed and I end up behind the computer troubleshooting in my underwear (sorry for the visual , but we've all been there).
I'm wondering if it makes sense to set up a rule that issues a refresh and/or configure on every device and have it run periodically. I don't think the hub has any mechanism to do it on its own, right? Any thoughts?
If Z-Wave, are they older 100/300 series Z-Wave (as opposed to Z-Wave Plus 500/700/800) devices? If so, this is a known issue as due to a copyright issue (w/Lutron, IIRC) 100/300 series Z-Wave devices don't update status like 500 & 700 Z-Wave Plus and later series devices do. So in some cases if your automations are depenedent on current device status on 100/300 series devices to trigger, polling the devices is the only way to be 100% sure.
There is a polling app (built-in app) you can use for this issue. But you should only use it where you need to. I would not want to have a hub-wide polling/refresh on every device on a regular basis. And if the device status isn't needed as a trigger, but needed in the guts of the automation, you can insert a Refresh on the device to ensure you have the correct current status. Also, in RL automations you can add the options to turn a switch on or off regardless of reported status.
Preferred route for many of us is to replace older 100/300 series stuff, but obviously that's not something that everyone wants to do.
i had a similar thing the other week with one of my virtual switches. i just tapped it to turn it off, and after fighting it a few times because it would turn back on again, it finally stayed off. thankfully it didn't actually turn things on or else all my lights would've turned on
I have had this issue continually with Leviton Z-wave switches I have. If I power cycle the switch, it clears up for a bit. I even used the most recent firmware on it. Those are the only two devices that I have problems with reporting correctly (usually shows "On" when it's off). I'm ready to junk those two switches and replace with something else.
Not device specific. I'm aware of the issues with older zwave devices, and older devices in general. Most everything in this house is new. Inovelli 2-1 Blue dimmers and fan switches and a lot of Hue bulbs and retrofit downlights.
The few zwave devices I brought from the old house are mostly 700 series Jasco devices. I do have a couple of old zwave bulbs that I can't bring myself to throw away because they work just fine even though they're not zwave plus devices.
BTW, the last time this happened was a day or two ago. I tried the All Off app you mentioned in another thread, but that didn't work. The switch was off but HE thought it was on, so it kept sending off commands which were obviously ignored by the switch because it was already off.
That switch was a Inovelli 2-1 Blue, which gets operated manually very often. In that particular case, I'm thinking that the binding between the switch and hub got hosed and the hub wasn't getting status updates, or the switch wasn't sending them. Configure() cleared that up. The actual configuration of the switch hasn't changed in a long time, no recent FW update to the switch, etc.
I don't think it's an issue of a device not reporting correctly. I think it's just that the actual device state gets out of sync with what the hub thinks it is.
All of my hubs are on the beta, so reboots and firmware updates are relatively frequent. It's very possible that a switch will be operated during an update or reboot, and I'm guessing the hub simply doesn't receive the updated status. Or, perhaps a device somehow loses its binding with the hub, I don't know, but a refresh and/or configure fixes things.
Whatever the reason, somehow things occasionally get out of sync. It's not a daily or even weekly occurrence. So my thought is, why not call configure() and/or refresh() periodically, rather than wait for something to get out of whack and I notice it. Does that make sense?
Yeah, if running configure cleared it up, then that's exactly what happened.
If a device binding to the hub gets cleared out for some reason, then the device will not report any changes for the cluster that was removed, whether its commanded digitally or physically.
Hubitat drivers don't clear bindings that are required for the device to report correctly.
Right, but I wouldn’t do such a rule periodically. There is, however, one situation that you could (and, in my opinion, need to) address, namely, when the hub is off for a length of time (due to orderly shutdown during a power fail, before the UPS is drained), or, as you note, during a reboot from firmware update or for some other reason.
There was extensive discussion a while back on whether the Hubitat OS could handle this automatically, but Bruce Ravenel (@bravenel) indicated (and convinced me) that this had been considered by Hubitat staff and that it was not possible to handle all the varieties of configurations and states being managed by users, and that, if desired, each user would have to develop a strategy on their own for an appropriate rule triggered by systemStart(). Mine is shown below, simply as an example. It used to have (as you discuss) a refresh() for each Ring Extender v2 repeater (I have 6) because the return-to-mains Z-Wave event is lost on power up reboot by the hub (the event is sent and dropped by the hub while rebooting). Denny Page (@dennypage) modified his excellent Ring Extender driver to schedule a delayed refresh() on startup so that the return-to-mains event was not lost. At the time he made this enhancement, the built-in Ring Extender driver had no such feature. I have not tested the built-in driver to know if this has ever been addressed in the intervening years since.
So, here is my System Start rule, simply as an example. Works for me, and it’s pretty simple and self-explanatory, I believe.
The 6 Hub Variables (Ring?-onBattery) are part of a set of power fail detection voting rules that shut down the Hub when a majority of the Ring Extenders vote that there has been a power fail. This handles failure of a single Ring Extender or having a Ring Extender accidentally be removed from an outlet, as has happened when my wife wants to use the outlet for vacuuming. Those rules have been presented elsewhere in the forum, and are not important for this discussion.
The final line in the rule initializes my rules that manage the Litter Robot, and change the color of the under-counter light strips depending on the waste level in the Litter Robot, and flash if the Litter Robot is in a fault situation or if it needs emptying. These rules have been presented elsewhere in the forum as well.
Thanks. I vaguely remember that discussion. It probably does make sense to run such a rule at startup, perhaps just calling refresh() for devices with on/off state. That probably covers the majority of times that things get out of sync. It didn't happen all that often in the past, although since the C7 to C8-Pro migration I've seen it several times now. Maybe some side effect of the migration.
, but we've all been there).
