Z-Wave Gerät verliert/verändert Eigenschaften / Readings

krikan · 04 Mai 2020, 20:34:24

Das ist die 26. Siehst Du im DEF nach der HomeId Deines ZWave-Netzes. Der Name des Devices sollte aber auch funktionieren.

Parador · 04 Mai 2020, 20:43:11

Hm, ok

Habe jetzt nochmal zwei Abfragen gestartet:

Code Auswählen

get ZWDongle_0 routeFor 26 (und auch mit Namen) ergab:

ZitatZWDongle_0 routeFor_26 => last Steinel_Motion at 40kbps

Das verblüfft mich jetzt weil "Steinel_Motion" ein Bewegungsmelder draußen ist und laut DEF die 33 ist...

krikan · 04 Mai 2020, 20:59:58

Das ist schon plausibel.
Bedeutet: Controller hat zuletzt (last) die NodeId 26 (Strips) über den Repeater NodeId 33 (Steinel) mit 40kbps erreicht.

100kbps sollte Ziel sein und das müsste auch über den Steinel funktionieren, da der afaik ZwavePlus ist.
Bestes Ergebnis wäre direkte Kommunikation des Controllers mit dem Strips; blöde Anmerkung: steht so auch in der Strips Anleitung.

Probiere erst mal neigborupdate und dann schauen wir weiter.

Wie groß ist die Entfernung zwischen Strips und Controller? Wie viele und welche Wände?

rudolfkoenig · 04 Mai 2020, 21:07:10

Die Routen meiner ZWDongle haben mich auch schon verbluefft. Da wird Geraet A ueber B und C geroutet, wobei C direkt neben A ist, und B in einer ganz anderen Ecke, ungefaehr genausoweit wie A und C. Und dass das kein Maerchen ist, konnte ich mit einem ZWCUL nachvollziehen.

Evtl. hilft bei dir das Spiel mit neighborUpdate.

In diesem Zusammenhang: falls du bei jedem Geraet "get neighborList" ausfuehrst, dann kann man in der ZWDongle Detailansicht die potentiellen Routen auch grafisch darstellen ("Show neighbor map"). Und ich bin nicht ueberzeugt, dass das vom ZWDongle tatsaechlich so verwendet wird.

Parador · 04 Mai 2020, 21:29:08

Wieder was gelernt..
also der Controller ist ziemlich exakt mittig, der Strip ist zwei massive Wände und der Steinel drei massive Wände und ca 1m weiter vom Controller entfernt...
das NeighborUpdate habe ich gestartet.. denke das braucht noch das entsprechende Wakeup überall...(kann also noch dauern)..
Denke Morgen kann ich den nächsten Versuch starten. Da sollte auch noch ein Repeater in der Nähe sein...
Dann versuche ich die Route manuell auf den Controller zu legen...
Melde mich morgen wieder...

