Versetztes Ein- und Ausschalten mehrerer Geräte

[Christian.]

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:

Code Auswählen Erweitern


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?

[DS_Starter]

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.

[enno]

oder mit zwei at wie von DS_Starter beschrieben und LightScene https://commandref.fhem.de/commandref.html#LightScene

Gruss
  Enno

[Morgennebel]

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

[Byte09]

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/"]https://wiki.fhem.de/wiki/MSwitch/[URL]

Gruss Byte09

Gesendet von meinem SM-G900F mit Tapatalk

[Beta-User]

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.

Sprechen die alle dasselbe Protokoll? Dann wäre diese Anforderung doch völlig unsinnig...

Der Einwand dürfte daher in die falsche Richtung gehen...

[Morgennebel]

Der Einwand dürfte daher in die falsche Richtung gehen...

Warum? Die Anforderung des TEs war, daß sich die

die 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

[Christian.]

Vielen Dank für Eure Antworten, da sollte ja was dabei sein.

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.

[Morgennebel]

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:

The 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

[Panik]

Das Ganze würde ich auch mit MSwitch lösen - das ist einfach genial.

[Christian.]

Bist 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.