Bei Abarbeitung meherer Befehle an Aktor kommen nicht alle an

[Fixel2012]

Guten Abend,

wie im Titel schon beschrieben, kommt es sehr häufig dazu, dass Aktoren auf gesendete Befehle nicht reagieren.

Im log sind dann folgende Einträge zu finden:

Code Auswählen Erweitern

2017.05.28 21:44:09 3: ZWave set UG.Schlafzimmer dim 35
2017.05.28 21:44:09 3: ZWave set 1OG.Bad dim 35
2017.05.28 21:44:09 3: ZWave set 1OG.Flur dim 35
2017.05.28 21:44:09 3: ZWave set 1OG.Martina dim 35
2017.05.28 21:44:09 3: ZWave set 1OG.Rolf_Links dim 35
2017.05.28 21:44:09 3: ZWave set 1OG.Rolf_Rechts dim 35
2017.05.28 21:44:09 3: ZWave set EG.Wohnzimmer_Rechts dim 35
2017.05.28 21:44:09 3: ZWave set EG.Wohnzimmer_Mitte_Rechts dim 35
2017.05.28 21:44:09 3: ZWave set EG.Wohnzimmer_Mitte_Links dim 35
2017.05.28 21:44:09 3: ZWave set EG.Wohnzimmer_Links dim 35
2017.05.28 21:44:09 3: ZWave set EG.Kueche dim 35
2017.05.28 21:44:09 3: ZWave set EG.Bad dim 35
2017.05.28 21:44:12 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130803260123254985
2017.05.28 21:44:12 2: ERROR: cannot SEND_DATA to EG.Bad: transmit queue overflow
2017.05.28 21:44:14 2: ZWave: No ACK from EG.Wohnzimmer_Mitte_Links after 5s for sentset:1309032601232548
2017.05.28 21:44:14 2: ZWave: No ACK from EG.Wohnzimmer_Links after 5s for sentset:1308032601232549
2017.05.28 21:44:14 2: ZWave: No ACK from EG.Kueche after 5s for sentset:130c03260123254a
2017.05.28 21:44:14 2: ZWave: No ACK from EG.Bad after 5s for set:130b03260123254b
2017.05.28 21:44:15 2: ZWDongle_Fibaro transmit NO_ACK for CB 49, target EG.Wohnzimmer_Links
2017.05.28 21:45:09 3: ZWave set EG.Esszimmer dim 35
2017.05.28 21:45:09 3: ZWave set Markise_Links on
2017.05.28 21:45:09 3: ZWave set Markise_Rechts on
2017.05.28 21:45:15 2: ZWave: No ACK from Markise_Rechts after 5s for sentset:131a032601FF254e
2017.05.28 22:36:56 1: Perfmon: possible freeze starting at 22:36:55, delay is 1.106

Habe schon in anderen Threads laut Rudi gehört, dass dies eigentlich nicht auftreten sollte 

ich schätze mal es liegt an der Überlastung des Zwave Netzwerks. Dies könnte man bestimmt Provisorisch durch ein paar sleeps im Code lösen. Aber ob das eine Dauerlösung ist, weiß ich nicht.

Weiß hier jemand mehr?

Danke und Gruß,

Fixel

[rudolfkoenig]

Eigentlich sollte ein sleep nicht helfen, da ZWave/ZWDongle die Befehle auf einem SendStack speichert, und diese erst nach dem ACK weiterschickt. Kannst du bitte was zur Topologie bzw. Routing der einzelnen Komponenten sagen, und ein "attr ZWDongle verbose 5" Mitschnitt des Problems hier anhaengen?

[Thyraz]

Ich hab solche Probleme auch schon teilweise gehabt.
Meine Vermutung war damals, dass die Geräte eben von sich aus nach einer Änderung sehr schnell weitere Rückmeldungen schicken.

Ein Dimmer z.B. den neuen Helligkeitswert, aktueller Stromverbrauch usw.
Kenn mich mit den Interna des Funkprotokolls aber zu wenig aus.

