How does restoreOnStartup work?

For many items I use restoreOnStartup, but I would know how does it exactly work and what are limitation.
Below my questions:

  • does this mechanism always restore values for all defined items? To be 100% sure that values are not nulls in rule that starts during startup I have following actions:

      if(ArmIntruderAlarmDelayCfg.state==NULL) {
      		ArmIntruderAlarmDelayCfg.sendCommand(4)
      		logInfo( "FILE", "Intr_startup: ArmIntruderAlarmDelayCfg set to [4]")
      	} else {
      		logInfo( "FILE", "Intr_startup: ArmIntruderAlarmDelayCfg [" + (ArmIntruderAlarmDelayCfg.state  as DecimalType).intValue + "]")
      	}
    

In many situation such rule is executed before “restoreOnStartup” and I have feeling that system does not restore values that are different than null.

  • does restoreOnStartup restore values for all Items? At least in 2.1 I had a feeling that in many situation old values were not restored.

  • is it possible what values were/were not restored during startup, any log?

  • is it possible to check if restore was completed during startup?

Michal Szymanski

Per the doc’s
When restarting your openHAB installation you may find there are times when your logs indicate some Items have the state, UNDEF . This is because, by default, Item states are not persisted when openHAB restarts - even if you have installed a persistence add-on. In order for items to be persisted across openHAB restarts, you must define a restoreOnStartup strategy for all your items. Then, whatever state they were in before the restart will be restored automatically.

When OH restarts there is no specific order of what’s loaded first. If you watch the log it shows items as undef/null then after a minuet or so it’s value will change to the last known state. This works for all item that you have listed in persistence.

1 Like

Just to elaborate a bit on H102’s response.

  • restoreOnStartup only restores the state on those Items that are defined in the .persist file to be restored.

  • those Items must also have a saving strategy (e.g. everyChange) or else nothing ever gets written to the database to restore

  • NULL does not get saved to persistence

  • as mentioned, items, rules, and persistence load at the same time so it is possible because of a bug for a Rule to start running before all your items have been loaded or restored from persistence. Also, some DBs will be slower than others. Typically, the embedded DBs will be faster than an external DB.

  • I think you can watch events.log and you should see changed events on each Item as they get restored from the DB. I’ve not actually done this so I could be wrong. You can probably put the persistence add-on into trace logging and see the restore queries there.

  • I know of no way off hand to determine whether restoreOnStartup completed.

2 Likes