Lessons being learned

10

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 [4.0.0.0;5.9.9.9])
  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.