Hallo zusammen,
ich habe folgendes Notify:
zg.garten.pumpenventil {
if (Value("zg.garten.pumpenventil") eq "rueckspuelen") {
fhem("set zg.garten.pumpe_Sw on-for-timer 240");
fhem("set zg.garten.pumpenventil aus");
} elsif (Value("zg.garten.pumpenventil") eq "nachspuelen") {
fhem("set zg.garten.pumpe_Sw on-for-timer 120");
fhem("set zg.garten.pumpenventil aus");
}
}
Hierbei wird eine Funksteckdose für 120 oder 240 Sekunden aktiviert. Ich hätte nun gerne, dass jeweils nach der angegebenen Zeit eine Benachrichtigung (also ein Befehl) ausgeführt wird. Ich bin mir jetzt nicht sicher, ob ein fhem("set zg.garten.pumpe_Sw on-for-timer 240"; wait 240; "set usw"); oder ob es da was sinnvolleres gibt.
Vielen Dank!
Hallo,
versuch es doch mal mit fhem("defmod pump_Sw_info at +240 set ...")
oder besser frag in einer DOIF den status des zg.garten.pumpe_Sw ab, er ist ja jetzt on, wenn er auf off wechselt, dann set ....
in etwa so: fhem("defmod pump_Sw_info DOIF (... eq off) set ... ")
Viel Erfolg
Bei Homematic gilt zu beachten: die Zeit läuft im Aktor! Und dort nicht ganz genau! (hat was mit Übertragung und dann "Auswertung" im Gerät zu tun / gibt irgendwo einen Thread Wikieintrag dazu: https://wiki.fhem.de/wiki/HomeMatic_Timerwerte)
EDIT: zg.garten.pumpe_Sw klingt zumindest danach / wie halt immer: ohne ausreichend Infos schwer zu helfen...
Vorteil: der Aktor geht auch aus, wenn fhem inzwischen ausgefallen sein sollte...
Wie wäre es einfach mal die Abfolge im Eventmonitor anschauen.
Bei einem meiner HM-Aktoren sieht es wie folgt aus:
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter commState: CMDs_pending
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter set_on-for-timer 10
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter commState: CMDs_processing...
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter commState: CMDs_done
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter deviceMsg: on (to vccu)
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter level: 100
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter pct: 100
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter on
2022-06-25 22:59:47 CUL_HM Schaltaktor_Bad_Luefter timedOn: running
2022-06-25 23:00:00 CUL_HM Schaltaktor_Bad_Luefter deviceMsg: off (to vccu)
2022-06-25 23:00:00 CUL_HM Schaltaktor_Bad_Luefter level: 0
2022-06-25 23:00:00 CUL_HM Schaltaktor_Bad_Luefter pct: 0
2022-06-25 23:00:00 CUL_HM Schaltaktor_Bad_Luefter off
2022-06-25 23:00:00 CUL_HM Schaltaktor_Bad_Luefter timedOn: off
Dann einfach einen passenden Event raussuchen, z.B.:
2022-06-25 23:00:00 CUL_HM Schaltaktor_Bad_Luefter timedOn: off
und dann ein notify anlegen lassen und dort dann Ausführen was immer du ausführen willst...
https://wiki.fhem.de/wiki/Event_monitor
https://wiki.fhem.de/wiki/Event_monitor#Vorgehensweise_beim_Anlegen_eines_Ger.C3.A4tes
Und dafür braucht es doch kein DOIF... ;)
Man kann sich auch selbst um on-for-timer kümmern:
set Aktor on; sleep 240; set Aktor off; set was-auch-immer auf-was-auch-immer
;)
EDIT: je nachdem wo/wie man das eingibt/verwendet auch mal Strichpunkte "doppeln"...
Nachteil(e): läuft in fhem, also fhem "kaputt" Aktor bleibt an. Nicht "Neustartfähig" (sleep ist dann "weg"). Lässt sich statt einem sleep auch per "defmod atTimer at 00:04:00 set Aktor off; ... auch bewerkstelligen.
Gruß, Joachim
Hallo zusammen,
auf den EventMonitor hätte ich auch selber kommen können ::) den nehm ich viel zu selten her...
Danke Euch für die Tipps. Habe es jetzt sogar noch ein Stück komfortabler:
zg.garten.pumpe_Sw:timedOn:.off {
if (Value("zg.garten.pumpenventil") eq "rueckspuelen") {
fhem("set all.signalbot send #Familie Rückspülen abgeschlossen. Bitte nachspülen.");
fhem("set zg.garten.pumpenventil aus");
} elsif (Value("zg.garten.pumpenventil") eq "nachspuelen") {
fhem("set all.signalbot send #Familie Nachspülen abgeschlossen. Bitte Pumpe wieder auf filtern umstellen.");
fhem("set zg.garten.pumpenventil aus");
}
}
@Joachim: Sorry für die fehlenden Informationen, ich war irgendwie zu sehr versteift auf ein "wait" :) Ist Homematic.
LG,
Alex
Kein Problem, ist halt nur einfacher (gezielt) zu helfen...
Einen Tipp noch: lass Value!!
Value("Devicename") "frägt" das INTERNAL!! STATE ab!
Und der kann (z.B. wegen "Optik") duch stateFormat u.ä. "beeinflusst" werden...
...und dann wundert man sich u.U. wenn irgendwelche Abfragen nicht mehr gehen...
Besser: ReadingsVal("Devicename", "ReadingName", "Ersatzwert") oder ReadingsNum für Zahlen oder AttrVal für Attribute oder wenn es wirklich STATE oder ein anderes INTERNAL sein soll InternalVal...
Und noch einer ;)
Neben set Device Irgendwas kann man auch einfach Readings setzen: setreading Devicename MeinReadingName Wert
Ein set "wirkt" ja immer auf das Device (bei einem dummy nicht entscheidend) und entweder tut das Device dann was (wenn das so soll, dann klar set) oder "versteht" nicht was man will (weil "echte" Devices ja "bestimmen" was sie "können" ;) )...
Gruß, Joachim
Ok, danke. In dem Fall dürfte es egal sein, da zg.garte.pumpenventil ein Dummy ist und im Endeffekt nur "virtuell" die "physische" Stellung des Ventils darstellt :)
Ich hatte es irgendwann mal geschafft, meine Pumpe auf Rückspülen stehen zu lassen, mit dem Resultat, dass Abends beim Regulären Pumpenlauf der Pool leergepumpt wurde ;) Also mache ich das jetzt über diesen Dummy. Wenn ich Rückspülen möchte, dann stelle ich ihn auf Rückspülen, dann springt die Pumpe mit "on-for-timer" an und stellt anschließend das "Ventil" auf off. Wenn das dann beim regulären Lauf immernoch auf off steht, bekomme ich ne Benachrichtigung und die Pumpe schaltet sich nicht an. Quasi ne Art "Kindersicherung" :)
Kann man so machen, ist aber halt Kacke.
Zitat von: betateilchen am 26 Juni 2022, 14:25:11
Kann man so machen, ist aber halt Kacke.
...ok?.. was genau und warum?
- zum Beispiel, weil Du immer noch mit Value() arbeitest
- zum Beispiel, weil das Triggern auf timedOn:off
eine saublöde nicht die beste Idee ist. Das steht nämlich auch auf "off" wenn der Aktor (warum auch immer, vielleicht sogar versehentlich) dauerhaft auf "on" gestellt wird - zum Beispiel, weil ich 99,9% aller in FHEM weltweit verwendeten dummy-devices für entbehrlich halte, hätte sich der Nutzer im Vorfeld ein klares Konzept zu seiner Logik gemacht
- ...
Zitat von: betateilchen am 26 Juni 2022, 14:35:27
- zum Beispiel, weil das Triggern auf timedOn:off
eine saublöde nicht die beste Idee ist. Das steht nämlich auch auf "off" wenn der Aktor (warum auch immer, vielleicht sogar versehentlich) dauerhaft auf "on" gestellt wird
Stehen schon aber (zumindest bei mir) gibt/gab es nur einen entsprechenden Event, wenn tatsächlich on-for-timer genutzt wurde.
Bei "normalem" on/off kam kein Event...
Gruß, Joachim
Zitat von: MadMax-FHEM am 26 Juni 2022, 14:44:30
Stehen schon aber (zumindest bei mir) gibt/gab es nur einen entsprechenden Event, wenn tatsächlich on-for-timer genutzt wurde.
Bei "normalem" on/off kam kein Event...
Bei mir kommt bei einem "set ... on" sehr wohl ein event:
2022-06-26 14:51:03 CUL_HM wz_Ventilator commState: CMDs_pending
2022-06-26 14:51:03 CUL_HM wz_Ventilator set_on noArg
2022-06-26 14:51:03 CUL_HM wz_Ventilator commState: CMDs_processing...
2022-06-26 14:51:03 CUL_HM wz_Ventilator trigLast: fhem:02
2022-06-26 14:51:03 CUL_HM wz_Ventilator commState: CMDs_done
2022-06-26 14:51:03 CUL_HM wz_Ventilator deviceMsg: on (to hmvccu)
2022-06-26 14:51:03 CUL_HM wz_Ventilator level: 100
2022-06-26 14:51:03 CUL_HM wz_Ventilator pct: 100
2022-06-26 14:51:03 CUL_HM wz_Ventilator on
2022-06-26 14:51:03 CUL_HM wz_Ventilator timedOn: off
und bei einem "set ... off" auch:
2022-06-26 14:51:54 CUL_HM wz_Ventilator commState: CMDs_pending
2022-06-26 14:51:54 CUL_HM wz_Ventilator set_off noArg
2022-06-26 14:51:54 CUL_HM wz_Ventilator commState: CMDs_processing...
2022-06-26 14:51:54 CUL_HM wz_Ventilator trigLast: fhem:02
2022-06-26 14:51:54 CUL_HM wz_Ventilator commState: CMDs_done
2022-06-26 14:51:54 CUL_HM wz_Ventilator deviceMsg: off (to hmvccu)
2022-06-26 14:51:54 CUL_HM wz_Ventilator level: 0
2022-06-26 14:51:54 CUL_HM wz_Ventilator pct: 0
2022-06-26 14:51:54 CUL_HM wz_Ventilator off
2022-06-26 14:51:54 CUL_HM wz_Ventilator timedOn: off
Zitat von: betateilchen am 26 Juni 2022, 14:35:27
- zum Beispiel, weil Du immer noch mit Value() arbeitest
- zum Beispiel, weil das Triggern auf timedOn:off
eine saublöde nicht die beste Idee ist. Das steht nämlich auch auf "off" wenn der Aktor (warum auch immer, vielleicht sogar versehentlich) dauerhaft auf "on" gestellt wird - zum Beispiel, weil ich 99,9% aller in FHEM weltweit verwendeten dummy-devices für entbehrlich halte, hätte sich der Nutzer im Vorfeld ein klares Konzept zu seiner Logik gemacht
- ...
Bezüglich des timedOn bin ich gerne für Verbesserungsvorschläge offen :) In meinem Fall fange ich es ja wiederum über das Pumpenventil ab.
Bezüglich des Dummys: Was wäre denn die Alternative? Aus meiner Sicht nur ein weiterer physischer Sensor o.ä. anders bekommt FHEM ja nicht mit, auf welcher Position das Ventil steht.
Zitat von: selfarian am 26 Juni 2022, 14:55:56
Bezüglich des Dummys: Was wäre denn die Alternative?
Das hatte Joachim in seinem vorletzten Beitrag schon versucht, zu erklären.
@betateilchen: ich habe event-on-change-reading gesetzt, vielleicht (verm.) kommt deshalb bei mir kein Event bzgl. timedOn bei "normalem" on/off...
@selfarian: z.B. mittels setreading im selben Device "merken"... Allerdings, da das notify auf das Device ja triggert braucht es einen "mini-Sleep", also z.B. sleep 0.1; setreading zg.garten.pumpe_Sw pumpenventil aus Oder direkt im Homematic "Haupt-Device", dann geht es auch ohne sleep: setreading zg.garten.pumpe pumpenventil aus
Gruß, Joachim
hm... klingt generell nicht verkehrt. Allerdings - kann auch sein, dass ich da einen "denkfehler" habe:
Setreading wäre ja dann ein Befehl den ich eingeben müsste. Mit dem Dummy sind es halt 1-2 Klicks um umzuschalten.
Gruß, Alex
Zitat von: selfarian am 26 Juni 2022, 15:34:27
hm... klingt generell nicht verkehrt. Allerdings - kann auch sein, dass ich da einen "denkfehler" habe:
Setreading wäre ja dann ein Befehl den ich eingeben müsste. Mit dem Dummy sind es halt 1-2 Klicks um umzuschalten.
Gruß, Alex
Ah, ja, wenn du extra ein Deivice willst/brauchst wo du auch manuell schalten willst, dann ist es (für dich) so einfacher...
...aber ginge auch mit den bestehenden Devices...
Gruß, Joachim
Zitat von: MadMax-FHEM am 26 Juni 2022, 15:14:18
@betateilchen: ich habe event-on-change-reading gesetzt, vielleicht (verm.) kommt deshalb bei mir kein Event
Das war mir schon klar. Du hast das Standardverhalten gezielt manipuliert. Kann man machen, aber man sollte halt nicht davon ausgehen, dass der manipulierte Zustand der Standard sei und sich bei allen Usern so verhält wie bei Dir.
In meinen gesamten FHEM Installationen gibt es kein einziges device, in dem ich irgendein event-on-irgendwas Attribut gesetzt hätte. Und alles funktioniert trotzdem so, wie ich es möchte.
Und es gibt bei mir auch kein einziges device vom TYPE=dummy 8)
Zitat von: MadMax-FHEM am 26 Juni 2022, 15:45:31
Ah, ja, wenn du extra ein Deivice willst/brauchst wo du auch manuell schalten willst, dann ist es (für dich) so einfacher...
...aber ginge auch mit den bestehenden Devices...
Gruß, Joachim
Ja, es ist halt wirklich das virtuelle Abbild eines manuellen "Schalters". Da der keinerlei elektrik besitzt müsste man da basteln... hab natürlich auch schon überlegt, ob ich da z.b. Fenstersensoren oder so nehme, aber das sind halt dann > 3 Sensoren für das Ventil und das ist aus meiner Sicht dann preislich etwas hoch angesiedelt... vor allem weil ich ja trotzdem manuell umschalten muss.
langsam wird es Zeit für Popcorn...