Anwendungsfall: eine Reihe von Geräten soll abends ein- und morgens ausgeschaltet werden. Dabei sollen die Schaltbefehle in einigen Sekunden Abstand erfolgen, damit die Funksignale sich nicht stören.
Meine derzeitige Lösung:
define foo_a ...
define foo_b ...
define structure_foo structure foo foo_a foo_b
attr structure_foo async_delay 2
define at_foo at *{sunset(-1800)} set structure_foo on-till-overnight {sunrise(+3600)}
Ergebnis: Die Geräte werden 30 Minuten vor Sonnenuntergang mit jeweils 2 Sekunden Abstand eingeschaltet - wie gewünscht, bestens.
Problem: Die Geräte werden 1 Stunde nach Sonnenaufgang ausgeschaltet, aber nicht versetzt, sondern alle genau zur selben Zeit.
Gibt es eine Lösung für dieses Problem ohne einzelne at-Befehle pro Gerät?
Zum Beispiel dieser Lösungsansatz:
Zwei Strukturen. Eine zum Einschalten (s.ein), eine zum Ausschalten (s.aus).
Zwei at ... eines zum Einschalten mit structure s.ein und das zweite at mit s.aus.
oder mit zwei at wie von DS_Starter beschrieben und LightScene https://commandref.fhem.de/commandref.html#LightScene
Gruss
Enno
Zitat von: Christian. am 31 Januar 2019, 06:58:52
Dabei sollen die Schaltbefehle in einigen Sekunden Abstand erfolgen, damit die Funksignale sich nicht stören.
Sprechen die alle dasselbe Protokoll? Dann wäre diese Anforderung doch völlig unsinnig...
Ciao, -MN
Kannst du relativ einfach mit einem MSwitch lösen. Dort kannst du sunset / sunrise als schaltzeitpunkt setzen , bei den einzelnen schaltbefehlen aber ein 'delay' setzen.
[URL]https://wiki.fhem.de/wiki/MSwitch/[URL]
Gruss Byte09
Gesendet von meinem SM-G900F mit Tapatalk
statt 2 at geht u.a. auch weekdaytimer
Das Problem dürfte daher kommen, dass structure den einen Befehl an die zugehörigen Devices vererbt. Dadurch ist dann aber der Ausschaltzeitpunkt bei allen gleich.
Zitat von: Morgennebel am 31 Januar 2019, 09:08:10
Sprechen die alle dasselbe Protokoll? Dann wäre diese Anforderung doch völlig unsinnig...
Der Einwand dürfte daher in die falsche Richtung gehen...
Zitat von: Beta-User am 31 Januar 2019, 09:36:22
Der Einwand dürfte daher in die falsche Richtung gehen...
Warum? Die Anforderung des TEs war, daß sich die
Zitatdie Funksignale sich nicht stören
Daher die Frage, welche Funkprotokolle und -frequenzen im Spiel sind. Ist es nur ein IO/ein Protokoll, ist dieser ganze Aufwand doch nicht notwendig...?
Ciao, -MN
Vielen Dank für Eure Antworten, da sollte ja was dabei sein.
Zitat von: Morgennebel am 31 Januar 2019, 09:08:10
Sprechen die alle dasselbe Protokoll? Dann wäre diese Anforderung doch völlig unsinnig...
Nein, im konkreten Fall eine Mischung aus IT und Z-Wave. Die Z-Wave-Geräte quittieren die Schaltbefehle; der zeitliche Versatz soll hier verhindern, dass die Quittung des ersten Z-Wave-Gerätes nicht mit dem Schaltbefehl für das zweite Z-Wave-Gerät kollidiert.
Zitat von: Christian. am 31 Januar 2019, 16:23:33
Die Z-Wave-Geräte quittieren die Schaltbefehle; der zeitliche Versatz soll hier verhindern, dass die Quittung des ersten Z-Wave-Gerätes nicht mit dem Schaltbefehl für das zweite Z-Wave-Gerät kollidiert.
Ich bin verwirrt. Laut Beschreibung:
ZitatThe Z-Wave protocol uses standard collision-avoidance methods when the transmission is postponed by a random number of milliseconds when media is busy.
The Z-Wave transfer layer controls the transfer of data between two nodes including retransmission, checksum check, and acknowledgements.
Damit sollte Z-Wave (analog zu TCP/IP) Befehle zur Not doppelt schicken. Bist Du sicher, daß Du Dein richtiges Problem löst und nicht ein Symptom eines anderes Problemes umgehst?
Ciao, -MN
Das Ganze würde ich auch mit MSwitch lösen - das ist einfach genial.
Zitat von: Morgennebel am 31 Januar 2019, 17:20:01Bist Du sicher, daß Du Dein richtiges Problem löst und nicht ein Symptom eines anderes Problemes umgehst?
Nein, bin ich nicht. Das Debugging von Verbindungsproblemen ist bei Z-Wave kein Zuckerschlecken.
Aber so habe ich auf jeden Fall wieder etwas gelernt.