Persistence logging - Wo Ergebnisse

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Antworten
kdb
Beiträge: 28
Registriert: 9. Jan 2024 18:00
Answers: 0

Persistence logging - Wo Ergebnisse

Beitrag von kdb »

OH 3 wurde mit UI eingerichtet mit Standard Persistene rrd4j und läuft stabil auf Raspberry 4.
Unter Einstellung können unter persistence configuration für Add-on logging settings Werte wie default, Error … eingestellt werden.
Was wird gesteuert und wo findet man die Ergebnisse ?
Hintergrund der Frage ist, dass ab und an ( ohne erkennbares Muster ) Daten aufgezeichnet werden - oder auch nicht.
Reboot beeinflusst das Verhalten nicht.

Benutzeravatar
udo1toni
Beiträge: 15087
Registriert: 11. Apr 2018 18:05
Answers: 239
Wohnort: Darmstadt

Re: Persistence logging - Wo Ergebnisse

Beitrag von udo1toni »

Man kann grundsätzlich für jedes Modul in openHAB eine eigene Logger Konfiguration anlegen. Das beinhaltet dann das Logverhalten nur für dieses eine Modul.
Loglevel
DEFAULT -> Der Loglevel wird vom Vorfahren geerbt.
OFF -> es findet unter keinen Umständen Logging statt.
ERROR -> es werden nur (schwere) Fehler geloggt.
WARN -> Es werden zusätzlich auch Warnungen geloggt.
INFO -> Es werden zusätzlich auch reine Informationen geloggt.
DEBUG -> Es werden zusätzlich noch Debug-Informationen geloggt.
TRACE -> Es werden zusätzlich bei der Abarbeitung des Codes für quasi jede Programmzeile Informationen geloggt (Soweit das vom Entwickler so vorgesehen wurde).

All diese Logzeilen landen gewöhnlich in der Datei openhab.log, allerdings kann man den Logger sehr weitgehend konfigurieren und darüber Logausgaben auch in andere Dateien umlenken oder auch zusätzlich an anderer Stelle erscheinen lassen (z.B. Karaf Konsole)

Was meinst Du mit "Daten werden aufgezeichnet"? Das ist der Sinn einer Persistence. Im Fall von rrd4j sollten alle Items, die numerische Werte liefern mindestens einmal pro Minute in der Persistence gespeichert werden, das ist für rrd4j essenziell.
openHAB4.3.2 stable in einem Debian-Container (bookworm) (Proxmox 8.3.3, LXC), mit openHABian eingerichtet

kdb
Beiträge: 28
Registriert: 9. Jan 2024 18:00
Answers: 0

Re: Persistence logging - Wo Ergebnisse

Beitrag von kdb »

Hallo, zu nächst vielen Dank für die Antwort.
Vielleicht liegt irgendwie eine Blockade bei mir vor oder ich habe etwas überlesen, deshalb ausführlicher was ich mit "aufzeichnen" meine.
Ich habe über UI Einstellungen RRD4J configuration meine zu persistierenden Items ausgesucht.
Der code hierfür ist ganz am Ende über cut & paste eingefügt.
Im Verzeichnis .../rdd4j liegen zahlreiche Files vor. Es gibt sehr viele Files der Grösse 0, deren Name nicht mit den Namen der configuration übereinstimmt. z.B. Daten über Memory Belegung des Raspberry ( Local_Computer ... )
Andere , wie z.B. mqttSmartMeter_GesamtEinspeisung oder HTTP21_temperatur_21 werden ständig mit 0 Byte Grösse angezeigt, obwohl sich die Werte minütlich ändern.
Die Meldungen aus dem log-file passen irgendwie auch nicht zur configuration
- RRD4jPersistenceService] - Ignoring item HTTP27_laufzeit27 ( Woher ?? )
bzw. sind für mich unerklärlich
-Invalid file header : File [/var/lib/openhab/persistence/rrd4j/mqttSmartMeter_Phase_2.rrd] is not a RRD4J RRD file

Ist erkennbar, woran das Problem liegen könnte ?
Welche Lösung wird empfohlen ?

Vielen Dank für jegliche Tips und Hinweise.

Klaus-Dieter Brinkmann
____________________________________________________________________________

Code: Alles auswählen

