Kai mentioned a new feature in 4.0: Thing Upgrade
Could anybody point me to the documentation / a code sample?
This got added with openhab-core#3330.
There is also some documentation about it.
You can find some examples here:
$ find . -name instructions.xml -type f
./bundles/org.openhab.binding.anthem/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.mynice/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.meteoalerte/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.renault/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.mielecloud/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.mystrom/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.comfoair/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.netatmo/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.sleepiq/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.radiothermostat/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.electroluxair/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.sonnen/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.danfossairunit/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.zoneminder/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.avmfritz/src/main/resources/OH-INF/update/instructions.xml
./bundles/org.openhab.binding.tibber/src/main/resources/OH-INF/update/instructions.xml
2 Likes
exactly what I’m looking for 
1 Like
I see the upgrade for a specific thing type. Is it possible to upgrade a channel xxx for all things?
e.g. I want to change the typeId for humidity channels to system:xxx and this channel is relevant for a bunch of devices. Defining this per thing type would add a significant amount of redundant xml definitions
I checked https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.avmfritz/src/main/resources/OH-INF/update/instructions.xml and it already shows the problem.
channel energy is part of various devices, for each one the instruction-set needs to be duplicated
same for actual_temp and color_temp
I changed about 10 channel types to system:xxx and there are about 40 different thing types. This would create a ton of redundant definitions.
Is there also a programmatic way to handle this by the binding?
@J-N-K I see that you committed the PR, nice work. Any idea how this could made more flexible. I’m creating channels dynamically and alway use the same channel definitions.
Something like <thing-type uid=shelly:*> would reduce the overhead by 95%. This would allow to have one channel update instruction set for all thing types defined by the binding.
@J-N-K @wborn @Kai any idea? Is there a way to provide update instructions on the channel rather the thing-type level (having channel as root element)?
What’s the reason why the framework tries to find the config for 120secs, which is way to long. If there is a reason while to wait than maybe 10sec should be sufficient. Otherwise the thing stays in status NOT_READY for 2 minutes.
2023-08-01 09:23:11.202 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'shelly:shellytrv:84fd2772a53c' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-08-01 09:23:11.206 [WARN ] [core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'shelly:shellytrv:84fd2772a53c': {thing/channel=Type description shelly:targetTemp for shelly:shellytrv:84fd2772a53c:control#targetTemp not found, although we checked the presence before.}
2023-08-01 09:23:11.254 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'shelly:shelly1pm:f2753c' are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
2023-08-01 09:23:11.256 [WARN ] [core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'shelly:shelly1pm:f2753c': {thing/channel=Type description shelly:deviceTemp for shelly:shelly1pm:f2753c:device#internalTemp not found, although we checked the presence before.}
This is important for the next release.
option a) all users run into this situation and are confused
option b) I need to add a long list of update instructions, which would be 90% redundant
No, it only works on the thing-type level. I don’t think there is a safe way to implement it in any other way because the same channel name could have a different set of configuration options (channel-types) depending on the thing-type (IIRC onewire uses that for configuring different sensors but the channel name is always temperature).
10s is not enough for a system on initial startup when bindings need to be installed. In fact, even 120s could be too low. The correct solution is to implement a channel-type provider or config-description provider, so that the channel-types/config descriptions are available when the thing is initialized.
Is there a way to register a callback handler in the binding and do the update myself?