Buggy - Z-wave trait/OZW software or dodgy node/s?

[stuiow]

I want some advice from you guys,

I have a gen5 z-wave network, mixture of powered, battery, meters etc.. about 90 nodes in all.

The mesh network is good, good coverage everywhere.

But i do keep getting issues where nodes die, go missing from the OZW control panel/domoticz for no reason.

I also every now and again get the situation where switch commands can take 30 seconds or fail completely.

Now, is this a trait of Z-Wave?? I have ensured i have a Gen5 only network, to allow to self heal, but i am finding it frustrating now, plus i get the misses having a moan when things don't work.

I am thinking of moving my aeotec gen5 stick over to Z-Way, any thoughts on that?

When i started to build the z-wave system, i had thought of it being pretty seamless, fast acting of responses but in reality , its nothing like that.

I have a relay that swtiches on when a door sensor is triggered so i can see my way out to the car in the morning.
Not once did it work this week, but i did get a neighbour tell me the light was on most of thursday, so it did come on, but only after i stubbed out to the car and then had driven off!
That is a Fibaro 213 relay with a NeoCoolcam door sensor, using blocky to sense the door sensor to trigger the relay on.
Do many other users find these a familiar thing to deal with?

[jake]

Yes, I have similar issues. 1 switch seems to be on, but it isn't on. Switching it off by domoticz then usually gives an error. By using the manual button on the switch, the connection is restored. Another switch that I only use for energy consumption sometimes doesn't update it's consumption. This also results in incorrect functioning of my home automation.

The mesh Network is good and both switched are fibaro.

The dead node is acting up almost every day, although it is connected to 5 other zwave devices. I searched the internet again and came across an topic on tweakers.net where a user who tried OpenHab after Domoticz. He noticed that Openhab keeps sending commands to a 'dead node', where Domoticz doesn't. Might this be a difference? A node is considered dead too quickly.

[rrozema]

Same issues using z-way.me's razberry board. I think it is domoticz or openzwave and not the hardware/devices themselves. For me it happens on fibaro 223 relays (have 2 of them both have issues at times) but it also happens with neo coolcam wall switches (have 7 of the 2ch plus 3 1ch. All have the command lost issue at times, node dead issue seems to happen on 2ch more often than on 1ch).

I did revently update the firmware on my razberry board. This did improve the responsiveness of my devices, but the lost commands and the dead nodes issues remaimed.

[jake]

I discovered that in the hardware page, zwave, controller, it is possible to choose a timeout. Standard it is 3sec. I now increased it to 30sec and see what happens.

[kimhav]

I discovered that in the hardware page, zwave, controller, it is possible to choose a timeout. Standard it is 3sec. I now increased it to 30sec and see what happens.

Did it make any difference changing the timeout?

[Dnpwwo]

I had trouble with some nodes, particularly during startup where Domoticz didn't 'see' them and sometimes sending commands failed. Fibaro nodes (I've only got a couple) were particularly troublesome.

My problem turned out to be related to the Z-Wave groups they were in. I chose a node that worked well and set all the other nodes to match (and specifically that they were all in group 1 as their first group). I did this via the Domoticz Hardware/ZWave/setup/Node Management/Networks & Groups page.

Might not help but you never know

[DutchHans]

Good morning,

I experienced similar.. z-wave delays of 30 seconds..or more.. unacceptable when PIRs are involved..I've about 35 nodes and ended up to change lua scripts to blockly which is slighty faster..

From the GUI switches work instant..but from scripts it is a problem.
Hope someone can solve this latency problem..

Regards, Hans

[rrozema]

I had trouble with some nodes, particularly during startup where Domoticz didn't 'see' them and sometimes sending commands failed. Fibaro nodes (I've only got a couple) were particularly troublesome.

My problem turned out to be related to the Z-Wave groups they were in. I chose a node that worked well and set all the other nodes to match (and specifically that they were all in group 1 as their first group). I did this via the Domoticz Hardware/ZWave/setup/Node Management/Networks & Groups page.

Might not help but you never know

The "groups" you mention are associations. All of your devices should have 1 in their first "group". This first group is the so called lifeline group. And 1 is the z-wave id of your z-wave controller. So by putting 1 in the first group for each device you tell each device to send it's reports to your z-wave controller. The meaning of the other "groups" on your list depends on the device that is listed. Some devices have one or more are "basic"-groups, meaning that if you put a device's number in that group, the device will send commands from the "basic"-command class (i.e. on and off commands) to the device with the device with that number. For example, many switch-like devices have a 2nd group that is often called the "basic" group, if you toggle the switch, an off or an on command is sent out to all devices in that "basic" group.

Most people using domoticz don't use any of the groups but the first, the life line, group. Domoticz has much more advanced techniques to have other switches and whatever devices go on and off. For that to work your controller does need to receive all notifications from all devices, so in that 1st group should be a 1 and only a 1 for your controller, and all other groups should most likely be empty.

The only reason why you should want to use the z-wave associations (a.k.a. the groups) is when you want a device to be controlled directly by some other device. For example: you have a pir device that you want to switch a light on or off, then put the light's z-wave id into the pir's basic group. This light will now go on when the pir detects motion, and the light will switch off once the pir's cooldown period has past. Two advantages are: 1 - the response to the pir is faster than when you have domoticz in between, 2 - the light still goes on, even if your domoticz is down. Two disadvantages are: 1 - the pir controls the light directly and there's no way around that: if you switch the light on manually, it will not off automatically, because the pir hasn't been triggered, so it will also not send an off command, 2 - you can not add any additional logic to the switch like for example, only switch on the light when the lux level is below some level (I know: some pir's do have that possibility built in, but not all. It's just an example of how you can't do more advanced scripting when using z-wave association).

[kimhav]

Most people using domoticz don't use any of the groups but the first, the life line, group. Domoticz has much more advanced techniques to have other switches and whatever devices go on and off. For that to work your controller does need to receive all notifications from all devices, so in that 1st group should be a 1 and only a 1 for your controller, and all other groups should most likely be empty.

Thanks for that informative explanation regarding the groups. Question though, if I look at my setup, I see that for Group 1, most of the values is set to 1 but there are several ones which points 1.1. What does that indicate or in what way does that differ to the value 1?

[rrozema]

...
Question though, if I look at my setup, I see that for Group 1, most of the values is set to 1 but there are several ones which points 1.1. What does that indicate or in what way does that differ to the value 1?

Very good question! I think this part of the Groups & Networks screen (and maybe even deeper) has a bug in either Domotiz and/or Openzwave. The "1.1" always occurs on multi channel devices, which at first sight could make sense. However I haven't been able to get my head around what exactly it indicates. I have a suspicion something has been reversed: I would expect the life line group to always show a "1" to indicate the single channel device "1" (= my controller) is being notified, both on a single channel as well as on a multi channel device. Only if some device targets a specific channel of a multi channel device I would expect to see the dot notation. f.e. I would expect to see "12.1" on a pir's basic (2nd?) group, to indicate the 1st channel of device with id 12 is triggered when the pir activates. And "12.2" to indicate channel 2 of the same device with id 12 is targeted. This is however not how it works. I have so far not been able to define an association of any (single channel) pir to notify/send commands to a multi channel device channel that is not the device's root channel.

[kimhav]

Based on what you're saying I did a quick check and the Qubino Flush 2 which has two relays are the ones which indicates 1.1.

[DutchHans]

Any progress on this latency problem?....

I am experiencing this latency for a while now... Sometimes more than 30 seconds...

Regards, Hans