[erledigt] Hilfe beim persistieren mit influxdb2

[scotty]

Zwischeninfo:

Nach sehr vielen Tests habe ich herausgefunden, dass influxdb 2.4 die Daten speichert. Ein Zurückschreiben (beispielsweise nach einem Neustart des Containers oder des gesamten Systems) funktioniert nur, wenn jedes Item in der influxdb.persist einzeln aufgelistet wird. Mit einer Gruppe oder gar einem Platzhalter funktioniert es leider nicht nicht.
Wenn jemand noch andere Erfahrungen gesammelt hat, würde ich mich gerne mit ihm austauschen.

Meine aktuelle (unvollständige) Strategie sieht so aus:

Code: Alles auswählen

Strategies {
    everyMinute      : "0 * * * * ?"
    everyFiveMinutes : "0 0/5 * * * ?"
    everyHour        : "0 0 * * * ?"
    everyDay         : "0 0 0 * * ?"

        default = everyUpdate

}
Items {
Item1, Item2, Item3...Item150 : strategy = everyUpdate, everyFiveMinutes, restoreOnStartup
}

[scotty]

Update:
Leider kommt es beim Zurückschreiben von NumberItems zu den schon beschriebenen ERROR-Meldungen. Meine Recherchen haben ergeben, dass es die Probleme schon bei früheren Versionen gab. Eine Lösung konnte ich bisher nicht finden.

[udo1toni]

Das scheint dann nur den Teil restoreOnStartup zu betreffen, welchen ich noch nie mit InfluxDB genutzt habe. Schade eigentlich.
Auf der anderen Seite aber immerhin eine Erkenntnis, mit der man dann weiter arbeiten kann.

Tipp: Für restoreOnStartup solltest Du am besten mapDB verwenden, das ist exakt und ausschließlich zu diesem Zweck da (weshalb es auch nur den aktuellen Wert speichert und keinen Zugriff auf die Historie zulässt). Man kann beliebig viele Persistences parallel verwenden.

Und Grundsätzlich sollten Items nur dann per restoreOnStartup wiederhergestellt werden, wenn es keine vernünftige Alternativ dazu gibt (knx z.B. kann beim Start alle Items mit den Rückmeldungen zur aktiven Statusabfrage füllen, das ist viel besser als eine Annahme über einen aktuellen Status, die nur geraten ist, weil Stand von vor dem letzten Shutdown). Also besser nicht einfach mit * : strategy = everyChange,restoreOnStartup alle Items blind auf "den letzten Stand" setzen.

[scotty]

Mir geht es im Moment hauptsächlich darum, flüchtige Daten aus Dummy-Items nach einem Neustart sofort wieder zur Verfügung zu stellen. Dein Tipp mit mapDB erscheint mir daher sinnvoller. Kann in der persist dann mit Platzhaltern oder Gruppen (gIrgendwas) gearbeitet werden und muss sonst noch etwas berücksichtigt werden? Wie wird mapDB zum Beispiel konfiguriert, in der Doku finde ich nur einen Bezug auf OH 2.5 und eine mapDB.persist habe ich auch nicht gefunden.

[udo1toni]

Die *.persist Dateien sind unabhängig von der Persistence, man erstellt einfach für jede Persistence eine mit den passenden Strategies und Items.
Gewöhnlich sollte Gruppenzugehörigkeit reichen (in der *-persist dann GruppenItem* als Itemname, der * ist kein Joker, sondern der Befehl, Member Items statt das Item selbst zu persisitieren)
Da mapDB pro persistiertem Item genau einen Wert speichert, gibt es keinen Grund, noch weitere Dinge zu konfigurieren.
Das hat auch den Vorteil, dass man dort nichts "kaputtverbessern" kann

[scotty]

Danke dir, damit sollte das Thema vorerst erledigt sein.

[scotty]

Eine Frage zu deiner letzten Antwort ist jetzt doch aufgetaucht: muss ich nicht irgend wo festlegen, welche Items persistiert werden? Momentan "rödelt" mein System fast laufend und ich habe das Gefühl, dass alle Items in den Prozess einbezogen sind.

[udo1toni]

Welche Items persistiert werden, regelt die *.persist Datei.
Seit openHAB3 ist dabei das Default Verhalten, dass, wenn keine *.persist Datei für einen installierten Persistence Service vorhanden ist, alle Items mit everyMinute,everyChange persistiert werden.
Ist kein Persistence Service installiert und auch keine Default Persistence ausgewählt, so wird dennoch rrd4j als Persistence verwendet und in Ermangelung einer ddr4j.persist landen alle Items mit everyMinute, everyChange auf der Platte (äh, SD-Karte... whatever...)

Meine Meinung dazu: es wäre besser, rrd4j installiert anzuzeigen und auch default eine passende rrd4j.persist Datei anzulegen, so dass das Verhalten nachvollziehbar ist.

[scotty]

Ich habe mich deiner Meinung angeschlossen, vielen Dank noch einmal.

[udo1toni]