[solved] [openHAB3 persistence] How to PREVENT "restore on startup"?

Setup, Configuration and Use Migration
,
1

If I understood correctly, openHAB3 automatically persists item states with reasonable default settings if a default persistence service is configured.

This inherently brings the ability to analyze historic item state without any hassle of configuring it manually. This is quite good. Love it! :+1:

Second benefit is the restore on startup which works automatically too…

This might we wanted in most but not all cases.

What, if I don’t want an item stating a “historic” state?
Think about:

  • measurements
  • alarms
  • presence
  • …?

If such items got “restored on startup” they may show wrong data. In some cases it would be better letting the item NULL until an actual status update/command got received instead of setting the item to an old and probably wrong state. Better to have no state than a wrong state.

Another case with unwanted restore on startup is related to charting of derived persisted values - discussed here: [openHAB 3 Main UI] How to configure my charts? - #9 by curlyel

Question: How to change the default restore-on-startup behaviour in openHAB3 for specific items preventing them from been restored with potentially wrong historic states?

1 Like
2

I think you can create a custom rrd4j.persist that explicitly has no RestoreOnStartup that should override the default behavior.

But I would not mess with it, restore on startup isn’t causing your “wrong” states.
Your rules on startup need to take care to reinitialize/sync state changes that may have happened while OH was down, if they don’t handle that properly that is where the problem is.

1 Like
3

Good point. Just thought the same. :wink:
Admittedly, I currently trying this out to see how this affects the “default” persisting/restoring behaviour and if this is a way to prevent “restoring” for some items.

Agree basically. But when does the restore on startup happen? So, even if I have a good procedure to initialize my items properly, would’nt restore on startup interfere here nevertheless? If yes, I should be prepared to deal with the “flapping” item state e.g.

from NULL via RESTORED-STATE to CORRECT-STATE

I think, even in case I have sophisticated initialization rules, preventing restore-on-startup for some crucial items might remain desired :wink:

4

As said above, I’ve tried a manually configured rrd4j.persist to prevent some items from beeing restored on startup.

EDIT: I’ve “reversed” my initial approach with “excluding” some items from been restored. Now I’m putting all items which should be restored in a dedicated group. Here is the updated post:

First, I created an additional group for all items, which should get restored after startup.

Group gRestoreOnStartup

Second, I added a rrd4j.persist file to the persistence folder:

Strategies {
    everyMinute : "0 * * * * ?"
}

Items {
    *                       : strategy = everyChange, everyMinute
    gRestoreOnStartup*      : strategy = everyChange, everyMinute, restoreOnStartup
}

As new default, all items get persisted but not restored. Just items belonging to gRestoreOnStartup will be restored after restart.

I guess this meets the need.