since a while I have a problem related to items and therefore sitemaps (it seems not to be related to things). It happens usually after reboot/upgrade or restart of openhab where the items are not loaded and not going to be initialized. It also seems not to happen to all items - which are organized in items files. I have most tings and almost all items in files. If I trigger a reload of the items by using e.g. sudo dos2unix /srv/openhab2-conf/items/*.items everything is working fine and I can see how the status of the items change in the logs, e.g. like:
Refreshing model ‘mqtt2.items’
==> /var/log/openhab2/events.log <==
2019-12-09 08:31:23.583 [vent.ItemStateChangedEvent] - Sensor_Laundry_Battery changed from NULL to 91.0
This did happen before my migration from RPi3 to 4 and also after changing the SD card. I’m usually on the latest dev branch of everything
I guess, I can exclude a faulty SD card and bad hardware. I’m on zulu Java and in recent time openhab is running very smooth, as long as I don’t have to reboot. I have another minor issue with the unifi binding here Ubiquiti Unifi Binding Feature Discussion but I think this is not related.
Does anybody else has encounterd this behaviour? And, is there a solution to this?
What I also realize is that after reboot - sometimes - the telegram action does not come up.
Caused by: org.eclipse.smarthome.model.script.engine.ScriptExecutionException: The name ‘sendTelegram’ cannot be resolved to an item or type; line 9, column 9, length 42
A restart of the openhab service resolves this problem.
Also I see this at restart:
Warning: The unit file, source configuration file or drop-ins of openhab2.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.
which I don’t understand, because I didn’t do any modifications to systemd or related, but this happens if I trigger a restart after rebooting.
No, I don’t use mapdb persistence but RRD4j and InfluxDB for items which are vizualized in graphana. But what distinguishes mapDB from the other persistence services?
I have cleared the cache already - no change.
this one I do to trigger a reload of the items files. I have more than 15 different files and in order to force openhab to reload them, I’ll change the content by just changing the line ending. This works quite well and next time I use unix2dos to change it back. However, there might be better ways of doing that. Nevertheless, this is the most easy way I can think of to change 15 files at ones and not to edit them serially by using an editor.
Also, after doing that, the items are getting initialized (or defined - they get a value), but why not at reboot? Btw. it seems that a restart works properly.
Yes, sounds a little like a timing issue. What I did try some time ago is:
44 | Delay rules load Delay loading rules to speed up overall startup
from openhabian-config. But this seems only related to rules not to items. From flying through the other threads it seems that there is no solution yet?
That’s right, no solution. It has been a bane of openHAB since version 1, poor control of the loading sequence. There are a bunch of symptoms that will vary from user to user; as you note a common form is running rules before Items are ready. This sounds like a subtly different version, loading Items before the gubbins that links them to channels or somesuch.
Just a quick report on the progress. I have reinstalled the OS and OpenHAB completely on new SD card, because I had read-only file systems. However, SD card was probably not the cause, but zram. I have activated zram, because I’m on a RPi4 with 4GB and thought that would make sense. Nevertheless the zram partition went into ro mode and jsondb couldnt be updated anymore.
A new reinstall without zram is running smoothly so far.
The original problem in this thread that items didn’t get populated are related to: https://github.com/openhab/openhab2-addons/issues/6562 and are fixed since S1775.
I still have some other issues like with the unifi binding and I’m still not convinced that all items are loaded and populated at startup (now using MapDB), but I have to observe it a little bit more.
Anyway, many thanks for all the hints and contributions.
Hi,
the issue is still there. Some items from different item files are not initialized after restart (not even reboot) of openhab. They never get initialized except I trigger it manually through e.g.
Nevertheless, even if rules are loaded late it won’t help, because the items are still not usable. This usually results in error messages triggered by some rules or sitemaps if loaded. Btw. this issue is visible at all type of items, independently if they are related to mqtt or something else.
Does anybody has an idea where I could search to track down this issue?
“Items not initialized” means the Items exist but they never leave their initial NULL state. This is what restoreOnSartup does. It replaces that initial NULL state with what ever state was most recently stored in the database. But the Items exist and are usable. You can show them on your sitemap without error (“-” will show as their state). You can sendCommand or postUpdate to them from your Rules.
“Items not usable” means that the Items do not even exist. You get errors in the logs when you try to show it on your sitemap. You get parsing errors when you load your Rules. etc.
So which is it? They are not initialized or they are not usable?
I would say the items are not linked, because if I touch the item files the links getting added. I’m wondering that this does not happen during startup and will also not be done later. It would be interesting if somebody else is seeing this behaviour or I’m the only one?
So far you are the only one reporting anything like this. But it still isn’t clear what is going on. What makes you think the Links are not being created? How are you checking?
I notice a strange thing after the upgrade from 2.4 release to 2.5 release. All group items, created from Paper UI, resetted their base type to None. This brought the situation when all groups states became NULL. It wasn’t a huge problem to click them manually in UI and set correct base type, but, does anybody also have such issue? This appeared only once after OH update, groups base types are preserved after restart/reboot. I’m using openhabian, update was done using openhabian-config. OH was manually stopped before the update.
