openhabforum.de

Hallo,

Grundsätzlich funktioniert die DB
folgendes Problem:

Es soll der Durchschnittswert eines Item (Temperatur) über 30min berechnet werden Leider kam es hier immer wieder zu Problemen bei
der dahinterliegenden ausführbaren Aktion (Rule). Die Ursache habe ich jetzt ansatzweise gefunden.
Bei diesem Item wurde die Strategie "every Change" gesetzt, was dazu führt, dass wenn es keine Änderung der Temp. gibt auch keine Date
in die DB geschrieben wird somit die Berechung = NULL ergibt. Somit habe ich die Strategie auf "everyUpdate" gesetzt oder und auf "every5Minutes".
Leider bringt dies nicht den Effekt das ich jetzt alle 5min einen Eintrag habe (Teleperiod ist auf 300) sondern weiterhin nur wenn sich die Temperatur
wirklich "changed".
Hat jemand ne Idee warum das nicht funktioniert.

Wo hast Du es denn konfiguriert? Bist Du sicher, dass die Daten von der konfigurierten Persistence gelesen werden?
Hast Du openHAB schon mal neu gestartet?

Wieder mal vielen Dank an dich bzgl. deiner Antwort.

Ich hoffe das ich deine Frage richtig verstehe/beantworte.

Ich habe nur eine Persistence und nur eine Datenbank (MariaDB)
Die Änderung der Strategy habe ich in der .persist Datei vorgenommen.
Bei dem Reboot bin ich mir nicht sicher ist aber gerade ausgeführt,
denn Reboot tut immer gut... Werde es beobachten und RM geben.
Blöd ist halt das sich die Temperatur meist innerhalb von 5min ändert (Nachkommastelle)
und somit der Effekt nicht direkt ersichtlich ist.

Also, wenn Du openHAB3 verwendest, ist im Hintergrund immer auch rrd4j installiert und persistiert auch alle Items mit everyChange, everyMinute.
Wenn Du keine Default Persistence auswählst, ist rrd4j als Default Persistence ausgewählt.

Leider ist openHAB in dieser Hinsicht inkonsequent, ich hätte nichts gegen eine Voreinstellung in dieser Form, aber sie sollte dann natürlich entsprechend angezeigt werden. Stattdessen sieht man nur, dass keine Default Persistence festgelegt ist (was nun mal nicht den Tatsachen entspricht).

Wenn Du in einer Rule auf die Persistence zugreifst, kannst Du immer auch die Persistence explizit mit angeben, z.B.
Wenn Du übrigens die Default Persistence änderst, aber nicht alle Items von der neuen Default Persistence vollumfänglich persistiert werden, funktioniert die Analyze Funktion nicht mehr

Es ist Openhab in Version3.4
In den Einstellungen ist unter Persitence Service die MariaDB ausgewählt.
Die Datenbank weist auch nach Neustart des ges. System Lücken auf

2023-01-06 16:25:38.981 11.6
2023-01-06 16:20:38.973 11.8
2023-01-06 16:15:38.937 11.9
2023-01-06 16:00:38.986 10.7
2023-01-06 15:50:38.968 10.8
2023-01-06 15:45:39.014 10.7
2023-01-06 15:40:38.994 10.8

Ich setze jetzt aber nochmal exlizit die Datenbank wie von dir angegeben.

Hast Du denn mal eine Blick in die Tabelle in MariaDB geworfen? Dort müsste man ja auch sehen, ob es Lücken gibt.

Ansonsten hast Du evtl. auch einen Fehler in deiner jdbc.persist und die greift gar nicht...

Fehler gefunden!

Du hast mich auf den richtigen Weg gebracht. Meine .persist Datei hat gar nicht gegriffen.
Mich hatte bei Durchsicht der DB gewundert das hier alle Items, auch die nicht über die .persist
vorgegebene Items angelegt waren. Da ich diese Datei schon seit div. Openhab Version mitgenommen habe
hieß sie mariadb.persist und eben nicht jdbc.persist. Das ist in den gängigen Anleitungen auch nicht gut beschrieben.
Alle Einstellung in der Openhab Gui waren richtig und Openhab hat trotz dieses Fehlers ALLE Items in die Datenbank
geschrieben und gefüllt. Nachdem es nun lief und ich Änderungen in der .persist vorgenommen hatte war auch jew.
ein Neustart erforderlich.