In solchen Fällen haben minimale Verzögerungen (0.1 bis 0.2 Sekunden) solche NO ACK Meldungen zuverlässig behoben.

[Fixel2012]

Eigentlich sollte ein sleep nicht helfen, da ZWave/ZWDongle die Befehle auf einem SendStack speichert, und diese erst nach dem ACK weiterschickt. Kannst du bitte was zur Topologie bzw. Routing der einzelnen Komponenten sagen, und ein "attr ZWDongle verbose 5" Mitschnitt des Problems hier anhaengen?

Verbose 5 habe ich so eben Gesetz, bis heute Abend werde ich es nach liefern.

Was genau meinst du mit Routing bzw Topologie?

Beides sagt mir was aber nicht im dem zwave Zusammenhang.

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

EDIT: vielleicht ist das hier auch wichtig:
https://forum.fhem.de/index.php/topic,66770.0.html

[Fixel2012]

Ich hab solche Probleme auch schon teilweise gehabt.
Meine Vermutung war damals, dass die Geräte eben von sich aus nach einer Änderung sehr schnell weitere Rückmeldungen schicken.

Ein Dimmer z.B. den neuen Helligkeitswert, aktueller Stromverbrauch usw.
Kenn mich mit den Interna des Funkprotokolls aber zu wenig aus.

In solchen Fällen haben minimale Verzögerungen (0.1 bis 0.2 Sekunden) solche NO ACK Meldungen zuverlässig behoben.

Ok, Mal schauen was bei rum kommt.

Die Verzögerung hast du beim Senden durch ein sleep Gesetz?

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

[rudolfkoenig]

Was genau meinst du mit Routing bzw Topologie?

Ob der ZWDongle die Geraete immer direkt erreicht, oder ob Zwischenstecker als Router verwendet werden, womoeglich mehrere Zwischenstecker fuer manche Geraete. Einen groben Hinweis darauf kann man aus dem ZWDongle-DetailAnsicht-"Show neighbor map" gewinnen.

[Fixel2012]

Ob der ZWDongle die Geraete immer direkt erreicht, oder ob Zwischenstecker als Router verwendet werden, womoeglich mehrere Zwischenstecker fuer manche Geraete. Einen groben Hinweis darauf kann man aus dem ZWDongle-DetailAnsicht-"Show neighbor map" gewinnen.

Guter Einwand! es könnte tatsächlich sein, dass ich dort nochmal eine zweite Steckdose als Repeater einsetzen muss!

Werde das heute nochmal Testen.

Was mich daran wundert, ist nur, dass ich keine Batterie-betriebenden Aktoren benutze. Ich dachte immer das jeder Aktor der eine aktive Stromversorgung hat automatisch als Repeater dient?

Um genau zu sein Nutze ich nur Fibaro, 16 Roller shutter 2 und nach anderes zeug wie Dimmer.

[krikan]

EDIT: vielleicht ist das hier auch wichtig:
https://forum.fhem.de/index.php/topic,66770.0.html

Achtung: Edits bekommt nicht jeder Forenteilnehmer unbedingt mit! 
Die Sekundärcontrollergeschichte könnte einen gewissen Einfluß haben, obwohl ich nicht glaube(!) einen entscheidenden. Ist das HC permanent aus?
Mehr kann man vielleicht auch im verbose 5 Log erkennen.

Was mich daran wundert, ist nur, dass ich keine Batterie-betriebenden Aktoren benutze. Ich dachte immer das jeder Aktor der eine aktive Stromversorgung hat automatisch als Repeater dient?

Ja, aber das sagt noch nichts über die Route des Telegramms und mögliche Erreichbarkeitsprobleme aus. Zudem nehmen Telegramme manchmal sonderbare Routen und nicht unbedingt den kürzesten Weg.
Die letzte vom Controller genutzte Route zum Node x kann man mit "get <ZWDongle> routeFor <NodeID>" abrufen.

[Fixel2012]

Ist das HC permanent aus?

Nein, dauerhaft an 

