Delays with version 3.0.1.124

[Moskus]

I've been checking many of the nodes that I know are automatically reporting status, and I just noticed something about some old Aeon Labs switches: It takes forever to retrieve their settings, even though they should be communicating just fine!

EDIT: Okay, now trying to access the device properties of the roots for these devices is just timing out after I tried to open the Settings tab (on the Z-wave tab).
There's something fishy with these devices now...

[happnatious1]

There's been something fishy about these for a long time. I put one of these in a drawer about 2 years ago.

[Moskus]

There's been something fishy about these for a long time. I put one of these in a drawer about 2 years ago.

... but they have been working great up to and including Z-wave plugin version .110....

[rjh]

If you enable debug logging, cause a delay, then send me the log file, I can see what is going on.

In regards to routes, you can set a route, but the Sigma chip will probably overwrite the route when it "thinks" there is a better one.

I find that with larger networks there are too many routing options and the chip picks routes poorly. To have better control over routing, back up your interface and then restore it. That will remove all routing info. You can then optimize maybe a couple key nodes, then set the routes you want. They are more likely to stick. The chip will have far less choices. I also think over time, the routing gets messed up.

There is a command to lock routes, and this disables the chip from determining routes, but I think that's probably not a good thing to enable.

... but they have been working great up to and including Z-wave plugin version .110....

[Moskus]

If you enable debug logging, cause a delay, then send me the log file, I can see what is going on.

Will do.

Last night I spent some time individually optimizing "problem nodes", and the results were good. I also turned on logging on all Z-wave devices last night, so today I have a much clearer view of what's going on. It seems like a couple of devices are holding up, here's what's happening when I turn on the alarm.

jul-04 07:31:14	 	Z-Wave	Device: 1. etg Gang Ytterdør Lås, Notification Set to 121
jul-04 07:30:46	 	Device Control	Device: 2. etg NM-rom Ovn, Switch to Off (0) by/from: CAPI Control Handler
jul-04 07:30:46	 	Device Control	Device: 2. etg LH-rom Ovn, Switch to Off (0) by/from: CAPI Control Handler
jul-04 07:30:46	 	Device Control	Device: 2. etg Soverom Ovn, Switch to Off (0) by/from: CAPI Control Handler
jul-04 07:30:39	 	Z-Wave	Device: 1. etg Gang Ytterdør Lås, Door Lock Set to 255
jul-04 07:30:37	 	Device Control	Device: 1. etg Gang Ytterdør Lås, Door Lock to Lock (255)
jul-04 07:30:37	 	Event	Event Trigger "Automatisk (standard) Ytterdør, automatisk lås (Alarm på)"
jul-04 07:30:37	 	Z-Wave	Device: 1. etg Gang Ytterdør Status, Sensor Set to Off/Closed/No Motion
jul-04 07:30:37	 	Z-Wave	Device: 1. etg Stue RGB stort vindu Switch Red Set to OFF
jul-04 07:30:37	 	Z-Wave	Device: 1. etg Kjokken Switch Multilevel 4 Set to OFF
JUL-04 07:30:23x 	Z-Wave	Device: 1. etg Stue Ved skap, Switch Set to 0
jul-04 07:30:23	 	Z-Wave	Device: 1. etg Stue Ved piano Set to 0
JUL-04 07:30:10x 	Z-Wave	Device: 1. etg Stue Ved pipe Set to 0
jul-04 07:30:10	 	Z-Wave	Device: 1. etg Stue Ved sofa Set to 0
jul-04 07:30:10	 	Z-Wave	Device: 1. etg Kjokken Bevegelsessensor, Bevegelse Set to Off/Closed/No Motion
jul-04 07:30:08	 	Z-Wave	Device: 2. etg Gang Taklys Set to 0
jul-04 07:30:08	 	Device Control	Device: 1. etg Stue RGB stort vindu Switch All to Off (0) by/from: CAPI Control Handler
jul-04 07:30:08	 	Device Control	Device: 1. etg Stue RGB skap Switch All to Off (0) by/from: CAPI Control Handler
jul-04 07:30:08	 	Device Control	Device: 1. etg Stue Ved skap, Switch to Off (0) by/from: CAPI Control Handler
jul-04 07:30:08	 	Device Control	Device: 1. etg Stue Ved piano to Off (0) by/from: CAPI Control Handler
jul-04 07:30:08	 	Device Control	Device: 1. etg Stue Ved pipe to Off (0) by/from: CAPI Control Handler
jul-04 07:30:08	 	Device Control	Device: 1. etg Stue Ved sofa to Off (0) by/from: CAPI Control Handler
jul-04 07:30:08	 	Z-Wave	Device: 1. etg Stue Taklys Set to 0
jul-04 07:30:08	 	Z-Wave	Device: 1. etg Kjokken Taklys Set to 0
jul-04 07:30:08	 	Z-Wave	Device: 1. etg Gang Taklys yttergang Set to 0
jul-04 07:30:08	 	Z-Wave	Device: 1. etg Gang Taklys Set to 0
jul-04 07:30:08	 	Z-Wave	Device: 1. etg Toalett Taklys Set to 0
jul-04 07:30:07	 	Z-Wave	Device: 1. etg Bad Taklys Set to 0
jul-04 07:30:06	 	Device Control	Device: 2. etg LH-rom RGB, Channel All to Off (0)
jul-04 07:30:06	 	Device Control	Device: 1. etg Stue RGB skap Switch All to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Sovelys Magnus to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Sovelys Kristine to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom RGBW, All channels to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Sovelys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Blomstlampe to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Farge Kontroll to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg LH-rom Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg LH-rom Sovelys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Gjesterom Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Gang Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 1. etg Stue Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 1. etg Kjokken Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 1. etg Kjokken HDMI receiver to Off (0)
jul-04 07:30:06	 	Device Control	Device: 1. etg Gang Taklys yttergang to Off (0)
jul-04 07:30:06	 	Device Control	Device: 1. etg Gang Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 1. etg Toalett Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 1. etg Bad Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Verksted to Off (0)
jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Vaskerom to Off (0)
jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Tørkegang to Off (0)
jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 0. etg Gang Matbod to Off (0)
jul-04 07:30:06	 	Device Control	Device: 0. etg Bad Vifte to Off (0)
jul-04 07:30:06	 	Device Control	Device: 0. etg Bad Taklys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg NM-rom Sovelys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg LH-rom Sovelys to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom RGBW, All channels to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Sovelys Kristine to Off (0)
jul-04 07:30:06	 	Device Control	Device: 2. etg Soverom Sovelys Magnus to Off (0)
jul-04 07:30:06	 	Event	Event Trigger "Kontroll Alarm på"

