Notify einmalige Ausführung vom Suchmuster

[Beta-User]

Es ging eigentlich nur um das "smartmatch"-notify:

Code Auswählen Erweitern


define not_MQTT2_Cube_action_wakeup notify MQTT2_Cube:action:.* {if (($EVTPART1 eq 'wakeup') && ($hour =~ m,[5..8],)){my $ts=3600*(24-($hour)+4)-($min)*60;;fhem"saysonos |Temple| Guten Morgen  ... Die Außentemperatur beträgt zur Zeit [HF_Aussensensor_Vorderhaus:temperaturegerundet]°;;attr not_MQTT2_Cube_action_wakeup disabledAfterTrigger $ts"};;}
attr not_MQTT2_Cube_action_wakeup disabledAfterTrigger 79200
attr not_MQTT2_Cube_action_wakeup group Cube
attr not_MQTT2_Cube_action_wakeup room Wohnzimmer


Das greift nur in einem bestimmten Zeitraum, und es soll nur einmal/Tag sein, was mit der vorgeschlagenen Methode ohne "rotes Fragezeichen" abbildbar wäre. Diesen Teil würde ich auch nicht weiter mit irgendwas anderem kombinieren.


Was den Rest angeht, würde ich das in myUtils auslagern; da kannst du dann auch nach Herzenslust weitere Fälle dazubasteln; evtl. würde es dann aber einfacher, wenn du da weitere if-Zweige reinbaust mit "to_side" usw....

Der eigene Name des notify dürfte übrigens $SELF sein .

[TomLee]

