Domoticz

Hi guys,

I have installed some sunscreens and control these with the TKB home TZ75 shutter relais.

Weather info, a PIR (Lux) and manual input control the screens. If I have the (Blockly) script turned on and the screens are triggered, the Zwave part of Domotics gets stuck (I say Zwave part, because the Zigate/Zigbee part of the switches keep working normally). Commands to other switches take ages to be executed. In the end, most of them are executed. If you switch a light on and of a couple of times, the queued jobs are executed as a batch (flickering light as a result).

If the script that controls the screens is turned off, after half an hour Domotics turns back to normal operation.

I've been going through the debug log, but I don't know what to look for. There are some error messages about dropping commands and data not being delivered to the Zwave stack. I also don't know how to see if a command is sent, received and executed, or queued. And if/when it's queued, see if it is actually executed later.

I would be helped if someone could tell me what the nomenclature of the messages are, to look for with these symptoms.

Thanks!

Best regards,

Tonka

I've edited the sunscreen control script.

There were some commands in it, that triggered the screens contiuously when the state of the screen was not the same as the commanded position.

So if the script (or a manual input for that matter) would command the screens to be closed and the screens reacted a bit slow, or the positioning report would report back that the screen was in transit to be closed, the script would retrigger the screens just as long until they were actually closed.

I've changed the interval for the re-trigger to 45 seconds.

Now things seem to ben normalized a bit.

Still I'm interested to know where and how I can see in the debug log the controller is queueing up.

Thanks.

Tonka

As far as I know, there is in Domoticz/openzwave no way to see if the z-wave controller's queue is full, how many entries it has or even how big it is. And you are right, overloading the z-wave controller with commands does tend to slow all z-wave traffic, resulting in exactly the symptoms you describe, so you are probably right to conclude that your repeated commands caused the issue.

Yet, I don't think it should be necessary to repeat any command, i.e. why repeat even every 45 seconds? It should be sufficient to send your open or close command once when the conditions change and then wait for that action to happen. In other words, only trigger the open/close command once, when the desired state -calculated from your sensors data- changes state.

Thanks.

I've replaced an (apparently) broken node. It was malfunctioning, but still connecting to the controller.

After the replacement I have also removed all of the repeating commands.

It seems to have cleared up some things significantly.