Since a few days my nodes are turning up dead. The controller is a Z-stick S2, the dead device are two Fibaro FGSS101 mains powered smoke detector devices and two switches. Battery powered devices are green and yellow in Habmin.
I’m running OH 1.7.1 with zwave 1.8.0
Any thoughts?
Thanks Niels
It’s hard to tell what’s happening without a log, but looking at the routing diagram, I would say your network is susceptible to problems due to the topology…
You have a lot of battery nodes, and only 2 mains nodes. Of the 2 mains nodes, the controller can only talk to one of them directly (node 12). Devices like node 5 are completely isolated (which is possibly why it’s dead!) since it can only talk to node 1 (the controller) via a battery device, and battery devices do not route - so this device can’t talk to the controller (at least not reliably).
I’ve not worked through all the routing, but the network topology doesn’t look reliable - I would look to get more mains devices so there is better connectivity amongst all devices, and specifically to ensure that there are multiple mains devices that can communicate with the controller.
This might work occasionally, but I would say is unreliable at best, and may work at different times of the day, different temperatures, when the TV is off - who knows 
… Radio propagation is not an exact science between these devices for many reasons…
Hello Chris,
There are more mains power nodes, 5 in total (controller, 2x smoke detector, 2x switch) and 3x battery powered nodes (2x multisensor, 1x radiator valve).
The funny thing is that the mains powered nodes are failing. The battery powered nodes seems to be performing normally.
How can I upload the log? I have 75MB of zwave.log, covering the period where every was fine until the moment issues started.
BR,
Niels
You can upload it to Google drive or dropbox or any such for sharing site. I will have a look on the morning and see if I can find anything.
Thanks Mahesh,
Sometimes Linux is just like Windows: All issues seem resolved after a reboot. I could not stop the OH service and decided to restart the host. I will kick the PAN06-1 into submission at some point.
How do I mark this topic as solved?
That’s normal - battery devices sleep a lot so they very seldom go DEAD as they don’t communicate often.
Ok, so you have the FGSS101 connected to the mains - can you post the XML file for these devices? Does HABmin show it’s a mains device?
On first sight Habmin just put the battery level at 100%, but when looking closer you see you cannot configure the wakeup interval anymore. The xml is below the image.
node19.xml (10.4 KB)
Interesting. It still reports the battery class, but otherwise it looks fine and the binding should treat it as a mains device…
Thanks.
@coyote when you included this device in the z-wave network, was it mains powered or battery powered?
First try was on battery, but switching it to mains powered did not change its wake up behavior. I then excluded the device and now it was included while it was mains powered, with corresponding behavior (no more wake up intervals).
Hi,
I am getting continously same message
2016-07-13 12:34:34.523 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:34.624 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:34.726 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:34.827 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:34.929 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.031 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.132 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.235 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.336 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.438 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.750 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.851 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.955 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:35.955 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 43: Sent Data was not placed on stack due to error 0. 2016-07-13 12:34:36.059 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 43: Node is DEAD. Dropping message. 2016-07-13 12:34:36.180 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:36.283 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 154: Sent Data was not placed on stack due to error 0. 2016-07-13 12:34:36.283 [ERROR] [eController$ZWaveReceiveThread] - Protocol error (CAN), resending 2016-07-13 12:34:36.389 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 154: Sent Data was not placed on stack due to error 0. 2016-07-13 12:34:41.386 [ERROR] [WaveController$ZWaveSendThread] - NODE 154: Timeout while sending message. Requeueing - 0 attempts left! 2016-07-13 12:34:41.387 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 154: Node is DEAD. Dropping message. 2016-07-13 12:34:45.485 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 154: Node is DEAD. Dropping message. 2016-07-13 12:34:47.535 [ERROR] [b.z.i.p.s.SendDataMessageClass] - NODE 154: Node is DEAD. Dropping message.
Any reason behind this…it happens generally and recovers automatically
Why it happens…?
Anybody have idea about this…?
Thanks.
Shrikant
I would advise that you enable debug logging and see what this shows. Error logs are really of no use at all for debugging.