Sollte man doch kombinieren können mit disabledForIntervals, was hier dann drei "Etappen" ergäbe: 0-5 Uhr, 8-24 Uhr und ("heute schon gemeldet" ? 5:-8 Uhr?

Code Auswählen Erweitern

Das greift nur in einem bestimmten Zeitraum, und es soll nur einmal/Tag sein, was mit der vorgeschlagenen Methode ohne "rotes Fragezeichen" abbildbar wäre. Diesen Teil würde ich auch nicht weiter mit irgendwas anderem kombinieren.

Komm ich auch nach längerem nachdenken nicht mit, mein Beispiel macht genau was es soll, zw. 5 und 8 (bzw. 08:59:59) reagiert es einmal und wird disabled bis zum nächsten Morgen um 5 Uhr (+ die paar Sekunden die ich nicht mitrechne). Warum soll ich das auf drei Etappen aufteilen ?

Das mit dem Fragezeichen ist noch unklar weil ich gerade irgendwie  nicht testen kann, weil:

gestern mein ich konnte ich das disabledAfterTrigger löschen, einen restart vom Server machen und das notify hat wieder 1x reagiert (nach anpassen des Smartmatch).

Jetzt will ich das mit dem ? nachvollziehen was genau passiert, mache das gleiche löschen, restart und das notify reagiert, das sieht man an dem Internal TRIGGERTIME, aber der Ausführungsteil wird nicht ausgeführt.

Überlebt die Sekunden Angabe in disabledForIntervals (irgendwo) doch einen restart und vorheriges löschen, gibts doch nicht 

Hab nix geändert seit gestern Abend, heute Morgen hat es einmal reagiert wie gewollt und hatte die richtige Sekundenangabe ins Attribut geschrieben, eben gelöscht, Neustart und kein Ausführungsteil mehr (nach anpassen des Smartmatch), merkwürdig, hieße ja dann jetzt warten bis morgen früh um fünf.

[Beta-User]

Hmm, ich hab's nicht nachgestellt, gehe aber davon aus, dass mit jeder Attribut-Änderung auch ein rotes Fragezeichen verbunden ist. Da das notify das Attribut setzt, müßte es eigentlich jeden Tag auch neue "zu speichernde" Änderungen geben. Soweit korrekt?

Die Frage ist daher, ob man das vermeiden kann.

Nachdem ich jetzt auch nochmal den Code in notify angesehen habe: Zuerst wird IsDisabled() geprüft, und damit auch die Uhrzeit. Paßt das nicht, passiert nichts, es wird also insbesondere wohl auch nicht die Trigger-Zeit aktualisiert. Erst danach kommt disabledAfterTrigger, der dann die Zeit des letzten Triggers prüfen würde.

Demnach sollte also - völlig statisch - folgendes gehen:

Code Auswählen Erweitern

define not_MQTT2_Cube_action_wakeup notify MQTT2_Cube:action:.wakeup.* saysonos |Temple| Guten Morgen  ... Die Außentemperatur beträgt zur Zeit [HF_Aussensensor_Vorderhaus:temperaturegerundet]°
attr not_MQTT2_Cube_action_wakeup disabledForIntervals 08-24 00-05
attr not_MQTT2_Cube_action_wakeup disabledAfterTrigger 10800
Einmal getriggert, ist für 3 Stunden Ruhe, also genau die maximale Zeitspanne von 05:00 Uhr bis 07:59:59 Uhr...

Oder denke ich an der Stelle zu einfach?


Nachtrag:
Hier ist es einfach, weil der Ablauf des Timers disabledAfterTrigger immer noch auf denselben Tag fällt. Könnte es zu Überschneidungen kommen, käme eben als dritter "Zeitraum" in disabledForIntervals eine "ver-Perl-te" Abfrage in Betracht, die checkt, ob heute schon getriggert wurde und dann eben auch den restlichen Zeitraum sperrt...
Hoffe, das ist jetzt etwas klarer?

[TomLee]

Einmal getriggert, ist für 3 Stunden Ruhe, also genau die maximale Zeitspanne von 05:00 Uhr bis 07:59:59 Uhr...

Oder denke ich an der Stelle zu einfach?

Ja, es soll einmal in den drei Stunden reagieren und sonst disabled sein, nur morgens beim aufstehen einmal reagieren sonst die Klappe halten, wie gesagt macht das meine Lösung.



Was spricht denn dagegen nach dem setzen ein save auszuführen wie ich das hier gemacht habe.

[Beta-User]

Was spricht denn dagegen nach dem setzen ein save auszuführen wie ich das hier gemacht habe.

Irgendwie werde ich immer sehr unruhig, wenn ich automatisches save höre. Hat wohl teils historische Gründe, teils hängt es mit meiner "Maintainer"-Rolle zu tun - da kommt es hin und wieder vor, dass ich mir beim Überarbeiten des Modulcodes bzw. dem Testen dann auch schon mal ein Modul zerschieße. Das hat dann zur Folge, dass die betreffenden Devices nicht aus der config gelesen werden - kommt da ein automatisches "save" dazwischen, ist der Reparaturaufwand viel größer, wie wenn ich das fixe und FHEM dann einfach wieder neu starte... Die historischen Gründe sind ähnlich: OWX hatte früher die mMn. unangenehme Eigenschaft, nicht verbundene Geräte einfach zu löschen, was ich auch ein paar Mal erst später gemerkt habe (damals gab es das rote Fragezeichen noch nicht)...

Ergo: automatisches Speichern ist in meiner persönlichen Gedankenwelt _deutlich_ "bäh"...

Daher würde ich sowas vermeiden, wenn es sich irgendwie vermeiden läßt. Und mMn. läßt es sich vermeiden . (Muß mir mal eine usecase für diese Sache mit dem mehrfachen "gemischt-Perl-disabledForIntervals"-Ding überlegen, dann finde ich es auch leichter wieder, wenn ich's mal zu Demo-Zwecken brauche...).

[TomLee]

Hast du das Beispiel aus #17 nochmal angepasst oder hatte ich das erste mal nicht richtig gelesen ?

Jetzt plötzlich kann ich das nachvollziehen, so sollte das passen  , aber noch nicht ausprobiert.

[Beta-User]

Der Nachtrag war nur die Ergänzung, der Code war vorher schon so. Mir ist dann nur nach dem Tippen aufgefallen, dass das eigentlich - wegen der konkreten zeitlichen Lage auf dem Tag - ein Spezialfall ist und ich auch noch nicht erklärt habe, wie das neulich mit den drei Zeiträumen gemeint war - auch der Teil dürfte jetzt aber klar sein, oder?

[TomLee]

Code Auswählen Erweitern

auch der Teil dürfte jetzt aber klar sein, oder?

Ja, dafür spricht das "plötzliche" Verstehen (heut noch  ), da haben sich Synapsen schneller gebildet, wie bei dem f2m2f-Thema (die schon wieder am verkümmern sind  )

Mal zwischendurch wieder auch ein großes Danke an dich

[TomLee]

und disabledForIntervals willst Du nicht nutzen?
Gruß Otto

War die Frage schon genauso gemeint, weshalb ich es nicht so wie jetzt in  #17 beschrieben umsetze ?
War dir das von vornherein war klar ?

[Otto123]

War die Frage schon genauso gemeint, weshalb ich es nicht so wie jetzt in  #17 beschrieben umsetze ?
War dir das von vornherein war klar ?

Ich hatte Dich so verstanden - aber klar !? Nee klar war das nicht