Also, „dieses Problem“ ist ja mal etwas unspezifisch...
Grundsätzlich sollte man genau schauen, welche Items man in Betrieb hat, mit welchen Bindings sie verbunden sind usw.
Ich habe z.B. knx in Betrieb. Wenn man das korrekt konfiguriert, lädt es beim Start von openHAB alle Status direkt vom Bus (natürlich muss man dafür sorgen, dass die Status auch zur Verfügung stehen). Warum sollte ich diese Status also aus einer Datenbank laden, die eventuell überholte Status zur Verfügung stellt?
Gleiches gilt für Wetter-Items, Uhrzeit, Astro usw.
Man sollte also genau schauen, welche Items nach dem Start von openHAB im NULL-Status hängen bleiben, weil das entsprechende Binding keine Daten liefert. Entweder, man nutzt dann gezielt eine Rule, die per System started triggert und dafür sorgt, dass die Items mit den korrekten Status gefüllt werden, oder man holt sich die letzten bekannten Status nur für diese Items aus einer Persistence.
Für diese (und nur für diese) Aufgabe bietet sich mapdb an, weil es ausschließlich den letzten Status zur Verfügung stellt. Am besten erstellt man dann ein Group Item gROS (für groupRestoreOnStartup) und weist jedem der Items, die wiederhergestellt werden sollen, zusätzlich diese Gruppe zu.
Dann installiert man noch die mapdb Persistence und legt im Ordner $OPENHAB_CONF/persistence/ eine Datei mapdb.persist an. In dieser Datei definiert man lediglich folgendes:
Code: Alles auswählen
Items {
gROS* : strategy = everyChange,restoreOnStartup
}
Dies sorgt dafür, dass jede Änderung eines Items, welches der Gruppe gROS angehört, in mapdb gespeichert wird. Weiterhin wird der Status dieser Items beim Systemstart aus der mapdb Persistence wiederhergestellt. Ein Setzen der default Persistence ist dazu nicht notwendig!
Prinzipiell kann man auch mit einem einfachen Stern alle Items wiederherstellen lassen, aber das ist (habe ich ja schon erläutert) keine gute Idee.
Gesendet von iPad mit Tapatalk