Die Ausgabe der Route zum Steinel ist noch fürchterlicher ;-(

Code Auswählen

ZWDongle_0 routeFor_Steinel_Motion => last ZW_Zwischenschalter_01 at 9.6kbps
Werde morgen mal versuchen das gezielt zu routen ..

krikan · 05 Mai 2020, 08:37:18

Nach einem erfolgreichem neigborUpdate im gesamten Netz, könntest Du vielleicht vor routeFor noch per set-returnRouteAdd allen Geräten Routen für den Rückweg zum Controller zuweisen und dann noch mal testen. set-routeFor ist sehr low-level, darum würde ich das -wie oben geschrieben- nur zur Not nutzen.

Wenn Du (hoffentlich) erfolgreich warst, solltest Du mal das Log kontrollieren, ob es bei ZWave viele Telegrammkollisionen/Funkstörungen gibt (NO_ACK, resend). Die könnten zum automatischen Herabstufen auf 40 bzw. 9.6 führen und Du solltest mal die Ursachen erforschen und versuchen diese zu verhindern. Wann die Geräte wieder automatisch auf 100 hochgehen, ist mir vollkommen unklar.

Parador · 05 Mai 2020, 09:50:18

ok, so werd ich heute Nachmittag vorgehen. Vielleicht auch die Position der Repeater / Relays nochmal überdenken.
heute Morgen hat FHEM mal unerwartet neugestartet und ich fand beim Neustart folgendes im Protokoll:

ZitatZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
ZWDongle_0: SOF missing (got 2c instead of 01)
ZWDongle_0 transmit NO_ACK for CB 01, target EG_Flur

das letzte NO_ACK ist von einem Fibaro MultiSensor der ca 120cm und eine Mauer vom Dongle entfernt ist....

krikan · 05 Mai 2020, 16:07:19

Wenn das nur einmalige bzw. seltene Probleme sind, ist das mMn egal. Nur bei gehäuften Auftreten würde ich Grübeln.

Zitatund wenn wir schon dabei sind, ich vermute, dass alle ZWaveSubDevices Relay-Funktion haben? Also in der Regel die mit Dauerstrom?

Nein, hat damit nichts zu tuen.
"ZWaveSubDevice=no" ist das FHEM-Device für root eines ZWave-Gerätes
"ZWaveSubDevice=yes" sind die FHEM-Devices für die Endpoints eines ZWave-Gerätes
Ein ZWave-Gerät mit mehreren Funktionen und Unterstützung der Command Class MULTI_CHANNEL steuert jede Funktion mit einem separaten Endpoint an. root eines ZWave-Gerätes ist die "übergeordnete" Einheit mit der zentrale Aufgaben angesteuert werden und u.a. Rückwärtskompatibilität mit anderen Kommunikationspartener, die MULTI_CHANNEL nicht beherrschen, sichergestellt wird.
Am Beispiel einer Mehrfach-Steckdosenleiste mit Unterstützung Command Class MULTI_CHANNEL: Jede einzelne Steckdose hat einen zugeordneten Endpoint, der genau diese Steckdose abbildet (An-/Ausschalten, Stromverbrauch,..). Die Steckdosenleiste wird durch root abgebildet, der übergreifende Funktionen wie neigborUpdate bietet und bspw. alle Dosen an- und ausschaltet. Letzteres ist leider nicht generell so, sondern im ZWave-Standard relativ frei definiert.
Details: https://www.silabs.com/documents/login/application-notes/APL12955-Z-Wave-Multi-Channel-Basics.pdf

krikan · 05 Mai 2020, 21:01:44

Testerfahrung im Zusammenhang mit Änderung der Datenübertragungsrate:

Hatte ein ZWave-Netz mit ausschließlich ZWavePlus-Geräten und einem ZWavePlus-Controller (5 Nodes). 2 netzbetriebene Geräte von Qubino und Aeotec hatten eine Datenübertragungsrate von 9,6; jedoch bisher keine durchgekommenen defekten Telegramme.

Habe diese Geräte mit Telegrammen überhäuft in der Hoffnung, dass diese automatisch wieder auf 100 hochschalten. Taten sie aber nicht, sondern blieben bei 9.6. Als genutztes Routenschema wurde im Callback-Telegramm immer "LastWorkingRoute" angezeigt.

Dann habe ich nur bei den beiden Nodes ein neigborUpdate durchgeführt. Bei der nächsten Kommunikation mit den Aktoren war die Übertragungsrate bei beiden Geräten dann plötzlich auf den gewünschten 100 und das angewandte Routenschema war "NextToLastWorkingRoute" laut Callback-Telegramm.

Für die Routenanalyse habe ich meinen (immer noch) unvollendeten Patch-Entwurf aus https://forum.fhem.de/index.php/topic,79893.msg829426.html#msg829426 genutzt. Damit lässt sich das besser nachvollziehen und analysieren als mit manuellen routeFor Abfragen.

Mein vorsichtiges Fazit: neighborUpdate ist wichtiger als von mir vermutet. Die Explorer Frames und andere Selbstheilungsmechanismen scheinen nicht automatisch zum Hochschalten der Übertragungsraten zu führen. Eventuell muss man regelmäßig ein neigborUpdate durchführen, um optimale Übertragungen sicherzustellen und damit auch weniger fehlerhafte Telegramme zu bekommen.

Gruß, Christian

Parador · 05 Mai 2020, 21:08:51

Hallo Christian,
werde mich morgen tiefer in den Patch-Entwurf einlesen. Aktuell habe ich versucht die Routen nachzuvollziehen, scheitere gerade daran, dass zu dem einen Gerät keine Route angezeigt wird, obwohl ein open/close ankommt...
Vielleicht setze ich nochmal die Repeater "perfekt" in die Mitte und mache noch ein neigborUpdate.
Habe ich eigentlich mit "get model" auch eine Chance auf Bereinigung der Readings? oder wird da nur das "Typenschild" neu eingelesen?

krikan · 05 Mai 2020, 21:26:18

Zitat von: Parador am 05 Mai 2020, 21:08:51
werde mich morgen tiefer in den Patch-Entwurf einlesen.

Musst Du nicht. Sollte auch ohne funktionieren. Ist nur Hintergrund-Info woher Routingschema kommt und ein wenig selbstaufgebauter Druck für mich mal endlich weiterzumachen. Bei Interesse darfst Du natürlich...

ZitatAktuell habe ich versucht die Routen nachzuvollziehen, scheitere gerade daran, dass zu dem einen Gerät keine Route angezeigt wird, obwohl ein open/close ankommt...

Wenn nur die Übertragungsrate bei routeFor angezeigt wird, ist das eine Direktverbindung zwischen Controller und Gerät.
Eigentlich sollte Dein Ziel nur sein bei ZwavePlus-Geräten die 100 als Übertragungsrate angezeigt zu bekommen. Die Route an sich ist (relativ) uninteressant; außer beim Strips (-> laut Anleitung Batterieschonung durch Direktverbindung zum Controller)

ZitatHabe ich eigentlich mit "get model" auch eine Chance auf Bereinigung der Readings? oder wird da nur das "Typenschild" neu eingelesen?

Keine Chance. Nimm einfach https://fhem.de/commandref.html#deletereading zum Aufräumen.

krikan · 05 Mai 2020, 21:34:00

Zitat von: Parador am 05 Mai 2020, 21:08:51
Vielleicht setze ich nochmal die Repeater "perfekt" in die Mitte und mache noch ein neigborUpdate.

Anmerkung: Damit die Datenübertragungsrate von 100 genutzt wird müssen alle Geräte auf der Route ZWavePlus sein und die 100 unterstützen. Ein ohne Plus-Gerät als Repeater zwingt zu höchstens 40. Andererseits könnte dennoch eine Stabilisierung eintreten. Jaja, hätte, könnte, wäre.

Parador · 04 Juni 2020, 16:09:32

Hallo Krikan,
ich kämpfe immer noch an meiner ZWave-Aufstellung. Noch sind nicht alle Repeater und andere Switches die als Repeater dienen könnten da...
Ich versuche immer noch meinen Sensative Strips die richtige Route mitzugeben, scheitere aber noch an der "Erreichbarkeit" bis sie aufwachen.
Du hast ja geschrieben: "außer bei dem Strips (-> laut Anleitung Batterieschonung durch Direktverbindung zum Controller)."
Mache ich das konkret? Ich versuche die Rückroute mit

Code Auswählen

set <Sensative_Name> returnRouteAdd <ZwaveControllerName>
zu manipulieren.
Oder muss ich hier noch was dazwischenpacken? Was ist, wenn die "Route zu lang" wird und der Sensative die Telegramme nicht bis zum Controller bringt? (Krieg ich das mit, außer dass keine Veränderungen kommen?
Danke für Deine Unterstützung schon jetzt

krikan · 06 Juni 2020, 07:53:48

Nach dem neigborUpdate für das Netz, kannst Du die Rückroute mit returnRouteAdd so wie von Dir gezeigt manipulieren. Welche Rückrouten der Controller an das Gerät schickt, kannst Du nicht beeinflußen. Mir ist auch kein Weg bekannt, wie man diese auslesen kann.

ZitatWas ist, wenn die "Route zu lang" wird und der Sensative die Telegramme nicht bis zum Controller bringt? (Krieg ich das mit, außer dass keine Veränderungen kommen?

~~returnRouteAdd erzeugt die Events laut commandref mit Infos zu Erfolg/Mißerfolg.~~
Schlimmstenfalls tritt Deine Befürchtung für spontane Nachrichten des Sensative ein. Wenn der Controller/Du einen Befehl an den Sensative schickt und NO_ACK auftaucht, siehst Du auch direkt, dass etwas im Argen liegt.

Mit dem Controllerbefehl get-routeFor kannst Du nachträglich herausfinden, welche Route der Controller zum Versand wählt.

Parador · 07 Juni 2020, 18:53:04

Und schon wieder hat sich eine Frage aufgetan:

Code Auswählen

set <Sensative_Name> returnRouteAdd <ZwaveControllerName> stimmt ja nicht ganz, eigentilich muss es wieder

Code Auswählen

set <Sensative_Name> returnRouteAdd <ZwaveControllerDezimaleNodeID> sein.

und die ist diesmal nicht in der DEF ... kannst Du mir da auch nochmal helfen?

Code Auswählen

Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/ttyACM0@115200
   DeviceName /dev/ttyACM0@115200
   FD         20
   FUUID      5c7add52-f33f-3c2f-24e7-3f62334ad9a8224f
   MaxSendRetries 3
   NAME       ZWDongle_0
   NR         59
   PARTIAL    
   RAWMSG     000400120a3202a14a0000012d0000
   ReadTime   1591548487.11977
   STATE      Initialized
   SendRetries 0
   SendTime   1591546173.18217
   TYPE       ZWDongle
   WaitForAck 0
   ZWDongle_0_MSGCNT 1229
   ZWDongle_0_TIME 2020-06-07 18:48:07
   homeId     e65a849f
   nodeIdHex  01
   nrNAck     0