Wakeup Geräte und keine neighborList mehr?

[Baerli34]

Moinsen,

kann es sein, dass die neighborList Abfragen nicht mehr auf dem Stapel landen bei batteriebetrieben Geräten?
Ich bekomme bei allen ein "Timeout Reading" - alle anderen Dinge werden korrekt scheduled...
Getested mit meinem Everspring Wassermelder und versch. Türsensoren.

lg, Jörg

[gero]

Das Verhalten, was du beschreibst ist mir auch schon aufgefallen.
- neighborList funktioniert nur, wenn das Gerät aktuell (oder innerhalb von kurzer Zeit) wach ist
- in der neighborList werden die WAKEUP Geräte herausgefiltert. Warum ist mir nicht ganz klar. Zur Analyse von Netzwerkproblemen ist es meiner Meinung nach hilfreich alle Nachbarn angezeigt zu bekommen.

Anbei ein kleiner Patch, der zumindest bei mir zur Zeit funktioniert.

Gruß,
Gero

[krikan]

- neighborList funktioniert nur, wenn das Gerät aktuell (oder innerhalb von kurzer Zeit) wach ist

Das ist mMn falsch. Es handelt sich um einem Controllerbefehl, der keinen Kontakt zum Wakeup-Device aufnimmt. Darum braucht das auch nicht in den Wakeup-Sendstack, sondern kann direkt verarbeitet werden. Derzeit scheint die Abfrage bei den Wakeup-Devices gar nicht an das Dongle geschickt/geschrieben zu werden. Und wenn nichts abgefragt wird, antwortet das Dongle nicht und Fhem laueft in den Timout. Kann derzeit nicht wirklich testen, aber nach Trockenübung bin ich mir dessen relativ sicher.

Zur Analyse von Netzwerkproblemen ist es meiner Meinung nach hilfreich alle Nachbarn angezeigt zu bekommen.

Die Wakep-Devices routen nicht, darum fehlt es vermutlich.
Wir braeuchten sowieso noch Optionen fuer Einschluss von DeadNodes und non-routing-Devices (wakeUp-Devices)
Habe damit schon mal angefangen, bin aber noch nicht so weit.
Wenn ich hier https://github.com/OpenZWave/open-zwave/blob/847d3857eaeb4ba685b97d606f9759a828eefc79/cpp/src/Driver.cpp nachsehe, stimmt der Kommentar im Code mMn nicht mehr: 00 heisst Einschluss, 01 Ausschluss der Option. Auch ungetestet  .

[gero]

Das ist mMn falsch. Es handelt sich um einem Controllerbefehl, der keinen Kontakt zum Wakeup-Device aufnimmt. Darum braucht das auch nicht in den Wakeup-Sendstack, sondern kann direkt verarbeitet werden. Derzeit scheint die Abfrage bei den Wakeup-Devices gar nicht an das Dongle geschickt/geschrieben zu werden. Und wenn nichts abgefragt wird, antwortet das Dongle nicht und Fhem laueft in den Timout. Kann derzeit nicht wirklich testen, aber nach Trockenübung bin ich mir dessen relativ sicher.

Da hast du vermutlich recht. Falls es so ist, kann der Patch etwas vereinfacht werden.

Die Wakep-Devices routen nicht, darum fehlt es vermutlich.
Wir braeuchten sowieso noch Optionen fuer Einschluss von DeadNodes und non-routing-Devices (wakeUp-Devices)
Habe damit schon mal angefangen, bin aber noch nicht so weit.
Wenn ich hier https://github.com/OpenZWave/open-zwave/blob/847d3857eaeb4ba685b97d606f9759a828eefc79/cpp/src/Driver.cpp nachsehe, stimmt der Kommentar im Code mMn nicht mehr: 00 heisst Einschluss, 01 Ausschluss der Option. Auch ungetestet  .

Ich bin mir nicht sicher, welchen Kommentar du meinst. Ich finde folgendes ist korrekt und durch meine eigenen Tests bestätigt:

Code Auswählen Erweitern