configurations:
  - items:
      - Erdgeschoss
      - RST_Heizkorpertemperatur_5_Flur_Eingang_Aktuelle_Temperatur
      - RST_Heizkorpertemperatur_5_Flur_Eingang_Luftfeuchtigkeit
      - WM10
    strategies:
      - everyChange
    filters: []
  - items:
      - RST_Heizkorperthermostat_Wohnzimmer*
      - RST_Heizkorpertemperatur_3_Schlafzimmer_Aktuelle_Temperatur
      - RST_Heizkorpertemperatur_3_Schlafzimmer_Luftfeuchtigkeit
      - RST_Heizkorpertemperatur_4_Span_Salon_Aktuelle_Temperatur
      - RST_Heizkorpertemperatur_5_Flur_Eingang_Aktuelle_Temperatur
      - RST_Heizkorperthermostat_Wohnzimmer_Aktuelle_Temperatur
    strategies:
      - everyChange
    filters: []
  - items:
      - HTTP21*
      - HTTP22*
      - HTTP23*
      - HTTP24*
      - HTTP25*
      - HTTP26*
      - HTTP27*
      - HTTP29*
      - HTTPbus*
      - HTTP21_feuchtigkeit21
      - HTTP21_temperatur21
      - HTTP22_feuchtigkeit22
      - HTTP22_temperatur22
      - HTTP23_feuchtigkeit23
      - HTTP23_temperatur23
      - HTTP24_feuchtigkeit24
      - HTTP24_temperatur24
      - HTTP25_feuchtigkeit25
      - HTTP25_temperatur25
      - HTTP26_feuchtigkeit26
      - HTTP26_temperatur26
      - HTTP27_feuchtigkeit27
      - HTTP27_temperature27
      - HTTP29_feuchtigkeit29
      - HTTP29_temperatur29
    strategies:
      - everyChange
    filters: []
  - items:
      - HTTPbus_bus_hausnach
      - HTTPbus_bus_hausvor
      - HTTPbus_bus_temp
      - HTTPbus_bus_treuganach
      - HTTPbus_bus_treugavor
    strategies:
      - everyChange
      - everyHour
    filters: []
  - items:
      - mqttSteckdose0_Leistungsaufnahme
      - mqttSteckdose0_Verbrauch_Gesamt
      - mqttSteckdose0_Verbrauch_Heute
      - mqttSteckdose1_Leistungsaufnahme
      - mqttSteckdose1_Verbrauch_Gesamt
      - mqttSteckdose1_Verbrauch_Heute
      - mqttSteckdose2_Leistungsaufnahme
      - mqttSteckdose2_Verbrauch_Gesamt
      - mqttSteckdose2_Verbrauch_Heute
    strategies:
      - everyChange
    filters: []
  - items:
      - mqttSmartMeter_GesamtEinspeisung
      - mqttSmartMeter_GesamtVerbrauch
      - mqttSmartMeter_Leistung_Gesamt
      - mqttSmartMeter_Phase_1
      - mqttSmartMeter_Phase_2
      - mqttSmartMeter_Phase_3
      - mqttSteckdose0_Verbrauch_Gesamt
      - mqttSteckdose1_Verbrauch_Gesamt
      - mqttSteckdose2_Verbrauch_Gesamt
    strategies:
      - everyChange
      - everyHour
    filters: []
  - items:
      - mqttMESSFUEHLER_TemperaturLang
    strategies:
      - everyChange
      - everyMinute
    filters: []
  - items:
      - JahresEinspeisung
      - mqttSmartMeter_GesamtEinspeisung
    strategies:
      - everyChange
      - everyHour
    filters: []
  - items:
      - mqttSmartMeter_Leistung_Gesamt
    strategies:
      - everyChange
      - everyHour
    filters: []
  - items:
      - JahresEinspeisung
    strategies:
      - everyHour
    filters: []
cronStrategies:
  - name: everyMinute
    cronExpression: 0 * * ? * *
  - name: everyHour
    cronExpression: 0 0 * * * ?
  - name: everyDay
    cronExpression: 0 0 0 * * ?
defaultStrategies:
  - everyChange
thresholdFilters: []
timeFilters: []
equalsFilters: []
includeFilters: []

Benutzeravatar
udo1toni
Beiträge: 15087
Registriert: 11. Apr 2018 18:05
Answers: 239
Wohnort: Darmstadt

Re: Persistence logging - Wo Ergebnisse

Beitrag von udo1toni »

