Why not? What is the problem? Ive not heard any issue reported and I don’t really see why it would be wrong.
Also, the image is not Paper UI - it’s HABmin - does that also have the same problem? It would be good to understand the issue.
Why not? What is the problem? Ive not heard any issue reported and I don’t really see why it would be wrong.
Also, the image is not Paper UI - it’s HABmin - does that also have the same problem? It would be good to understand the issue.
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.
No - it’s absolutely not this at all.
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.
It is an indication of the discovery progress and that it is incomplete though.
I guess I really phrased things poorly in this thread.
I guess you meant REQUEST_NIF
.
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.
Looks close enough?
openhab> bundle:list |grep ZWave
242 x Active x 80 x 2.5.0.201911230756 x openHAB Add-ons :: Bundles :: ZWave Binding
openhab> bundle:list |grep erial
194 x Active x 80 x 3.14.0 x nrjavaserial
195 x Active x 80 x 3.15.0.OH2 x nrjavaserial
211 x Active x 80 x 0.10.0.oh240 x Eclipse SmartHome Configuration USB-Serial Discovery
212 x Active x 80 x 0.10.0.oh240 x Eclipse SmartHome Configuration USB-Serial Discovery Linux sysf Scanning
213 x Active x 80 x 0.10.0.oh240 x Eclipse SmartHome Config Serial
214 x Active x 80 x 0.10.0.oh240 x Eclipse SmartHome Serial Transport
215 x Active x 80 x 0.10.0.oh240 x Eclipse SmartHome Serial Transport for RXTX
216 x Active x 80 x 0.10.0.oh240 x Eclipse SmartHome Serial Transport extension for RXTX RFC2217
openhab> bundle:list |grep xstream
241 x Active x 80 x 1.4.7.1 x Apache ServiceMix :: Bundles :: xstream
openhab>
Mvh.
Torkil
In Paper UI everything is online where as in HABmin some devices are grey’d out with a delete button:
Mvh.
Torkil
The NAS-WR01ZE nodes are all on the same firmware version? Or are the running ones different from the not running ones?
Seems different versions. The ones not running pr HABmin are version 2.32 where as it doesn’t say for the others:
Mvh.
Torkil
Something is not right here. I am running 2.5 Milestone 5
& database item 1014
in the PaperUI shows
ManufacturerRef 0100:1027,0200:1027
, different than shown above on a snapshot binding?
Not sure what the implications are but I tried removing and re-adding all the 2.32 ones and that seems to have solved the problem for all but one of them, which is detected as an unknown device.
Mvh.
Torkil
Ah the fun. I restarted openhab to see if that would fix the unknown device and now I am unable to even discover it.
I had a spare unboxed device so I powered that on and that can be discovered, but also as unknown device:
Here’s the attributes from a similar device with firmware 3.94 which works:
So why can I no longer detect node 11 and why did it come up as unknown device before rebooting? The latter also applies to the spare plug.
Mvh.
Torkil
I restarted openhab to see if that would fix the unknown device and now I am unable to even discover it.
The node formerly know as 11 and going missing was now detected as a new node 20 after a factory reset on the physical device:
I also managed to lose one of the ghost devices along the way, so now just one left.
Thanks guys.
Mvh.
Torkil
Something is not right here.
I guess this is related to:
Thx, I looked through my emails and found: A user request on 2019/09/26 to change firmware versions: { "database_id": 1014, "label": "NAS-WR01ZE", "manufacturer_name": "Shenzhen Neo Electronics Co., Ltd", "manufacturer_id": "0258", "device_ref": [ "0100:1027", "0200:1027" ], old: "version_min": 2.32, new: "version_min": 2.21, "version_max": 2.32, which you reverted during approval to { "database_id": 1014, "label": "NAS-WR01ZE", …
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.
Still got the one ghost device I can’t get rid of, any new solutions come to mind?
This is what I get when I do fail + remove:
Jan 8 11:39:07 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Configuration update set action_failed to true (Boolean)
Jan 8 11:39:07 openhab zwave [DEBUG] [essage.ReplaceFailedNodeMessageClass] NODE 2: Marking node as having failed.
Jan 8 11:39:07 openhab zwave [DEBUG] [rialmessage.IsFailedNodeMessageClass] NODE 2: Requesting IsFailedNode status from controller.
Jan 8 11:39:07 openhab zwave [ERROR] [essage.ReplaceFailedNodeMessageClass] NODE 2: Replace failed node failed as node is functioning!
Jan 8 11:39:07 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Got an event from Z-Wave network: ZWaveNetworkEvent
Jan 8 11:39:07 openhab zwave [ERROR] [essage.ReplaceFailedNodeMessageClass] NODE 2: Replace failed node failed as node is functioning!
Jan 8 11:39:07 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Got an event from Z-Wave network: ZWaveNetworkEvent
Jan 8 11:39:07 openhab zwave [ERROR] [essage.ReplaceFailedNodeMessageClass] NODE 2: Replace failed node failed as node is functioning!
Jan 8 11:39:07 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Got an event from Z-Wave network: ZWaveNetworkEvent
Jan 8 11:39:07 openhab zwave [DEBUG] [rialmessage.IsFailedNodeMessageClass] NODE 2: Is currently marked as healthy by the controller
Jan 8 11:39:48 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Configuration update received
Jan 8 11:39:48 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Configuration update set action_remove to true (Boolean)
Jan 8 11:39:48 openhab zwave [DEBUG] [message.RemoveFailedNodeMessageClass] NODE 2: Marking node as having failed.
Jan 8 11:39:48 openhab zwave [ERROR] [message.RemoveFailedNodeMessageClass] NODE 2: Remove failed node failed as node not found
Jan 8 11:39:48 openhab zwave [DEBUG] [ding.zwave.handler.ZWaveThingHandler] NODE 2: Got an event from Z-Wave network: ZWaveNetworkEvent
Mvh.
Torkil