Msg* msg = new Msg( "Get Routing Info", _nodeId, REQUEST, FUNC_ID_ZW_GET_ROUTING_INFO, false );
msg->Append( _nodeId );
msg->Append( 0 ); // don't remove bad links
msg->Append( 0 ); // don't remove non-repeaters
msg->Append( 3 ); // funcid

Meiner Meinung nach sollten auch "non-repeaters" in der NeighborList in fhem angezeigt werden.Denn nur so ist die Netzwerktopologie vollständig zu erkennen.
Ein Beispiel:
Ich habe einen Fibaro Motion Sensor (WAKEUP) und einen Fibaro Wallplug (Routing Device). Der Motion Sensor kann vom Dongle aus nicht direkt erreicht werden. Ich empfange die WAKEUP Nachrichten am Dongle. Kann selbst aber in den meisten Fällen keine Befehle an den Motion Sensor senden.
Die aktuelle Implementierung in fhem liefert mir folgende Info:

ZWave_SENSOR_BINARY_9: neighborList -> ZWave_SWITCH_BINARY_8
ZWave_SWITCH_BINARY_8: neighborList -> empty

Da ich die ZWave Interna nicht kenne, habe ich zuerst vermutet, dass der ZWave_SWITCH_BINARY_8 tatsächlich keinen Nachbarn kennt und somit meine Befehle auch nicht Routen kann. Erst nach einem Blick in den Code und einer Änderung des neighborList Befehls, war ich mir sicher, dass das Probem wo anders lag.

Gruß,
Gero

[krikan]

Ich bin mir nicht sicher, welchen Kommentar du meinst.

Meinte den Kommentar "# GET_ROUTING_TABLE_LINE, include dead links, non-routing neigbors" in 10_ZWave.pm, der widerspricht doch dem Fhem-Code, wenn ich mit OZW vergleiche !?. Bis jetzt fragt Fhem die Dead Nodes und non-roting-devices nicht mit ab. Das passt mMn auch zu Deinen neigborList. Es ging keinesfalls um Deinen Code.

[krikan]

Getestete Problemkonkretisierung:
Bei mir funktioniert die Abfrage "get <device> neigbourlist" nach einem "shutdown restart" pro Device genau einmal. Danach kommt auf eine Abfrage nur die Timeout-Meldung. Anliegend log mit verbose 5. Node 18 und 30 sind Wakeup-Devices. Wo das Problem im Detail liegt, kann ich leider nicht finden.

Code Auswählen Erweitern

2015.10.23 12:16:24 2: ZWave get ZWave_GARAGE_DOOR_30 neighborList
2015.10.23 12:16:24 5: ZWave_GARAGE_DOOR_30: Sendstack bypassed for 801e0101
2015.10.23 12:16:24 5: ZWDongle_Write 00 801e0101
2015.10.23 12:16:24 5: SW: 010600801e010167
2015.10.23 12:16:24 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.10.23 12:16:24 5: ACK received, removing 010600801e010167 from dongle sendstack
2015.10.23 12:16:24 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01802900000600000000000000000000000000000000000000000000000000
2015.10.23 12:16:24 5: SW: 06
2015.10.23 12:16:24 4: ZWDongle_ReadAnswer for neighborList: 01802900000600000000000000000000000000000000000000000000000000
2015.10.23 12:16:33 2: ZWave get ZWave_GARAGE_DOOR_30 neighborList
2015.10.23 12:16:33 5: ZWave_GARAGE_DOOR_30: Sendstack bypassed for 801e0101
2015.10.23 12:16:33 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.10.23 12:16:36 5: ZWDongle_ReadAnswer: select timeout
2015.10.23 12:16:51 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040012063105030a015a
2015.10.23 12:16:51 5: SW: 06
2015.10.23 12:16:51 5: ZWDongle_0 dispatch 00040012063105030a015a
2015.10.23 12:16:51 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:12 ARG:063105030a015a
2015.10.23 12:17:08 2: ZWave get ZWave_SENSOR_BINARY_18 neighborList
2015.10.23 12:17:08 5: ZWDongle_Write 00 80120101
2015.10.23 12:17:08 5: SW: 010600801201016b
2015.10.23 12:17:08 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.10.23 12:17:08 5: ACK received, removing 010600801201016b from dongle sendstack
2015.10.23 12:17:08 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01802900000000000000000000000000000000000000000000000000000000
2015.10.23 12:17:08 5: SW: 06
2015.10.23 12:17:08 4: ZWDongle_ReadAnswer for neighborList: 01802900000000000000000000000000000000000000000000000000000000
2015.10.23 12:17:11 2: ZWave get ZWave_SENSOR_BINARY_18 neighborList
2015.10.23 12:17:11 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.10.23 12:17:15 5: ZWDongle_ReadAnswer: select timeout
2015.10.23 12:17:32 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004001a06310504220000
2015.10.23 12:17:32 5: SW: 06
2015.10.23 12:17:32 5: ZWDongle_0 dispatch 0004001a06310504220000
2015.10.23 12:17:32 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:06310504220000
2015.10.23 12:17:35 2: ZWave get ZWave_GARAGE_DOOR_30 neighborList
2015.10.23 12:17:35 5: ZWave_GARAGE_DOOR_30: Sendstack bypassed for 801e0101
2015.10.23 12:17:35 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.10.23 12:17:38 5: ZWDongle_ReadAnswer: select timeout

