Trigger rule execution when all bindings are initialised

[somy (mai)]

Hi,
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:

1. Use “system restarted” event, most values I need are in NULL state so not usable
2. 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,

Many thanks in advance!

[somy (mai)]

Ok, maybe a solution using the event “System reached start level 100”
Will do more test and report

[Andrew_Rowe]

You may find some good hints in this recent thread

Blocky/JS unusable (showstopper delay on 1st run): please advice for alternative solution

Hi Rich, Yes indeed, I did not know this way of passing information from one script calling another one, but that is much better than using the metadata on an item. Using metadata works but it’s certainly slower, as it stores and retrieve the information from somewhere in the disk – metadata being persistent. So, the “load scripts and rules” script executed at level 100 after openhab service is started became: [image] and in each script the test to run it “blank” and do nothing but load the…

if you skip down to the bottom there are several working example code

[rlkoshak (Rich Koshak)]

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.

[somy (mai)]

@rlkoshak

restoreOnStartup

Thank you for your reply! What is restoreOnStartup?

[rlkoshak (Rich Koshak)]

@somy

What is restoreOnStartup?

Persistence

Persistence

[somy (mai)]

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:

1. 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).
2. What could be an example of unsupported item type?

[rlkoshak (Rich Koshak)]

@somy

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).

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.

@somy

What could be an example of unsupported item type?

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.