Hallo,
Ich bräuchte mal einen Denkanstoss, wie ich (z.B. in einem DOIF) eine Bedingung formulieren kann, die abprüft, wie lange ein Reading eines Device schon den aktuellen Zustand hat. Das muss nicht das DOIF triggern, ich brauche es nur als zusätzliche Bedingung.
Also z.B. eine Garagentor Device mit einem Reading das open|close|unknown werden kann, der zugehörige Sensor pollt den aktuellen Zustand alle 5 Minuten und aktualisiert den Timestamp des Readings.
In einem DOIF, das alle 10 Minuten getriggert wird, soll eine Aktion ausgeführt werden, wenn das Reading schon länger als 20 Minuten auf "open" steht, also unabhängig davon wann das Reading zuletzt aktualisiert wurde, aber abhängig davon wie lang der Statuswechsel schon her ist.
Ein Userreading beim Garagentor Device ? Aber das aktualisert sich ja nur dann, wenn dort ein Event stattfindet, also alle 10 Minuten ....
"timestamp-on-change-reading" könnte evtl. weiterhelfen.
DOIF ([+:10] and [?device:reading] eq "open" and [?device:reading:sec] > 60*20) (...)
Hallo,
für solche Anwendungsfälle wurde doch das Modul watchdog entwickelt.
https://wiki.fhem.de/wiki/Watchdog
Grüße Jörg
Zitat von: Damian am 06 Februar 2024, 22:15:46DOIF ([+:10] and [?device:reading] eq "open" and [?device:reading:sec] > 60*20) (...)
Alternativ kannst du als DOIF-User eventbasiert entsprechend einem Watchdog definieren:
DOIF ([device:"open"]) ()(...)
wait 20*60
Zitat von: Damian am 06 Februar 2024, 22:15:46DOIF ([+:10] and [?device:reading] eq "open" and [?device:reading:sec] > 60*20) (...)
Das wäre genial, funktioniert aber scheinbar nicht. [?device:reading:sec] wird offenbar bei jedem Update des Readings auf 0 gesetzt (auch wenn sich der Wert beim Update nicht verändert hat), ich brauche aber die Zeit, seit der das Reading auf dem bislherigen Wert steht.
Eigentlich willst Du doch gar nicht wissen, wie lange das reading schon seinen Wert hat, sondern wie lange es her ist, dass der Zustand des Garagentors sich geändert hat. Das muss nicht zwingend identisch sein.
Zitat von: gadget am 06 Februar 2024, 18:30:28der zugehörige Sensor pollt den aktuellen Zustand alle 5 Minuten und aktualisiert den Timestamp des Readings.
An der Stelle würde ich ansetzen. Wie hast Du das umgesetzt?
Zitat von: JoWiemann am 07 Februar 2024, 06:28:34Hallo,
für solche Anwendungsfälle wurde doch das Modul watchdog entwickelt.
https://wiki.fhem.de/wiki/Watchdog
Grüße Jörg
Ok, das probiere ich aus. Werde dann aber vermutlich regexp1WontReactivate brauchen, sonst wird der Watchdog ja beim pollen zurück gesetzt, richtig ?
Zitat von: betateilchen am 07 Februar 2024, 12:36:31Eigentlich willst Du doch gar nicht wissen, wie lange das reading schon seinen Wert hat, sondern wie lange es her ist, dass der Zustand des Garagentors sich geändert hat. Das muss nicht zwingend identisch sein.
Zitat von: gadget am 06 Februar 2024, 18:30:28der zugehörige Sensor pollt den aktuellen Zustand alle 5 Minuten und aktualisiert den Timestamp des Readings.
An der Stelle würde ich ansetzen. Wie hast Du das umgesetzt?
Da kann ich leider nicht ansetzen. Garagentor war jetzt nur ein Beispiel. Konkret geht es bei mir um den Verdichter meiner Wärmepumpe. Ich will möglichst bei PV Überschuss bei der WP auf Vorrat den Heizwasserspeicher aufheizen. Wenn die Sonne weg geht will ich den Verdichter aber nicht abwürgen wenn der erst ein paar Minuten gelaufen ist. Den Zustand des Verdichters bekomme ich über das uralte VCONTROL Modul, das die Heizung per Infrarotschnittstelle zyklisch ausliest.
Hallo,
Beta-User hat im Post 1 schon den richtigen Hinweis gegeben:
Zitat von: Beta-User am 06 Februar 2024, 18:36:59"timestamp-on-change-reading" könnte evtl. weiterhelfen.
Setze timestamp-on-change-reading UND event-on-change-reading für das entsprechende Reading, damit der Readingstimestamp nur neu gesetzt wird, wenn sich der Readingswert ändert.
Grüße
fz55
Der watchdog hilft Dir nicht weiter. Eigentlich denke ich auch, dass der Hinweis mit timestamp-on-change-reading ein guter Ansatz ist. Er setzt genau an der Stelle an, die ich in meinem vorherigen Beitrag meinte.
Zitat von: fz55 am 07 Februar 2024, 13:27:45Zitat von: Beta-User am 06 Februar 2024, 18:36:59"timestamp-on-change-reading" könnte evtl. weiterhelfen.
Setze timestamp-on-change-reading UND event-on-change-reading für das entsprechende Reading, damit der Readingstimestamp nur neu gesetzt wird, wenn sich der Readingswert ändert.
Probiere ich aus. Verständnisfrage: In der Hilfe steht:
event-on-update-reading
Wenn nicht gesetzt, erzeugt jede Veränderung eines Readings ein Ereignis, welches z.B. von notify oder FileLog berücksichtigt wird. Wenn gesetzt erzeugen nur Aktualisierungen der eingetragenen Readings ein Ereignis
timestamp-on-change-reading
Dieses Attribut enthält eine durch Kommata getrennte Liste von Readings. Wenn gesetzt, werden die gelisteten Readings nicht aktualisiert (oder angelegt) wenn durch ein ebenfalls gesetztes event-on-change-reading für dieses Reading kein Ereignis erzeugen würde.Mal abgesehen von dem schrägen Deutsch bei der Erläuterung zu timestamp-on-change-reading: Wie verhalten sich dann die
anderen Readings, die bei event-on-update-reading
nicht erwähnt werden ? Da ändert sich doch dann der Default, oder ? Mein Device hat um die 30 Readings, die auch in diversen anderen Automationen verwurstet werden ...
Zitat von: gadget am 07 Februar 2024, 17:38:12Mal abgesehen von dem schrägen Deutsch bei der Erläuterung zu
Das sei dem Autor, dessen Muttersprache meines Wissens nicht Deutsch ist, zugestanden und verziehen.
Deshalb ist bezüglich der Dokumentation immer die englischsprachige commandref die Quelle der Wahrheit.
Für viele Module gibt es gar keine deutsche Beschreibung, sie ist für Modulautoren nicht verpflichtend, um ein Modul zu veröffentlichen.
Readings, die in den Attributen nicht aufgeführt sind, werden nicht aktualisiert.
Ich habe mit timestamp-on-change-reading keinen Erfolg gehabt. Das entsprechende Reading wird dann überhaupt nicht mehr aktualisiert und zwar unabhängig davon was ich bei event-on-update-reading eintrage. Im DOIF ist dann [?device:reading:sec] immer 0.
Ich verfolge jetzt mal die Watchdog-Idee. Ich habe mir einen Dummy gebaut, den der watchdog ankläfft, wenn mein reading mehr als 20 Minuten lang auf "on" steht. Also in etwa so:
defmod wd watchdog device:reading:.on 00:20:00 device:reading:.off set dummy_timeout on
attr wd autoRestart 1
attr wd regexp1WontReactivate 1
und dazu noch ein notify, das dummy_timeout auf off stellt wenn device:reading dann doch endlich "off" ist.
Parallel dazu habe ich mir auch noch einen HourCounter mit interval 2 angelegt. Und ich glaube, das ist für meinen Fall die beste (weil übersichtlichste) Lösung. Da kann ich dann einfach das Reading pulseTimeIncrement abfragen.
Zeit für Popcorn.
Zitat von: gadget am 06 Februar 2024, 18:30:28der zugehörige Sensor pollt den aktuellen Zustand alle 5 Minuten und aktualisiert den Timestamp des Readings.
Warum tut der Sensor das?
Welchen Wert hat den der Timestamp der letzten Abfrage für Dich?
Warum nicht der Timestamp der letzten Änderung?
Die Lösung ist immer so gut wie die Problembeschreibung.
Wenn du beim Sensor "event-on-change-reading state" setzt, werden schon mal keine Events erzeugt, wenn der Zustand des Status beim Update gleich bleibt.
Damit sich auch der Zeitstempel des Status nicht ändert, musst du zusätzlich "timestamp-on-change-reading state" setzen.
Damit gibt es nur ein Event beim ersten "open" und auch der Zeitstempel bleibt gleich, solange es bei open bleibt, egal wie oft der Sensor "open" aktualisiert (der Status darf natürlich nicht zwischendurch wechseln)
Damit sollten meine beiden DOIF-Vorschläge funktionieren.
Zitat von: gadget am 07 Februar 2024, 19:50:12Ich habe mit timestamp-on-change-reading keinen Erfolg gehabt. Das entsprechende Reading wird dann überhaupt nicht mehr aktualisiert und zwar unabhängig davon was ich bei event-on-update-reading eintrage. Im DOIF ist dann [?device:reading:sec] immer 0.
event-on-update-reading sollte für das Reading nicht gesetzt werden sondern event-on-change-reading und timestamp-on-change-reading.
Popcorn muss noch warten. Brauche erst wieder genug PV-Überschuss für den Real-Life Test .... :)
Zitat von: fz55 am 07 Februar 2024, 22:58:23Zitat von: gadget am 07 Februar 2024, 19:50:12Ich habe mit timestamp-on-change-reading keinen Erfolg gehabt. Das entsprechende Reading wird dann überhaupt nicht mehr aktualisiert und zwar unabhängig davon was ich bei event-on-update-reading eintrage. Im DOIF ist dann [?device:reading:sec] immer 0.
event-on-update-reading sollte für das Reading nicht gesetzt werden sondern event-on-change-reading und timestamp-on-change-reading.
Sorry, mein Fehler. Hatte event-on-change-reading gesetzt, so wie es in der commandref beschrieben ist. War nur in meinem Post falsch.
Zitat von: Damian am 07 Februar 2024, 21:42:35Wenn du beim Sensor "event-on-change-reading state" setzt, werden schon mal keine Events erzeugt, wenn der Zustand des Status beim Update gleich bleibt.
Damit sich auch der Zeitstempel des Status nicht ändert, musst du zusätzlich "timestamp-on-change-reading state" setzen.
Damit gibt es nur ein Event beim ersten "open" und auch der Zeitstempel bleibt gleich, solange es bei open bleibt, egal wie oft der Sensor "open" aktualisiert (der Status darf natürlich nicht zwischendurch wechseln)
Damit sollten meine beiden DOIF-Vorschläge funktionieren.
Ja, das ist auch theoretisch alles richtig und wäre mir so am liebsten. In der Praxis hatte ich aber den Effekt, dass dann überhaupt kein Reading mehr Events erzeugt hat (und da gibt es wie gesagt echt viele bei der Wärmepumpe, Garagentor war ja nur Beispiel) und diverse andere Automationen / Grafiken / Überwachungsmechanismen rund um das Gerät nicht mehr funktioniert haben. Ich werde berichten, was dann letztendlich am besten funktiojiert hat wenn ich wieder genug PV-Überschuss habe für die Wärmepumpe. Mein Favorit ist aber derzeit der HourCounter.
Fazit nach einer Woche: Sowohl die Variante mit watchdog als auch der HourCounter funktionieren. Habe mich jetzt für den HC entschieden. Setze den Thread auf "gelöst". Danke an alle Beteiligten !