[A.Harrenberg]

Hi,

zum einen sehe ich da das mir bereits bekannte Verhalten das teilweise die ReadAnswerFn aktiv wird bevor der Befehle überhaupt verschickt wurde. Das führt dann zu dem Time-Out. Da FHEM während der Time-Out Zeit keine Sachen mehr sendet wird der Befehl dann aber eigentlich NACH dem Time-Out gesendet, dann allerdings ohne die ReadAnswerFn aufzurufen.

In diesem Fall wird aber anscheinenend beim zweiten Versuch gar kein "Write" ausgelöst. Für den ersten Aufruf wird noch ein

Code Auswählen Erweitern

2015.10.23 12:16:24 5: ZWDongle_Write 00 801e0101
erzeugt, für den zweiten Aufruf kommt das schon nicht mehr.

Das habe ich bisher noch nicht beobachtet, eine Idee dazu habe ich aber auch erst mal nicht.

Gruß,
Andreas.

[krikan]

Wenn es hilft, probiere ich rückwärts verschiedene Revisionen der ZWave-Module durch, um festzustellen seit wann das Problem auftritt.

Btw.: Ist es eigentlich noch(?) notwendig, dass Fhem auf die get-Befehle wartet? Kann das nicht set angepasst werden?

Gruß, Christian

[A.Harrenberg]

Hi Krikan,

also Rudi würde ja gerne das GET abschaffen, ich würde es gerne behalten und die "nur" die Behandlung anpassen (-> ReadAnswerFn entfernen bzw. anders/non-blocking implementieren).

Zum einen finde ich es für den Nutzer noch ganz praktisch das zu unterscheiden, zum anderen ist es Voraussetzung für eine richtige Ablaufsteuerung die ich ja für Security brauche. Irgendwie muss ich ja "wissen" ob ich auf eine Antwort warten muss oder nicht. Ich bin auch der Meinung das zwischen GET-Anfrage und REPORT-Antwort nichts gesendet werden darf da ansonsten CAN-Msg auftreteten, Rudi sieht das etwas anders...

Wenn Du die Revision rausfinden kannst bei der das Problem eingeführt wurde hilft das sicherlich bei der Analyse und Fehlerbehebung, ich hab' aber frühestens in einer Woche wieder Zeit...

Gruß,
Andreas.

[rudolfkoenig]

ich würde es gerne behalten und die "nur" die Behandlung anpassen (-> ReadAnswerFn entfernen bzw. anders/non-blocking implementieren).

Wenn du das hinkriegst, baue ich es sofort ein. Aber nur, wenn dazu nicht alle Module (telnet/FHEMWEB/etc) angefasst werden muessen. Tipp: meiner Ansicht nacht geht das nur mit groesseren Umbauten.

ist es Voraussetzung für eine richtige Ablaufsteuerung die ich ja für Security brauche.

Das ist ja nicht ganz richtig: mit get ist es nur einfacher/bequemer. Sonst muss man Status abspeichern, um beim Eintreffen der Nachricht wieder aufsetzen zu koennen.

