Best practice Verbindungsprobleme / Funkausfälle

[Flachzange]

Neben meiner umfangreichen EnOcean-Installation habe ich Rauch- und Co-Melder von Fibaro mit ZWave. Diese sind bekanntermaßen keine aktiven Komponenten im Netz und können Nachricht nicht weiterleiten. Also habe ich noch zwei Wall-Plugs, um auch alle Melder zu erreichen.

Bei EnOcean habe ich mir diverse Watchdog-Konstrukte gebaut, um herauszfinden, ob ein Aktor/Sensor nicht vernünftig erreichbar oder sogar ausgefallen ist.

Wie realisiere ich das bei ZWave am besten? Es gibt ja das transmit-Reading. Was genau sagt das aus? Kann man das für diesen Zweck benutzen?

Danke und Gruß
Chris

[rudolfkoenig]

Es gibt ja das transmit-Reading. Was genau sagt das aus?

Ob die letzte Netzwerkuebertragung erfolgreich war.

Weiterhn gibt es timeToAck. Ich wuerde Sorgen machen, falls das ueber 0.1s liegt.

Wenn man fuer alle Geraete erst ein "set neighborUpdate" und dann ein "get neighborList" durchfuehrt (neighborUpdate bitte nicht als "batch" absetzen", das brauht seine Zeit), dann kann man im ZWDongle Detailfenster mit "Show neighbor map" das "statische" Routing anzeigen lassen. Das ist nur ein grober Hinweis, da neuere Geraete auch "dynamisch" routen koennen.

[Flachzange]

Ob die letzte Netzwerkuebertragung erfolgreich war.

Ok, danke. Nur damit ich es verstehe: Die Rauchmelder melden sich in einem regelmäßigen Wakeup-Interval oder werden diesen in einem regelmäßigen Interval abgefragt? Also wer initiert die Kommunikation und wie wird ein NO_ACK ermittelt? Wenn das jetzt ZWave-Basic-Fragen sind, gerne an die richtige Stelle verlinken.

Weiterhn gibt es timeToAck. Ich wuerde Sorgen machen, falls das ueber 0.1s liegt.

Ich habe tatsächlich ein paar Geräte, bei denen das der Fall ist. Warum ist das problematisch? Ich habe keine zeitkritischen Abläufe. Ob das Rauchmelder-Signal jetzt nach 0,1 oder 0,5 Sekunden kommt, ist mir nicht so wichtig, Hauptsache ist, es kommt an.

[rudolfkoenig]

Also wer initiert die Kommunikation und wie wird ein NO_ACK ermittelt?

Batteriebetriebene Geraete wachen in einem konfigurierbaren Intervall auf.
Das Modul sendet die bis dahin angefallenen Anfragen dann los.
Die Anfrage selbst muss bestaetigt werden (die Antwort kommt spaeter).
NO_ACK heisst, dass eine Anfrage oder Befehl nicht quittiert wurde.

Wenn das jetzt ZWave-Basic-Fragen sind, gerne an die richtige Stelle verlinken.

Wir haben einen umfangreichen Wiki-Artikel: https://wiki.fhem.de/wiki/Z-Wave mit etlichen Links.

Warum ist das problematisch? Ich habe keine zeitkritischen Abläufe.

Weil das zeigt, dass die Befehle erst nach etlichen Wiederholungen bestaetigt wurden.
Eine Nachricht wird hoehstens 3-mal gesendet.
Wenn die Quittug erst bei der Dritten erfolgt, ist die Wahrscheinlichkeit gross, dass sie manchmal gar nicht ankommt.

[Flachzange]

Dank Dir. Ich habe mir jetzt mal die Lektüre von Herrn Dr. Pätz zu Gemüte geführt. Das hilft beim Verständnis