Binding in "NOT_YET_READY" state after recent core changes #3394
Comments
|
That happens if "something" is missing. You can set |
|
Thanks, here's the relevant log: This is also happening to the remoteopenhab binding
Looks like the thing types are not being initialized right ? |
|
The result lists the missing entities:
|
|
So, both of these bindings I believe create dynamic channels at runtime, could that have something to do with it? |
|
Probably. The question is how to solve that. We can either introduce a timeout similar to what we have for missing The reason the check was introduced is that we found that configuration parameters can cause issues if they are not normalized. For the normalization we need the config description of the thing/channel and that is available in the Maybe we should introduce an I can make the code implementation and one reference implementation in openhab-addons, but I will not adjust all bindings. |
I worry that there a quite a few more bindings then that will be broken in 4.0 ? I don't mind going through bindings and fixing if our solution is a simple persist call, although would we have to handle removal in that case? Not sure what that lifecycle would look like. Could we have bindings declare in their service or config that they use dynamic channels, and so are skipped the check that is currently failing ? |
|
I think excluding from the check is wrong. We could do both things: Provide a way for easily persisting the types and add the time-out. That will not break systems (because it only delays initialization by IIRC 2 minutes and log w warning) and also show which bindings still need to be fixed. |
Relevant UI code, which could indeed use some improvement: /~https://github.com/openhab/openhab-webui/blob/main/bundles/org.openhab.ui/web/src/components/thing/thing-status-mixin.js |
Gotcha, so the binding would eventually initialize after 2 mins regardless. If the binding is then modified to persist dynamic channels, then when a user upgrades , the first start would be delayed, but subsequent starts would not ( they now have persisted data)? |
|
Probably 20 bindings impacted ! Isn't 2 minutes a little too much ? |
See openhab/openhab-core#3394. Signed-off-by: Jan N. Klug <github@klug.nrw>
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/openhab-4-0-snapshot-discussion/142322/188 |
|
Could we possibly modify the BaseThingHandler to remove then add and persist channels when updated ? So handle this behind the scenes so bindings don't need to change ? maybe here? |
|
No, there is no way to clean that up after thing deletion in that case. I'm working on a solution that requires only minimal changes to bindings. |
|
Is this fixed now? |
|
There is a temporary fix, the „permanent“ solution is in the linked PR. |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: |
|
Should we keep this issue opened until bindings are fixed? |
|
I'd say it is ok to keep it closed as #3397 anyhow mitigates the issue. |
|
@J-N-K : when I install the NTP binding with the last snapshot, I can see these logs: Is it normal that the thing is "not yet ready" during less than one second just after I installed the NTP binding ? |
|
Could be. If the handler factory is present before all XMLs (with the thing definitions and config descriptions) are parsed, this can happen. |
|
Shouldn't our startup levels make sure that handlers are not initialized before all XMLs are processed? |
|
This works fine if you start the system with installed add-ons, but not if you install add-ons later, because we don't reduce the start-levels. |
|
Ok, right. |
|
It looks like it happens even when the binding is already installed. and then I restart it: I still have the "NOT_YET_READY". It is a test OH server with the default install setup + the NTP binding installed. |
|
That's the same as installing/uninstalling. |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: |
|
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 |
Hi, i'm not sure if this is an error with the Harmony Binding that is only now surfacing with recent core changes, or if recent core changes are affecting certain existing bindings negatively by accident, so i'll start with opening the issue here.
After upgrading yesterday to the latest nightly build (with core 4.0.0.202302191628) , my harmonyhub things come up in a new state i have never seen before "NOT_YET_READY", which looks like was added to indicate binding dependencies or configs have not yet been satisfied ? In any case, the handler never activates, and i'm not sure what to do to fix this in the binding.
Here's a screenshot of the things in the UI (we probably need to add this state in the Main UI @ghys )
Here's a shot of a thing in this state:
Here's a dump of logs if i restart the Harmony Binding. Let me know what else i can do to help, thanks!
The text was updated successfully, but these errors were encountered: