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.

Sign up for GitHub

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

Jump to bottom

Config param changes in .things file not propagating to things #3791

Closed
andrewfg opened this issue Aug 31, 2023 · 23 comments
Closed

Config param changes in .things file not propagating to things #3791

andrewfg opened this issue Aug 31, 2023 · 23 comments
Labels
bug An unexpected problem or unintended behavior of the Core

Comments

@andrewfg
Copy link
Contributor

I am not yet 100% sure if this is a binding issue or a core issue, so posting here just in case it is the latter.

There are two reported cases where changing a config param value in a .things file does not propagate to the thing. The log file shows that the .things file was reloaded, but the config param value of the thing does not change. Also disabling and reenabling the thing does not update the value. However restarting OH does update the value.

https://community.openhab.org/t/changes-in-thing-config-files-not-populated-in-oh4/149208?u=andrewfg

openhab/openhab-addons#15498
@andrewfg andrewfg added the bug An unexpected problem or unintended behavior of the Core label Aug 31, 2023
@openhab-bot
Copy link
Collaborator

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/changes-in-thing-config-files-not-populated-in-oh4/149208/11

@wborn
Copy link
Member

wborn commented Aug 31, 2023

Please describe your environment as requested in the issue template.

@andrewfg
Copy link
Contributor Author

andrewfg commented Aug 31, 2023 •
edited

describe your environment as requested in the issue template.

I can't speak for the one who posted his issue on the community forum. However my own case is OH v4.02 running on openhabian on an RPi.

EDIT the OP on the forum said he is running v4.02 (but he did not mention what hardware). Also @mstormi reported a similar issue, and it is safe to say he is running openhabian, I think.. :)

@wborn
Copy link
Member

wborn commented Aug 31, 2023

It would also be good to know what underlying file system is used as that can also influence if and when file events are triggered.

@wborn
Copy link
Member

wborn commented Aug 31, 2023

Maybe you can also test if it works better with 4.1.0-SNAPSHOT? 🙂 It has some fixes, see openhab/openhab-osgiify#42.

@andrewfg
Copy link
Contributor Author

andrewfg commented Aug 31, 2023 •
edited

good to know what underlying file system is used

I believe that the openhabian images use ext4

@andrewfg
Copy link
Contributor Author

Maybe you can also test if it works better with 4.1.0-SNAPSHOT?

I am away for about 1 week, so I can only test when I get back.

@morph166955
Copy link

I ran into this issue last night. I'm on snapshot 3600. I have a things file containing a single line for my Denon 8500 (denonmarantz binding). No other things are in the file. I made an IP address change and had to update the thing. Nothing made it pull in. I tried a disable and re-enable of the thing in the GUI, nothing. Finally restarted OH and it worked. During the restart I saw this message which I haven't seen before. All of my things came up clean so it's unclear if it caused an issue.

