Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bindings migration to use AbstractStorageBasedTypeProvider #14954

Open
9 of 30 tasks
lolodomo opened this issue May 8, 2023 · 17 comments
Open
9 of 30 tasks

Bindings migration to use AbstractStorageBasedTypeProvider #14954

lolodomo opened this issue May 8, 2023 · 17 comments
Labels
enhancement An enhancement or new feature for an existing add-on

Comments

@lolodomo
Copy link
Contributor

lolodomo commented May 8, 2023

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:

@lolodomo lolodomo added the enhancement An enhancement or new feature for an existing add-on label May 8, 2023
@J-N-K
Copy link
Member

J-N-K commented May 8, 2023

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.

1 similar comment
@J-N-K
Copy link
Member

J-N-K commented May 8, 2023

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
Copy link
Contributor Author

lolodomo commented May 8, 2023

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
Copy link
Contributor Author

lolodomo commented May 8, 2023

@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

lolodomo added a commit to lolodomo/openhab-addons that referenced this issue May 8, 2023
Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
@J-N-K
Copy link
Member

J-N-K commented May 9, 2023

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

lolodomo added a commit to lolodomo/openhab-addons that referenced this issue May 9, 2023
Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
@clinique
Copy link
Contributor

clinique commented May 9, 2023

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
Copy link
Contributor Author

lolodomo commented May 9, 2023

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
Copy link
Contributor Author

lolodomo commented May 9, 2023

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
Copy link
Contributor Author

@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 added a commit to lolodomo/openhab-addons that referenced this issue May 11, 2023
Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
@lolodomo
Copy link
Contributor Author

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.

lolodomo added a commit to lolodomo/openhab-addons that referenced this issue May 11, 2023
Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
lolodomo added a commit to lolodomo/openhab-addons that referenced this issue May 11, 2023
Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
lolodomo added a commit to lolodomo/openhab-addons that referenced this issue May 12, 2023
Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
J-N-K pushed a commit that referenced this issue May 12, 2023
* [remoteopenhab] Use AbstractStorageBasedTypeProvider

Related to #14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
@openhab-bot
Copy link
Collaborator

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
Copy link

moodyblue commented May 25, 2023

I have the 2 minute delay in the following bindings:

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

OH 4.0.0.M3

@moodyblue
Copy link

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

Me too, no delay in that binding

tb4jc pushed a commit to tb4jc/openhab-addons that referenced this issue Jun 19, 2023
* [remoteopenhab] Use AbstractStorageBasedTypeProvider

Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Signed-off-by: Thomas Burri <thomas.burri@alstomgroup.com>
@jlaur
Copy link
Contributor

jlaur commented Jul 20, 2023

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.

matchews pushed a commit to matchews/openhab-addons that referenced this issue Aug 9, 2023
* [remoteopenhab] Use AbstractStorageBasedTypeProvider

Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Signed-off-by: Matt Myers <mmyers75@icloud.com>
@openhab-bot
Copy link
Collaborator

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
Copy link
Contributor

lsiepel commented Aug 18, 2023

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

@openhab-bot
Copy link
Collaborator

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

austvik pushed a commit to austvik/openhab-addons that referenced this issue Mar 27, 2024
* [remoteopenhab] Use AbstractStorageBasedTypeProvider

Related to openhab#14954

Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Signed-off-by: Jørgen Austvik <jaustvik@acm.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature for an existing add-on
Projects
None yet
Development

No branches or pull requests

7 participants