[SOLVED] 1st attempt to restore on startup

Just added persistence with mapdb and want to keep/restore a variable. I’m probably missing something very simple as a beginner :wink:

Before I had this:

rule "Initialize heating states"
when
System started
then
postUpdate(TargetTemp, 22)
end

Now I’m expecting persistence to be working but need to avoid Uninitialized errors.
So, this is what I have now:

rule "init the state"
when
Item TargetTemp.state changed to Uninitialized
then
postUpdate(TargetTemp, 22)
end

With this rule I have an error:

Error during the execution of rule ‘Heater’: Cannot cast org.openhab.core.types.UnDefType to org.openhab.core.library.types.DecimalType

What’s my mistake?
Thanks!

Once you get persistence up and running you shouldn’t be getting uninitialized errors as the restore on start up should run before your rules. Therefore you shouldn’t need those two rules you posted.

You’ve not shown us what your “Heater” rule is so it looks like the problem may be elsewhere.

OK, I’ve removed the initial rules and left only the main one (which was working without issues earlier):
// Rule to drive the Heater
rule "Heater"
when
Item CurrentTemp received update or
Item TargetTemp received update
then
// Turn on the heater if the temp gets more than 2 degrees below the TargetTemp to prevent rapid cycling
if((CurrentTemp.state as DecimalType)+1 < (TargetTemp.state as DecimalType)) {
if(Heater.state != ON) Heater.sendCommand(ON)
}
else {
if(Heater.state != OFF) Heater.sendCommand(OFF)
}
end

Errors I see:

Error occured while creating backend object for item Heater, exception: Device or resource busy
Error during the execution of rule ‘Heater’: Cannot cast org.openhab.core.types.UnDefType to org.openhab.core.library.types.DecimalType

My understanding that the variable should be properly initialized at least once before it will be stored/restored by persistence.

Correct. Have CurrentTemp and TargetTemp already had a value set at least once?

Not for TargetTemp. That’s why I tried to set it if it’s current state is Uninitialized. What will be the right way to do so?

There’s a few ways.

Personally I’ve added a widget to the sitemap for my target temp. I’ve used SetPoints and Selections for this in the past. You could also send an update from the console or use the webserver/REST API.

I have this in sitemap:

Setpoint item= TargetTemp minValue= 5 maxValue= 28 step= 1

The question is how to set the initial value and keep the last one between restarts.

Setting up persistence (which it sounds like you have) will keep the last value between restarts. If you haven’t, or don’t think you’ve set it up properly, then that’s a different issue to solve and we can look at that aspect if you need.

I gave you a few options. Assuming persistence is working properly (and you’ve used restoreOnStartup), you can use your SetPoint to set TargetTemp value. Once you’ve done this the first time it will always have a value.

I was thinking exactly the same way, but I’m getting an error:

Received unknown command ‘Uninitialized’ for item ‘TargetTemp’

That’s why I’m still thinking that I need to initialize this variable somehow.

Maybe you could try this:

rule "Initialize heating states"
when
  System started
then
  if (TargetTemp.state == Uninitialized) {
    postUpdate(TargetTemp, 22)
  }
end

This should take care of your very first startup, after which persistence (and restoreOnStartup) should handle any subsequent startups.

Please note however, that this assumes that items and persistence are loaded before your rules, which is not really guaranteed in openhab - at least not without some fiddling.

1 Like

Unfortunately, after restart I see only the pre-defined value of 22 and lot the last one I set :frowning:

Yes, that is exactly what the rule does. :slightly_smiling:
Maybe you overlooked the hint from Daniel: you need to set up “restoreOnStartup” in your persistence file:

Items {
    <your_item>: strategy = everyChange, restoreOnStartup
    }

@danielwalters86
"Once you get persistence up and running you shouldn’t be getting
uninitialized errors as the restore on start up should run before your
rule"

It would be great if this is true but unfortunately it is not. Since the scheduling of services (in openhab1) is not really deterministic, you cannot assume that all items are restored when your rule engine is starting.

The workarround I am using, that I have added a “delayed Start” item, which gates all rules, that rely on persisted items. I am setting this item to true after about 3 minutes im my case. After this, (mostly) persistence has restored items.

There’s a setting you can use to delay the loading of files. When I ran OH1 on my RPi I delayed the loading of rules by about 20 seconds to ensure the items and states had been loaded and restored properly before the rules were loaded.

I have the following from the very beginning:
Strategies {
default = everyChange
}

Items {
    * : strategy = default, restoreOnStartup
}

And it doesn’t help to adapt the openhab.cfg to something like:

folder:items=20,items
folder:sitemaps=26,sitemap
folder:rules=30,rules
folder:scripts=24,script
folder:persistence=22,persist

?

This is working fine here on my side with rrd4j and mapdb persistence service.

Hmm, never saw that syntax, could you try change it to:

* : strategy = everyChange, restoreOnStartup

@sihui and danielwalter86
I did not know about this option.
I will try it out

But thanks for letting me know .

Seems to be working now as expected. Tested with Delayed_Startup item first and ended up with

folder:rules=60,rules

Thank you all !!

Andrew

The syntax is not fully explained in the wiki.
If I have 3 rules files, named r1,r2 and r3, do I have to write e.g.
folder:rules=30, r1,r2,r3 ?

Also in the example above, you are defining the scan periode.
So the persistence is scanned every 22 seconds and rules every 30 seconds.
Which, at the first scan, gives the persistences a headstart of about 8 seconds.
This assumes that the scanning of all those folders is starting at the same time. Also it implys that everything can be loaded within 30 seconds. It is stated in the wiki that the periode can be 240 second max.

If all this is true, then this can only be applied for either very fast machines or installations with a small number of items and rules.

I have about 80 rules (4000 lines of code) and about 400 items. Loading this setup takes about 3-4 miniutes. I an experiencing always the bug, that some rules are failing to load at the beginning.
The workarround I am applying, it that I am “toughing” those rules after about 1 minute again.

Is my conclusion therefore correct, that this is not applicable in such a scenario?
Or did I understand the approach wrong.