Was flutet mein ZWave Netzwerk?

[der_oBi]

Hey zusammen,

irgendwie weiß ich mir keinen Rat mehr...Bis gestern morgen hat mein Z-Wave Netzwerk tadellos funktioniert. Ich habe zB 9 Fibaro Roller Shutter im Einsatz. Von denen reagierten 3 nur noch sporadisch, mittlerweile sogar garnicht mehr. Teilweise findet ein ansprechbarer RS den danebenliegenden RS nicht mehr als Nachbar 

Mit Verbose 4 auf dem ZWDongle bekomme ich folgende immer wiederkehrenden Logeinträge:

Code Auswählen Erweitern

2018.02.20 20:51:11 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220004 CB:00
2018.02.20 20:51:13 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220003 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:13 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220003 CB:00
2018.02.20 20:51:14 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220004 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:14 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220004 CB:00
2018.02.20 20:51:17 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220003 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220003 CB:00
2018.02.20 20:51:18 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220004 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:18 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220004 CB:00
2018.02.20 20:51:37 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220003 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:37 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220003 CB:00
2018.02.20 20:51:39 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220004 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:39 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220004 CB:00
2018.02.20 20:51:40 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220003 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:40 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220003 CB:00
2018.02.20 20:51:44 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220004 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:44 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220004 CB:00
2018.02.20 20:51:45 4: ZWDongle_Read ZWDongle_0: rcvd 0004001006310504220003 (request APPLICATION_COMMAND_HANDLER), sending ACK
2018.02.20 20:51:45 4: CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:06310504220003 CB:00

Sieht für mich aus, als würde irgendwas im Sekundentakt mein ZWave Netzwerk zuspammen. Oder verstehe ich hier was falsch?
Falls dem so ist: Wie finde ich heraus, wer das ist und wieso er das macht?

Ich hoffe, Ihr könnt mir helfen. Ich liefere natürlich gerne noch weitere Infos nach.

Gruß

[krikan]

ID:10 = NodeId 10hex = NodeId 16dec  schickt andauernd Nachrichten (power).
Den Aktor vielleicht mal vom Strom nehmen.
Gruß, Christian

[der_oBi]

Hey, super, danke für die Hilfe!
Es war ein Wall Plug, der einen Standby-Strom der zwischen 0,3 und 0,4W schwankt, immer und immer wieder reported hat 

[der_oBi]

Das zweite Problem mit den nur sporadisch ansprechbaren Roller Shuttern habe ich auch gelöst...
Da sich in einer Abzweigdose eine Neutralklemme gelöst hatte (sind noch im Fast-Rohbau) waren die ohne Strom.
Was ich aber nicht verstehe: Außer diesen dreien waren auch die anderen nur noch sporadisch ansprechbar. Morgens wenn alle Rollos gleichzeitig hochfahren sollten, bekam ich reihenweise no-Acks, auch von den übrigen Aktoren und sonstigen ZWave Geräten.

Wieso ist das so? Wollte der ZWDongle über die RSen routen, die nun eben stromlos waren, und konnte daher die Nachrichten nicht an den "Mann" bringen? Ich dachte, das würde das Mesh-Netzwerk von alleine hinbringen?

Seitdem nun alle wieder mit Strom versorgt sind ist jedenfalls auch dieses Problem gelöst. 

[krikan]

Damit Mesh helfen kann, muss zunaechst eine mögliche Route zwischen Controller und Geraeten existieren, die eine Kommunikation funktechnisch erlaubt. Diese Route muss insb. dem Controller bekannt sein. Wenn sie dem Controller nicht bekannt ist, könnten Explorer Frames für eine Selbstheilung (=selbststaendige Routenermittlung) sorgen. Dann muss aber neben den Geraeten auch der Controller Explorer Frames beherrschen. Also einige zu erfüllende Bedingungen.

Und wenn es ganz dumm kommt, dann sorgen Unmengen von Explorer Frames für Funkstörungen im ZWave-Netz.

[der_oBi]

Meines Wissens sind alle ZWave Geräte Gen5. Das heisst doch, dass sie Explorer Frames unterstützen, oder?

Vielleicht war ja genau die Menge an Explorer Frames dann der Grund für die zahlreichen No-Acks?

[krikan]

Meines Wissens sind alle ZWave Geräte Gen5. Das heisst doch, dass sie Explorer Frames unterstützen, oder?

Die Fibaro FGR(M)-222 sind mWn alle noch Gen3, können aber Explorer Frames. Die Reichweite der FGR(M)-222 ist nach meiner eigenen Erfahrung eingebaut nicht so groß.

Vielleicht war ja genau die Menge an Explorer Frames dann der Grund für die zahlreichen No-Acks?

Kann sein, muss aber nicht    Geraten: Kein Explorer Frames Problem, sondern es gab einfach keine per Funk nutzbare Route.
Ob es an Explorer Frames lag/liegt, kann man am Besten mit ZWCUl in Lauschmodus feststellen.

[der_oBi]

Du hast (natürlich) recht. Ich hatte abgespeichert die FGR-222 wären ebenfalls Gen5, sind sie aber nicht.
Und trotzdem können sie mit Explorer Frames umgehen? Muss ich also nicht bei jeder neuen Inklusion auf allen ZWave Geräten ein neighborUpdate anstoßen?

[krikan]

Und trotzdem können sie mit Explorer Frames umgehen?

Ja. Es sind Gen3 mit SDK 4.5 und beherrschen deshalb Explorer Frames. Gen3-Geraete mit SDK 5.x beherrschen hingegen keine Explorer Frames.
Explorer Frames sind keine Errungenschaft von ZWavePlus oder Gen5, obwohl man das aus den Angaben zu ZWavePlus schließen könnte, sondern ein "altes" Feature.

Muss ich also nicht bei jeder neuen Inklusion auf allen ZWave Geräten ein neighborUpdate anstoßen?

Meiner Meinung nach ist das neigborUpdate dann normalerweise nicht notwendig, schadet aber nicht.