Issues configuring a few ZWave things

Setup, Configuration and Use Beginners
21

I am still struggling with these two Fibaro flood sensors. I had one reset and included afresh, and it worked for a day, then it would no loger reply to the NIF request, would not wake up even if triggered manually. I wanted to remove them from the controller, so I used the HABmin option, but this is what I get in the logs:

2020-05-27 10:56:38.591 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 42: Remove failed node failed as node not found
2020-05-27 10:57:17.735 [ERROR] [message.RemoveFailedNodeMessageClass] - NODE 38: Remove failed node failed as node not found

They are still showing there. Any suggestions how to proceed?

PS. I have deleted the sensor Things and I reset them again. Unfortunately, when I search for new ZWave devices, they all keep coming back, so now I have 4 phantom devices. Further, for some reason, I see Node 1 has appeared. This is strange, as it is the controller itself. Why is it finding itself as a new “Unknown device”? I now have 33, 39 (which I have had for a while), 38 (just removed), 42 (which is a replica of 33 & 39), and for some reason node 1.

2020-05-27 11:21:29.243 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 1: Device discovery could not resolve to a thingType! Manufacturer data not known.
2020-05-27 11:21:29.244 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:controller:node1' to inbox.
2020-05-27 11:21:29.259 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 31: Device discovery could not resolve to a thingType! Manufacturer data not known.
2020-05-27 11:21:29.262 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 33: Device discovery could not resolve to a thingType! Manufacturer data not known.
2020-05-27 11:21:29.263 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:controller:node33' to inbox.
2020-05-27 11:21:29.268 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 39: Device discovery could not resolve to a thingType! Manufacturer data not known.
2020-05-27 11:21:29.269 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:controller:node39' to inbox.2020-05-27 11:26:50.882 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:controller:node42' to inbox.

What is happening?

22

I have managed to download the Zensys software from Aeotec site. When it launches it actually shows as “PC Controller”. I used it to remove the 4 phantom nodes, and I will attempt adding the devices once again.

For what it is worth to others who may stumble on this thread, the ZWave stick has to have some sort of an internal database that remembers all the nodes. In other words, when you ask the binding to add new Things to the inbox, it does not add devices which are live and running but whatever it has in its internal store/database. That means the OpenHAB ZWave binding will automatically add any phantom failed devices that the stick has in its own internal database. This caused me a lot of confusion over the recent weeks, and in the past, as I thought the nodes that were popping up where new, live devices.

2 Likes
23

I ran into a similair situation.
Added a zwave thing, removed it, added it again (getting a higher node nummer).
But the removed one kept on coming back to the inbox, no matter what I tried.
Even after a factory reset, it was still in the Inbox! :thinking:

The solution I discovered is very simple:
Remove the Zwave controller from the thing menu.
Than recreate it. And there you go, the inbox was empty.
My suggestion: the binding does not contain any historical data. However, OpenHAB (via the Inbox) does!

I ran OH 2.5.12 when this happened, a few months ago.