The motion sensor was one of my first devices sitting unused for almost a year. I now wanted to use it for something but for some reason there we no events and nothing in the zwave debug log. I removed and re-added it a couple times to no avail but suddenly it showed up with a different device id. Adding it with the new id worked like a charm but it keeps turning up as the old device id also, which doesn’t work.
The same goes for the plug which out of the packaging showed up just fine but no events. Re-added a couple times, suddenly showed up with a new id and works fine, but also keeps turning up as the old id.
If I add them it looks like this in the debug log, but no further communication:
root@kvm:~# tail -f /tank/syslog/192.168.40.120/zwave.log | grep node2
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] Initializing ZWave thing handler zwave:device:071de70e:node2.
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising cmd channel zwave:device:071de70e:node2:sensor_binary for OnOffType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:sensor_binary for OnOffType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:sensor_binary for OnOffType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising cmd channel zwave:device:071de70e:node2:sensor_temperature for QuantityType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:sensor_temperature for QuantityType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising cmd channel zwave:device:071de70e:node2:sensor_seismicintensity for DecimalType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:sensor_seismicintensity for DecimalType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising cmd channel zwave:device:071de70e:node2:sensor_luminance for DecimalType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:sensor_luminance for DecimalType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising cmd channel zwave:device:071de70e:node2:alarm_motion for OnOffType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:alarm_motion for OnOffType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising cmd channel zwave:device:071de70e:node2:alarm_tamper for OnOffType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:alarm_tamper for OnOffType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising cmd channel zwave:device:071de70e:node2:battery-level for PercentType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:battery-level for PercentType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising cmd channel zwave:device:071de70e:node2:alarm_general for OnOffType
Nov 24 21:58:19 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Initialising state channel zwave:device:071de70e:node2:alarm_general
Use HABmin advanced settings, set the node to failed, then remove it from the controller, or if that does not work search the forum for how to use the Zensys tool.
Neither failing the nodes nor removing them from the controller has any effect. One stays green and the other is not communicating.
Using a Windows tool is not really an option, but I saw in another thread that Chris was looking at getting the binding to mirror the commands the Zensys tools send, so I guess I’ll just wait until that hopefully starts working.
The commands the binding sends to remove the node should be the same as used in the Zensys tool - I think we confirmed that a long time ago. The only difference is that the Zensys tool sends a NOP (ie a ping) and the controller will mark the device as failed if the device doesn’t respond. The binding sends a ping (NOP) to all non-battery devices on startup, so this should also have put the device into the failed list, replicating what the Zensys tool does.
That made no difference, node2 still looks all fine in HABmin and node14 is not communicating with the controller. Neither responds in any way to heal, fail or remove from controller judging by the zwave debug log. Any suggestions on how to debug further?
Also half my devices are now greyed out in HABmin with a delete button showing. They seem fine in Paper UI and events are flowing. What’s that about?
That device you highlighted says it is not communicating with the controller.
This usually means the device is not connected to the network. Sometimes unplugging it and plugging it back in helps. I have a couple of those plugs periodically going offline like that.
It does not report the z-wave status like REQUEST_INF when a device is not fully discovered, for example.
I need to use HABmin to see the status if I miss it in the logs.
Does it need to? The main states are ONLINE/OFFLINE. States such as you mention here are internal progress during the interrogation and not related to the state of the device at all.
It is the state of communication between the device & binding. I likely use that more than most people.
I believe I have seen the Paper UI say a device was online when HABmin reports correctly. I assumed that was due to the deprecated Paper UI development.
It is solely an internal state that the binding uses to sequence the interrogation. It will NOT stop ongoing communications between the device and the binding.
Yes, that’s finally something that is correct . Does that matter though? It’s not the device status, and it does not prevent the device working at all. It’s simply an internal state that users should not need to worry about and is one of the reasons that I prefer not to provide this sort of information to users, as it’s often misunderstood.
