I’m writing and hope somebody can give me some hints on how to deal with initialisation of OpenHAB.
I have noticed the bindings are not initialised in the same order (or be ready at the same time), hence it gives me some problem when I trigger some rules which is supposed to run after system restart. To be more specific, I have a rule that schedules charging my car at cheapest hours by a timer, and obviously I’d like to make sure the timer is re-created when the system restarts. What I have tried so far:
Use “system restarted” event, most values I need are in NULL state so not usable
Listen to particular value changing from NULL to meanful state, for example the state of my charger change from NULL to WAITING_TO_CHARGE, however I use another binding to get electricity price and the binding is not always ready when the rule is triggered.
Is there a way to say system restarted and all bindings have been initialised or system restarted + 5 minutes?
Maybe I’m not doing it properly and hope somebody can help me with some suggestion on how to ensure timers are re-created after system restart,
There is no foolproof solution to this problem. Your on the right track to use a system runlevel > 80 (80 is Things initialized) but even then there’s no guarantee that the bindings are all installed and available by that point if there was an upgrade or the cache was cleared. It takes some time to download and install add-ons and OH doesn’t block it’s startup and wait.
Even if the add-ons are there, there’s no guarantee that even if the Things are initialized that they have successfully fetched the latest data to update the Items.
Is there a reason why restoreOnStartup wouldn’t work here? How long is OH typically offline? Are the values you need to use likely to change in that time?
To get something more foolproof, assuming there’s a good reason restoreOnStartup isn’t viable you’ll want to do something like the following:
trigger the rule at runlevel 100
check to see all Items are in a usable state (i.e. not NULL)
if it’s fine run
if not create a timer that checks if the Items are usable a little later. If they are still NULL reschedule the timer to check again later. Eventually time out with an error.
Hi, thanks for pointing me to the documents.
I noticed many of the items changed state from NULL to some value, but not sure if it is because of restoreOnStartup. The document writes:
“openHAB ships with rrdj4 as the default persistence database and comes with a default persistence strategy of everyChange, everyMinute, and restoreOnStartup for every supported Item. The good thing about rrd4j is that the database never grows beyond a given size, so you never have to clean it up. However, the way it achieves this (replacing ten readings with the average of the ten readings as the data gets older) makes the database not work for all Item types. If you need to restoreOnStartup unsupported Item types, MapDB might be a better choice for you.”
In my setup I haven’t touched any setting of persistency so I assume restoreOnStartup is enabled by default. However I’m very confused by the way how it’s supposed to work and the “unsupported” item types:
Does restoreOnStartup restore the values to the items before or after the items/bindings are initialised? My observation of the values in the rule usually comes quite late and most of times it’s just too late to fail the rule (if I use system started trigger).
What could be an example of unsupported item type?
It happens after the Items are first loaded. That may or may not be bedore the Things are initialized. I believe that if the Item is not NULL restoreOnStartup does not update the Item. Only if it’s NULL will it restore the last state.
If you use .items files, restoreOnStartup happens on every change to any .items file.
rrd4j only supports Numbers, Switches and Contacts. None of the other Item types are supported.
rrd4j comes by default in OH 3 (not in OH 4 any longer I think) so that charting works out of the box (no database, no charts).
MapDB makes a better choice for restoreOnStartup when you have more than just Number Items that you want restored.