There is a section in the binding docs that explains this.
No - this should (I think) work ok. The error clearly states though that the reason for not allowing the update is the controller is an “unmanaged thing” which indicates that the system thinks it is configured through files.
Why could that be? The only other reference to zwave that I have in files is in the addons.cfg where I have listed zwave on the binding= line as per the OH1 to OH2 migration guide. Should I remove it from there and install the binding via the UI? Will it lose my things?
I’m not sure.
Just to be clear - you added the controller using the UI as well, and didn’t define this in a things file?
Oh dear—no. I have added the controller in a .things file because I had to enter the rfc2217:// port, which, at the time, I could not create in the UI. Does it mean I should get rid of the .things entry for the controller and add it in the UI (hopefully rfc2217 is allowed now)?
Will I lose all my already configured Things that used the controller as its ZWave bridge?
Up to you, but that’s the cause of the error, so if you want to change something in the controller, you will need to change this.
I don’t think so.
I have removed the ZWave stick from the Things file, and I have added it using the UI, giving it the same device ID as it had before. I am glad to say that it is working and I have not lost any of my ZWave devices. Also, just as you explained @chris, I now have access to some ZWave functions in the UI that I could not access before. Unfortunately, they did not help me resolve the 3 outstanding issues.
First of all, I still cannot see the ZWave map in HABmin. The screen is blank as per screenshot above.
Secondly, I still can neither remove, add, include, exclude or reset the Fibaro flood sensor, device ID 39. I have turned on logging as per documentation, and then, using your log viewer, I can see this:
Finally, regarding my phantom device 33, which may be the same one or not, this is what I see in the log:
Any suggestions at all? Many thanks.
Both the logs you show here are exactly the same, and for node 33 so I’m a little confused - sorry.
That is exactly the issue I am trying to troubleshoot. Device 33 is a “phantom” I think of another device, I suspect, of 39. I do not understand why it shows up as the only physical device that I have that is not associated with anything working is, indeed, device 39, the Fibaro flood sensor.
What I am hoping to do is to remove them both (33 and 39) from the configuration memory, do a full factory reset (again) on the sensor, then include it normally. Where I am stuck is that I am unable to remove them… I suppose this is my misunderstanding of how things work in ZWave. Are those two IDs coming from the physical devices, or is it possible that they are somehow in the ZWave controller’s database? Is there a way to see what is in the database? And is it possible to see those device actual addresses?
Ok, sorry, but I’m confused… The two logs are EXACTLY the same - ie same node, at the same time - they are exactly the same image.
I don’t really know what you mean here. If you are receiving node 33 messages, then node 33 exists. If you’re not receiving node 39 messages, then I’d suggest it doesn’t exist.
If you reset the devices, then they will stop sending data. You will then need to remove them from the controller using either HABmin or the Silabs controller tools. The device must not be working for this to work - if the device is still sending data, you cannot simply delete it from the controller and you will instead need to exclude it using the exclude option in HABmin.
Again, I’m a bit confused as I only see node 33 here, but in any case, this log entry above is generated by a device.
What database? You mean the list of nodes in the network - the binding logs this on startup.
The binding should log this on startup
They are exactly the same, except for the node ID—I have highlighted it in this screenshot:
I suppose the only way I can do it is by adding them as a Thing (even though they will not respond to any of the NIF requests etc) and then to use HABmin to “remove” them from the controller?
Any ideas as to why I cannot see the ZWave network map?
Many thanks for your help, @chris.
Sorry - I missed that there were a few milliseconds difference here. I’ve no real expanation of that.
There’s no real database - the binding simply reports what nodes are in the network - the binding logs this on startup (as mentioned above), but it is just the node number - there’s no way to know if there are any duplicates. Did you check the logs as mentioned?
Not really - maybe the neighbours aren’t updated, or maybe there’s a browser problem - hard to say without more information.
Thank you. For what it is worth, having done a factory reset of device 39 (the Fibaro flood sensor) I have been able to add it to the network. It now has ID 42 and I am happy to report that it works well. However, if I search for new things using the ZWave binding (Paper UI/Inbox/+/ZWave/wait a little) I can see that both id 33 and 39 come back to it. How is that possible? They are all the same device, which now has id of 42, so how come 33 and 39 are showing up? This makes me think that there is some internal database, perhaps inside the controller (Aeotec Gen5) that brings them up. Is that possible? You mentioned SiLabs as a source of tool I could use to dig into that—what should I install to try?
Basically, I am wondering if the stick is in a confused state having been moved from a working (but old) OH1 to OH2. Will I need to reset the stick and reinclude all devices to clean it up? That would be painful. 
Thank you, @chris, for your continued patience with my questions. A couple more on their way…
Oh, I just checked both in Safari and in Firefox and there are no page errors in the Console and other dev tools when I access the network viewer. Still no viewer, as also mentioned in this new thread: ZWave: No Map and a Queue Full Message
If you reset the device, and re-include it, it will be allocated a new ID. This is perfectly normal and your stick is not in a confused state. I think I’ve mentioned this earlier, but you need to remove these nodes either using HABmin or the the Silabs controller software.
The stick is not confused - it’s just the way that ZWave works. You don’t need to reset the stick.
Thank you, again, @chris. I have tried removing them, but I fail to do that. I tried adding them as a Thing—they remain in the Unknown state, by the way—and then I used the “Remove from controller” option in HABmin, but that did not remove them. Is there another way of removing them? Sorry to be asking for so much help… As for Silabs: is it the “ZWave PC Programmer” that I need?
No - it’s ZWave PC Controller. I’m not 100% sure but I think it’s only available through Simplicity Studio.
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?
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.
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! 
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.