Z-wave newtwork "overload"?

Tags: #<Tag:0x00007efebfb27018>

I have a group gDuskLights and the following simple rule to turn on a large number of lights when the sun sets:

rule "Sunset Rule"
when
	Channel "astro:sun:local:set#event" triggered START
then
    gDuskLights.sendCommand(ON)
end

The lights are a combination of window lamps using wall plugs (Z-wave), switches (Z-wave) and a few bulbs (Hue), all in all around 20-25 lights. From time to time, a few of the lamps (only Z-wave, never Hue) don’t turn on as they should and I’m not sure what’s causing that. My Z-wave network seems to be ok when looking at the map in HABMin and I can always turn on the failing lamps later using Basic UI or HABPanel.

So, is it a stupid idea to do it like this? Can the Z-wave network be overloaded or saturated causing messages to fail when sending a burst of commands like this?

Thanks,
Christian

  • Platform information:
    • Hardware: CPUArchitecture/RAM/storage Raspberry Pi3 with Aeotec Z-stick gen5.
    • OS: what OS is used and which version Openhabian
    • Java Runtime Environment: which java platform is used and what version
    • openHAB version: 2.5.6-2
  • Issue of the topic: please be detailed explaining your issue
  • Please post configurations (if applicable):
    • Items configuration related to the issue
    • Sitemap configuration related to the issue
    • Rules code related to the issue
    • Services configuration related to the issue
  • If logs where generated please post these here using code fences:

It does seem like you are overloading the system and commands are being lost. But I’ve mostly seen this reported with Hue so it’s interesting that it’s the Hue bulbs that are working properly.

Assuming that sending the commands too fast is the root cause of the problem, you can apply Design Pattern: Gate Keeper to limit how fast you can send the command to the zwave devices. It’s going to take some customization to it though with a proxy Item I think.

  • Split your Hue from the Zwave lights and put them into separate groups. Just sendCommand(ON) to the Hue Group.

  • Create a Zwave_Lights String Item.

  • In the rule, create a loop through the Zwave group and sendCommand with the name of the Zwave Item to Zwave_Lights.

  • Use Zwave_Lights to trigger the Gatekeeper rule which will ensure that the commands are not sent out faster than the rate that you define. Experiment with the delay between commands to make it as short as possible with no dropped commands.

1 Like

It shouldn’t - the binding will queue commands and send them one at a time. I’d suggest that getting a log would be useful to understand what is happening here.

This should not be required. As above, the ZWave binding only sends out one command at a time, and it queues any incoming commands. Such a concept to pace commands being sent to a binding cannot be guaranteed to work as it will depend on the activity on the network.

2 Likes

So THAT is the reason you wrote in the documentation how to collect DEBUG logs when things do not go as expected… :smiley:

Will do - that was the plan as the logical next step. Just wanted to check first wether this was a known/common issue.

1 Like

Ok, here is the log from today’s run. All lights turned on as they should today, but when looking into the log there are still some strange stuff going on. Not really sure what might causing the red stuff, like long response time and “rejected by controller”, and/or if this is something I need to worry about!?

The rule execution starts at 15:33:00.

2020-10-17_zwave.log