WakeUp, Scheduled Tasks Probleme

[hanske]

Hallo,

ich habe hier immer wieder Probleme mit den batteriebetrieben ZWave Komponenten.
Das Absetzten von "set" und "get" Befehlen, die eigentlich beim nächsten Wakeup erfolgen sollen funktioniert sehr unzuverlässig.
Manche Komponenten liefern gar kein WakeUp Event (oder FHEM zeigt es nicht an) obwohl sie die Konfiguration mit "wakeupReport interval 65000 target 1" bestätigt haben.
Manchmal werden die zurückgestellten "set" und "get" ausgeführt, wenn das Gerät ein anderes Event schickt, ohne das dabei explizit ein wakeUp Event im Log auftaucht.
Gibt es eine Möglichkeit die zurückgestellten Befehle einzusehen, um das ganze zu debuggen?
Ich dachte, dass der "SendStack" vom Dongle dafür zuständig ist. Der bleibt aber nach dem Absetzten von scheduled Befehlen leer.
Kann man eventuell mit anderen Tools tiefer in den Dongle sehen?

Danke

[rudolfkoenig]

mWn sollten alle "Klassen-Befehle" (set/get), die an einem Geraet mit der Klasse WAKE_UP gesendet werden, erst in der internen WakeUp Liste des Geraetes landen. Bei einem ZW_APPLICATION_UPDATE Nachricht oder sonstigen Antwort von diesem Geraet werden die Befehle aus der Liste der Reihe nach gesendet.

Mir ist eine im Dongle gehaltener Befehlspuffer nicht bekannt, und was gesendet/empfangen wird, sieht man, wenn man verbose der ZWDongle auf 5 dreht.

FHEM kennt bisher nur relativ wenige Dongle-Befehle (siehe die Liste in 00_ZWDongle.pm, nicht zu verwechseln mit den ZWave Klassen aus 10_ZWave.pm), diese werden aber bisher nicht sehr vermisst.

[hanske]

Hallo,

heißt das, die gespeicherten Befehle werden bei jedem Event eines Gerätes versendet, also auch bei Reports?
Vielleicht reagiert dann das Gerät nicht darauf, dass wäre eine Begründung warum so viele verloren gehen.
Ich habe jetzt auch mit list <device> die WakeUp Liste gefunden. Der Befehl ist da schon zu einer 14 stelligen Zahl kodiert!?
Wenn die Liste irgendwann leer ist, sollte das Gerät doch auch die Daten empfangen haben, oder sind sie einfach in "blaue" verschickt worden?
Ich überprüfe das mal mit verbose 5 auf den Dongle.

Mein Bedarf an den Dongle wäre die interne Nodeliste.
Ich musste meinen Fibaro drei mal in- und exkludieren bevor er halbwegs lief. Der Dongle hat dann die NodeId immer weiter hochgezählt.
Ich hätte erwartet, dass die Ids neu vergeben werden und möchte nun nachsehen, ob wirklich alle alten Instanzen exkludiert worden sind.

[rudolfkoenig]

get zwdongle nodeList

[hanske]

Bei "get nodelist" fehlen dann die exkludierten NodeIDs. Damit sind sie dann wohl hoffentlich im Dongle auch exkludiert.
Ich hatte mich nur gewundert, dass die IDs nicht neu vergeben werden.

Zu meinem WakeUp Problem:

Ich hatte zwei "get config xx" Anfragen angefordert, in der WakeUp Liste vom Device waren dann auch zwei 14 stellige Befehle eingetragen.
Das Device hat dann einen Helligkeitsreport geschickt, danach war nur noch ein Befehl in der Liste aber eine Antwort auf "get config xx" blieb aus.

Hier das Log zum Zeitpunkt des Helligkeitsreport: 

Code Auswählen Erweitern

2014.10.16 16:19:01 5: ZWDongle/RAW: /010c0004000a063105030a0013d5
2014.10.16 16:19:01 5: SW: 06
2014.10.16 16:19:01 5: ZWDongle_Read ZWDongle_0: 0004000a063105030a0013
2014.10.16 16:19:01 5: ZWDongle_0 dispatch 0004000a063105030a0013
2014.10.16 16:19:01 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0a ARG:063105030a0013
2014.10.16 16:19:01 5: SW: 010900130a037005140588
2014.10.16 16:19:01 5: ZWDongle/RAW: /060104011301e8
2014.10.16 16:19:01 5: SW: 06
2014.10.16 16:19:01 5: ZWDongle_Read ZWDongle_0: 011301
2014.10.16 16:19:01 5: ZWDongle_0 dispatch 011301

Ist das so in Ordnung?

[rudolfkoenig]

aber eine Antwort auf "get config xx" blieb aus.

Das ist schlecht. Ich habe lange experimentiert, bis ich mit meinem Batterie-Testgeraet (EZMotion 3-in-1) einigermassen kommunizieren konnte. Da habe ich regelmaessig Helligkeit und temperatur abgefragt, und das ging zum Schluss. Vlt. muss man noch weiter experimentieren, wann FHEM die gepufferten Befehle senden soll. Es geht darum, dass ich nicht genau weiss, wer das "011301" sendet (Geraet oder Dongle, soll ein Ack sein), und ob FHEM darauf die weiteren Befehle schicken kann, oder erst warten soll oder was.

Die Helligkeit scheint bei dir aber angekommen zu sein, siehe ARG, bzw. die SENSOR_MULTILEVEL Zeile in 10_ZWave.pm:

Code Auswählen Erweitern

fhem> { ZWave_ParseMultilevel("03", "0a", "0013") }
luminance:19 Lux


[hanske]