Also, erst mal, wie oben schon angedeutet, alle Items, die per rrd4j persistiert werden sollen, müssen zwingend(!) mit der Strategy everyMinute persistiert werden. Zusätzlich zu everyMinute kannst Du natürlich noch andere Strategies verwenden, also everyChange oder everyUpdate. Vergiss bitte andere Strategies wie everyHour oder everyDay, diese sind default nicht konfiguriert und sind bei rrd4j nicht sinnvoll, weil (wie erwähnt) everyMinute zwingend vorgeschrieben ist.
Wenn Du everyMinute weg lässt, kann rrd4j nicht arbeiten und tut dies dann auch nicht. In der Folge werden allenfalls kaputte Dateien geschrieben.

Abhilfe: Du konfigurierst alle Items, die Du persistieren willst, mindestens mit everyMinute und löschst alle 0-Byte-Dateien aus dem Verzeichnis rrd4j.

Dann HTTP21* bis HTTPbus* und RST_Heizkorperthermostat_Wohnzimmer*: Hast Du tatsächlich Group Items (!) deren Namen
HTTP21, HTTP22, HTTP23, HTTP24, HTTP25, HTTP26, HTTP27, HTTP29, HTTPbus und RST_Heizkorperthermostat_Wohnzimmer lauten (exakt diese Namen)?
Weil: Der * am Ende des Itemnamens bedeutet, dass nicht dieses Item persistiert wird, sondern die Member des Group Items mit diesem Namen. Es handelt sich also nicht um einen Joker, sondern um die Markierung dieser Spezialfunktion (persistiere die Member, nicht das Items selbst).

Code: Alles auswählen

Ignoring item HTTP27_laufzeit27
Ja, wie gesagt, entweder, die Meldung ist korrekt, weil Du dieses Item ja nicht gelistet hast ;) oder dieses Item ist Teil einer Gruppe (z.B. HTTP_27), liefert aber keine minütlichen Daten und wird entsprechend gar nicht persistiert, weil rrd4j die Daten nicht schreiben kann.
openHAB4.3.2 stable in einem Debian-Container (bookworm) (Proxmox 8.3.3, LXC), mit openHABian eingerichtet

kdb
Beiträge: 28
Registriert: 9. Jan 2024 18:00
Answers: 0

Re: Persistence logging - Wo Ergebnisse

Beitrag von kdb »

Danke für die schnelle Antwort. Zwingend 1 Minute hatte ich tatsächlich überlesen.
Was machen dann every Change .. für einen Sinn ? Geringere Änderungen sind doch eher unwahrsccheinlich.
Wäre es in meinem Falle nicht am Einfachsten, wenn ich in configuration einfach alle items zusammenfasse ?
Wo kommen die in configuration nicht angegeben Dateien / Daten her ?

Vielen Dank

Benutzeravatar
udo1toni
Beiträge: 15087
Registriert: 11. Apr 2018 18:05
Answers: 239
Wohnort: Darmstadt

Re: Persistence logging - Wo Ergebnisse

Beitrag von udo1toni »

