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:
- 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:
- do not use restoreOnStartup on those sensors
- 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;4.9.9.9])
- 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. 
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.
I have Kwickset 910 (I think) deadbolts which support both Zigbee and Zwave (though I mainly use that to monitor the batteries), I’m using them as Zwave as at the time that’s all I had). And the previous owners of this house had an alarm system and when they left all they did was pull the central panel but left the reed and vibration sensors in place.
So I can tell from the reed sensor on the door whether it’s open or closed and from the deadbolt whether it’s locked or not. I even published a list Item widget to combine the two into one widget.
It works great, especially since we use the setting that causes it to automatically lock after 30 seconds. So even if the deadbolt didn’t report it’s locked/unlocked state, I could assume no more than 30 seconds after the door changes state (opened or closed) the deadbolt will become locked.
The deadbolt is ugly to be sure and the fact that each button represents two numbers drastically reduces the actual number of combinations to a pitiful 1024 possible combinations (assuming 4 digit codes) as opposed to the proper 1048576 possible combinations if each number had it’s own button. But there are other better options and we have other mitigations (e.g. the previous owners of our house were also paranoid, each exterior door has two deadbolts, cameras at the doors which will tell us if someone is trying to brute force the lock, etc.).
I’d stay away from the BT ones like August which tend not to be all that secure but both Zwave and Zigbee should be safe enough (you have to consider your personal threat situation though, I live in a relatively safe area of a relatively safe city, YMMV). If you have a smart lock and a contact sensor you can know if the door is both closed and locked.
Lots of good advice.
One thing I did not see mentioned related to your “missing” message concern is that Zwave and Zigbee protocols require that the device sending the message get back an “ACK” from the target. If it is not received, the device will send the message again (and again).
In general (using a zniffer) I have observed that after a couple of tries on the last working route the device will send the message at a slower speed, after a couple more tries it will send the message on another path, then another path, etc. If the message is coming from OH it will resend the message three times and each time the controller will basically flood the network for 5 seconds looking for a ACK. You do have to be watch for dead (or asleep) battery nodes, but the binding will also mark a powered node “DEAD” after three tries of 5 seconds across various speeds and routes.
Also as noted above by several posters battery devices are asleep most of the time, but still send messages based on their function (motion, light, humidity etc) at intervals, when detected or when exceeding a threshhold depending on how you set the parameters. Again those need to be ACK’ed by the controller. I generally set the battery wake at 86400 seconds to get a daily battery reading and save battery life (generally year plus for me).
Lastly a typical zwave (i believe Zigbee is about the same) message is maybe 10-15 bytes and the radio runs at 40K or 100K, a single hop message could be sent and Ack’ed in under 10ms.
So, there IS an ack!!! Resolved!
Thanks!
I did some digging, and sure enough.
ZigBee Document 05-3474-21
August 5, 2015
There is a retry sequence and acknowledgement specification. Acknowledgement is End-to-End and hop-to-hop along the way. This would seem to indicate that those who have had issues with missed messages (I have not had any) are either too far with no repeater, or in an extremely noisy RF environment.
A properly designed and laid out system should not have issues with lost messages. (Other than the coordinator or, in our case, OH being down during a status update)
I didn’t look up Z Wave, but the assumption is that it is very similar.
Related to the camera discussion this is old information but in 2019 years ago I bought 4 Reolink POE cameras (RLC-420-5MP). They were ONVIF, had IR for night, elementary motion detection (via a FTP picture), an SD card slot, but no PTZ. Also bought an Rpi4 2GB with an attached SS memory (60 GB) and installed OH and the IPcamera binding (very early version - binding has far greater capability now). No connections outside of my local LAN required for setup or operation, but I did download the Reolink app. Initially used the FTP binding for motion, but with that generation of camera too many false alarms (like passing clouds). Added 4 Zooz Zwave motion detectors (two on USB, two on battery) to trigger 10 seconds of snapshots (.gif) when motion is detected. Also lights go on at night with motion. Still use it today. Capture a lot of wildlife (local bobcat).
Can also extract a higher quality video with needed.
I assume that essentially motion detection does a “this pic vs that pic compare” and if they are the same, no motion. But if there is a difference, something is going on?
I was indeed wondering about doing my own triggering like you mention as well.
Where is video stored?
For a $40 camera 4+ years ago, I think there was some sort of % pixel changed, hence the problem with clouds. Now I believe there are much more sophisticated algorithms. You could always add a separate motion device later, if you don’t like what the camera is doing.
The 10 second snippets are about 1MB and are stored on the SSdrive connected to the Pi via an USB3 dongle. I periodically weed out the uninteresting ones and every 6 months or so more the old ones to a PC.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.