dbLog: manche readings nur in current ablegen - nicht in history

[fhem024]

Hallo zusammen,
ich weiß, man kann Werte komplett ignorieren. Ich habe nun aber den use case, dass ich einen Wert nicht komplett ignorieren möchte, sondern nur in current haben möchte (also nicht in history). DbLog ist so konfiguriert, dass alle Daten in current und history geschrieben werden und das muss / soll auch so bleiben.

Der konkrete use case ist, dass ein Sender Device einen zyklischen Wert ausgibt - konkret die Uhrzeit. Diesen Wert würde ich gerne als Basis für einen Watchdog verwenden, der beim Ausbleiben nach definierter Zeit eine entsprechende Aktion durchführen kann (einen Reboot des Senders via curl).

Ich gehe mal davon aus, dass man den Watchdog nicht auf ignorierte readings ansetzen kann. Daher der Wunsch, dass die übertragene Uhrzeit nur in der current-Tabelle aufschlägt aber nicht in der history Tabelle.
Gibt es irgendwo die Möglichkeit, eine derartige Weiche zu konfigurieren?

Danke
fhem024

[betateilchen]

Einfachste Lösung mit DbLog: ein zweites DbLog device anlegen.


Das geht aber prinzipiell doch auch einfacher und ohne dblog?

Bei mir wird ein raspberry per reboot neu gestartet, wenn die Datei /opt/fhem/log/fhem.heartbeat nicht regelmäßig aktualisiert wird.

Code Auswählen Erweitern

define at_heartbeat at +*00:01:00 {qx(touch /opt/fhem/log/fhem.heartbeat)}

Der watchdog auf Betriebssystemebene überwacht diese Datei und wenn sie länger als 3 Minuten nicht aktualisiert wird, erfolgt ein reboot.

Das Aktualisieren einer solchen "heartbeat-Datei" kannst du natürlich auch per notify auf das reading Deines Senders ausführen.

[fhem024]

Danke betateilchen,
die Idee, das auf Linux-Ebene direkt zu machen, ist hier wohl kaum machbar, weil ich auf Linux-Ebene gar nicht bemerke, ob mein mqtt-Sender (eine Schnittstellenkarte einer Heizung) nicht mehr funktioniert. Es ist ja nicht so, dass die nicht mehr kommunizieren würde. Das tut sie ja schon (sonst könnte man ja auch nicht via curl einen reboot der Karte auslösen). Die sendet nur(!) keine Daten mehr. Das bekommt aber lediglich das fhem mqtt-device mit durch das Ausbleiben von Daten. Eigentlich gehört diese Funktion in das Gateway ism7mqtt. Alles andere sind mehr oder weniger üble workarounds. Naja, mal beobachten, wie sich das Thema weiter verhält.

Wie ich das mit einer zweiten dblog Instanz machen soll, ist mir nicht ganz klar. Die würde dann in die gleiche DB schreiben (ich hoffe, da wird row level locking genutzt (mariadb)). Mir ist aber nicht klar, wie ich es dann schaffen soll, dass nur ein einziger Datensatz dieses Devices von der zweiten Instanz bearbeitet wird - alles andere von der ersten.

Gruß
fhem024

[betateilchen]

Wie ich das mit einer zweiten dblog Instanz machen soll, ist mir nicht ganz klar. Die würde dann in die gleiche DB schreiben

Natürlich solltest Du das trennen und eine zweite Datenbank für das zweite device anlegen.
Und dann hast Du mehrere Möglichkeiten. Entweder, Du konfigurierst das device so, dass nur ein einziges reading gelogged wird oder Du attributierst diese Instanz so, dass sie den DbLogType = current besitzt, dann wird überhaupt keine history Tabelle geschrieben.

[betateilchen]

Übrigens verstehe ich immer noch nicht, warum Du DbLog verwenden möchtest, um zu Erkennen, ob ein reading regelmäßig aktualisiert wird. Dafür gibt es wahrlich simplere Lösungen.

[fhem024]

Ich bestehe nicht auf die DbLog für diesen Zweck. Mein primäres Ziel ist, dass diese (inhaltlich) sinnlosen "Daten" eigentlich nirgendwo auf der Platte (SD-Card) landen. Wenn das auch noch anders geht, lerne ich sehr gerne dazu! Irgendwie brauche ich eben einen watchdog, bei dem die Uhrzeit regelmäßig landet und der entsprechend reagiert, wenn sie nach einer bestimmten Zeit nicht mehr kommt.

[fhem024]

Ich habe nun das Thema gelöst. Eigentlich trivial. Hintergrund war, dass ich ein Missverständnis hatte in der konkreten Auswirkung von DbLogExclude und suppressReading (letzteres hatte ich hier aktiv ursprünglich für genau dieses reading). Bei DbLogExclude wird das Reading durchaus noch verarbeitet (aber nicht mehr gespeichert (falls auch FileLog deaktiviert ist)), während suppressReading das Reading von Anfang an verwirft (die Verarbeitungschain im Prinzip also gar nicht mehr erreicht).

Auf der Basis (DbLogExclude=Reading1,Reading2,...) im Device kann man nun Readings durchaus noch verarbeiten und damit den watchdog draufsetzen.

Ja, ich weiß, in diesem Szenario werden die Readings auch nicht in current geschrieben. Was ja auch absolut ok ist (das war sowieso schon ein Zugeständnis - eigentlich wollte ich diese Readings in gar keiner DB mehr haben). Abgesehen davon meldet der watchdog ja das Auftreten des Readings in tiggeredBy* und activated. In soweit ist die Nachvollziehbarkeit ja sowieso gegeben.

In 99_myUtils.pm habe ich mir nun einen Betriebssystemcall angelegt, der die eigentliche Workload startet (welche asynchron sofort zurückkommt - wir wollen fhem ja nicht blocken). Da tritt dann das Problem auf, dass, obwohl der Call erfolgreich ausgeführt wurde, immer der Fehler "No child processes -1" kommt. Hintergrund dürfte wohl das sein. Das -1 habe ich als ok abgefangen und gut ist.

Ich habe in diesem Zusammenhang auch das Tool mqttcli gefunden. Das macht die ganze Nummer erheblich einfacher, um verschiedene Szenarien unabhängig vom produktiven Device durchzuspielen. Das war die wichtigste Erkenntnis .


Danke
Gruß
fhem024