Would it be possible to add "reset" (like "refresh") to the generic sensor device handlers?
Occasionally, I have Z-Wave motion/contact sensors whose states get out of sync with those of their corresponding software devices in Hubitat. The physical devices are inactive or closed and appear—based on the lights on the devices—to have sent the appropriate Z-Wave events, but Hubitat thinks they are active/open, presumably because either the inactive/closed Z-Wave event was dropped somewhere in transmission or the race conditions within the Hubitat platform cause unintended behaviors if multiple Z-Wave events are received by the Hub within a short time. Rather than having to manually trigger new motion or open+close a door or window, I would like a way to (re)set the state of the software sensors when I know the software device state is incorrect.
Coding this is simple enough, but if I were to make my own device handlers for this, I wouldn't get the benefit of platform updates to system device handlers. And I would guess that I am not the only owner who experiences this issue from time to time. Thanks!
No, “refresh” polls the device for state, but many sensors are sleepy (battery-powered), which means the “refresh” won’t occur until the device periodically wakes up, which may be many hours later.
Why don't we fix that problem instead of putting a band-aid on it? Your sensors shouldn't be getting out of sync with Hubitat. If they are, that points to a mesh problem or a device problem of some kind.
Plus, how would you know what state to "reset" it to without polling the device? A sensor doesn't have a "normal" setting. It's a sensor. If my window is open in the summer, I don't want hubitat resetting it to closed after 8 hours if the window is still open. It's still open. This isn't a practical thing to implement.
Thanks, @M874585684875. Solving the underlying issue would be great. I agree that, in an ideal world, I wouldn't have my sensors get out of sync with Hubitat in the first place. I'm not clear whether the Z-Wave and Zigbee protocols themselves guarantee reliable transmission, but we can set that consideration aside.
Here is background information for you to help diagnose the underlying issue: I have a mesh network with 120+ Z-Wave devices, almost all of which are Z-Wave Plus and about half of which are hardwired repeaters, in a two-story 2000-square-foot house (so the mesh network has a lot of redundancy to cover not a particularly large space). I don't have any other Z-Wave hubs or devices or any baby monitor or cordless phone causing interference, and I'm not aware of any neighbors with Z-Wave devices, baby monitors, or cordless phones. The sensors in question are standard Dome motion sensors and Ecolink contact sensors, all Z-Wave Plus, all listed by the Hubitat website as officially supported devices for the platform, and all running the factory-installed default "generic" drivers. All of them have newish batteries (with levels reported above 95). I repair the network after each add/remove of a repeater, most recently yesterday p.m., and the repair doesn't surface any errors. The only apps I have on the hub are the factory-installed Amazon Echo app, Rule Machine, IFTTT integration, and Life360 integration, as well as a single third-party app, Echo Speaks. The intermittent issues were present before I installed Echo Speaks (when I had only factory-installed apps on my hub).
Please let me know if you have any suggestions about what could be causing the underlying issue or how to resolve it.
Hubitat could, for example, give a software contact sensor an "open" action and a "close" action (or a "setState" action that takes open/close as an argument), very much like what virtual sensors already have.
Sounds like you might not use the proposed feature, which is fine. For me, at least, one practical use case is that if I go out the door, close it, and lock up, but then Hubitat reminds me as I'm walking away to close the door (which, Hubitat says, is still open), I would love to have access to a "close" action (callable, for example, as a Custom Action via Rule Machine) so I could sync the software device state to the physical device state without having to open+close the door again. This would enable me to "arm" the contact sensor for security purposes after I have left and closed the door.
There is a Dome Motion sensor driver. So, if you are using the generic, that is incorrect.
How would Hubitat know that it should set the sensor to closed? How does it know the physical state if it didn't receive the message? I'm still not following how Hubitat would know the difference between a sensor that is really open and one that is really closed but it didn't receive the message.
I would contact support@hubitat.com if you are having issues with devices not reporting. Putting a manual override on a sensor is not a fix, it's a workaround and a security risk. You could accidentally cause the sensor to become unsynced instead of resyncing it. Then, you would miss a security intrusion.
You never answered my question...how would hubitat know what state to reset it in and when to reset the state of the sensor? How would it differentiate between the sensor being in the correct state and the wrong state?
The question missed the point. I'm not asking for Hubitat to know when the software state doesn't correctly reflect the physical state. That doesn't make any sense. What I'm asking is for me to be able to invoke an action to set/reset/change the state.
One example of how I would have this work is I would have Hubitat automatically (via a "Custom Action" Rule in Rule Machine) reset all motion sensors to "inactive" when Away mode is triggered. Yes, it's hypothetically possible that motion could be active at that precise moment, but I have weighed the pros and cons, and implementing a rule to reset my motion sensors automatically would cure 99.9% of my problems with out-of-sync sensors.
Assuming that we will not get (re)set for any of the built-in drivers, would it be possible to get at least a refresh option for the generic contact sensor driver?
I assume this thread will not be addressed, but in the meantime, in case anyone else is searching in the future and comes across this, I have come up with my own solution:
If a sensor that doesn't have a "refresh" capability gets out of sync with the hub, just change the driver temporarily to a "Virtual Contact Sensor", click to set the appropriate state (open/close), and then switch back to the correct device driver.
This approach should also work if any other kinds of sensors, such as motion sensors (using "Virtual Motion Sensor" or the other appropriate driver), get out of sync with the hub.
I hope this helps someone who comes looking in the future
