Improve my ZWave latency?

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?

Have you tried a heal network yet? That process helps nodes find lower latency paths back to the controller.

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.

1 Like

Presumably the locks are secure nodes, does that make a difference to the routing?
Is there an overhead in the encryption?

Latency issues in Z-Wave is not so simple to solve. There is no real ā€œGenericā€ solution to this. Things you can look at:

  1. 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)
  2. 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.
  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).
  4. 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.
  5. Devices like Locks are mandatory for encryption. You canā€™t turn it off and still expect the lock to work.
  6. 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 @sparkydave yea there are several other neighbors most are the light switches. I donā€™t have a screenshot to send at the moment.

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.

Hereā€™s an article about it.
http://thingsthataresmart.wiki/index.php?title=Beaming

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.