ja die Helligkeit kam an, aber die wakeUp Nachrichten gingen verloren.
Bei vielen Geräten scheint es ja zu klappen, bei jedem Event die gesammelten Anforderungen gleich mit abzusetzen.
Der Fibaro scheint aber kurz angebunden zu sein und schläft dann gleich wieder.
Eine Zeit lang ging es, als ich temp und lumi reports gleichzeitig bekam, da kam dann auch der ein oder andere scheduled Event mit durch.
Ist aber generell zu unsicher.
Sollten nicht ZWave Nachrichten immer bestätigt werden? Der Dongle meldet doch auch manchmal, wenn er z.B. ein ausgeschaltetes Gerät nicht erreichen kann. Müsste man das nicht bei den fehlgeschlagenen wakeUp Nachrichten auch bekommen?
Wo ist das eigentlich implementiert?

[krikan]

Beim Philio PSM02 kann ich fehlende Antworten von gepufferten Abfragen (wakeup-List) bestätigen:
Gepufferte Befehle werden nur beantwortet, wenn zwischen Abfrage (Anlage wakeup-List) und wakeup notification kein Telegramm für Türöffnung kommt.
Falls Türöffnungstelegramm kommt, werden die gepufferten Abfragen verschickt, aber es kommt nie eine Antwort.

[rudolfkoenig]

Wie geschrieben: wann genau FHEM die naechsten Befehle an WAKE_UP Geraete schicken soll, weiss ich nicht.
Das eigentliche Implementieren ist nicht mein/das Problem, sondern zu wissen, wie es genau gehoert.

Implementiert ist es in 10_ZWave.pm, suche nach WakeUp im Zusammenhang mit IOWrite.

[krikan]

Aus diversen Diskussionen auf http://groups.google.com/group/openzwave und den Kommentierungen in https://code.google.com/p/open-zwave/source/browse/trunk/cpp/src/Node.cpp ergibt sich für mich:

• WAKE_UP Geräte akzeptieren und verarbeiten Befehle nur korrekt, wenn der Befehl direkt auf die Wakeup notification oder nach Erhalt des NIF verschickt wird. Geräte sollten dann ca. 2,5-10 Sek wach sein.
• Werden Befehle bei anderen Nachrichten (bspw. Erhalt BASIC Commands) an das WAKE_UP Gerät verschickt, ist eine korrekte Verarbeitung der Befehle durch das Gerät nicht sichergestellt. Standardmäßig sollte wohl nichts verarbeitet werden, da das Gerät nicht "wach" genug ist. Jedoch soll es Geräte geben, die trotzdem Befehle (teilweise) verarbeiten.

Dies würde sich mit meinen Beobachtungen zum PSM02 decken (siehe meinen vorherigen Beitrag) und evtl. auch bei Hanske Sinn geben.

Besonderer Behandlung bedürfen batteriebetriebene FLIRS (frequently listening routing slave) Geräte. Hierzu zählt bspw. https://code.google.com/p/open-zwave/source/browse/trunk/config/aeon_labs/hem.xml. Diese warten alle 1-1,5 Sek auf einen "beam". Näher beschrieben unter anderem hier http://library.ademconet.com/MWT/fs2/VAM/Introductory-Guide-to-Z-Wave-Technology.PDF. Die Jungs von openzwave haben dieses Thema im Release 1.2 von vor 2 Tagen als wichtigen Änderungspunkt dokumentiert https://groups.google.com/forum/#!topic/openzwave/Hcr3mFlQCaI. Mir sind die Informationen zu FLIRS und beam leider zu technisch; aber vielleicht kann jemand mehr damit anfangen.

Allgemeines zur Unterscheidung Empfangsbereitschaft: http://docs.smartthings.com/en/latest/device-type-developers-guide/building-z-wave-device-types/z-wave-primer.html#listening-and-sleepy-devices


edit: Laut http://handbuch.zwave.de/ ist HEM doch kein FLIRS-Gerät, darum oben gestrichen.

[hanske]

Hallo,

mir wäre es recht, wenn nur bei wakeUp Events und NIF, bzw. ZW_APPLICATION_UPDATE (ist das eigentlich das gleiche?) die gespeicherten Nachrichten abgesetzt werden.
Ich habe jetzt auch alle meine batteriebetriebenen Geräte dazu gebracht, sich per WakeUp Notification zu melden.
Ich denke, abgesehen von FLIRS, ist dies die einzige sichere Methode keine Nachrichten zu verlieren.
Meine Perl Kenntnisse sind leider so gut wie nicht vorhanden.
Ich habe aber in der 10_ZWave.pm ab Zeile 990 folgendes gefunden:

