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

[systeminfo] broken when thing defined in text file #13708

Closed
UrsusS opened this issue Nov 13, 2022 · 4 comments
Closed

[systeminfo] broken when thing defined in text file #13708

UrsusS opened this issue Nov 13, 2022 · 4 comments
Labels
bug An unexpected problem or unintended behavior of an add-on

Comments

@UrsusS
Copy link

UrsusS commented Nov 13, 2022

The version in 3.4.0.M4 does not work with a textual thing definition as discussed [here]
(https://community.openhab.org/t/openhab-3-4-milestone-discussion/138093/105):

At least I would like to have a warning in startup that the dynamic channels can't get created and that the startup proceeds with the static channels as before.

@UrsusS UrsusS added the bug An unexpected problem or unintended behavior of an add-on label Nov 13, 2022
@lolodomo
Copy link
Contributor

PR #13562 broke something. In worst case, we should revert that change.

@andrewfg
Copy link
Contributor

With the thing defined via a .things file, when the system initially starts up, I get the following error, and the thing is shown as offline.

2022-11-13 22:09:52.696 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key systeminfo:computer:g24 in ManagedThingProvider, because it does not exists.

However if, after the system has started, I then disable and re-enable the thing, then it goes online normally.

So @mherwege this makes me suspect that there is possibly some kind of timing issue…

@Hilbrand
Copy link
Member

This seems to be a bug in core. The systeminfo calls the method migrateThingType, which directly calls the managed thing provider (managed things are things created via the UI, unmanaged things are created via text files). The migrateThingType method should have called an update thing in a similar way as the thingUpdated method (in core). I guess the method migrateThingType was never used before.

The reason it works when disable and re-enable the thing, is because the migrateThingType fails in the last statement in that method. So all code steps needed before are done. When one disables and re-enables a thing openHAB will re-initialize the thing. This will again call the thingUpdated method because the binding will always update the thing (via updateProperties()) and that triggers a thingUpdated (The method that should have been called in migrateThingType) and because the thing changes in the binding are still there it will update with the correct thing data, and because the binding internally still has the modified thing it won't call migrateThingType again.

I've created a pr with a fix for core: openhab/openhab-core#3162

@lolodomo
Copy link
Contributor

Should be fixed.
@UrsusS : please reopen in case you have still the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An unexpected problem or unintended behavior of an add-on
Projects
None yet
Development

No branches or pull requests

4 participants