Probleme bei "set <device> configRequestAll"

[krikan]

In ZWDongle_DoInit($) wird der timeout mMn auf 1 Sekunde festgelegt. Also gibt es einen Timer, so dass ausbleibende Bestätigungen vom Gerät an Controller nach einer Sekunde als Timeout in 0113xx01 enden sollten. Das, was bei mir auftritt darf doch dann nicht entstehen!?

Meine Gedanken:
Mein System hat einen Fehler.
Kann das Problem noch jemand reproduzieren?
Falls ja, dann:
Controller kommt bei der Vielzahl von Nachrichten durcheinander: Er kann wegen gleicher CallbackId die Antwort nicht der korrekten Nachricht zuordnen und verwirft etwas falsches automatisch.
Es gibt mehrfach einen 1 Sekunden-Timer im Modul; hier kommt es eventuell zu Überschneidungen und den Problemen.

Zur Not:
Dein Favorit, ohne Wiederholungen. Zufrieden bin ich damit aber nicht wirklich. Meiner Meinung nach haben wir dannnicht die Ursache gefunden, da es wegen des gesetzten Timeouts nicht vorkommen darf.

[rudolfkoenig]

In ZWDongle_DoInit($) wird der timeout mMn auf 1 Sekunde festgelegt.

Ja, aber der wartet nur auf dem ACK, und beruecksichtigt nicht den weiteren Werdegang eines Paketes.

Er kann wegen gleicher CallbackId die Antwort nicht der korrekten Nachricht zuordnen

Nice try , gilt aber nicht: seit der Einfuehrung der ZWave-SendStacks (nicht ZWDongle) gibt es jeweils nur eine ausstehende Nachricht von einem Geraet, und damit ist die GeraeteId als CallBackId nicht schlechter, als eine fortlaufende.

Es gibt mehrfach einen 1 Sekunden-Timer im Modul

Welchen meinst Du? Ich sehe nur eins im ZWDongle, und keins (was in diesem Fall aktiviert waere) in ZWave.

da es wegen des gesetzten Timeouts nicht vorkommen darf.

Das habe ich nicht verstanden, ich versuch morgen nochmal

[krikan]

Ja, aber der wartet nur auf dem ACK, und beruecksichtigt nicht den weiteren Werdegang eines Paketes.

Dann habe ich das Problem vielleicht nicht verstanden.
Durch ZWDongle_DoInit($) und Festlegen des timeout auf 1 Sekunde, sollte mMn die maximale Wartezeit des Dongle auf das ACK des Gerätes mit 001304xx festgelegt werden. Wenn die ACK (00130400) vom Gerät an Dongle ausbleibt, muss Dongle nach Timeout Fehler mit 00130401 an Fhem melden. Also dürfte doch nie der Zustand eintreten, dass die Antwort 001304xx (=callback) an Fhem fehlt? Darum befürchte ich Macke in meinem System, wenn das Problem nicht bei anderen reproduzierbar ist.

PS: In meiner letzten Antwort habe ich statt 0013xx01 mal wieder 01 verwendet. Evtl. hat das verwirrt.

Also gibt es einen Timer, so dass ausbleibende Bestätigungen vom Gerät an Controller nach einer Sekunde als Timeout in 0113xx01 enden sollten.

[rudolfkoenig]

Den timeout aus DoInit habe ich schon ganz vergessen. Ich habe nur im ZWave-Dokument INS11095 (such in google nach ZWave INS11095) Hinweise dazu gelesen (such nach FUNC_ID_SERIAL_API_SET_TIMEOUT), und da gehts um die Dongle <-> Host (d.h. FHEM) Kommunikation.
D.h. wenn wir (FHEM) nach 1s kein ACK (SW:06) geschickt haben, dann kriegen wir vom Dongle die Daten nochmal gesendet. Kannst mich aber gerne korrigieren. Apropos: CANs gibts erst ab SerialApi 4.0. Mein Goodway sagt was von 3.28, sendet aber trotzdem CANs. Wo war nochmal die Versionsmapping Tabelle? Und ich haette gerne irgendwo eine Doku der 011301/0013XXYY Telegramme, habe aber nix gefunden.

Bin noch der Ansicht, dass wir auch "kaputte" Dongles unterstuetzen sollten, auch wenn das wg. mehreren zusaetzlichen Timer etwas Performance kostet. Evtl. zunaechst nur per Attribut optional?

[krikan]

Ich habe nur im ZWave-Dokument INS11095 (such in google nach ZWave INS11095) Hinweise dazu gelesen (such nach FUNC_ID_SERIAL_API_SET_TIMEOUT), und da gehts um die Dongle <-> Host (d.h. FHEM) Kommunikation.
D.h. wenn wir (FHEM) nach 1s kein ACK (SW:06) geschickt haben, dann kriegen wir vom Dongle die Daten nochmal gesendet. Kannst mich aber gerne korrigieren.

