I am running openHAB on a RaspberryPi and have another host that runs InfluxDB in a Docker Container. openHAB is persisting values into InfluxDB. I am partly calculating these values, e.g. by taking the value a Thing reports (total consumption) and then calculate a diff on my own and adding that to the item that is persisted. So I am not persisting the reported value, but my own. This was necessary because some things started their reported consumption at 0 again, but I did not want to lose the already collected data. So far, so solvable.
Now I needed to restart all my servers. I restart openHAB frequently and restoring the state from InfluxDB always works fine, no problem. But this time, my items started at 0. I assume that was caused by the InfluxDB server not being ready when openHAB started, leading to openHAB not being able to restore the previous states from InfluxDB.
That got me thinking, that relying on an external service for what I am doing is bad as it could happen again, causing my data to be corrupted again.
My solution was to remove all restore on startup statements from my InfluxDB config and add new rules to the MapDB config (every change, restore on startup).
Is my thought process wrong, or is this some trivial thing everyone knew but me?
There is a rule template on the marketplace that does that for others who face this problem. I’m sure it does pretty much the same as your code. It’s called “MeterReading II” and can be installed from the MainUI Add-on Store.
Your thought process is sound. I always recommend using MapDB for restoreOnStartup because it handles all the Item types, doesn’t grow because it only saves one data entry, and it’s embedded so once OH comes up, it’s available no matter what.
rrd4j is also embedded, but it cannot save every data type. SQLite is also embedded, but it will save every change, not just the latest one so you have to do extra work to clean up or the DB will grow too big over time.
Any external database will cause OH to fail to perform restoreOnStartup if the DB is unavailable when OH starts up.
Using MapDB for restoreOnStartup is briefly mentioned in Getting Started:
If you need to restoreOnStartup unsupported Item types, MapDB might be a better choice for you.
But explaining in detail why is not.
This is comparing to rrd4j.
One thing to watch out for is that by default most persistence add-ons will do restoreOnStartup by default. But you don’t want more than one DB restoring states to your Items so you should create a persistence strategy that doesn’t include restoreOnStartup for external databases.
