Bindings migration to use AbstractStorageBasedTypeProvider

[lolodomo]

Some bindings implementing dynamic thing types, channel types or channel group types are now initialized with a delay of 2 minutes. The thing status is UNINITIALIZED/NOT_YET_READY during this delay. After this delay, you got these warning in logs and the thing finally goes ONLINE:

20:25:31.807 [INFO ] [org.openhab.core.Activator           ] - Starting openHAB 4.0.0 (build Build #3453)

20:25:47.197 [INFO ] [re.automation.internal.RuleEngineImpl] - Rule engine started.

20:27:44.279 [WARN ] [.core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'remoteopenhab:server:prod' 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.
20:27:44.290 [WARN ] [.core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'remoteopenhab:server:prod': {thing/channel=Type description remoteopenhab:itemString1 for remoteopenhab:server:prod:SonosSalonRadio not found, although we checked the presence before.}
20:27:44.313 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'remoteopenhab:server:prod' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING
20:27:44.319 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'remoteopenhab:server:prod' changed from INITIALIZING to UNKNOWN
20:27:45.598 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'remoteopenhab:server:prod' changed from UNKNOWN to ONLINE

See issue openhab/openhab-core#3394
PR openhab/openhab-core#3407 introduces AbstractStorageBasedTypeProvider to reduce this problem.
It has now to be used in the bindings with dynamic type providers showing this delay at startup.

Bindings implementing ThingTypeProvider:

• digitalstrom
• homematic
• mqtt.generic
• netatmo => no change required
• systeminfo => PR [systeminfo] Use AbstractStorageBasedTypeProvider #14501

Bindings implementing ChannelTypeProvider:

• bluetooth.generic
• digitalstrom
• guntamatic : change required
• harmonyhub => PR [harmonyhub] Use AbstractStorageBasedTypeProvider #14507
• homematic
• km200
• miio
• mqtt.generic
• netatmo => no change required
• networkupstools
• remoteopenhab => PR [remoteopenhab] Use AbstractStorageBasedTypeProvider #14956
• resol => no change required
• sensibo : change required
• smartmeter : change required
• solarwatt
• tacmi
• tr064 => no change required
• wundergroundupdatereceiver
• yamahareceiver : change required

Bindings implementing ChannelGroupTypeProvider:

• evcc : requires dynamic channel groups per loadpoint and vehicle. not yet implemented
• harmonyhub => PR [harmonyhub] Use AbstractStorageBasedTypeProvider #14507
• homematic
• km200
• mqtt.generic
• sensibo : to be removed as the binding does not use channel groups

[J-N-K]

Please note that not all of these suffer from the issue with delayed initialization. It depends on the implementation of the provider.

Tr064 is not affected, it has a dynamic provider, but it can create all necessary channels when the binding starts, without a storage.

[J-N-K]

Please note that not all of these suffer from the issue with delayed initialization. It depends on the implementation of the provider.

Tr064 is not affected, it has a dynamic provider, but it can create all necessary channels when the binding starts, without a storage.

[lolodomo]

Tr064 is not affected, it has a dynamic provider, but it can create all necessary channels when the binding starts, without a storage.

Interesting. I imagine these channels are not dependent on the things themself.
The number of impacted bindings could be finally largely reduced.
If we have nothing to do for certain of these bindings, that is perfect.

For the remote openHAB binding (I am working on it), I am sure we need the storage.

[lolodomo]

@J-N-K : it seems there is a problem. When I call putChannelType, I got many errors of this kind:

00:04:16.548 [ERROR] [ore.storage.json.internal.JsonStorage] - Couldn't deserialize value 'org.openhab.core.storage.json.internal.StorageEntry@35e456f3'. Root cause is: Interfaces can't be instantiated! Register an InstanceCreator or a TypeAdapter for this type. Interface name: org.openhab.core.types.StateDescriptionFragment

Looks like a problem with the state descriptions ?

I can see a new file named org.openhab.binding.remoteopenhab.internal.RemoteopenhabChannelTypeProvider-ChannelType.json and its content looks good even if I have not checked in details. Example of entry from this JSON DB:

My current PR is #14956

[J-N-K]

Yes. We should probably not store StateDescriptionFragment but a new StateDescriptionFragmentEntity instead.

[clinique]

Please note that not all of these suffer from the issue with delayed initialization. It depends on the implementation of the provider.

Tr064 is not affected, it has a dynamic provider, but it can create all necessary channels when the binding starts, without a storage.

I have not seen these WARN messages with Netatmo binding neither.

[lolodomo]

I have not seen these WARN messages with Netatmo binding neither.

Me too.
I suppose that this will be OK for dynamic types that are not really dynamic, I mean types that are hardcoded in the binding code but handled as dynamic by the binding ?
I will check the netatmo binding code to understand.

[lolodomo]

I am also using the networkupstools binding and did not notice delay at initialization, and warnings so maybe another one that is not impacted.

[lolodomo]

@J-N-K / I can confirm that your PR openhab/openhab-core#3598 properly resolved my problem. My PR for the remote openHAB binding is now working well.

[lolodomo]

I have not seen these WARN messages with Netatmo binding neither.

Me too. I suppose that this will be OK for dynamic types that are not really dynamic, I mean types that are hardcoded in the binding code but handled as dynamic by the binding ? I will check the netatmo binding code to understand.

Ok, the netatmo binding gets its dynamic thing types and channel types from Java enum classes, that is why the thing types and channel types are present at binding startup. No need for the storage in this case.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-4-0-milestone-discussion/145133/289

[moodyblue]

I have the 2 minute delay in the following bindings:

• daikin
• SmartHome J/HTTP
• miio (mentioned above)

OH 4.0.0.M3

[moodyblue]

I am also using the networkupstools binding and did not notice delay at initialization

Me too, no delay in that binding

[jlaur]

It seems there might be an issue with the Kodi binding as well? I didn't see this with my file-based configuration though, but it was reported here:
https://community.openhab.org/t/openhab-4-0-milestone-discussion/145133/595

2023-07-20 18:14:21.100 [WARN ] [core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'kodi:kodi:9849245e' 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-07-20 18:14:21.103 [WARN ] [core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'kodi:kodi:9849245e': {thing/channel=Type description kodi:volume for kodi:kodi:9849245e:volume not found, although we checked the presence before.}

EDIT: I could not reproduce this, and the problem was resolved by the user by recreating the thing.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/xiaomi-robot-vacuum-binding/31317/2120

[lsiepel]

Not in the list, but could denonmarantz binding also be affected? See #15444 (comment)

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/esphome-binding-for-the-native-api/146849/57