It’s been an interesting journey so far. And much frustration, nothing to do with openhab.
Cameras are either -
1- not very globally compatible supporting a lot of “open source” options. Actually a lot still require their site to start setup.
2- best options are things like Ring etc which are package systems, but intentionally not incredibly “open” with no guarantee they don’t cut you off. With a lot of dependence on their company. And they don’t REALLY want you oprnHABbing their stuff. They lose the monthly $$
A surprise dirty little secret.
> Update: after much discussion here and digging in the ZB spec, there are requirements for retries and acknowledgements. I have responded with a note later in the chain referencing the Zigbee Spec.
My Sonos door contacts send status change immediately, and a VERY long period status update. Why? To not kill batteries. Actually makes sense. But…
This means that the dirty little secret is that even pro installed alarms, unless fully hardwired suffer the same restrictions. They have to. Otherwise you replace batteries monthly. Even the pro systems could easily miss the one and only status change and guess what? You don’t know that your door or window has been opened. (I’m guessing polling every 60 seconds will kill batteries left and right).
At least open items like Sonos and many others aren’t unique with this.
Doesn’t necessarily stop me. But it means this is not simple “buy cameras and sensors off shelf”, integrate, and have a system up and running.
There seems to be only a couple of open source openHAB type systems out there. I’m really surprised nobody actually makes hardware (cameras, thermostats) intentionally target to general connectivity use.
I haven’t noticed my battery powered xiaomi zigbee contact sensor ever missing an open / closed event. Sure it may not send status updates when nothing had changed, but if something did change, it will send a message.
telemetry/heartbeat updates only when required/configured
(Of course if the batteries have died then you’re getting nothing, but hopefully the telemetry updates include battery status so there should be a fair amount of advanced warning…)
Just don’t use security devices that don’t support a heartbeat. Then it’s simple: no heartbeat => device is dead. The more ‘intelligent’ a device is, the less sure you can be about its health.
Others here have mentioned having the issue. I have not (yet). But, since there is not “I got your message” handshake, it would be possible to not see a status change. Near the limits of signal for instance?
But this would be something to be implemented in the device and available via API. Otherwise, this would be useless, as the device would not know what to do with such a message.
“Don’t try to solve problems you’ve not confirmed you are actually having.”
You will forever be chasing stuff like this in this problem space. There is no end to very complex reliability and fault tolerance problems you can invent and try to solve. But this is home automation, not a safety critical subsystem where lives are at risk if it fails (if you are using OH for that, please don’t). Good enough is almost always good enough.
Also, the problem is likely not as bad as you think. My understanding of how Zwave/Zigbee battery devices operate is as follows:
when something changes report it immediately
wake up periodically (relatively short period) to see if there is a request from the controller/coordinator (e.g. "give me your current status)
very slow and periodic heartbeat of some sort
If OH/coordinator happened to be offline when 1 occurred (the only case where the message would have been lost in a properly configured mesh) the coordinator sends out the message “hey, give me your current status” so within a few minutes, OH will get the current status of the sensor.
Note: The above is based on observation and deduction, not from studying the spec so I could have something wrong).
So you are much better off making sure you have a solid Zigbee mesh so no messages are lost due to networking/signal strength/interference and making sure your automations are robust and can recognize and behave appropriately in cases where we cannot know what state the device is in.
How to do the latter? If depends on the automation and the nature of the sensors and such. One example is:
Not really, not with those wireless protocols like WiFi, Zigbee, and Zwave (probably Thread too given how much it’s based on Zigbee). If you poll too fast you can overwhelm the mesh network and cause messages to be dropped/lost. TANSTAAFL
This is not limited to battery operated devices.
Even mains powered ones using broadcast type of protocol could send a message to be missed. ISM8 adapter for my Wolf heating is a good (bad) example. The device is built into the heating system and therefore always on.
But it just sends UDP messages for state updates. So you will never know when the last valid message arrived unless you check manually.
If you have devices at the edge of signal/network reach, then your network needs improving. Add more repeaters to strengthen the mesh. Don’t have a system where some of the members of your network is on marginal signal level constantly at risk of falling out of the network. This is regardless of whether it’s a battery or hardwired device.
Now that the reliability due to weak/ signal loss is addressed, the only issue is when the status update was sent while openhab is down.
Since I use zigbee2mqtt, it and the mqttbroker will retain that message / status for me. What if the mqtt broker is down? When zigbee2mqtt reconnects I believe it will refresh the status from all devices. I haven’t paid too close attention to this since everything works fine for me.
It APPEARS that even if my system is down and I restart OH, even the door switches will “go online” after about 15 minutes without a state change which implies someone may be asking for a “startup” status.
And, I agree. If I’m missing messages due to my own ineptness of trying to track the status of the zigbee door sensors from 250’ away? I probably need to be rethinking my hobby.
As noted earlier. I only commented that it was interesting of what COULD happen (but has not to me) and that was only triggered by a few users mentioning problems that they had.
And no WAY am I adding physical mechanical switches around the house to monitor! Kind of defeats this whole thing!
LOL. Guess I still didn’t phrase that well. Physical MECHANICAL hardwired switches - no wifi, not z-anything, no protocols. Just a bunch of mechanical switches hardwired to an I/O port that constantly monitors.
Reliable? Well, as nobody cuts a wire I guess. Realistic? Now way!
BTW - semi-unrelated. This is why I’m frustrated a bit with the camera side. I understand a lot more. But, realistically, I need at least a hardwire power camera so it can stay live and not worry about battery. And that is not easy in a manufactured home. No basement. The bottom “belly” is sealed and very difficult to crawl under and repair holes I put in the lining. (I have 115VAC outside - so I’m going powered, but Wifi)
