Bug: ZNet goes offline then HSWX300 status led lights become very slow to update

[begunfx]

Okay here's the breakdown of my setup and how I experienced the bug:

1. I have multiple ZNets and one smartstick
2. I have multiple HSWX300 Light dimmers across all interfaces.
3. I have events that trigger the LED status lights on all of these dimmers across
all of the interfaces.
4. I have events that change the LED status lights on all dimmers across all of the
interfaces.

Here's an example of my usage:
If my garage door opens, I turn LED 1 to "blinking red" on all HSWX300 Dimmers that are
located on different interfaces throughout the house.

If the garage door is closed these lights turn to solid green.

When all of the interfaces are online and working as expected, the LED status changes in
mere seconds (all of them).

Recently, I ran into an issue with my garage znet interface. It went offline and wasn't
responsive to pings or anything. After reading on the forum that it was likely a bad
microSD card. I reached out to support and they sent me a replacement.

During that time (about 2 weeks), the LED status lights would take forever to update.
Sometimes as long as 10-15 minutes. I tried resetting the Z-Wave database, rebooting
HomeSeer. Nothing worked. Remember these dimmers are on multiple interfaces so
you can't blame the behavior on just another bad one.

As soon as I got my Garage interface back up and running the LEDs are now as responsive
as they were before the interface went offline.

This cannot be a coincidence.

There seems to be some issue when running events for LED status lights across multiple
interfaces that perhaps they way the event is structured, if one of the interfaces is
not available causes the lag.

I will be posting this to support as well. Just thought the community might want to be aware of this or if anyone else has experienced this to feel free to comment.

Thanks.

[randy]

I don’t know how it could be 10-15 minutes, but I also saw delays when a controller went offline several years ago. My delays were 20-30 seconds for devices on active controllers at that time.

It is probably related to how quickly a Device responds to a command. If an interface is offline, the plug-in will have to wait for the timeout to lapse on each command. I don’t know if they are handled in parallel or serial, but I’m guessing they are handled serially. All determined by the send timeout setting. I have mine at 8 seconds, the default is 2 IIRC.

When an interface is up and a command is sent to one of its devices, the confirmation is usually in the same second. We have no unusual delays in our Z-Wave network, making that confirmation almost instantaneous. If a controller is down, the command is sent from HomeSeer, but there is no response from the device. It will timeout after 2+ seconds. Depending on how commands are issued and how the timeout is handled, there could be significant delays in the Z-Wave command queue.

I do similar things with HS-Wx200/300 devices where every one of them is changed in an event. We have just over 30 of these devices. If a controller is down, about 10 of these devices would fail.

You could likely reduce the lag if you kept or set the timeout at a minimal level, but then you have a greater risk of a complete command failure, instead of giving enough time to respond when the network has unusual latency.

[begunfx]

I don’t know how it could be 10-15 minutes, but I also saw delays when a controller went offline several years ago. My delays were 20-30 seconds for devices on active controllers at that time.

It is probably related to how quickly a Device responds to a command. If an interface is offline, the plug-in will have to wait for the timeout to lapse on each command. I don’t know if they are handled in parallel or serial, but I’m guessing they are handled serially. All determined by the send timeout setting. I have mine at 8 seconds, the default is 2 IIRC.

When an interface is up and a command is sent to one of its devices, the confirmation is usually in the same second. We have no unusual delays in our Z-Wave network, making that confirmation almost instantaneous. If a controller is down, the command is sent from HomeSeer, but there is no response from the device. It will timeout after 2+ seconds. Depending on how commands are issued and how the timeout is handled, there could be significant delays in the Z-Wave command queue.

I do similar things with HS-Wx200/300 devices where every one of them is changed in an event. We have just over 30 of these devices. If a controller is down, about 10 of these devices would fail.

You could likely reduce the lag if you kept or set the timeout at a minimal level, but then you have a greater risk of a complete command failure, instead of giving enough time to respond when the network has unusual latency.

Thanks for the response randy. I heard back from support. Sounds like this is expected behavior and it sounds like to me that commands are sent serially - which is very disappointing. I would assume if you have multiple interfaces that each interface (since they are considered discreet networks in Zwave world) would have its own queue - at the least. That way if one interface goes down, then other interfaces should not be affected by performance, but as I found out, that doesn't seem to be the case.

I agree that it would probably be riskier to reduce the timeout to a minimal level and I don't think it's worth the trade-off to potentially get command failures simply because the timeout is too short.

I wish there was a better solution or that HomeSeer would consider improving how the interfaces queue commands. If anyone else has a suggestion or ideas please feel free to speak up. All feedback is always appreciated.

[randy]

I *think* the Z-Wave command structure might be part of the problem. You should be able to test by disconnecting the Z-Net, enabling Z-Wave logging and watch how the commands are logged. It won’t solve the problem but it might be enlightening.

[TC1]

Since Z-wave doesn't have the concept of channels (like Wifi and Zigbee) any commands have to be sent sequentially or no devices would ever be reachable. Even though one might have separate Z-wave networks via multiple Z-nets, they are all in physical proximity of each other sometimes and transmitting on the same frequency. If one or more Z-nets transmit at the same time then they are interfering with each other, which will cause retries, which will create an endless cycle, etc.

Z-wave Long Range will eventually alleviate the need for multiple Z-wave transceivers to cover a given geographic region, ie, a large house/property.