Persistence mit Logback

[pschauder]

Hallo,

ich habe mich jetzt ein paar Tage mit openhab beschäftigt und habe jetzt die Notwendigkeit, einige Einstellungen über einen Serverrestart zu retten. Dazu sollte nach meinem Verständnis 'persistence' benutzt werden. Ich habe als im Wiki gelesen und mich für die Logback Version entschieden.
- persistence add-on installiert
- logging.persist in ..../configurations/persistence erstellt
- kurze Regel eingefügt:

Strategies {
default = everyChange,everyUpdate
}
Items {
DG_Automode -> "testlog" : strategy = everyChange, restoreOnStartup
}
Der einzige "Erfolg" ist eine Fehlermeldung im openhab.log:
23:39:18.717 WARN o.o.c.p.i.PersistenceManager[:383]- Failed to restore item states as persistence service 'logging' can not be queried.

Ich hab nur keine Idee, was der Grund dafür sein könnte. Was kann ich tun?
Gruß
Peter

[thoern]

Failed to restore item states as persistence service 'logging' can not be queried.

Denk mal über diesen Satz genau nach...
=> Für Queries solltest du dich für einen anderen Persistence-Service entscheiden - so würde ich das zumindest interpretieren. Nimm RRD. Damit geht es und wachsen tun die rrd-Files auch nicht.

Gruß,
thoern

[pschauder]

Naja, eigendlich will ich (derzeit) nur den einen oder anderen Schalterstatus über einen reboot retten...einen query verwende ich meines wissens nicht...Die Meldung kommt beim booten des Systems (bzw starten vom openHAB).
Ich hab mir die Meldung schon längere Zeit angeschaut und habe sie so verstanden, dass der Logback Services, denn das sollte ja hier der 'persistent service' sein, nicht abgefragt (queried) werden kann. Andererseits ist er aber sehr wohl in der Lage, einen Eintrag in der Datei ..../logs/testlog zu erzeugen.

Das gehört für mich irgendwie nicht zusammen. Und für den Anwendungsfall 'speichern eines internen Zustands' würde ich rrd doch ehrer als nicht geeignet sehen; da geht es doch eher darum, auch statistische Infos auswerten zu können, oder?

Gruß
Peter

P.S. aber du hast recht.... irgendwo im Kleingedruckten hab ich gefunden, dass: Note that some options might only be good for exporting data (e.g. IoT services or log files) und unter die Logfiles fällt auch LogBack...
Danke fürs schupsen in die neue Richtung.

[thoern]

Naja, eigendlich will ich (derzeit) nur den einen oder anderen Schalterstatus über einen reboot retten...

Das habe ich schon so verstanden.

einen query verwende ich meines wissens nicht...

Doch! Denn genau das macht die Option "restoreOnStartup"

Und für den Anwendungsfall 'speichern eines internen Zustands' würde ich rrd doch ehrer als nicht geeignet sehen; da geht es doch eher darum, auch statistische Infos auswerten zu können, oder?

Ja, normalerweise wird RRD für statistische Auswertungen oder genauer gesagt, zur Erzeugung von Graphen verwendet. Dazu legt es die über einen Zeitraum ermittelten Werte in einer Round-Robin-Database (RRD) ab. Genau das wiederum macht sich "restoreOnStartup" zu nutze und holt sich nach dem Restart aus dem jeweiligen RRD-Database-File den letzten abgespeicherten Wert.

P.S. aber du hast recht.... irgendwo im Kleingedruckten hab ich gefunden, dass: Note that some options might only be good for exporting data (e.g. IoT services or log files)

Der Satz geht noch weiter:
...while others can be easily queried as well and hence be used for providing historical data for openHAB functionality.

"functionality" ist in diesem Fall auch "restoreOnStartup".

Gruß,
thoern

[pschauder]

Hi,

danke für die ausführliche Antwort, aber ich scheine zu blöd zu sein.

Ich hab gestern nochmal mit rrd4j und db4o probiert, aber es ist mir nicht geglückt den Status von DG_Automode zu restaurieren. Scheinbar ist er nach dem Neustart undefiniert und daraus schließe ich, das er entweder nicht gespeichert wurde (dagegen spricht, dass ich ihn in der LogBack Version im Log gefunden habe) oder er wird nicht wieder gelesen (wohl eher).
So wie du schreibst, gehört zu der 'functionality' von rrd4j ja eben das restoreOnStartup, somit sollte das doch dann auch funktionieren. Oder kann es sein, das meine Testrule vor dem restore abgearbeitet wird?

Gruß
Peter

[thoern]

Hi,

ich mache genau das was du möchtest mit folgender RRD-Persistence:

cat rrd4j.persist
// persistence strategies have a name and a definition and are referred to in the "Items" section
Strategies {
        // for rrd charts, we need a cron strategy
        everyMinute : "0 * * * * ?"
}

Items {
        loadAverage1min : strategy = everyMinute, restoreOnStartup
        IPWETemp, IPWEHumidity, IPWEWind : strategy = everyMinute, restoreOnStartup
        Helligkeit_Carportdurchgang : strategy = everyMinute
        SetpointTemperature_EG_Bad, SetpointTemperature_EG_Kueche, SetpointTemperature_DG_Bad : strategy = everyChange, restoreOnStartup
}

Hier werden beispielsweise meine Sollwerttemperaturen (SetpointTemperature_XXX)nach dem Restart aus der RRD-Aufzeichnung wieder restauriert.


Befinden sich die RRD files im openhab/etc/rrd4j Verzeichnis?

Gruß,
Thomas

[pschauder]

Hi Thomas,

der entscheidende Punkt scheint everyMinute zu sein. Ich hab das noch nicht verlangsamt, aber so funktioniert es...

Vielen Dank für die Hilfe. Jetzt kann ich wieder nach neuen Problemen suchen:-)

Gruß
Peter

[thoern]

Hi Thomas,

der entscheidende Punkt scheint everyMinute zu sein. Ich hab das noch nicht verlangsamt, aber so funktioniert es...

Hmm, eigentlich nicht. Schau dir meine Setpoint-Items an. Da gibt es auch nur everyChange! everyMinute brauchst du nur, wenn du Charts erzeugen möchtest.

[klayer]

Meine Erfahrung mit der Persistence sind auch durchwachsen. Ich nutze rdd4j.

1. Bug: Es scheint, dass die Restore Funktion asynchron mit der rule Engine started. Es kann also sein, dass die rule Engine schon auf items zugreifen will, diese aber noch "restored" wurde und somit undefined sind.
Workaround. Die Rules, die von persistierten Variablen abhängig sind, für eine bestimmte Zeit maskieren. Diese Zeit mit Trial und Error "herausmessen"

2. Bug: Ich habe es nicht hinbekommen, ein Item vom Type "DateType" zu persistieren. Use Case wäre das Mitschreiben eines Kalenderdatums, an dem eine Messung beginnt.
Vermutlicher Workaround. Das Kalenderdatum in eine Number konvertieren und dann das Item Number speichern.