Autor Thema: Tipp(s) für ein stabiles ZWave Netz bei der Anlage der FHEM-Steuerungslogik  (Gelesen 370 mal)

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6120
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 19374
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.

Offline gamauf

  • Full Member
  • ***
  • Beiträge: 284
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

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6120
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.

Offline thewolfman

  • New Member
  • *
  • Beiträge: 4
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.

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6120
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.  :-\

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6120
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.

Offline ToKa

  • Full Member
  • ***
  • Beiträge: 330
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
RaspberryPi3 mit RaZberry2
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
GreenWave: PowerNode 1 port
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Zipato Bulb 2

 

decade-submarginal