While experimenting with the KLF200 binding, I managed to get two “Bridge” things created but only one shows up in the web interface or the command line via openhab:things list.
I know there are two of these because in the log file, I see entries for velux:klf200:UID with two different UIDs.
The fact that there are two of theses makes the KLF200 behave strangely and I would like to go back to a clean state.
The question is then how do I remove a thing which is not listed in any of the interfaces?
Should I remove the binding altogether?
Check jsondb i.e. /var/lib/openhab/jsondb/org.openhab.core.thing.Thing.json if it’s really there twice.
If so (but only if !), you can edit the file. OH must be down and mind the syntax. At your own risk !
Thanks, but alas, only the expected one is there, not the ghost one.
Here is what I get in the log for the one I can’t find:
Handler VeluxBridgeHandler of thing velux:klf200:UID tried checking if channel status is linked although the handler was already disposed.
And using WireShark after having paused the accessible bridge, I still see connections attempts as often as the above line comes up in the log file. So clearly, there is something that tries to talk to the KLF, with a bogus configuration which leads to this repeated message:
velux bridge connection successfully established but login failed
As the KLF200 only ever accepts two connections on its TCP interface, this phantom one is quite annoying.
You could try console command remove orphan links, might solve your issue…
I looked around in the files in /var/lib/openhab/jsondb/ and the UID for the ghost one is inside thing_status_storage.json with the following structure:
"velux:klf200:GHOST_UID": {
"class": "java.lang.String",
"value": ""
},
And it’s the only file it is present in any of the files inside /var/lib/openhab/jsondb/
I launched this command:
openhab:links orphan list
and it gave an empty list in return, so I don’t think there are any orphans that would help me here. But thanks for the suggestion.
As it did not harm it was woth a try 
1 Like
If it’s not stored anywhere it might be that the binding keeps it in memory, a restart of the binding (or openHAB) should clean it out if that’s the case.
do you use any .things files ? If so these would count in addition to the jsondb entry.
Why did I not think of that? When in doubt, reboot!
Thanks, it sorted the situation nicely, the log is now clean from that ghost UID.
No I don’t, I’m new to OpenHAB and am trying to stick to the version3 of configuring the installlation.