Code Auswählen Erweitern

     my $className = $zwave_id2class{lc($class)} ?
                  $zwave_id2class{lc($class)} : "UNKNOWN_".uc($class);
    if($className eq "MULTI_CMD") {
   .
   .
   .
  my $wu = $baseHash->{WakeUp};
  if($wu && @{$wu}) {
    shift @{$wu} if($wu->[0] eq "");
    IOWrite($hash, "00", shift @{$wu}) if(@{$wu});
  }

Man müsste das vielleicht in etwa so verändern:

Code Auswählen Erweitern

     my $className = $zwave_id2class{lc($class)} ?
                  $zwave_id2class{lc($class)} : "UNKNOWN_".uc($class);
    .
    .
    .
    if($className eq "WAKE_UP") {
       my $wu = $baseHash->{WakeUp};
       if($wu && @{$wu}) {
         shift @{$wu} if($wu->[0] eq "");
         IOWrite($hash, "00", shift @{$wu}) if(@{$wu});
     }


Besser wäre noch man würde auch noch abfangen, ob es sich um ein "wakeup:notification" und nicht um ein "wakeupReport:interval" handelt.
Wenn das jemand abnickt oder einchecked würde ich es auch testen.

[krikan]

Es geht darum, dass ich nicht genau weiss, wer das "011301" sendet (Geraet oder Dongle, soll ein Ack sein),...

Aus Funkverkehr des PSM02 und Lesen von openzwave-Infos aus Sicht eines NICHT-Programmiers interpretiere ich:

Gescheiterte Abfrage (bei Bewegungserkennung):

Code Auswählen Erweitern

2014.10.21 20:19:35 5: SW: 01080013030284050561
2014.10.21 20:19:35 5: ZWDongle/RAW: /060104011301e8
2014.10.21 20:19:35 5: SW: 06
2014.10.21 20:19:35 5: ZWDongle_Read ZWDongle_0: 011301
2014.10.21 20:19:35 5: ZWDongle_0 dispatch 011301
2014.10.21 20:19:35 5: ZWDongle/RAW: /010500132601ce
2014.10.21 20:19:35 5: SW: 06
2014.10.21 20:19:35 5: ZWDongle_Read ZWDongle_0: 00132601
2014.10.21 20:19:35 5: ZWDongle_0 dispatch 00132601
2014.10.21 20:19:35 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:
2014.10.21 20:19:35 2: ZWDongle_0 ERROR: SEND_DATA returned 01

011301 -> Controller hat die Abfrage erfolgreich verschickt
01 = Request
13 = ZW_SEND_DATA Kennzeichen
01 = ??

00132601 -> Controller hat auf Abfrage kein ACK vom Gerät erhalten
00 = Response
13 = ZW_SEND_DATA Kennzichen
26 = ??
01 = TRANSMIT_COMPLETE_NO_ACK

laut https://code.google.com/p/open-zwave/source/browse/trunk/cpp/src/Defs.h / Driver.cpp mögliche Werte der letzten beiden Stellen:
TRANSMIT_COMPLETE_OK     0x00
TRANSMIT_COMPLETE_NO_ACK 0x01
TRANSMIT_COMPLETE_FAIL   0x02
TRANSMIT_COMPLETE_NOT_IDLE    0x03
TRANSMIT_COMPLETE_NOROUTE     0x04

Erfolgreiche Abfrage (bei wakeup):

Code Auswählen Erweitern

2014.10.21 22:47:57 5: SW: 06
2014.10.21 22:47:57 5: ZWDongle_Read ZWDongle_0: 011301
2014.10.21 22:47:57 5: ZWDongle_0 dispatch 011301
2014.10.21 22:47:57 5: ZWDongle/RAW: /010500132600cf
2014.10.21 22:47:57 5: SW: 06
2014.10.21 22:47:57 5: ZWDongle_Read ZWDongle_0: 00132600
2014.10.21 22:47:57 5: ZWDongle_0 dispatch 00132600
2014.10.21 22:47:57 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:

011301 -> Controller hat die Abfrage erfolgreich verschickt
01 = Request
13 = ZW_SEND_DATA Kennzeichen
01 = ??

00132600 -> Controller hat auf Abfrage vom Gerät ACK erhalten
00 = Response
13 = ZW_SEND_DATA Kennzeichen
26 = ??
00 = TRANSMIT_COMPLETE_OK

------------
Bei einer gescheiterten Abfrage bei einem WAKE_UP-Gerät, das nicht frequentListening ist, sollte die Abfrage evtl. wiederholt werden, damit es nicht zum Verlust der Abfragen kommt. Das erzeugt aber unter Umständen erhebliche unnötige Funklast. Der Weg nur bei "wakeup notification" Befehle zu schicken ist Funklastmäßig sicherlich besser: jedoch habe ich bei meinem einzigen Testgerät festgestellt, dass das Event bei anstehenden Abfragen nicht geniert wird. Hier analysiere ich aber noch.

Die Info, ob ein Geräte frequentListung ist, kann man gem. openzwave bekommen indem 00_ZWDongle.pm (Zeile 342f.) bei get <device> nodeInfo ergänzt wird um

Code Auswählen Erweitern

push @list, "frequentListening:" . ($r[3] & ( 0x20 | 0x40 ));
push @list, "beaming:" . ($r[3] & 0x10);

Wenn "frequentListening" ungleich 0, dann sollte es ein frequentListening-Gerät sein. Meine Geräte (PSM02 und Aktor FGRM222) werden mit 0 erkannt.
Wenn "beaming" ungleich 0, sollte es nach meinem Verständnis eine beaming-Gerät (FLIRS) sein. Meine Geräte haben beide einen Wert von 16 -> Also beaming, verstehe ich nicht. Diesen Wert spuckt aber auch das openzwave-control-panel aus.

Ich habe zu wenig ZWave-Geräte um erfolgreich testen zu können. Wäre also für Gegenchecks dankbar. Zudem sind Ideen willkommen.
Und mir fehlen die Programmierkenntnisse, um Ideen einzubinden .

[hanske]

Hallo,

ich habe meine kleine Änderung jetzt mal zwei Tage getestet.
Die gute Nachricht, es gehen keine gespeicherten Befehle mehr verloren.
Die schlechte ist, dass der Befehlsstapel bei einigen Geräten nicht komplett abgearbeitet wird und Befehle im Stapel zurückbleiben.
Am Ende des Stapels müsste auch noch ein "wakeupNoMoreInformation" an das Gerät geschickt werden, um es wieder zum sofortigen Einschlafen zu zwingen. Das würde bei Geräten mit langer WakeUp Zeit sicher die Batterielebensdauer erhöhen.
Das "wakeupNoMoreInformation" sollte auch geschickt werden, wenn keine Nachrichten im Stapel sind.
Programmieren kann ich das leider (noch) nicht.

Anbei mein kleiner Patch zur aktuellen Version.
Vielleicht guckt sich das mal jemand an.

Danke

[hanske]

@krikan

bisher habe ich jedes meiner batteriebetriebenen Geräte dazu gebracht ein "wakeup notification" zu senden.
Die kommen natürlich nur im vorgegebenem Zeitintervall. Wenn man einen Befehl absetzt muss man halt entsprechend  lange warten bis er verarbeitet wird.
FLIRS ist noch ein anderes Thema und wird von den meisten Geräten nicht unterstützt.
Ich denke zunächst sollte die Behandlung der "wakeup notification" richtig implementiert sein.
Bekommst Du denn überhaupt regelmäßig eine "wakeup notification"?

[krikan]

@hanske
Ja, "wakeup notification" ist eingeschaltet und kommt mit nachfolgder Ausnahme regelmäßig. Das ist nicht mein Problem.
Bei anstehenden Abfragen wird die Abfrage zum Zeitpunkt der "wakep notification" korrekt verschickt und beantwortet. Nur das Event "wakeup notification" taucht tlw. dann vorher nicht auf. Das begreife ich noch nicht und suche meinen (Gedanken-)Fehler.
FLIRS-Device habe ich keins gefunden -> darum finde ich die auch relativ uninteressant
frequentListening könnte aber Thema bei Geräten mit "kaputter"  ZWave-Klasse "WAKE_UP" sein.
"wakeupNoMoreInformation" ist sicherlich sinnvoll.

Armer Rudi, zwei Leute mit kaum Progammier-Ahnung.

[hanske]

@krikan
Ich habe ja den PSP01, der müsste Deinem PSM02 ziemlich ähnlich sein.
Der schickt zuverlässig die  "wakeup notification". Hatte bei einem anderen Sensor auch schon Ausfälle gesehen.
Ich kann ja mal Deine beiden Zeilen:

Code Auswählen Erweitern

push @list, "frequentListening:" . ($r[3] & ( 0x20 | 0x40 ));
push @list, "beaming:" . ($r[3] & 0x10);
einfügen und Dir dann berichten.
Programmieren kann ich schon, aber mit Perl kenne ich mich gar nicht aus.

[krikan]

@hanske

Der schickt zuverlässig die  "wakeup notification". Hatte bei einem anderen Sensor auch schon Ausfälle gesehen.

Drücke mich wahrscheinlich unverständlich aus:  "wakeup notification" kommt regelmäßig solange keine ausstehenden Befehle im Sendstack. Wenn Befehle im sendstack, dann wurden die genau zum Zeitpunkt der üblichen "wakeup notification" verschickt und verarbeitet, das Event "wakeup notification" kam aber dann nicht. Das begreife ich nicht. Ich glaube eher nicht an Ausfälle, als an eigene Dummheit. Muss noch mal weiterprobieren.

Bei meinen beiden Code-Zeilen würde mich interessieren, was Deine Geräte ausspucken. Ob wir das aber letztlich brauchen, weiß ich leider nicht.

Programmieren kann ich schon, aber ...

War keinesfalls böse gemeint, bevor hier Mißverständnisse aufkommen  . Perl kann ja noch werden!

Gruß, Christian

[krikan]

eigene Dummheit

genau so ist es (ungenügende Versuchsreihe bzw. zu viel gleichzeitig verändert):
Die Auto battery reports des Sensors wurden zum Zeitpunkt der "wakeup notification" ebenfalls verschickt. Diese battery reports führen beim PSM02 dazu, dass die "wakeup notification" ausbleibt und er wach ist. Zudem führen battery reports dazu, dass die Startzeit für die nächste "wakeup notification" neu gesetzt wird.
Damit hat meine Theorie bezüglich Wachzustand gewisse Brüche. Oder ist ein battery report nichts anderes als eine "wakeup notification"? Dazu brächte man Vergleichsensoren.

Das ändert aber nichts an meinen Ausführungen zu den ACK von oben.

[hanske]

Ich habe alle meine Geräte mit Deinem Patch getestet.
Genau wie bei Dir:

Code Auswählen Erweitern

frequentListening:0 beaming:16
Kann also irgendwas nicht stimmen.

Zu Deiner anderen Frage:
Bei meinem PSP01 kommen "wakeup notification" und "battery" Meldungen asynchron, kann aber sein, dass es bei Deinem Gerät anders implementiert ist.
Den Battery Report kann man bei mir auch getrennt einstellen über:

Code Auswählen Erweitern

Auto Report Battery Time (Parameter Number 10, Parameter Size 1) interval time for auto report the battery level
1 — 127 30 minutes per tick and minimum time is 30 minutes, default tick is 12 (6 hours) (Default 12)

Wahrscheinlich muss bei der Stapelverarbeitung wirklich erst mal der "arme Rudi" ran.
Bis ich Perl kann sind wahrscheinlich schon etliche Neunutzer verzweifelt.
Bei mir ist ja erst mal alles konfiguriert 

[krikan]

Kann also irgendwas nicht stimmen.

Bin ich nicht sicher. Vermutlich geben die Werte für frequentListung und beaming nur in Kombination mit den anderen nodeInfo-Werten einen Sinn. Warum würde sonst das openzwav-control-panel bei mir zu den gleichen Werten kommen? Die Entwickler von openzwave werden sich doch was dabei gedacht haben.

Bei meinem PSP01 kommen "wakeup notification" und "battery" Meldungen asynchron, kann aber sein, dass es bei Deinem Gerät anders implementiert ist.
Den Battery Report kann man bei mir auch getrennt einstellen über

Kann man bei meinem auch und genau die Spielerei daran, hat zu meinem Irrtum geführt. Nach Reset auf Default kam die Erkenntnis.

Wir haben jetzt immerhin ein paar Erkenntnisse und kennen die Abhilfe/Lösung. Ob das geändert werden sollte oder nicht, kann ich nicht wirklich beurteilen, da ich die möglichen negativen Nebeneffekte und Probleme nicht kenne. Von Rudis Zeit/Spaß ganz zu schweigen.....

----
Im übrigen habe ich gerade einmal 20 get configs im sendstack gleichzeitig bei der "wakeup notification" abarbeiten lassen. Das läuft mit Rückantworten ohne Probleme durch. Während schon ein get config im sendstack bei Türöffnungstelegrammen zu dauernden CAN-Fehlern führt. Keine Ahnung, ob das evtl. bei Rudis zweiten Teil der Frage 

wer das "011301" sendet (Geraet oder Dongle, soll ein Ack sein), und ob FHEM darauf die weiteren Befehle schicken kann, oder erst warten soll oder was.

beiträgt. Demnach tendiere ich zu sofort. Mir ist unbekannt, wie ich das durch Test absichern könnte.

[rudolfkoenig]

Ich habe leider im Moment nicht die Zeit fuer laengere FHEM-Experimentier-Sessions. Ich beobachte aber diese Diskussion und kann gerne patches ueberfliegen/testen/einchecken, am besten bitte direkt als solches markieren. Und habt von perl keine Angst, es kann doch nichts schiefgehen (wenn man vorher eine Sicherung gemacht hat :)

"Sofort" (was auch immer das meint) schicken funktioniert nicht, habs frueher getestet.
Ich behaupte, mehr als ein Befehl auszusenden ohne auf irgendein Ack zu warten klappt nicht.

Testen kannst Du deine Theorie aber trotzdem, indem du

Code Auswählen Erweitern

    if($hash && $hash->{WakeUp} && @{$hash->{WakeUp}}) {
      IOWrite($hash, "00", shift @{$hash->{WakeUp}});
    }
in 10_ZWave.pm/ZWave_Parse() dahin platzierst, wo es deiner Ansicht nach sinnvoll ist.
Und wo sinnvoll ist, kann man schrittweise mit zusaetzlichen Zeilen wie

Code Auswählen Erweitern

Log 1, "Debug line ".__LINE__;
eingrenzen. Mit der Zeit muss man nicht mehr die Nachrichten abwarten, und schauen, welche "Debug line" Zeilen erscheinen, weil man zunehmend den Code versteht.

[hanske]

Wenn ich den Code von 10_zwave.pm richtig verstehe, macht es doch nur in der "while(@args)" Schleife von Zeile 985ff Sinn.
Nur dort habe ich doch den "Classname" zur Abfrage Verfügung.
Mein Patch

Code Auswählen Erweitern

# send stored requests
if($className eq "WAKE_UP") {
  my $wu = $baseHash->{WakeUp};
  if($wu && @{$wu}) {
shift @{$wu} if($wu->[0] eq "");
IOWrite($hash, "00", shift @{$wu}) if(@{$wu});
  }
  # todo send a final wakeupNoMoreInformation
}
hat ja leider nicht vollständig funktioniert. Es sind immer wieder Nachrichten im Stack geblieben.
Dabei hatte ich das ja eigentlich nur von ein paar Zeilen weiter unten nach oben verschoben. Vorher wurde ja immer der ganze Stack verschickt (nur leider zum falschen Zeitpunkt)
Meinst Du Dein Code:

Code Auswählen Erweitern

if($hash && $hash->{WakeUp} && @{$hash->{WakeUp}}) {
      IOWrite($hash, "00", shift @{$hash->{WakeUp}});
    }
bringt an dieser Stelle eine Verbesserung?

Erstmal soll ja nur der ganze Befehlsspeicher abgeschickt werden.
Um ein Acknowledge und das finale "wakeupNoMoreInformation" kann man sich (ich mich) dann ja später kümmern

[hanske]

Ich habe mir gerade mal die Perl Syntax etwas angesehen.
Dein Code:

Code Auswählen Erweitern

if($hash && $hash->{WakeUp} && @{$hash->{WakeUp}}) {
      IOWrite($hash, "00", shift @{$hash->{WakeUp}});
    }
schreibt doch nur einen gespeicherten Befehl raus, oder?
Das war wahrscheinlich mein Problem.

Kann ich stattdessen

Code Auswählen Erweitern


if ($hash){
   foreach (@{$hash->{WakeUp}}) {
      IOWrite($hash, "00",$_);
}
}

schreiben?

[hanske]

Ich habe jetzt eine Lösung die gut funktioniert.
Ist zwar nicht besonders elegant programmiert, für mich aber einfacher verständlich.
Ich werde das aber noch weiter testen.

Code Auswählen Erweitern


# send stored requests
if($className eq "WAKE_UP") {
  if ($hash){
foreach (@{$hash->{WakeUp}}) {
IOWrite($hash, "00",$_);
Log3 $hash, 4, "Sending stored command: $_";
}
@{$hash->{WakeUp}}=();
    #send a final wakeupNoMoreInformation
my $nodeId = $hash->{id};
IOWrite($hash, "00", "13${nodeId}02840805");
Log3 $hash, 4, "Sending wakeupNoMoreInformation to node: $nodeId";
  }
}

[krikan]

@hanske
Wo müsste Dein Code genau hin (Zeile), damit ich am Wochenende mittesten und grübeln kann?

@Rudi
Danke für Deinen Analysetipp, probiere ich mal aus.

[hanske]

Ab Zeile 1000:

Code Auswählen Erweitern


      push @args, substr($arg, $off*2, $l*2);
         $off += $l;
       }
       next;
    }