Vielen Dank für die Hilfe und Wegweisung

Der Punkt mit den persist-Dateien ist, die heißen immer exakt wie der Persistence Service.

Es gab früher eine MySQL Persistence, eine Postgre Persistence usw., letztlich nutzen die aber unter der Motorhaube ohnehin alle jdbc (JavaDataBaseConnectivity). Die JDBC Persistence brachte dann auch noch einige Features mit, die mehr Möglichkeiten bot.
Nachteil der Zusammenfasssung: Man muss sich für eine der Datenbank Engines entscheiden, man kann nicht mehrere JDBC DB-Engines nebeneinander nutzen.

Interessanterweise gab es übrigens nie eine MariaDB Persistence ich gehe also davon aus, dass Du die Datei lediglich im Eifer des Gefechts falsch benannt hast (ist mir zu Anfang auch mal passiert)
Alternativ hätte die Persistence nie funktioniert - jedenfalls nicht unter openHAB < 3.0, und unter openHAB 3.0 ff. wäre die Datei nie aktiv gewesen.

Danke nochmal für die Antwort.

Du hast auch hier recht. Ich habe in den alten Backups nachgeschaut und tatsächlich hieß sie früher mysql.persist.
Muss ich irgendwann umbenannt haben und habe das Problem dahinter nie bemerkt....da ja alle Daten vorhanden waren.
Aber nochmal grundsätzlich die Frage bzgl. der Namensgebung der Persistence Datei, falls jemand über diesen Post hierzu kommt.
Wann muss die Datei wie heißen, oder reicht es falls nur eine jdbc existiert die auch jdbc.persist zu benennen.

LG

Ich versuche es mal komplett aufzuschreiben...

Unter openHAB3: Solange zu einem installierten Persistence Service keine <name>.persist Datei im Ordner $OPENHAB_CONF/persistence/ existiert, werden alle existierenden Items mit everyChange persistiert. Bei rrd4j werden sie zusätzlich mit everyMinute persistiert.

Möchte man die Persistence individuell steuern, so muss man für den betreffenden Persistence Service eine passende Datei anlegen, diese heißt genau wie der Service, also Die Dateien sind jeweils identisch aufgebaut: Immer wichtig im Hinterkopf zu haben: das * ist kein Joker (alle Item, deren Name mit ... anfängt), sondern die Kennzeichnung, dass stattdes Items selbst (welches eben ein Group Item ist) die Member des Group Items persistiert werden sollen.
Als Strategies stehen everyChange, everyUpdate, restoreOnStartup und die in der Datei definierten Strategies zur Verfügung (im Beispiel default und everyMinute)
Strategies können beliebig miteinander kombiniert werden. Man sollte aber darauf achten, wenn man mehrere Persistence Services nutzt, nicht an mehreren Stellen für das selbe Item restoreOnStartup zu wählen, das wäre eher ungünstig.

Gewöhnlich reicht everyChange als Strategy aus, im Fall von rrd4j werden aber zwingend Minutenwerte gebraucht. Es ist auch möglich, dass ein Item grundsätzlich seinen Zustand nicht ändert und man über die Persistence eher den Zeitpunkt speichern möchte (ich habe z.B. eine Anbindung der Klingelknöpfe. Beim Klingeln wird ON gesendet, aber eben kein OFF beim Loslassen), dann ist everyUpdate sinnvoll.
Wertet man die Daten über 3rd-Party-Tools aus, kann es passieren, dass für einen betrachteten Zeitraum keine Werte vorliegen (Grafana im Zusammenspiel mit InfluxDB), dann müsste man notfalls auch eine Cron-Strategie nutzen.

In der gezeigten *.persist Datei werden alle Items mit default persistiert, Item1 und Item2 sind davon auch betroffen, hier geht es nur darum, die unterschiedlichen Möglichkeiten zu zeigen.