I hat some ghost items which I could see on startup in the log to be initialized… I do nightly updates for many weeks on OH2 Snapshot… Think it happened some time back
I thought best way is to wipe MapDB 
wasn’t aware that channels do not get generated with the same name again
however find and replace solves it quickly
I assume that it is the Thing UID which changes for things that were not discovered, but manually added, is this what you mean?
If so, this should solve it, once it is implemented.
I mainly have zwave things.
when discovered in oh2 and channels get automatically populated I use this channel name to have my manual items back (zwave:aeon_zw100_00_000:15348538564:node9:sensor_binary)
e.g.:
// Sensor Arbeit Aeon Multi ZW100 --> Node 9 -> MS1
Switch MS1_Motion "Status [%s]" <corridor> (Arbeitszimmer) { channel="zwave:aeon_zw100_00_000:15348538564:node9:sensor_binary" }
Number MS1_Temp "Temperature [%.1f °C]" <temperature> (Arbeitszimmer, MS1_Chart) { channel="zwave:aeon_zw100_00_000:15348538564:node9:sensor_temperature" }
a part of that channel name is “renamed” when I deleted the mapdb and started fresh …
specifically
old: 152faff77f7 → zwave:aeon_zw100_00_000:152faff77f7:node9:sensor_temperature
new:15348538564 → zwave:aeon_zw100_00_000:15348538564:node9:sensor_temperature
changed randomly after deleting mapdb and do discovery again… not by me
Hm, when doing discovery, it should actually always create exactly the same thing UID and not generate a random number.
@chris, how do you create the Thing UID for discovery? Why does it change here?
The only part that changes is the bridge ID. This is a random value as we have no information on which to give it a ‘real’ value until after the bridge is created. We could make this manually set, but that’s the only way I can think of to make it create ‘exactly the same thing UID’.
Do you have another idea? I would love to be able to use the HomeID, but this needs to be read from the stick, so can’t happen until after the bridge is created.
How does PaperUI handle this to keep it fixed?
The bridge is anyhow NOT discovered, but created manually by the user, right?
So it is the case that I mentioned above and this issue should (literally) fix it.
Yes - if the bridge name is set, then all automatically generated things will have the same name.
but the bridge name is not set manually by the user?
the name is also automatically set when you add the serial controller … all I can do is set the port?
if I actually talk about the same
Unless you manually create the bridge in the thing file?
I will make this an option in HABmin so that it can be set manually, but I assume it’s possible now simply by putting the bridge in the thing file? (I don’t use the files, so I’m not 100% sure here as I’ve never looked at them).
well a Thing File did not exist in OH1 so I assume most migrating users will:
by 1. the bridge id was/is set automatically by the binding
Nonetheless, for anyone coming from OH1 having items and sitemap files, it is the most logical step to also add a things file, so this should be the suggested way in the documentation.
jup ok 
thanks for getting a clear view on that 
I’ve now added a manual UID setting in HABmin… (it will be in tonights build).
Probably it should not be added to the documentation, before it works 
I just tried it. In general it is fine, but the problem is that the “action configuration” does not work on things that are not in the database:
21:51:06.842 [INFO ] [ome.io.rest.core.thing.ThingResource] - Received HTTP PUT request for update configuration at 'things/zwave:serial_zstick:usb_right/config' for an unmanaged thing 'zwave:serial_zstick:usb_right'.
I guess we will have to change the REST API to let configuration updates through to the handler in any case…
I just installed OpenHAB 2.0 beta 3, and this might be a strange question but why can’t I setup certain Things? Specifically that concerns three Things: ntp.ntp.demo, astro.sun.home and yahooweather.weather.berlin. I also tried to remove the Things, but they keep being there, even if the Extension is deactivated.
I also tried in the shell with smarthome:things clear, and it says it removed them but it doesn’t. The single Things are:
yahooweather:weather:berlin (Type=Thing, Status=ONLINE, Label=Weather Information, Bridge=null)
astro:sun:home (Type=Thing, Status=ONLINE, Label=Astro sun data, Bridge=null)
ntp:ntp:demo (Type=Thing, Status=UNINITIALIZED (HANDLER_MISSING_ERROR), Label=NTP Server, Bridge=null)
Is this a bug or a misunderstanding of mine? Is there a way to wipe the whole Thing database and to start from scratch?
Best regards
Aurelio
Hello @Aurelio,
you said you installed openHAB 2 beta 3. Please work with the newest snapshot as many fixes and improvements are incorporated daily. If the bug still occurs, please create a new thread (do not reopen old threads).
Probably these are from the demo package. These items are defined in files, and therefore can not be deleted. IF you want to delete them, you need to delete the files.
Deactivating an extension won’t remove items since items are implemented outside of the extension (of course the items won’t work without the extension 
).
Hello @ThomDietrich
Thank you for the suggestion. In fact I have a Synology and used the packaged version. I would have to use Github to always have the latest version, but I don’t know Github well enough (actually I am in the Sourceforge generation 
and I would have to check what changed in the Synology version. However I’ll do my best to try that all, as I am planning to somehow contribute to OpenHAB.