Persistence logging - Wo Ergebnisse
-
- Beiträge: 28
- Registriert: 9. Jan 2024 18:00
Persistence logging - Wo Ergebnisse
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.
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.
- udo1toni
- Beiträge: 15087
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Persistence logging - Wo Ergebnisse
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.
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
-
- Beiträge: 28
- Registriert: 9. Jan 2024 18:00
Re: Persistence logging - Wo Ergebnisse
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
____________________________________________________________________________
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: []
- udo1toni
- Beiträge: 15087
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Persistence logging - Wo Ergebnisse
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).
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.
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).
Ja, wie gesagt, entweder, die Meldung ist korrekt, weil Du dieses Item ja nicht gelistet hastCode: Alles auswählen
Ignoring item HTTP27_laufzeit27

openHAB4.3.2 stable in einem Debian-Container (bookworm) (Proxmox 8.3.3, LXC), mit openHABian eingerichtet
-
- Beiträge: 28
- Registriert: 9. Jan 2024 18:00
Re: Persistence logging - Wo Ergebnisse
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
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
- udo1toni
- Beiträge: 15087
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Persistence logging - Wo Ergebnisse
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.
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

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
-
- Beiträge: 4
- Registriert: 2. Sep 2022 01:21
Re: Persistence logging - Wo Ergebnisse
Hallo Udo!
Kann man eigtl. eine rrd4j Persistance wie z. B. eine SQL-Datenbank abfragen?
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
Diverse Shellys
Diverse NOUS A1T
ESP32 zum Sammeln von Daten der Heizung und Auslesen des Smartmeters
-
- Beiträge: 28
- Registriert: 9. Jan 2024 18:00
Re: Persistence logging - Wo Ergebnisse
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.
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.
- udo1toni
- Beiträge: 15087
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Persistence logging - Wo Ergebnisse
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
-
- Beiträge: 4
- Registriert: 2. Sep 2022 01:21
Re: Persistence logging - Wo Ergebnisse
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
Diverse Shellys
Diverse NOUS A1T
ESP32 zum Sammeln von Daten der Heizung und Auslesen des Smartmeters