Erst mal: Es gibt verschiedene Persistences. Aber alle Persistences sind gleich konfigurierbar, unabhängig davon, ob die bestimmte Persistence hierfür überhaupt geeignet ist.
rrd4j ist eine RoundRobin Datenbank, das heißt, jedes Mal, wenn ein Wert in ide Datenbank geschrieben wird, wird auch ein Wert gelöscht (nämlich der älteste). Gleichzeitig arbeitet rrd4j mit verschiedenen Containern mit unterschiedlicher zeitlicher Auflösung. Die jüngsten Daten stehen in Zehn-Sekunden-Auflösung zur Verfügung, d.h. es dürfen maximal 6 Messwerte pro Minute erfasst werden. Auf der anderen Seite möchte man aber möglichst genaue Werte erfassen, auch in der zeitlichen Auflösung. Wenn ein Wert sich ändert, soll also vielleicht dennoch der Wert erfasst werden, mit einem Sub-Sekunden genauen Zeitstempel. Intern werden die Werte automatisch verrechnet und der Durchschnittswert wird dann in den nächstgröberen Container geschrieben, bis hin zum gröbsten Container, der dann Messwerte für mehrere Jahre enthält, aber halt nur den Tagesdurchschnitt. Durch dieses RoundRobin Verfahren hat man eine grobe Auflösung über einen langen Zeitraum und eine feine Auflösung über einen kurzen Zeitraum, was dem normalen Datenzugriff entspricht (die letzten Stunden sind im Detail interessant, die letzten Jahre eher als grober Vergleichswert). Udn weil die Anzahl der Datensätze konstant ist, ist auch die Dateigröße konstant, was ungemein praktisch ist :)
Wenn Du Items nicht in der Persistence konfigurierst, werden diese auch nicht persistiert, mit einer Ausnahme, und zwar, wenn Du gar keine Konfiguration anlegst, dann wird openHAB einfach alle Items mit everyMinute, everyChange persistieren - um es Einsteigern zu erleichtern...
Nun gibt es aber ein Problem, das besteht darin, dass openHAB vollständig asynchron läuft. Das heißt, beim Start des Systems werden "einfach" mehr als hundert Threads gestartet, jeder mit einer bestimmten Aufgabe. Es gibt dabei keine bestimmte Reihenfolge, und die Threads erledigen einfach ihren Job. Z.B. gibt es einen Thread, der rrd4j ausführt, einen weiteren Thread, der Items anlegt, und noch einen Thread, der die Persistence Konfiguration einliest. Es kann also passieren, dass Items bereits angelegt sind und ide Persistence schon läuft, aber keine Konfiguraiotn in die Persistence hineingeladen wurde. Und in diesem Moment werden dann halt alle Items persistiert.
Gewöhnlich passiert das aber nur sehr selten, und es stört ja nicht weiter ;) solange man nicht über Dateien stolpert, die es eigentlich nicht geben dürfte.
Natürlich kann es auch sein, dass ein Item bereits existierte, bevor man überhaupt die Persistence konfiguriert hat, dann wird es auch für dieses Item Daten geben.
Ob für Deine Daten eine rein zeitliche Erfassung sinnvoll ist, kommt auf Deine Daten an. Mein Stromzähler liefert z.B. jede Sekunde zwei Messwerte (Bezug und Einspeisung), die möchte ich schon sekundengenau erfassen (immer dran denken, rrd4j errechnet automatisch die korrekten Durchschnittswerte), entsprechend ist da bei mir auf jeden Fall everyChange zusätzlich angegeben.
openHAB4.3.2 stable in einem Debian-Container (bookworm) (Proxmox 8.3.3, LXC), mit openHABian eingerichtet

Brammel
Beiträge: 4
Registriert: 2. Sep 2022 01:21
Answers: 0

Re: Persistence logging - Wo Ergebnisse

Beitrag von Brammel »

Hallo Udo!

Kann man eigtl. eine rrd4j Persistance wie z. B. eine SQL-Datenbank abfragen?
OH 3.3 auf QNAP TS453A
Diverse Shellys
Diverse NOUS A1T
ESP32 zum Sammeln von Daten der Heizung und Auslesen des Smartmeters

kdb
Beiträge: 28
Registriert: 9. Jan 2024 18:00
Answers: 0

Re: Persistence logging - Wo Ergebnisse

Beitrag von kdb »

Danke für die gute Erklärung.
Problemlösung dann doch überraschend einfach : Nach Löschen aller Datenbank-Dateien mit Größe 0 waren die Fehlermeldung im log File verschwinden.
Dann Anpassung auf every Minute und alles läuft wie gewünscht.👍

Benutzeravatar
udo1toni
Beiträge: 15087
Registriert: 11. Apr 2018 18:05
Answers: 239
Wohnort: Darmstadt

Re: Persistence logging - Wo Ergebnisse

Beitrag von udo1toni »

Brammel hat geschrieben: 5. Feb 2025 09:47 Kann man eigtl. eine rrd4j Persistance wie z. B. eine SQL-Datenbank abfragen?
Es gibt Bibliotheken um auf rrd4j zuzugreifen.
Aufgrund des inneren Aufbaus ist eine Abfrage aber nicht so wie bei einer "gewöhnlichen" Datenbank möglich.
rrd4j ist z.B. nicht relational. Es gibt auch keine Daten"bank" im herkömmlichen Sinne, sondern nur einzelne Tabellen.

Es gibt ein (altes) Tool, den rrd Inspector, siehe hier: viewtopic.php?t=5839
openHAB4.3.2 stable in einem Debian-Container (bookworm) (Proxmox 8.3.3, LXC), mit openHABian eingerichtet

Brammel
Beiträge: 4
Registriert: 2. Sep 2022 01:21
Answers: 0

Re: Persistence logging - Wo Ergebnisse

Beitrag von Brammel »

Danke für den Hinweis.
OH 3.3 auf QNAP TS453A
Diverse Shellys
Diverse NOUS A1T
ESP32 zum Sammeln von Daten der Heizung und Auslesen des Smartmeters

Antworten