Earlier this week I installed a Jasco 45609 Switch with my GEN5 stick controller. The controller was able to pick up the switch and everything was fine. This morning I checked OH and saw
“Node is not communicating with the controller”
When seeing that alert I expected to not be able to control the switch, yet I am able to control through OH, and ALEXA.
What should be the plan of attack?
I had several nodes behave like this in the past. My problem ended up being a sparse mesh network where only one mains powered device was able to see the controller directly. That node became a bottleneck and was unable to handle relaying the messages for the rest of the nodes by itself. I purchased a repeater which gave every node at least two paths to the controller and the described behavior stopped.
Thanks for the insight. I just found it very strange that the network would report it inaccessible yet I can still control it. Isn’t that a conflict?
What version of the binding are you using? Can you post a log of what these messages are exactly please.
I look to be using version 2.0.0
From the log files I see:
017-05-11 00:19:46.739 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-05-11 00:19:51.742 [ERROR] [ing.zwave.handler.ZWaveSerialHandler] - Got I/O exception Input/output error in writeArray during sending. exiting thread.
2017-05-11 00:19:51.742 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 2: Timeout while sending message. Requeueing - 2 attempts left!
2017-05-11 00:19:51.742 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 2: Node is DEAD. Dropping message.
Appreciate any assistance. I still can control the switch via OH and via Alexa
Squid
This looks to be an internal DEAD status and in this case the binding will still attempt to send a command to the device. Otherwise there would be no way to find out if it came alive again - ie no means of recovery.
I thought devices become “Dead” when the receiver no longer receives messages and then can come alive once signal range improves or signal path is restored.
Is this not the case?
Yes, that’s the case. This is why we send the message.
Because if you don’t send a message to the device, how do you know if it’s recovered? Eg. if I don’t send a message to the device, then it doesn’t send a message back, and we have no recovery in many cases…
This isn’t true of every device of course - eg sensors will send occasional messages so they can recover, but for many devices we don’t get a response until we send a request.
Am I not sending a “request” when I use OH to turn the switch ON or OFF?
Yes 
. This is the point - the binding continues to send requests to a device even when it is considered DEAD. Isn’t this what you were originally asking?
I’m confused now…
You asked why the device continues to be controllable even when the binding thinks it’s dead.
I answered that this is because if we don’t send the device a message, we would never know if it comes alive again. By this, I mean that if the device goes dead, and we didn’t try to communicate with it again, then it would effectively remain dead. This is in fact what some controllers do (eg OZW), but in OH I decided it was better to continue to send messages in the hope that the device would come alive again.
Does that explain things? I’m not really sure what you are asking now - sorry.
So (trying not to confuse things any more) I was curious why a switch would be considered DEAD when it is still controllable. It would seem to me that if an item is DEAD you would not have control of it. Since I have control of it, I would assume it’s not DEAD.
So I’m assuming (and this could be part of the issue) is that OH thinks it’s dead because it has not received a message back from it.
The switch and the USB stick are somewhat far apart so that could be part of the issue. I plan on adding some additional ZWAVE devices which should hopefully provide better coverage in the house.
So if my ZWAVE network becomes more stable is it possible this switch may rejoin the living? Is there anything I need to do to allow OH to see it again or will OH remove the DEAD designation once it has better signal path?
Thanks for your patience.
Squid
Yes - a switch initially might go dead because the stick doesn’t get a response to a request - this is what you showed in the log above. At this point, we could just say “goodbye” to this switch and never talk to it again, but we don’t - if you try and control it later, we still send the request. If the device is right on the edge of coverage, then next time it might respond, and as you say, we can then assume it isn’t dead - in this instance, the DEAD status should automatically be removed when the device responds to this subsequent request.
I hope that makes sense 
.