search

openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.86k stars 3.57k forks source link

Bindings migration to use AbstractStorageBasedTypeProvider #14954

Open lolodomo opened 1 year ago

lolodomo commented 1 year ago

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:

Bindings implementing ChannelTypeProvider:

Bindings implementing ChannelGroupTypeProvider:

J-N-K commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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: image

My current PR is #14956

J-N-K commented 1 year ago

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

clinique commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

I have the 2 minute delay in the following bindings:

OH 4.0.0.M3

moodyblue commented 1 year ago

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

Me too, no delay in that binding

jlaur commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Not in the list, but could denonmarantz binding also be affected? See https://github.com/openhab/openhab-addons/issues/15444#issuecomment-1683958966

openhab-bot commented 11 months ago

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