[krikan]

Problem, dass der Befehl "get <device> neigbourList" bei einem WakeUp-Devices nur beim ersten Aufruf nach Fhem-Start funktioniert, tritt seit r9371 vom 04.10.2015 auf. D.h. seitdem der Befehl von 00_ZWDongle.pm nach 10_ZWave.pm verschoben wurde.

[rudolfkoenig]

Gefixt.

[A.Harrenberg]

Hi Rudi,

Wenn du das hinkriegst, baue ich es sofort ein. Aber nur, wenn dazu nicht alle Module (telnet/FHEMWEB/etc) angefasst werden muessen. Tipp: meiner Ansicht nacht geht das nur mit groesseren Umbauten.

die Tatsache das mir da jetzt der Zusammenhang mit telnet/FHEMWEB/etc fehlt zeigt mir das ich das wahrscheinlich was GANZ grob unterschätze...

Das ist ja nicht ganz richtig: mit get ist es nur einfacher/bequemer. Sonst muss man Status abspeichern, um beim Eintreffen der Nachricht wieder aufsetzen zu koennen.

Da muss ich jetzt leider widersprechen. Ich muss wissen ob eine Antwort erwartet wird oder nicht. Falls noch eine Antwort erwartet wird darf ich keinen neuen Befehl an das Gerät senden.
Die vielen CAN-Msg beim Aufwachen von Security-WakeUp-Geräten zeigen das recht deutlich...

Das ganze Thema mit der Ablaufsteuerung ist mMn noch nicht wirklich zu Ende gedacht, zumindest nicht von meiner Seite aus. Ich habe noch keine Ahnung wie ich auf eine Antwort warten kann ohne das System zu blockieren. Mir würde hier nur einfallen einen Timer zu starten der zyklisch nachschaut ob eine passende Nachricht eingetroffen ist und auch auf einen Time-Out reagieren kann.

Kannst Du vielleicht mal skizzieren wie Du Dir den Stack mittels ZWave_Set / ZWave_Get vorgestellt hast?

Gruß,
Andreas.

[rudolfkoenig]

Hier geht es weiter.

[toms01]

Hallo allerseits,

eventuell OT:
Ich bekomme seit dem 30.09. keine wakeup notification mehr von einem Everspring SP103 Bewegungsmelder.
2015-09-30_18:48:37 ID023_BM_AUSSEN wakeup: notification

Bewegung detektiert/meldet er noch immer, allerdings verschluckt jetzt manchmal ein paar.

Danach konnte man einmal das lesen:
2015-10-12_19:37:18 ID023_BM_AUSSEN UNPARSED: BASIC 032041bf

sowie einmal das:
2015-10-15_18:21:40 ID023_BM_AUSSEN UNPARSED: CONTROLLER_REPLICATION 032101ff

Batterien sind ausgewechselt: 90%

Wurde etwas grundsätzlich geändert, was das ausgelöst haben könnte?
Vielen Dank,
Thomas

[rudolfkoenig]

Ja, das ist off-topic.
Geaendert haben wir mWn an dieser Ecke nichts. Da das Geraet selbst die wakeup-notifications schickt, ist das mit grosser Wahrscheinlichkeit kein FHEM Programmierfehler, eher ist das Geraet verkonfiguriert. Siehe get/set wakeupInterval.

BASIC 032041bf: Typ/Byte 41 in der BASIC Klasse ist sowohl mir, wie auch dem Modul unbekannt. Wir kennen 01 (set), 02 (get) und 03 (report).

CONTROLLER_REPLICATION 032101ff: Diese Klasse ist in FHEM nicht implemetiert.

[toms01]

Wollte nur noch kurz die Lösung meines Problems berichten:

Es war kein Konfigurationsfehler des Wakeup-Intervalls, sondern ein Attribut welches man
bei einem batteriebetriebenen Gerät nicht setzen sollte:

attr ID023_BM_AUSSEN event-on-change-reading .*

Also ein Anfängerfehler, wakeup hatte immer wieder den Status notification und löste somit kein Event aus.

Was bei Mehrfachmeldungen also weggefiltert werden soll muss also gut überlegt sein.