Grundsätzlich für die 1. Stufe, d.h. 0113xx = Versand, verstehe ich es auch so, wenn das Dongle kein CAN unterstützt (Kann mir aber nicht vorstellen, dass es User mit so alten Dongles gibt). Dann muss auf Ebene der Software durch einen zusätzlichen Timer eine Überwachung stattfinden.
Aber bei ZW_SendData ist der Timer nach meinem Verständnis auch für die Überwachung der zusätzlichen Rückgbe aus der callbackFunc/completedFunc (0013[callbackId]xx) zuständig. Wenn innerhalb Timout kein ACK vom ZWave-Endgerät, dann TRANSMIT_COMPLETE_NO_ACK = 0013[callbackId]01 (siehe Erläuterung Normalerweise kommt immer die 0013[callbackId]01-Fehlermeldung, wenn man etwas an einen toten Node schickt. Wann sollte ohne Bestimmung der Überwachungszeit diese Meldung generiert werden. Die Ausführungen zu "state machine" interpretiere ich auch in diese Richtung.

ZWave-Dokument INS11095 (such in google nach ZWave INS11095)

btw: google liefert auch Treffer für das aktuellere INS10682-9 400

Mein Goodway sagt was von 3.28

Das ist SDK 5.03. Tabelle -> sdkids.xml z-way

Doku der 011301/0013XXYY Telegramme

beseres für 0013[callbackID][xx] als http://svn.linuxmce.org/trac/browser/trunk/src/ZWave/ZW_SerialAPI.h?rev=7415 kenne ich nicht.
Letztlich ist das bei 0113 und 0013 auch Schlußfolgerung aus Beobachtung und Erläuterung zu ZW_SendData in INS*

Bin noch der Ansicht, dass wir auch "kaputte" Dongles unterstuetzen sollten, auch wenn das wg. mehreren zusaetzlichen Timer etwas Performance kostet. Evtl. zunaechst nur per Attribut optional?

Grundsätzlich stimme ich auch hier zu. Aber ich habe Zweifel, ob mein Dongle wirklich kaputt ist und befürchte eher, dass unter Last irgendetwas noch anzupassen ist.

[krikan]

Wenn innerhalb Timout kein ACK vom ZWave-Endgerät, dann TRANSMIT_COMPLETE_NO_ACK = 0013[callbackId]01 (siehe Erläuterung

"siehe Erläuterungen zu (ZW_SendData, callbackFunc und TRANSMIT_COMPLETE_NO_ACK)"
sollte es weitergehen

[krikan]

Habe versucht mein Verständnis mit praktischen Tests mit verschiedenen Timeouts zu prüfen. Leider nicht gelungen. Die NO_ACK-Meldungen treten teilweise erst nach 8 Sekunden bei toten Nodes auf, obwohl Timeout niedriger liegt. Dann verstehe ich die Ausführungen zu TRANSMIT_COMPLETE_NO_ACK bzgl Timwouts in INS* überhaupt nicht mehr.....

[rudolfkoenig]

Habe jetzt eine Version mit ZWave timer (10s) eingecheckt.

Ich habe "dein" Problem auch mit meinem Goodway reproduzieren koennen: ich habe auch fuer 3 Geraete configRequestAll abgesetzt. Die angeforderten Daten sind zwar alle angekommen (zweimal sogar doppelt), aber einmal ist ein 0013XXYY verlorengegangen.

Ich habe das 3-mal wiederholt: 2x ging ein 0013 verloren, einmal war alles da. Wg. dem neuen Timer verklemmt sich das System aber nicht mehr.

[krikan]

Ich habe "dein" Problem auch mit meinem Goodway reproduzieren koennen: ich habe auch fuer 3 Geraete configRequestAll abgesetzt.

"Leicht" OffTopic: Dann hat der Goodway trotz SDK 5.03 keine Probleme mit der TRANSMIT_OPTION Explorer Frames. Hast Du eventuell auch schon einmal probiert, ob bei Nutzung von "set <ZWdongle> addNode nwOn" ein Inklusion durchläuft? Dann brächten wir evtl. die 2 addNode-Varianten nicht zwingend.

[rudolfkoenig]

Habs gerade probiert, ich merke keinen Unterschied, scheint zu funktionieren.

[krikan]

Habs gerade probiert, ich merke keinen Unterschied, scheint zu funktionieren.

Sollen dann überhaupt noch nwOn und on als separate addNode-Varianten erhalten bleiben?
Oder sollen wir netzwerkweite Inklusion nwOn als (umbenanntes) on zum Standard machen und Standardinklusion, low power-Inklusion, ... per Attribut einschaltbar machen?

[rudolfkoenig]

Attribut finde ich doof, lieber Argumente zu addNode, wie lowPower, direct. Wenn jemand bessere Namen hat, her damit.

[krikan]

lieber Argumente zu addNode, wie lowPower, direct.

Das finde ich zwar auch besser, habe aber noch ein Einbindungsproblem (Attribute kann ich schon ). Findest Du das überhaupt sinnvoll?
Bei "set <ZWDongle> addnode on sec" ist jetzt schon die Unschönheit, dass das nicht per Dropdown bzw. Eingabefeld auswählbar/ergänzbar ist, sondern man/ich alles eintippen muss.

[rudolfkoenig]

Stimmt. d.h. wir brauchen alle Varianten mit und ohne sec: on, onSec, direct, directSec, lowPower, lowPowerSec
Nicht ganz schick, aber auch nicht unmoeglich.

[krikan]

Stimmt. d.h. wir brauchen alle Varianten mit und ohne sec: on, onSec, direct, directSec, lowPower, lowPowerSec
Nicht ganz schick, aber auch nicht unmoeglich.

Wegen "schick" wollte ich eigentlich nwOn rausnehmen und nur noch on haben. Die Ergänzung (sec, direct) hätte ich dann lieber in zusätzlichem Auswahlfeld/Testbox. Das bedeutet aber vermutlich einen größeren Umbau, der in keinem Verhältnis zum Nutzen steht!? Also doch unschick. Dann schiebe ich das in meiner Dringlichkeit nach hinten und versuche xFailedNode-Befehle besser einzubinden.