2023-08-30 17:36:36.457 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed to refresh bundles after processing config update
org.apache.karaf.features.internal.util.MultiException: Error:
	Error downloading mvn:io.swagger.core.v3/swagger-core/2.2.15
	Error downloading mvn:io.swagger.core.v3/swagger-annotations/2.2.15
	Error downloading mvn:io.swagger.core.v3/swagger-integration/2.2.15
	Error downloading mvn:org.javassist/javassist/3.29.2-GA
	Error downloading mvn:io.swagger.core.v3/swagger-models/2.2.15
	Error downloading mvn:io.swagger.core.v3/swagger-jaxrs2/2.2.15
	at org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.<init>(MavenDownloadManager.java:91) ~[?:?]
	at org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72) ~[?:?]
	at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:474) ~[?:?]
	at org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:469) ~[?:?]
	at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:223) ~[?:?]
	at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:399) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069) ~[?:?]
	at org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
	at java.lang.Thread.run(Thread.java:833) ~[?

@andrewfg
Copy link
Contributor Author

As posted elsewhere, I wonder if the issue is caused by a mismatch between date/time stamp on the .things file in the file system versus the date/time stamp on the cached data within OH?? I.e. it may be related to the system clock time in the OS (used for file system timestamps) vs the time zone used in OH. Or something like that..

@morph166955
Copy link

I've never had issues with this before and this systems been up almost 2 years. Not sure how the clocks would get out of sync like that on a single system.

@mstormi
Copy link

mstormi commented Aug 31, 2023

I.e. it may be related to the system clock time in the OS

No shooting at the dark please.
Yes it can happen with RPis as they have no hardware clock, the'll set system time to kernel compilation date. but only until ntp gets back into sync.
And you would need to boot the system to get off that far, and neither did I nor was it reported by anyone else with this problem.

@J-N-K
Copy link
Member

J-N-K commented Aug 31, 2023

If you see the "Loading foo.things" (or similar) message, the file-system is NOT your issue. In that case the issue is in the GenericThingProvider which has a very complicated logic for creating things (and updating them) and unfortunately is not Java code but Xtend. If you don't see the "Loading foo.things" message, your issue is in the file watcher/file system.

@maihacke
Copy link

maihacke commented Sep 1, 2023

Please describe your environment as requested in the issue template.

I'm running OH 4.0.2 on Ubuntu, ext4 filesystem on a Dell x86 system. No openhabian, no rasbi.

I can see the loading xxx.things message in the log.

@lolodomo
Copy link
Contributor

lolodomo commented Sep 1, 2023 •
edited

As it was confirmed it was working in OH3, we can then assume it was broken by PR #3526 which was there to fix an issue.
So it should help to understand what is wrong.

@J-N-K
Copy link
Member

J-N-K commented Sep 1, 2023

Can you all confirm that this issue is still present in the latest snapshot?

@lolodomo
Copy link
Contributor

lolodomo commented Sep 1, 2023

Can you all confirm that this issue is still present in the latest snapshot?

Not yet for me but at the same time I never encountered it yet. I will have to mix several things from different bindings in the same file to reproduce it first.

@openhab-bot
Copy link
Collaborator

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/oh4-upgrade-issue/148009/24

@morph166955
Copy link

I can update this weekend and test again. 3600 isn't too old, is there a recent commit which updated something?

@wborn
Copy link
Member

wborn commented Sep 1, 2023 •
edited

3600 isn't too old, is there a recent commit which updated something?

It's too old! 😉 It doesn't have #3790 which may help if files aren't properly reloaded.

@andrewfg
Copy link
Contributor Author

andrewfg commented Sep 1, 2023 •
edited

@J-N-K I will test the latest snapshot when I return in one week. And will give an update then.

unfortunately is not Java code but Xtend

Perhaps we should consider porting this to Java? Or at least open an issue to remind us to do it in future..

@morph166955
Copy link

Upgraded to most current snapshot 3613. I can not replicate this anymore. File watch service looks like it's working as expected. First time I changed the IP to an invalid one, second one I changed it back. GUI also showed the updates.

2023-09-02 15:08:40.780 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'denon.things'
2023-09-02 15:08:46.818 [INFO ] [openhab.core.model.script.THINGSTATE] - State Change For Denon8500_ThingState - From: ONLINE To: UNKNOWN
2023-09-02 15:09:05.438 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'denon.things'
2023-09-02 15:09:05.614 [INFO ] [openhab.core.model.script.THINGSTATE] - State Change For Denon8500_ThingState - From: UNKNOWN To: ONLINE

@wborn
Copy link
Member

wborn commented Sep 2, 2023

I've now backported #3779 and #3790 to 4.0.x after doing some successful testing and seeing bugs being fixed by them.

@wborn wborn closed this as completed Sep 2, 2023
@openhab-bot
Copy link
Collaborator

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/things-changes-require-to-restart-openhab/86435/14

@andrewfg andrewfg mentioned this issue Oct 7, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug An unexpected problem or unintended behavior of the Core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@andrewfg @J-N-K @openhab-bot @maihacke @lolodomo @wborn @mstormi @morph166955