Ja, aber das sagt noch nichts über die Route des Telegramms und mögliche Erreichbarkeitsprobleme aus. Zudem nehmen Telegramme manchmal sonderbare Routen und nicht unbedingt den kürzesten Weg.
Die letzte vom Controller genutzte Route zum Node x kann man mit "get <ZWDongle> routeFor <NodeID>" abrufen.

Tatsächlich werden sehr seltsame Routen genommen...  Das meiste geht direkt über den zweit controller. Beispiel: Schaltsteckdose im Heizungsraum -> Fhem ist 1 Meter entfernt -> sendet aber erst an das HC -> dann über einen weiteren Aktor erst zum Heizungskeller.

Der speed war immer mit 40kbps angegeben.

[krikan]

Nein, dauerhaft an 

Wenn HC nicht irgendetwas automatisch repariert/reparieren will, beruhigt mich das.

Tatsächlich werden sehr seltsame Routen genommen...  Das meiste geht direkt über den zweit controller. Beispiel: Schaltsteckdose im Heizungsraum -> Fhem ist 1 Meter entfernt -> sendet aber erst an das HC -> dann über einen weiteren Aktor erst zum Heizungskeller.

Probiere einmal bei einem Aktor ein neigborUpdate mit FHEM anzustoßen und schau mal, ob das etwas ändert.
Welcher Controller ist SUC im Netz? Sollte nicht HC sein. Ist ein SIS eingerichtet?

Der speed war immer mit 40kbps angegeben.

Begrenzender Faktor ist immer das Gerät mit der niedrigsten kbps auf der Route. FGRM und HC können nur 40k. Nur die Fibaro ZWave+-Geräte unterstützen 100k, das ist aber eigentlich nicht tragisch.

[Fixel2012]

Wenn HC nicht irgendetwas automatisch repariert/reparieren will, beruhigt mich das.

Das weiß ich nicht, bzw was sollte es denn reparieren wollen?

Probiere einmal bei einem Aktor ein neigborUpdate mit FHEM anzustoßen und schau mal, ob das etwas ändert.
Welcher Controller ist SUC im Netz? Sollte nicht HC sein. Ist ein SIS eingerichtet?

SUC ist Fhem, SIS ist denke ich mal das HC. Bin mir da aber nicht sicher.

[krikan]

Das weiß ich nicht, bzw was sollte es denn reparieren wollen?

Ist (für mich) eine Black Box. Keine Ahnung, was die alles automatisch macht  (Routenupdates, Assoziationenkorrektur,...).

SUC ist Fhem, SIS ist denke ich mal das HC. Bin mir da aber nicht sicher.

Wenn das aus dem anderen Thread für den FHEM-Controller (noch) gilt:

Code Auswählen Erweitern

2017-02-11 14:51:07   ctrlCaps        OTHER MEMBER SUC
Dann ist das ein SUC mit aktivierter SIS-Funktionalität. Man könnte notfalls HC ausstellen, neigbhorUpdate von FHEM aus durchführen und hätte damit HC aus den neigbhors und Routen raus.

[Fixel2012]

Wenn das aus dem anderen Thread für den FHEM-Controller (noch) gilt:

Code Auswählen Erweitern

2017-02-11 14:51:07   ctrlCaps        OTHER MEMBER SUC

Ja, das ist immer noch gleich. Ich werde, wenn sich nichts bessert die von dir oben beschriebene Methode ausprobieren!

Danke euch viel Mals!

Gruß Fixel

EDIT: eine Frage noch, muss ich das neighborUpdate bei jedem Aktor ausführen?

[krikan]

EDIT: eine Frage noch, muss ich das neighborUpdate bei jedem Aktor ausführen?

Ja. In einem Rutsch für alle Geräte:

Code Auswählen Erweitern

set TYPE=ZWave:FILTER=ZWaveSubDevice=no neighborUpdate

[Fixel2012]

Werde es morgen ausprobieren, danke dir!!!

Gesendet von meinem ONEPLUS A3003 mit Tapatalk