Sync issue with restoreOnStartup and rules

Setup, Configuration and Use Beginners
1

I still have problems with rules and restoreOnStartup sync.
I have a rule what runs every 30s to make some calculations based on electricity usage, sun energy etc.
For this I need many items where I store values I use in my calculations.
I expect that the first time the rule is fired is before some values are restored.
Now the questions.

  1. When is a rule the first time fired when it is started with Time cron “0/30 * * ? * *”
  2. Can I delay a rule after a system restart for some time?
  3. Default all items are restored by rrd4j. Should I also add restoreOnStartup on the items stored in influxdb? Didn’t do this because looks not logical to me.
  4. Is there a event what is fired after a 100% restore?
  5. System started is started when system has reached start level 20. Can I change this level?
  6. Are other rules only started after the system has reached start level 100?.
  7. Any idea’s how to wait with rules until the system has restore all items.
  8. Any tips how to solve this?
2

That is the general intention, but not only is the openHAB startup a bit hectic, restore depends on external database services.

I’m pretty sure that will just make it worse.
I wouldn’t restore from either of those services at all. You’ve given rrd4j a pile of work to do with ‘everything’, and I think influx takes longer to start up?

How about only storing selected Items in Mapdb, and restoring only those, so its an altogether simpler (faster) task.

If you’re running the rule every thirty seconds, who cares if stuff is not ready at first run?

if (thisItem.state != NULL && thaItem.state !=NULL) {
   // do calculations
}

or just let it error out, another one will come along in half a minute.

3

A lot of the below will just be restating what rossko57 said. I just wanted to make sure all 8 of your questions are clearly addressed.

The first second 0 or 30 after the rule engine starts.

Yes. there are two approaches you could use.

  1. Create a rule that triggers at system runlevel 40 (lowest runlevel) that disables the rule. Create another rule that triggers at system runlevel 100 (highest runlevel) that enables the rule. You could even create a timer to enable that rule sometime after OH reaches runlevel 100.

  2. Add a condition to the rule that checks the states of all the Items it depends upon and doesn’t try to do anything if a needed Item isn’t in a usable state.

2 is going to be more fool proof and make your rule resistant to other errors. Remember, any Item could potentially become NULL or UNDEF at any time, not just during startup. 2 solves that problem too. Note this is what rossko57 is suggesting and I second the recommendation.

You are right, that will only make the restoreOnStartup less well constrained and controlled. MapDB indeed is the best choice to use for restoreOnStartup. It’s the fastest and supports all Item types.

No.

In the UI based rules you can choose between 40 and 100. In file based rules DSL you cannot change the meaning of System started.

No, rules will start running after run level 50.

Though I’m not certain about file based rules. Those might start running at run level 40 (rules loaded).

Add error checking to the rule so it only runs when all the Items it needs have valid states.

4

This means I need to create my own rrd4j.persist without the resoreOnStartup. What is the default the be sure I make a good replacement.

5

Thanks for all the positive feedback.
My conclusion is to try the below first.

  1. I will replace the restoreOnStartup in MapDB (who can share what is in the default rrd4j.persist)
  2. I will check all the items used in every calculation and exit the rule if one of the items is NULL

Is this the default rrd4j.persist?
And how do I know my rrd4j.persist is used instead of the default one?

 Strategies {
    default = everyChange
}

Items {    

    *  : strategy = everyChange, restoreOnStartup
}
6

It’s in the docs.

The rrd4j persistence services comes with a default persistence strategy which persists every Item on every state change and at least once a minute. Additionally, it restores the last stored value at system startup.

You’ll see a line in openhba.log saying that it loaded that file.