WakeUp, Scheduled Tasks Probleme

hanske · 16 Oktober 2014, 13:35:56

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 · 16 Oktober 2014, 15:22:07

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 · 16 Oktober 2014, 15:54:59

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 · 16 Oktober 2014, 16:07:45

get zwdongle nodeList

hanske · 16 Oktober 2014, 16:48:57

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

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 · 16 Oktober 2014, 18:14:47

Zitataber 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

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

hanske · 16 Oktober 2014, 20:05:26

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 · 16 Oktober 2014, 21:09:45

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 · 16 Oktober 2014, 23:19:59

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 · 17 Oktober 2014, 13:37:15

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 · 20 Oktober 2014, 13:26:19

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

     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

     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 · 22 Oktober 2014, 09:43:34

ZitatEs 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

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

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

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 · 22 Oktober 2014, 09:45:47

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 · 22 Oktober 2014, 09:57:26

@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 · 22 Oktober 2014, 10:18:27

@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.