Open lolodomo opened 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.
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.
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.
@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
Yes. We should probably not store StateDescriptionFragment
but a new StateDescriptionFragmentEntity
instead.
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.
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.
I am also using the networkupstools binding and did not notice delay at initialization, and warnings so maybe another one that is not impacted.
@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.
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.
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
I have the 2 minute delay in the following bindings:
OH 4.0.0.M3
I am also using the networkupstools binding and did not notice delay at initialization
Me too, no delay in that binding
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.
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
Not in the list, but could denonmarantz binding also be affected? See https://github.com/openhab/openhab-addons/issues/15444#issuecomment-1683958966
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
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:
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:
loadpoint
andvehicle
. not yet implemented