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