Lessons being learned

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.

1 Like

I was with you up until the above. As @JimT says,

  • status changes are always reported
  • 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.

Status is alwaysreported. But is it SEEN? And if not seen, then the potential issue.

So far under my setup I have not missed any Sonoff status changes.

Just the fact that hardwired (after market/user or pro install) the status is always svsilable where zigbee it COULD be mussed.

Agree. No heartbeat=2 year battery. Heartbeat=change the battery every month!

Why would a status update, sent by a battery powered ZigBee device, be missed? Missed by what?

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.

I’d like to counter with my own lesson learned.

“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:

  1. when something changes report it immediately
  2. wake up periodically (relatively short period) to see if there is a request from the controller/coordinator (e.g. "give me your current status)
  3. 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:

  1. do not use restoreOnStartup on those sensors
  2. set up a rule to set the Items for the device to NULL or UNDEF when the Thing goes offline (see Thing Status Reporting [;
  3. any automation that uses those Items looks for and does something appropriate when the Items are NULL or UNDEF

This is why NULL and UNDEF exist as a state for Items. They represent the cases where the Item doesn’t have a known state.

Oh, I agree. But the point is, a single shot zigbee / zwave message could be missed and you would not know.

Hardwired? You could pole the living daylights out of everything and not care. No battery life up worry about.

Not an OH shortcoming at all. Just an observation. And one that clearly has been determined to be reliable enough by the industry to not be a concern.

It does mean I have to pay attention and not put a critical zigbee device at the limits of communication with no repeaters in between.

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

1 Like

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.

I meant literally hardwired switches (that would be a PAIN). Monitored by hardware IO that could be polled 100 times a second!

Of course - not so practical. So. Off to wireless land!

As mentioned in my last post, some devices don‘t like to be polled to frequent….

In practice it really isn’t an issue.

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.

I’d have notified something isn’t working.

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. :smiley:

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)

1 Like

What I’d like to have:

  • a way to tell for sure whether a door is actually locked or just closed.
  • a way to motorise and physically close doors and windows (safely without crushing people or things in the way)
  • and a way to activate/control the locks
  • inexpensive

As for cameras you’ll have to bite the bullet and install PoE cameras if you want to do it right.

yeah. re: cameras. I know. I can do POE cameras for power that have WiFi (which seems odd to me).

I actually agree about the LATCHED (locked) door thing. I’m actually contemplating this one a bit.