Moin,
kann man das Suchmuster eines notify auf einmalige Ausführung in einem Zeitraum beschränken wie es bei DOIF mit repeatsame möglich ist, mir fehlt der Weitblick sollte man das mit Perl irgendwie umgesetzt bekommen ?
MQTT2_Cube:action:.*
{if (($EVTPART1 eq 'wakeup') && ($hour =~ m,[5..8],)){fhem"saysonos |Temple| Guten Morgen ... . Die Außentemperatur beträgt zur Zeit [HF_Aussensensor_Vorderhaus:temperaturegerundet] °"};}
Gruß
Thomas
Moin Thomas,
ZitatdisabledAfterTrigger <sekunden>
deaktiviert die Ausführung für <sekunden> nach dem das notify ausgelöst wurde.
und disabledForIntervals willst Du nicht nutzen?
Gruß Otto
;D könnte man wirklich drüber nachdenken.
Abgesehen davon das ich den Cube idR. gar nicht nutze (bis auf das wakeup ;D) wär die Bedienung von TV und Jupiter um diese Zeit nicht nötig, aber vlt. doch einmal die von Sonos.
MQTT2_Cube:action:.*
{if (($EVTPART1 eq 'wakeup') && ($hour =~ m,[5..8],)){fhem"saysonos |Temple| Guten Morgen ... Die Außentemperatur beträgt zur Zeit [HF_Aussensensor_Vorderhaus:temperaturegerundet] °"};
if (($EVTPART1 eq 'rotate_right') && (ReadingsVal($NAME,'to_side','') eq '0')){fhem"set TV_Wohnzimmer channelUp"};
if (($EVTPART1 eq 'rotate_left') && (ReadingsVal($NAME,'to_side','') eq '0')){fhem"set TV_Wohnzimmer channelDown"};
if (($EVTPART1 eq 'tap') && (ReadingsVal($NAME,'to_side','') eq '0')){ReadingsVal('TV_Wohnzimmer','state','') eq 'off' ? fhem"set MQTT2_IR_OG_Wohnzimmer power" : ReadingsVal('TV_Wohnzimmer','mute','') eq 'off' ? fhem"set TV_Wohnzimmer mute on" : fhem"set TV_Wohnzimmer mute off"};
if (($EVTPART1 eq 'rotate_right') && (ReadingsVal($NAME,'to_side','') eq '3')){fhem"set Sonos_Wohnzimmer Volume {([Sonos_Wohnzimmer:Volume]+3)}"};
if (($EVTPART1 eq 'rotate_left') && (ReadingsVal($NAME,'to_side','') eq '3')){fhem"set Sonos_Wohnzimmer Volume {([Sonos_Wohnzimmer:Volume]-3)}"};
if (($EVTPART1 eq 'tap') && (ReadingsVal($NAME,'to_side','') eq '3')){ReadingsVal('Sonos_Wohnzimmer','state','STOPPED') eq 'PLAYING' ? fhem"set Sonos_Wohnzimmer Pause" : fhem"set Sonos_Wohnzimmer Play"};
if (($EVTPART1 eq 'rotate_right') && (ReadingsVal($NAME,'to_side','') eq '4')){fhem"set MQTT2_Mi_Wecklicht hue {([MQTT2_Mi_Wecklicht:hue]-15)}"};
if (($EVTPART1 eq 'rotate_left') && (ReadingsVal($NAME,'to_side','') eq '4')){fhem"set MQTT2_Mi_Wecklicht hue {([MQTT2_Mi_Wecklicht:hue]+15)}"};
if (($EVTPART1 eq 'tap') && (ReadingsVal($NAME,'to_side','') eq '4')){fhem"set MQTT2_Mi_Wecklicht toggle"};
}
Jetzt kommt mir beim schreiben das vermutlich ein zusätzliches notify eine Lösung wäre.
disabledForIntervals weniger mein ich jetzt.
disabledAfterTrigger schon, allerdings dann in einem zusätzlichen notify
Hab mir ein Konstrukt ausgedacht welches mir über die Kommandozeile die korrekte Zeit in Sekunden zurückgibt, wenn jeden Tag erneut ab 5 Uhr einmal neu getriggert werden darf, jeder Kenner der richtigen Funktionen vermutlich aber die Hände über dem Kopf zusammenschlägt.
{(3600*(24-($hour)+5)-($min)*60)}
Wie muß ich, wenn das Konstrukt nicht ganz daneben ist
attr not_MQTT2_Cube_action_wakeup disabledAfterTrigger {(3600*(24-($hour)+5)-($min)*60)}
anpassen das nicht
{(3600*(24-($hour)+5)-($min)*60)}
im Attribut landet, habs schon mit verschiedenen Klammersetzungen versucht ?
Für einen Hieb in die richtige Richtung mit welchen Zeit-Funktion ich mich beschäftigen sollte wenn das Konstrukt total daneben ist wär ich dankbar.
So sieht bisher das zusätzliche notify aus:
defmod not_MQTT2_Cube_action_wakeup notify MQTT2_Cube:action:.* {if (($EVTPART1 eq 'wakeup') && ($hour =~ m,[5..8],)){fhem"saysonos |Temple| Guten Morgen ... Die Außentemperatur beträgt zur Zeit [HF_Aussensensor_Vorderhaus:temperaturegerundet]°;;attr not_MQTT2_Cube_action_wakeup disabledAfterTrigger {(3600*(24-($hour)+5)-($min)*60)}"};;}
attr not_MQTT2_Cube_action_wakeup disabledAfterTrigger {(3600*(24-($hour)+5)-($min)*60)}
attr not_MQTT2_Cube_action_wakeup group Cube
attr not_MQTT2_Cube_action_wakeup room Wohnzimmer
mmh, da war der Wunsch wohl Vater des Gedanken
ZitatdisabledAfterTrigger <sekunden>
deaktiviert die Ausführung für <sekunden> nach dem das notify ausgelöst wurde.
da steht nicht {Perlausdruck} ich gehe davon aus, da gehen wirklich nur Zahlen.
Nee, nee.
ich schreibe das was
{(3600*(24-($hour)+5)-($min)*60)}
in der Kommandozeile zürückgbt in das Attribut, kein Perl-Ausdruck in disabledAfterTrigger.
Das, was
{(3600*(24-($hour)+5)-($min)*60)}
zurückgibt, stimmt von der Syntax her vorne und hinten nicht ist mir schon klar, gibt aber in der Kommandozeile zurück was ich will.
Also falls ich Dich richtig verstehe:
{my $ts=3600*(24-($hour)+5)-($min)*60;;fhem("attr not_MQTT2_Cube_action_wakeup disabledAfterTrigger $ts")}
Ja, so werden die Sekunden ins Attribut geschrieben. Danke.
Das Bier war heute Abend aber so gut das ich gerade nicht mehr verstehe, warum der endende Wert jetzt nicht mehr 5 Uhr ergibt, komm ich aber noch drauf. ;D
Alles gut. :P
Denkfehler
{FmtTime(20040)}
ergibt 06:34:00, also in 6 Stunden 34 Minuten, nicht 6 Uhr 34 Minuten ;D
edit:
achso und merkwürdigerweise müssen es +4 statt +5 sein
{(3600*(24-($hour)+4)-($min)*60)}
Vielleicht noch ein interessanter Link aus meiner persönlichen Linkliste: https://forum.fhem.de/index.php/topic,76123.msg683725.html#msg683725
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)-8 Uhr?
Sollte man doch kombinieren können mit disabledForIntervals
Ja, ein notify wär mir auch lieber, hab eigentlich schon drei.
list -r MQTT2_Cube_.* :
define not_MQTT2_Cube_action notify MQTT2_Cube:action:.*\
{if (($EVTPART1 eq 'rotate_right') && (ReadingsVal($NAME,'to_side','') eq '0')) {fhem"set TV_Wohnzimmer channelUp"};;\
if (($EVTPART1 eq 'rotate_left') && (ReadingsVal($NAME,'to_side','') eq '0')){fhem"set TV_Wohnzimmer channelDown"};;\
if (($EVTPART1 eq 'tap') && (ReadingsVal($NAME,'to_side','') eq '0')){ReadingsVal('TV_Wohnzimmer','state','') eq 'off' ? fhem"set MQTT2_IR_OG_Wohnzimmer power" : ReadingsVal('TV_Wohnzimmer','mute','') eq 'off' ? fhem"set TV_Wohnzimmer mute on" : fhem"set TV_Wohnzimmer mute off"};;\
\
if (($EVTPART1 eq 'rotate_right') && (ReadingsVal($NAME,'to_side','') eq '1')) {fhem"set TV_Wohnzimmer volumeUp"};;\
if (($EVTPART1 eq 'rotate_left') && (ReadingsVal($NAME,'to_side','') eq '1')){fhem"set TV_Wohnzimmer volumeDown"};;\
if (($EVTPART1 eq 'tap') && (ReadingsVal($NAME,'to_side','') eq '1')){ReadingsVal('TV_Wohnzimmer','state','') eq 'off' ? fhem"MQTT2_IR_OG_Wohnzimmer power" : ReadingsVal('TV_Wohnzimmer','mute','') eq 'off' ? fhem"set TV_Wohnzimmer mute on" : fhem"set TV_Wohnzimmer mute off"};;\
\
\
if (($EVTPART1 eq 'rotate_right') && (ReadingsVal($NAME,'to_side','') eq '3')){fhem"set Sonos_Wohnzimmer Volume {([Sonos_Wohnzimmer:Volume]+3)}"};;\
if (($EVTPART1 eq 'rotate_left') && (ReadingsVal($NAME,'to_side','') eq '3')){fhem"set Sonos_Wohnzimmer Volume {([Sonos_Wohnzimmer:Volume]-3)}"};;\
if (($EVTPART1 eq 'tap') && (ReadingsVal($NAME,'to_side','') eq '3')){ReadingsVal('Sonos_Wohnzimmer','state','STOPPED') eq 'PLAYING' ? fhem"set Sonos_Wohnzimmer Pause" : fhem"set Sonos_Wohnzimmer Play"};;\
\
if (($EVTPART1 eq 'rotate_right') && (ReadingsVal($NAME,'to_side','') eq '4')){fhem"set MQTT2_Mi_Wecklicht hue {([MQTT2_Mi_Wecklicht:hue]-15)}"};;\
if (($EVTPART1 eq 'rotate_left') && (ReadingsVal($NAME,'to_side','') eq '4')){fhem"set MQTT2_Mi_Wecklicht hue {([MQTT2_Mi_Wecklicht:hue]+15)}"};;\
if (($EVTPART1 eq 'tap') && (ReadingsVal($NAME,'to_side','') eq '4')){fhem"set MQTT2_Mi_Wecklicht toggle"};;\
}
attr not_MQTT2_Cube_action group Cube
attr not_MQTT2_Cube_action room Wohnzimmer
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
define not_MQTT2_Cube_to_side notify MQTT2_Cube:to_side:.* \
{if ($EVTPART1 eq '0'){fhem"saysonos Teefau Programm"};;\
if ($EVTPART1 eq '1'){fhem"saysonos Teevau Lautstaerke"};;\
if ($EVTPART1 eq '2'){fhem"saysonos Licht"};;\
if ($EVTPART1 eq '3'){fhem"saysonos Sonos"};;\
if ($EVTPART1 eq '4'){fhem"saysonos Jupiter"};;\
}
attr not_MQTT2_Cube_to_side group Cube
attr not_MQTT2_Cube_to_side room Wohnzimmer
setstate not_MQTT2_Cube_action 2020-07-07 09:09:30
setstate not_MQTT2_Cube_action 2020-07-06 22:50:20 state active
setstate not_MQTT2_Cube_action_wakeup 2020-07-07 06:00:26
setstate not_MQTT2_Cube_action_wakeup 2020-07-06 22:53:24 state active
setstate not_MQTT2_Cube_to_side 2020-07-06 23:18:11
setstate not_MQTT2_Cube_to_side 2020-07-06 22:50:20 state active
not_MQTT2_Cube_to_side und not_MQTT2_Cube_action ginge zu kombinieren, wie ich es bis jetzt glaube verstanden zu haben, aber noch nicht getestet.
not_MQTT2_Cube_action_wakeup aber doch nicht !?
Wenn in der Zeit von 5-8 getriggert wird wär das komplette notify disabled, also keine Funktion mehr irgendwas zu bedienen, sehe nicht auf was du aus bist.
Zitatdefine not_MQTT2_Cube_action_wakeup notify MQTT2_Cube:action:.* {if (($EVTPART1 eq 'wakeup') && ($hour =~ m,[6..22],)){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"};;}
Warum kann ich im Ausführungsteil kein $name verwenden, weil ich im if bin ?
Weil es im notify $NAME ist ;)
Nee, nee.
$NAME ist der Name von dem Gerät welches das Event erzeugt oder steh ich jetzt auf dem Schlauch ?
Zitat von: TomLee am 07 Juli 2020, 11:40:37
Nee, nee.
$NAME ist der Name von dem Gerät welches das Event erzeugt oder steh ich jetzt auf dem Schlauch ?
Nein stimmt schon: also $NAME im notify ist der NAME des "feuernden" Devices ;)
EDIT: wenn ein passendes/gut gewähltes Namensschema zugrunde liegt kann man aber evtl. von "feuerndem Device" auf das "gewünschte Device" kommen... :)
EDIT: wobei ich zugegebenermassen nicht komplett gelesen habe ;) Sorry für's "Einmischen" 8)
Gruß, Joachim
Es ging eigentlich nur um das "smartmatch"-notify:
Zitat von: TomLee am 07 Juli 2020, 11:07:52
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 ;) .
ZitatSollte 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)-8 Uhr?
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 :o
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.
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:
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?
ZitatEinmal 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 (https://forum.fhem.de/index.php/topic,112361.msg1069861.html#msg1069861) gemacht habe.
Zitat von: TomLee am 07 Juli 2020, 15:59:37
Was spricht denn dagegen nach dem setzen ein save auszuführen wie ich das hier (https://forum.fhem.de/index.php/topic,112361.msg1069861.html#msg1069861) 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...).
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.
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?
auch der Teil dürfte jetzt aber klar sein, oder?
Ja, dafür spricht das "plötzliche" Verstehen (heut noch ;D), da haben sich Synapsen ;D schneller gebildet, wie bei dem f2m2f-Thema (die schon wieder am verkümmern sind :P)
Mal zwischendurch wieder auch ein großes Danke an dich
Zitat von: Otto123 am 06 Juli 2020, 09:11:46
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 ?
Zitat von: TomLee am 07 Juli 2020, 20:19:36
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 ;)