I just got around to creating the dirt simple zwave panel thanks to @firstof9 for pointing me to the right direction.
I finally did it mostly since I have my august lock that is really slow. Today i pressed unlock like 3 times and the delay was so long that I decided to use the august app and open the door but then when I was inside the lock kept unlocking itself 3 times since the command finally arrived to my lock. I noticed that on this map the August lock is actually not bouncing from any other node and therefore it has such a long latency. How can I force a node to be bounced off of another node? Is this possible?
Devices will only ābounceā off other nodes if they have to. That said, you can select āall neighborsā and the graph will show all inter-device connections
Are there other devices between the August lock and the z-wave hub?
I have two Schlage locks and they have always been slow. Looking at my Z wave graph right now, they are both in the 1.5-2.5 second range. Iāve seen the farthest one (my detached garage) up to 3 or 4 seconds before. Everything else is <1 second, even a few sensors with 2 hops (in the same garage)
I have my locks setup so that if you enter a code and someone is not yet registered as home for whatever reason, it will disarm everything. Due to the delay, my family is trained to put the code in, pause for a second, then open the door.
The latency on your mains powered devices looks fine to me. Battery powered Zwave devices have always sucked. Not much you can do about that since they are technically have to wake up before they respond any queries.
Latency issues in Z-Wave is not so simple to solve. There is no real āGenericā solution to this. Things you can look at:
How āChattyā your network is. You can gauge this from how many āReceived:ā Lines appear in OZW_Log.txt per minute. If you see one device sending lots of updates when your network is fully running (not immediately after a restart), then you probably want to explore that (At best, Z-Wave can go upto 100K bandwidth, but with older non-ZW+ devices, or lots of hops, that bandwidth will drop quickly)
Look at the RTT measurements reported in the OZW_Log file for that device. Iād take commands other than Locking/Unlocking as your samples due to 3.
Older Z-Wave devices can use a old chipset that unfortunately is āslowā in encrypting/decrypting packets. You might be able to send/recieve quickly, but the MicroController than encrypts/decrypts just takes time (Iāve seen upto 2 seconds).
Heal Network should only be used when adding/removing or physically moving mains powered devices. Doing it too frequently when nothing has really changed will actually decrease performance/reliability etc.
Devices like Locks are mandatory for encryption. You canāt turn it off and still expect the lock to work.
The Cat walking by, Neighbor turning on the microwave etc all have a affect on RF Reliability etc. Sometimes just moving the Stick or pointing it in a different direction can have a drastic improvement in performance of the Network.
Hey @firstof9 I actually did try the heal network right after I posted this as I wanted to take a third or 15th look at the documentation in case I missed something. And it didnāt seem to improve anything.
I wish mine was as consistent as just pausing a moment before trying to open the door. I have experienced the worst which is the delay I mentioned above that was probably 30s even if the delay is around 2-3s I donāt often get that.
I even added another Neo Z-Wave plug in the same floor in hope the lock after a heal would choose that route and go faster but no luck.
Iām thinking the August lockās ZWave may just be slow.
Hey @daphatty I agree with you that those latency may not be much I could do however the garage tilt sensor I have is a battery powered device yet that one is very quick to wake and send itās single.
I donāt even get close, often times, to this latency events that are present there. This last time it took about a 30s to a min to open up.
Hey @Fishwaldo would you expect an improved response if I moved to a model of having ZWave2MQTT?
My current setup is the following. An unRAID desktop turned server in the third floor where the August lock is in the first floor. Itās a condo so not large footprint per floor. Mind you the garage tilt sensor is in the same first floor and that one doesnāt take long at all to ping me a notification that my garage door opened up. Granted as you said there is no encryption and decryption. I have had this setup for a long time but in general to unlock my August lock has never been reliable under zWave this time I felt like I wanted to try it again.
The following is my understanding of how Zwave devices work. Please correct me if Iām wrong
I believe the answer to your question is that you unfortunately canāt help it. There are 3 large buckets of devices. There are mains/plugged in devices that are always on and listening. There are battery powered devices that cannot be controlled. For instance motion sensors only send data they donāt get sent commands to control them outside configuration. Then there are battery powered devices that CAN be controlled. These are locks that need to be sent commands in order to lock/unlock. These such devices sleep just like other battery powered devices, but wake up very frequently (like once a second or so). Devices that are sleeping CANNOT accept commands. So to solve you sending a command while itās sleeping and the command getting lost, the command is held by a neighboring mains/plugged in device. This device then repeatedly beams the command to the lock until it wakes up and receives it. This is where the delay comes in.
Now onto ways to lower the latency. From what I said above thereās really not much you can do. 2-2.5 seconds is exactly the same latency my 2 locks also exhibit. The one thing you can do is get a mains/plugged in device installed as close to your lock as possible that has low latency. This device then should be the one holding the command and beaming it to your lock.
Just as an update. I think after some time the network has seemed to have improved its latency! I am eager to try out and see if there is any visible improvement. I will try using zwave more often again and see if I noticed the same effect I had before that I described before where there was almost mins of delay between me clicking unlock in HA on my lovelace and when it actually got picked up by the lock.
I am curious if I would notice any improvements in using a zwave2mqtt āhubā. Given I am going to use my old Rpi that i use to use for my HA instance (now that is in my server where my Zwave usb is plugged in) as a Zigbee2MQTT hub and perhaps also as a bluetooth room assistant hub as well I can always move my zwave plug there and just move over to using MQTT. However, right now I donāt want to do such an endeavor if I no longer experience such a delay as before.
Any updates on Z Wave latency here? I have a Schlage door lock and it takes ~10 seconds to respond when triggered through Home Assistant. You can say it is a āZ Waveā issue but the truth is the performance was great on SmartThings and is abysmal on Home Assistant with my Nortek stick on a Pi4. Not only is the delay unacceptable but this thing is now chewing through batteries not like never before. I am considering reconnecting the lock to my SmartThings hub and just using the integration to bridge it.
I have two Schlage locks and they have always been somewhat slow. Iāve always had to disconnect the battery and reconnect them about once a month. This was on SmartThings and now HomeAssistant.
Try to heal your Z wave network or restart it. Its also possible you another bad node somewhere acting as a hop on the way to the door lock.
Is your Schlage lock the FE599 model by any chance? I have that lock and it gives me lots of issues. I also have Schlage BE469 locks and have fewer issues with them.
I can say that my august lock z wave latency never improved. I just donāt use it with zwave. I do want to buy a zwave lock specifically but want one that is not slow and if itās slow then maybe test out zigbee locks as well.
Mine is a BE469. I just had to replace another set of batteries the other day. The battery life and the latency are still unacceptable on it. If I bought another smart lock I would probably give zigbee a try instead.
