Welche halbwegs generalisierbaren Tipps kann man den FHEM-Usern für ein stabiles ZWave-Netz (wenig Telegrammkollisionen, wenig Telegrammverluste,..) insbesondere bei der Anlage von Steuerungslogiken mit FHEM per at, notify, DOIF, ... geben?
Mir fallen ein:
- Gleichzeitiges Verschicken von Befehlen an (viele) verschiedene netzbetriebene Geräte (per at, DOIF, notify,..) vermeiden. Dazu leicht zeitversetztes Senden bspw. mit Hilfe von sleep zwischen den Befehlen an verschiedene Geräte oder einer structure mit entsprechend gesetztem Attribut async_delay sicherstellen. Bei Befehlen an verschiedene WAKEUP-Geräte ist das gleichzeitige Absetzen mehrerer Befehle regelmäßig unproblematisch, da diese an verschiedenen Zeitpunkten aufwachen. Bei mehreren Befehlen an ein Gerät sind gleichzeitig abgesetzte Befehle normalerweise unproblematisch, da FHEM eine serielle Abarbeitung sicherstellt.
- Funkverkehr an der Quelle reduzieren, d.h. unnötige Telegramme des ZWave-Gerätes an den Controller nach Möglichkeit per Geräte-Konfiguration ausschalten bzw. das Sendeintervall reduzieren. Assoziationen mit dem Controller auf die notwendigen AssocGroups beschränken. (Hat eigentlich nur mittelbaren Einfluß; aber "Dauer"sender stören auch den Ablauf)
Hintergrund: Wollte das eigentlich in die Wiki-FAQ packen, hätte aber vorher gerne Meinungen, Ideen, Kritik, ...
Gruß, Christian
Fuer weit entfernte Geraete an strategischen Stellen Repeater (wie Zwischenstecker) einbauen. Was weit entfernt ist, haengt von den Zwischenwaenden ab.
Bei der Beschaffung auf ZWave+ achten.
Soweit moeglich, den Controller in der Mitte zu platzieren.
Edit: sehe gerade, dass du von der Steuerungslogik sprichst. Damit sind meine Bemerkungen hier fehl am Platz.
wie reagiert FEHM eigentlich auf ein
set ZW_Device_.* off
?
Wird das "off" an alle Geräte die mit "ZW_Device_" anfangen gleichzeitig gesendet, oder werden Pausen zwischen den einzelnen Funktelegrammen eingehalten?
Wenn obiger Befehl unweigerlich zu Funk-Kollisionen führt, wäre es toll wenn FHEM automatisch Pausen machen würde um die Kollisionen zu vermeiden!
LG
Rainer
Genau das ist der Problemfall den ich mit 1. verhindern möchte. Der Versand des Befehls erfolgt schon nacheinander, aber die ACK und Antworten der Geräte stören sich je nach Telegramlaufzeiten gegenseitig.
Der Ablauf ist bei set- und get-Befehlen unterschiedlich implementiert; Problem ist aber nahezu gleich.
Automatische Pausen wünsche ich mir eben nicht, da ich momentan deutlich flexibler in der Steuerung bin, als bei eventuellen eingebauten Versuchen Telegrammlaufzeiten vorherzusagen. Nur muss man das Thema als Anwender kennen.
Der Punkt 1. gilt im Prinzip auch für FLiRS Geräte. Ich hatte das in einem anderen Zusammenhang mal kurz als Fehlerquelle im Verdacht, allerdings habe ich genau mit 3 dieser Geräte (Spirit Z-Wave PLUS Thermostate) über das letzte Jahr keine Probleme festgestellt, die darauf zurückzuführen sind. Obwohl ich genau das mache: Eine neue Ziel Temperatur auf ein mal an alle senden.
Zitat von: thewolfman am 07 November 2018, 10:48:21
Der Punkt 1. gilt im Prinzip auch für FLiRS Geräte. Ich hatte das in einem anderen Zusammenhang mal kurz als Fehlerquelle im Verdacht, allerdings habe ich genau mit 3 dieser Geräte (Spirit Z-Wave PLUS Thermostate) über das letzte Jahr keine Probleme festgestellt, die darauf zurückzuführen sind. Obwohl ich genau das mache: Eine neue Ziel Temperatur auf ein mal an alle senden.
Der gleichzeitige Versand muss dummerweise keine Probleme machen, aber kann.
Bei den FLiRS-Geräten bin ich aber unsicher, ob der gleichzeitige Versand an mehrere FLiRS-Geräte nicht unter Umständen sogar Vorteile bringt: Nach einer Theorie, die ich vergangene Woche gelesen habe, weckt ein Beam alle FliRS-Geräte im Netz auf, da der Beam nicht gerätespezifisch ist. Wenn das zutrifft, dann könnte das FHEM-Vorgehen zu einer schnelleren Abarbeitung als eine strikte serielle Abarbeitung der Befehle über alle Geräte führen und eventuell sogar batterieschonend sein. Habe noch nicht getestet, ob diese Theorie stimmt. In offziellen ZWave-Dokus finde ich dazu nicht. Aber selbst wenn es stimmt, kann man Kollisionen bei gleichzeitigem Versand nicht ausschließen.
Jetzt wird es (mache ich es?) so kompliziert, dass ich schon fast wieder überlege, keine "generalisierten" Hinweise zu geben. :-\
Nach Nachschauen im Code und drüber Grübeln: Selbst wenn Theorie zum Beam stimmt, dann gibt es aufgrund des Sendeablaufes in FHEM keine Vorteile.
Hallo Christian,
der Punkt 1 ist sicherlich für alle, die nicht so tief in der Materie drin sind wie Du sehr hilfreich. Ich hatte ja auch das Problem mit meine 10 Spirits und dem gleichzeitigen Einstellen der Temperaturen. Mit Deinen und Rudis Tipps habe ich ja dann "InternalTimer" verwendet, um den Nachrichtenversand zu serialisieren.
Gruß
Torsten