It seems like the "Ved skap" and "Ved pipe" devices are causing delays. I've now done some more optimizing on these two nodes, we'll see if that works.

But I have a question:
What is the "notification" device for my Yale Lock? And why does it need an additional minute to be updated?

In regards to routes, you can set a route, but the Sigma chip will probably overwrite the route when it "thinks" there is a better one.

Yeah, that's exactly what it looks like to me. Thanks for the explanation.

I find that with larger networks there are too many routing options and the chip picks routes poorly. To have better control over routing, back up your interface and then restore it. That will remove all routing info. You can then optimize maybe a couple key nodes, then set the routes you want. They are more likely to stick. The chip will have far less choices. I also think over time, the routing gets messed up.

This seems "risky" to me, but I'm tempted to try it.

It really seems weird that looking in a table is actually slower than figuring out the paths each time.

And my network is a mix of new and old devices, and I thought that without a routing table that could be a problem. Care to weigh in?

There is a command to lock routes, and this disables the chip from determining routes, but I think that's probably not a good thing to enable.

I'm always for giving the users the options, but this seems like a risky move indeed...

[Moskus]

I find that with larger networks there are too many routing options and the chip picks routes poorly. To have better control over routing, back up your interface and then restore it. That will remove all routing info. You can then optimize maybe a couple key nodes, then set the routes you want. They are more likely to stick. The chip will have far less choices. I also think over time, the routing gets messed up.

WAIT! The routing table is stored in the physical controller, right? A Z-NET in my case?

I have a backup Z-NET, meaning I can try this backing up Z-NET #1 and restore it to Z-NET #2, disconnect Z-NET1, and configure Z-NET2 to use the same IP as 1 and then just restore the backup to it? Right?

Then if it does not work like I want to, I can just power down Z-NET2 and reconnect Z-NET1 again and everything should be back to normal...? Right?!

[randy]

WAIT! The routing table is stored in the physical controller, right? A Z-NET in my case?

I have a backup Z-NET, meaning I can try this backing up Z-NET #1 and restore it to Z-NET #2, disconnect Z-NET1, and configure Z-NET2 to use the same IP as 1 and then just restore the backup to it? Right?

Then if it does not work like I want to, I can just power down Z-NET2 and reconnect Z-NET1 again and everything should be back to normal...? Right?!

Yes, all of the routing and node info is stored in the nonvolatile memory of the Z-Wave controller. If you don't add or delete any Z-Wave devices while on Z-Net2, you can go back to Z-Net1 and be back where you were.

[Moskus]

Yes, all of the routing and node info is stored in the nonvolatile memory of the Z-Wave controller. If you don't add or delete any Z-Wave devices while on Z-Net2, you can go back to Z-Net1 and be back where you were.

Sorry for not reporting back, but yes I did the switch!

And Rich is right: Not having a routing table for most devices is much, MUCH faster. I've optimized a few nodes on the "edge" of the house, but most nodes are not optimized.

On average doing a full test with 10 packets took 1.7 to 2 seconds for most nodes. Some took longer. Now, the same test is done under half a second!


However, that did solve my problem. But I found that an outdoor motion sensor (Aoen Labs multisensor, but not the new one) apparently was spamming the network with motion data somehow. Changing the re-trigger time to 60 minutes did the trick.

[racerfern]

I've got the Aeotec delay down to about 8 seconds by following advice here and changing parameter 5 to "2".

However, that's still an unacceptable amount of time. I've read about eliminating routing tables and that might be part of it. I have two sensors, one within two feet of the z-net, the other across the house. The one next to the z-net is as quick as can be, the one at the opposite end, painfully slow.

I put them both next to the z-net and the one from the other side of the house is still slow. To me that indicates a defective unit or more than likely a routing issue.

How can I eliminate (as much as possible) routing that I assume is done when optimizing? Should I optimize the device while next to the z-net and then move it to its desired location? My goal is to have lights come on based on ambient lighting. The sensor will be USB powered.

Any advice is welcome. FWIW, I am now on 3.0.1.140