Textually defined things not available after restart

[schup011]

Expected Behavior

As in OH3.x, during the start up procedure things defined by textual .things files should appear after a certain time in the log as being INITIALIZING and then becoming ONLINE. This can also be seen in the Things section in MainUI.

Current Behavior

After a restart of OH4.x, things are not appearing neither in the log nor in MainUI. Some items and rules are working, some others not. Probably, this depends on the binding. Also a sitemap defined by a .sitemap file is not working and not defined.
After touching the respective files (.things and .sitemaps), everything becomes ONLINE and is working as expected.
After a restart with cleaned cache (openhab-CLI clean-cache), usually things files are loaded without a problem. Another restart without cleaning the cache reproduces the problem.

Possible Solution

Steps to Reproduce (for Bugs)

1. Provide a .things file thing definition.
2. Start openHAB. If the things are available, restart openhab (in my platform sudo systemctl restart openhab.service).

Context

Especially in the situation of having migrated, frequent restarts of openhab are sometimes unavoidable. I am also migrating rules from Jython to Javascript at the moment.

Your Environment

Fresh openhabian installation on Raspberry Pi 4 with 2GB RAM.
Fresh SanDisk Extreme SD Card.
Standard installation, including Mosquitto & Influx+Grafana.

[openhab-bot]

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

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

[openhab-bot]

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

https://community.openhab.org/t/things-textual-config-sometimes-not-available-after-reboot-oh4-x/149257/2

[schup011]

Maybe one hint: Recently, I added some things in the MainUI. It could be that having at least one "MainUI-defined" thing could prevent this bug to happen. At least it did not happen in my system for the last two restarts (sorry, no good statistics).

[morph166955]

Upgraded to snapshot 3615 this morning, same issue here. None of my things files load. items and rules are fine, but it never loads things. If I go and manually touch a file (add a blank line for example) it loads at that time (only that file). If I move the .things file out and back in it also works. This seems to just be a startup issue.

EDIT: To note, I'm on a fresh install. I lost my docker host (not the files just the host itself) so I migrated to a new OH4 install. I moved my things/items/rules in like normal and reconfigured everything else. Not sure if that has an impact here that I'm no longer on docker.

[AnTrii]

I'm at OpenHAB 4.0.2 Release / Java 17.0.8 / Debian 11 / kernel 5.15.108-1, same issue. Have defined a MainUI Modbus TCP Thing for test. After restarting OpenHAB I see only that one MainUI Thing. After restart, there is no .things mentioning whatsoever in OpenHAB logs. By the way, reinstalling OpenHAB make Things to work again until restart.

[morph166955]

For reasons unknown, this bug resolved itself for me some time yesterday.

[morph166955]

...And now a few hours later, it's back.

[morph166955]

I thought I was good on this, restarted the OH server, and it's broken again. I'm on shapshot 3625 still. It was working well for a solid few days. I needed to shut everything down for a software upgrade and when it came back my things wouldn't come back.

[wborn]

I failed reproducing this today with 100 thing files each having 6 astro things. Tried both Docker/non-Docker , with/without cache and tmp dirs and also with/without managed things.

• If you have the issue do the things show in the things list command?
• Are always the same things missing and if so which bindings do they belong to?
• Maybe you can provide a thread dump so we can see if something is blocked?
• If someone can easily reproduce it perhaps enabling more debug logging might help explain what happens.

[morph166955]

It is definitely hard to reproduce. It didn't start to happen to me until I moved my setup out from docker to an Ubuntu 22 VM (esxi). My docker setup took a dump and it forced me to move. It seems to happen most frequently right after the VM is rebooted. My storage is mounted to esxi via nfs. My configs are all however stored inside the vmdk, not across a second nfs connection or anything odd like that. When it happens, it hits all things across all bindings. My things are all text based, I don't have any in the json. As soon as I move the files out and then back in, they all import. It's almost like there's some kind of race condition at start, possibly an issue with the start level or something like that (just a gut feeling). I have noticed that when it is working the things don't seem to respect any order. Sometimes it's before rules and items, some times in the middle, and sometimes after. Next time it happens I'll run the commands requested.

[wborn]

It would also be interesting to know if you see "Loading model ..." for those files in the logging when the issue occurs:

10:12:56.637 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'demo-59.things'
10:12:56.643 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'demo-57.things'
10:12:56.649 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'demo-5.things'
10:12:56.654 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'demo-28.things'
10:12:56.659 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'demo-92.things'
10:12:56.664 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'demo-94.things'

[morph166955]

No, you never see the log message

[schup011]

• f you have the issue do the things show in the things list command?

• Are always the same things missing and if so which bindings do they belong to?

• Maybe you can provide a thread dump so we can see if something is blocked?

• If someone can easily reproduce it perhaps enabling more debug logging might help explain what happens.

I can confirm it happened with all things files and they had to be re-activated file per file. I did that by opening each of them and adding or removing a blank line.
Once I had a couple of UI-defined things. Those ones were not affected and then were the only ones showing up.

My bindings are astro, openweathermap, homematic, mqtt, modbus, Daikin, fritzbox, squeezebox, influxdb persistence, exec.

[morph166955]

@schup011 if you move the files out of the folder and then back in, even on bulk, it should restore them. Makes it a little faster tonl get back. I can confirm on my side that modifying the file also makes it load.

[schup011]

@schup011 if you move the files out of the folder and then back in, even on bulk, it should restore them. Makes it a little faster tonl get back. I can confirm on my side that modifying the file also makes it load.

Yeah, thanks for the hint. I already took that into my mind from reading your post. I just wanted to tell how I did it last time. In fact, the issue did not happen to me quite a while, as restarting openhab wasn't necessary at all the last weeks.

[wborn]

In the latest snapshot build (3656) the FolderObserver logs more helpful debug info. To enable it set the log level to debug on the org.openhab.core.model.core.internal.folder.FolderObserver class. If you run into the issue add the generated logging to this issue. If you add logging for both a successful and unsuccessful startup we may be able to figure out why the files go missing.

[morph166955]

I'll upgrade and test as soon as I get back from vacation.

[openhab-bot]

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

https://community.openhab.org/t/things-not-loaded-after-reboot/150459/5