forum

Hi,

This question are pointed to PoltoS as I saw his comments on dead nodes here before.

I am really annoyed about the z-wave/way(?) handling of non responsive Nodes after it gets the status "Dead". A device can be gone just because a power loss and after x-time it get's status "Dead", presume it's dead if you like however in most cases a device is just temporary unresponsive due to power failure.

I read from an old post you have written that Dead Nodes are after certain time only re-checked "once a day". This rare check up's are because "not to block useful traffic"...

Well, in my point of view it is very important traffic to try restore communication with a node. So the method to wait for x-hours or x-days are not good enough. Making your way to the device (could be placed anyware) and push buttons can be difficult... removing an wall switch for example - No No! Or Restarting the whole Z-Wave controller/application? No something is wrong here! ...almost as bad alternative, not a beautiful method either, both alternatives are user hands on demanding alternatives.

So, cant you let the user decide how often a dead node should be checked? it's only the user that can say if searching for non responsive/dead nodes are high or low in priority. Or shorten the longest time for re-check to once an hour? I think the present method is stupid, it could be a much smarter way of dealing with it. As said if checking dead nodes every hour would not cause any noticeable traffic, and even if there is many dead nodes would not cause any noticeable traffic compared to data from normal state devices.

The dead Node thing in Z-Wave/Way(?) makes the system not qualified for the professional users!

Kind regards,
Ricard

I think, just calling some sort of "refresh" command to a device should try to communicate with it and may be enough for a user. I think the "automatic" way of checking for a dead node is correct. Once a day is probably enough.

For my part, I have two RGB buld from Aeotec. Most of the time, the switch is turned off. Of course, they may be considered as "dead" because they don't communicate. But, I'm able to turn the wall switch on, my bulb turn on and when I ask for a color change thru the UI, it works... okay, it is delayed the first time but once communication is re-establish, it works great.

You must consider the way "Z-Wave" is thinking of dead node too. Z-Way isn't alone in this process...

The way Z-Wave consider dead node is based on "power consumption" a retrying to connect to a dead node, like a power off bulb, can be power expensive and we are in a "eco-power" environnement.

Anyway, I think automatic retry must be long timed but the user may initiate a "manual retry".

I would like to hear other's opinion on this.

Thanks

Hi DomotikQuebec, all,

The only reason for my concerns is that by RaZberry(?) considered "dead nodes" (regardless of the node manufacture as far I seen) are impossible to wake up prior the Z-Wave(?) unknown x-minutes, hours, days, weeks, month delay, except manually restarting the Raspberry Pi. Actually I never seen a dead node come to live again by itself, but it's probably because I only waited for some hours before restarting the Pi.

DomotikQuebec you are controlling lamp bulbs as you describe. I'm using the system also to control critical functions in my villa, heating, blinds etc.., and in this situation waiting for days anyone understand is not acceptable, especially winter -25 C night... .

However as usual this forum experts(?) don't show any interest in their customers... So I will try get in contact with Sigma Designs (owner of ZWave) and hear if it's really meant to work this way.

Best regards,
Ricard

I wonder why you are getting dead node in the first place ?
Is it always the same node ?

Solution 1.
You can easily program a module to assign some node as "critical" and force communication retries more frequently for those.

For the heating, usually, you set the set-point of the thermostat.
It is risky to set the thermostat to OFF instead of setting the set-point to 15°C for example.
If you use a low set-point, you can have a failed node and won't risk "freezing damage" to your villa.
This technique is called "Failed-safe".