# HIER NEUER CODE

    my $ptr = ZWave_getHash($hash, $className, "parse");
    if(!$ptr) {


Ich wollte auch noch eine Patchdatei erstellen , aber mein GIT funktioniert gerade nicht.

[hanske]

Die alte Implementierung muss dann natürlich auch noch raus.
Anbei das Patchfile .

[krikan]

Habe den Patch mal kurz getestet, da meine Zeit am Wochenende begrenzt sein wird.
Grundsätzlich läuft es ohne direkt erkennbare Probleme. 

Bei Abfrage WakeupIntervall, wird der "wakeupNoMoreInformation" mehrmals verschickt (vgl. anliegendes Log), da ja auf WAKE_UP-Klasse geparst wird. Negative Auswirkungen auf die Abarbeitung der Befehle kann ich aber interessanterweise nicht erkennen. Hätte erwartet, dass nach Versand "wakeupNoMoreInformation" die nachfolgenden Befehle ins Leere laufen (NCK). Dem ist aber selbst bei vielen gleichzeitigen Abfragen wie im anliegenden Log bei mir nicht so. Ob "wakeupNoMoreInformation" überhaupt zum Sensor-"Schlaf" führt, habe ich noch nicht kontrolliert.

Gibt es eigentlich eine Zeitbegrenzung, ab der keine Befehle mehr verschickt werden, oder wird (vermute ich) bei Deiner Änderung einfach immer der vollständige Sendstack verschickt?

[hanske]

Hallo,

bei mir läuft es auch gut. Der ganze Stack wird nun regelmäßig und zuverlässig versendet.

Die beiden TODOs sind tatsächlich noch das Selektieren zwischen "wakeup notification" und "wakeup intervall" Rückmeldung.
Letztere kommt allerdings auch nur wenn man danach fragt.
Das andere TODO wäre die Abfrage, ob die Befehle auch angekommen sind, da hattest Du ja schon mal was zu geschrieben.
Das scheint aber ein grundsätzliches Problem zu sein. Ich habe einen Schalter, der manchmal nicht erreichbar ist und FHEM schickt ihm brav Befehle die nicht ankommen ohne dazu einen Fehler zu loggen.
Zeitbegrenzung ist nicht implementiert, normalerweise bleiben die Geräte ein paar Sekunden wach und sollten in dieser Zeit auch schon einige Befehle entgegen nehmen können. Sind ja immer nur ein paar Bytes. Du selbst hattest ja schon 20 Befehle in einem Rutsch absetzen können.

Vielleicht kann der Herr König (um nicht schon wieder "der arme Rudi" schreiben zu müssen ) meinen PATCH ja mal einarbeiten.
Kann gerne auch noch verschönert werden z.B. mit "while" und "shift".
Ich lass das mal hier so weiterlaufen und schau immer mal in die Logs.

schönen Abend noch...

[krikan]

Mich irritiert gerade folgender Beitrag:
http://forum.fhem.de/index.php/topic,20884.msg144227.html#msg144227
Demnach gibt es wohl noch mehr Geräte, die nicht nur bei "wakeup notification" Befehle verarbeiten. Schafft man bie diesen Geräten Probleme mit dem Patch?
Wobei der sichere Weg wohl nur Versand bei "wakeup notification" in Kombination mit Kontrolle der Rückmeldung des Gerätes ist.

Ich habe einen Schalter, der manchmal nicht erreichbar ist und FHEM schickt ihm brav Befehle die nicht ankommen ohne dazu einen Fehler zu loggen.

Gar keine Rückmeldung? Noch nicht einmal mt verbose 5? Zumindest ein NO_ACK oder ähnliches solltest Du haben. Oder ist für Dich das Log im Fehlerfall nicht deutlich genug?

Ich hatte eben mal angefangen umzusetzen, dass nur auf eine "wakeup notification" die gesammelten Befehle verschickt werden. Mein Gedanke ist, dies durch einfügen einer zusätzlichen Bedingung für das"wakeup notification"-Telegramm in Zeile 1020 zu lösen:
if($arg =~ m/028407/ && $wu && @{$wu}) 
Habe ich aber noch nicht zu Ende gedacht/probiert.

Rudi wird schon mitlesen und passend eingreifen, ruhig an.

[hanske]

Gar keine Rückmeldung? Noch nicht einmal mt verbose 5? Zumindest ein NO_ACK oder ähnliches solltest Du haben. Oder ist für Dich das Log im Fehlerfall nicht deutlich genug?

Ich habe nur Verbose 3 eingestellt, da kommt dann im Log "ZWave set sw_wall on" und das Icon an der Oberfläche wird auf "on" gesetzt. Weitere Meldungen werden nicht raus geschrieben. Wenn ich den Status des Schalters abfrage wird mir "off" zurückgeliefert.

Deinen Codevorschlag kann ich auf Grund meiner geringen Perl Kenntnisse nicht kommentieren.
Mir reicht der aktuelle Stand aus, es ist bis jetzt nichts mehr verloren gegangen.
Wenn er bei Dir auch eine Verbesserung bringt, kann man ihn ja erst mal einpflegen.

Grüße

[krikan]

Verbose 3 eingestellt, da kommt dann im Log "ZWave set sw_wall on" und das Icon an der Oberfläche wird auf "on" gesetzt

Könntest Du das nicht mal testhalber hochschrauben. Eigentlich müsste nach meiner Meinung soetwas in der Art auftauchen:

Code Auswählen Erweitern

2014.10.21 20:19:35 5: ZWDongle_0 dispatch 00132601
2014.10.21 20:19:35 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:
2014.10.21 20:19:35 2: ZWDongle_0 ERROR: SEND_DATA returned 01
Wenn nicht, sind meine Gedankengänge zur Empfangsbestätigung durch die Geräte per ACK hinfällig, was ich eigentlich nicht glauben kann.

Deinen Codevorschlag kann ich auf Grund meiner geringen Perl Kenntnisse nicht kommentieren.
Mir reicht der aktuelle Stand aus, es ist bis jetzt nichts mehr verloren gegangen.
Wenn er bei Dir auch eine Verbesserung bringt, kann man ihn ja erst mal einpflegen.

Ich selbst habe es noch nicht zu Ende gedacht/probiert; ist also unvollendet. Wollte Deine Schleife noch mal dort hineinschieben und meine Try-And-Error-Übungen fortsetzen. Mir fehlen nicht nur Perl-Kenntnisse, sondern auch der Programmiererdurchblick .

[rudolfkoenig]

@hanske: habe deine Zeilen angeschaut, hier meine Bemerkungen:
- die Stelle um Zeile 1000 analysiert eingetroffene Pakete. Bei einem mit MULTI_CMD verpackten Nachricht koennen auch mehrere sein, deswegen die Schleife.
- dein Code reagiert, falls irgendeine eine Nachricht der Klasse WAKE_UP eintrifft. Kann nicht beurteilen, ob das sinnvoll ist.
- die Abfrage if($hash) ist ueberflussig, falls kein $hash gefunden wurde, wird diese Zeile nicht erreicht (siehe Zeile 973). Stattdessen wuerde ich $hash->{WakeUp} pruefen, da dieser Hash nicht immer angelegt ist.
- dass man mehrere Befehle direkt hintereinander absenden kann, verwundert mich immer noch, aber wenn eure Tests bestaetigen, dass es klappt, dann ist es wohl so.

@krikan: du pruefst mit 028407 explizit auf WAKEUP (84) notification(07), ist mir prinzipiell sympatischer, weiss aber nicht ob es tut.

Wenn es fertig zum Einchecken ist (habe noch nicht dein Eindruck anhand der Meldungen hier), bitte Bescheid geben.

[krikan]

Habe den Code von hanske mit der von mir vorgeschlagenen Prüfung nur auf die "wakeup notification" einmal umgesetzt. Den Patch habe ich angehängt. Er enthält auch noch detaillierteres Logging bei fehlgeschlagenen Empfang der Geräterücktelegramme. Funktionsprobleme konnte ich bisher keine feststellen. Er müsste aber von anderen noch mal gegengetest und überprüft werden.

man mehrere Befehle direkt hintereinander absenden kann, verwundert mich immer noch, aber wenn eure Tests bestaetigen, dass es klappt, dann ist es wohl so.

Läuft ohne erkennbare Probleme. Selbst das Log sieht für mich im Vergleich zum Einzelversand gleich aus. Mir wäre aber ein Einzelversand mit Warten auf das Rücktelegramm lieber. Würde dann gerne das Rücktelegramm auf ACK und NACK testen. Wenn kein ACK, dann sollte der fehlgeschlagene Befehl im sendstack verbleiben und keine weiteren Befehle verschickt werden. Erst bei der nächsten "wakeup notification" sollte erneut verschickt werden. Das ganze vielleicht maximal 3 mal, bevor man es endgültig verwirft/aufgibt. (Zukunftsvision!)

[krikan]

Die Änderung des obigen Patches läuft bei mir nach diversen Tests ohne erkennbare Probleme.

Folgende Punkte verstehe ich im 10_ZWave.pm-Code nicht und lassen mich ungewünschte Seiteneffekte befürchten:
- Im sub ZWave_cmd wird hier ein "" in den Sendstack eingefügt:

Code Auswählen Erweitern

if($awake && @{$baseHash->{WakeUp}} == 0) {
push @{$baseHash->{WakeUp}}, ""; # Block the next
Im sub ZWave_parse wird dieses "" immer entfernt und der nächste Befehl gesendet. Dies ist im Patch-Code nicht berücksichtigt.
- Warum wird mal hash und mal baseHash (und auch noch wu) verwendet? Laut den zusätzlichen Logs die ich eingebaut habe, ist der Inhalt immer gleich. Im Patch wird hash verwendet.

Weitere ungelöste Probleme
Zwingend:
Prüfung darf nicht nur auf "wakeup notification" laufen, ansonsten erhalten WAKE_UP-Geräte, die zwar WAKE_UP class haben aber aufgrund der config frequentListening sind, niemals die Befehle. Beispiel:  EZMotion 3-in-1 (HSM100) kann mit set <device> configStayAwake 1 auf frequentListening umgestellt werden. Dadurch entfällt "wakeup notification" event und Befehle können immer empfangen werden. Abhilfe: Befehl nodeInfo um

Code Auswählen Erweitern

push @list, "frequentListening:" . ($r[3] & ( 0x20 | 0x40 ));
push @list, "beaming:" . ($r[3] & 0x10);
ergänzen und in der Abfrage bei frequentListening <> 0, das Gerät als "wach" behandeln. Soll man diese nodeInfo-Abfrage bei jedem Durchlauf stellen (mMn richtig) oder nur beim fhem-Start, oder... Abfrageergebnisse müssten wohl sinnvollerweise auch als Reading beim Gerät gespeichert werden.
Optimierung:
Wenn kein ACK, dann sollte der fehlgeschlagene Befehl im sendstack verbleiben und keine weiteren Befehle verschickt werden. Erst bei der nächsten "wakeup notification" sollte erneut verschickt werden. Das ganze vielleicht maximal 3 mal, bevor man es endgültig verwirft/aufgibt.

Leider bin ich mangels Programmierkünsten jetzt wieder auf Hilfe angewiesen. Sorry. Insgesamt halte ich den Patch persönlich für zu unvollständig zum Einchecken. Zumindest die frequentListenung-Thematik sollte abgedeckt werden, auch wenn es nur eine geringe Geräteanzahl betreffen sollte.

[rudolfkoenig]

- Im sub ZWave_cmd wird hier ein "" in den Sendstack eingefügt:

Theorie (evtl. falsch): man darf nur ein nicht beantwortetes Befehl an das Geraet senden, da das Dongle keine Warteschlange verwaltet. Falls der Benutzer zwei Befehle absetzt, und das Geraet wach ist, dann sendet FHEM eins direkt, den zweiten muss es aber (wg. der Theorie) blockieren. Um zu wissen, dass etwas noch nicht beantwortet ist, wird "" eingefuegt. Falls die Theorie falsch ist, dann ist das ueberfluessig, und die Schlange wird vom Dongle verwaltet. Wuesste gerne, wie lange seine Schlange sein kann.

- Warum wird mal hash und mal baseHash (und auch noch wu) verwendet?

$baseHash und $hash ist nur fuer MULTI_CHANNEL Geraete ab Kanal 2 unterschiedlich. Heisst aber nicht, dass man es ignorieren sollte.
$wu ist Abkuerzung fuer $baseHash->{WakeUp}. Erstens ist kuerzer zu schreiben/lesbarer, zweitens schneller in der Abarbeitung.
Wenn ich sowas mehr als einmal brauche, dann kuerze ich es gerne ab.

[krikan]

Schlange wird vom Dongle verwaltet. Wuesste gerne, wie lange seine Schlange sein kann.

Habe jetzt bis zu 80 Befehle in einem Rutsch übertragen und stelle in meiner Mini-Zwave-Umgebung keine Probleme fest.
Dennoch bin ich wieder auf dem Weg zu Deiner Theorie: Nur ein unbeantworteten Befehl an das Gerät senden.
Gründe:
-openzwave (ozw) macht das genauso und die beschäftigen sich schon länger damit
-in den ozw-groups wird vom mitsniffen des Zwave-Funkverkehrs einer closed Source Software berichtet, die auch so vorgeht
-entscheidend: könnten das wirklich alle Controller?  ACKs Zuordnung zu Telegrammen ist nur bei einem unbeantworteten Befehl sicher durchführbar
Mal schauen wie weit ich komme....

[hanske]

Hallo,
gibt es schon was neues?
Ist mein Patch (evtl. mit Anpassungen) eigentlich mal eingepflegt worden?
Soll ich noch etwas ändern oder testen?
Es wäre gut wenn meine Änderungen mit reinkommen, sonst kann ich nicht mehr so einfach updaten.

Grüße

[rudolfkoenig]

@hanske: kannst du bitte krikans Patch testen, wenn es funktioniert, wuerde ich es einchecken.

[krikan]

Bitte unbedingt aber meine erwähnten "weiteren ungelösten Probleme" von hier http://forum.fhem.de/index.php/topic,27984.msg212622.html#msg212622 beachten.
Der Patch ist also noch nicht optimal. Ich werde mich weiter an der Problemlösung versuchen, wenn es kein anderer übernimmt. Schaffe das aber nur langfristig. Mir fehlt monentan die Zeit.

[rudolfkoenig]

Es muessen nicht auf Anhieb alle Probleme geloest sein, aber ich haette gerne diesen Patch von mind 2 Leuten getestet.

[hanske]

Ich denke auch, dass nicht alles auf einmal gelöst werden muss.
Der Patch wird das WakeUp Verhalten aber insgesamt deutlich verbessern.

Ich wende den Patch von Krikan mal auf die aktuelle Version an und probiere übers Wochenende mal einiges aus.
Bis dann

[hanske]

Hat alles gut funktioniert. Die Stapel wurden komplett abgearbeitet und die Rückmeldungen kamen auch an.
Ich hatte allerdings ein anderes Problem in der Testzeit, welches mir vorher nicht aufgefallen war, aber mit dem Patch wohl trotzdem nichts zu tun hat:
Als ich meine Fritzbox neu startete, hatte ich im WebUi plötzlich 3 Tage alte Readings. Neue Readings und States der ZWave Geräte kamen weder im Log noch im UI an. Ich konnte die Geräte aber trotzdem über das UI steuern. Ein "shutdown restart" brachte auch nichts.
Erst nach einem Fritzbox Neustart am nächsten Tag ging wieder alles.
Hattet Ihr so was schon mal?

[hanske]

Hallo,

der Patch läuft immer noch ohne Probleme und ich würde mich freuen, wenn er mit in das Release käme.
Man sollte allerdings auch bei "ZW_APPLICATION_UPDATE" den ganzen Stapel abarbeiten.

Ich hatte gerade einen neuen Sensor eingerichtet und gleich eine ganze Menge Setting abgesetzt.
Leider hatte ich nicht als erstes das Wakeupinterval und den Empfängerknoten angegeben.

Ich habe dann manuell Wakeups ausgelöst, die aber nur als  "ZW_APPLICATION_UPDATE" ankamen.
Es wurde dann aber immer nur ein gespeicherter Befehl abgesetzt.
Ich habe dann das foreach aus dem Wakeup auch dorthin kopiert und schon lief es perfekt.

Also, es wäre schön wenn das mal in das Release kommt, dann kann ich auch wieder updaten

[krikan]

Hallo hanske,
könntest Du bitte einen Patch gegen die aktuelle svn-Version hochladen. Dann würde ich auch noch mal testen und Rudi hätte einen getesten Patch, den er einfach einbauen könnte.
Danke, Christian

[krikan]

@hanske: In http://forum.fhem.de/index.php/topic,28656.0.html hatte wieder jemand das hier diskutierte Problem. Es wäre daher gut, wenn Du einen Patch bereitstellen könntest oder mir Deine Änderung an meinem Patch bzgl.  "ZW_APPLICATION_UPDATE" mitteilst. Dann kann ich das testen und Rudi könnte es einbauen, bevor das zur endlosen Dauerbaustelle wird... Danke

[hanske]

Hallo,

hier kommt der Patch.
Ich musste das hier erst noch mal drei Tage laufen lassen.
Ist aber ganz simpel und funktioniert bei mir prima.
@krikan: Deine Änderungen sind auch drin.

Grüße
hanske

[krikan]

Super, Danke! 
Probiere ich heute abend noch mal aus.

[krikan]

Habe den Patch nochmals getestet und keine Probleme festgestellt.

@rudolfkoenig: Könntest Du das bei Gelegenheit bitte einbauen? Danke.

[rudolfkoenig]

Habs eingecheckt. Habe vorher etwas verschoenert und verkleinert, ich hoffe dass dabei nichts verlorengegangen ist. Einziger Unterschied: bei 028407 verwende ich den basHash und nicht den hash, ich meine das ist fuer multi-channel Geraete besser.