Bulk recreate Things after binding updates?

[mas (Markus)]

Hi,

in GitHub issue #20240 I was advised to delete and recreate the affected Things manually in the Main UI, which solved the problem.

However, I have multiple Things and recreating them manually is quite time consuming.

This situation seems to occur from time to time, especially after binding updates. I have experienced this several times already where Things had to be deleted and recreated to work properly again.

Therefore my questions:

1. Is there a way to automatically recreate multiple Things?
2. Can exported Things (YAML or DSL) be imported again?
   • There is an export option for Things
   • but I can only find an import option for Items in the Main UI

Is there a recommended approach for bulk recreation of Things after binding updates?

Thanks.

[rlkoshak (Rich Koshak)]

It all depends on why the Things need to be recreated and whether the Things are automatically created or not.

When they can be automatically discovered the process is usually remove all the Things (taking now if the UID) for that binding, manually recreate the bridge using the same ID and then rediscover all the Things. If the bridge has the same ID, all the discovered Things will too and all your links will continue to work.

If you have to do it manually exporting and then importing may or may not work but most likely it won’t work. This is because of the Things needs to be recreated it’s because something about the Things definition changed. Importing an exported definition without that change is still not going to have that change.

[mas (Markus)]

I’ve noticed that the issue described here does not work properly unless all affected Things are deleted and recreated:

useTags=true not applied in .items although bindings provide default semantic tags

This is a follow-up to a discussion in the openHAB 5.1 release thread: According to the Release Notes and documentation, bindings can provide recommended default semantic tags that can be applied using [useTags=true] in .items files. I verified that such default semantic tags are present by creating items via the UI (Astro and deCONZ bindings), where the semantic model are applied as expected. However, defining the same items in .items files using [useTags=true] does not apply semantic tags…

I tested this with a few Things: after deleting and recreating them, useTags=true is applied correctly and the default semantic tags provided by the binding are present as expected.

However, I have a large number of Things, and deleting and recreating them manually via the UI is very time-consuming.

[ErikDB (Erik)]

I read here that disabling and enabling Things de facto ‘removes’ and ‘recreates’ them…

[rlkoshak (Rich Koshak)]

If that’s true, the following two lines of JS would do the trick.

Things.getThings().forEach( (t) => t.setEnabed(false));
setTimeout(() => Things.getThings().forEach( (t) => t.setEnabled(true)), 10000); // wait ten seconds to reenable

However, if you have some Things that are already disabled this will reenable the. So we can filter those out with

const enabledThings = Things.getThings().filter(t => t.isEnabled)
                            .forEach( t => t.setEnabed(false));
setTimeout(() => enabledThings.forEach( t => t.setEnabled(true)), 10000); // wait ten seconds to reenable

[mas (Markus)]

Disabling and enabling a Thing does not actually remove and recreate it. It unloads the handler and initializes it again, so effectively it behaves like a restart of the Thing. That’s why it can help after connection issues or when a binding needs to reinitialize.

However, it is not equivalent to deleting and recreating the Thing. The UID, configuration, links, and metadata remain unchanged. If a binding update introduced structural changes (e.g., different channel or thing type definitions), a real delete and recreate may still be required for those changes to be applied properly.

So the JS approach works well as a bulk “reset”, but it’s not a full replacement for an actual remove/recreate in all scenarios.

[rlkoshak (Rich Koshak)]

@mas

So the JS approach works well as a bulk “reset”, but it’s not a full replacement for an actual remove/recreate in all scenarios.

That’s what I thought originally. I didn’t read the full thread posted by @ErikDB so, assuming what he said was true and a correct interpretation of that thread, the solution is a couple lines of code. If the Things have to be wholly recreated obviously that won’t work.

[ErikDB (Erik)]

I merely referenced what @AndrewFG stated… So disabling and te-enabling Things does in fact not destroy and recreates them?

[AndrewFG (Andrew Fiddian-Green)]

Disabling and enabling a Thing does not actually remove and recreate it. It unloads the handler and initializes it again

AFAICT there are two behaviors:

1. Disable/Enable the Thing, and editThing(): both call disable() on the thing handler and destroy that handler instance; then they create a new thing handler instance and call initialize() on that.

2. Configuration Updated: calls disable() on the thing handler instance; then it calls initialize() on that SAME instance.

I have no idea why that is so.