Readings bei batteriebetriebenen Geräten

Begonnen von 9zehn75, 22 Februar 2016, 20:23:42

Vorheriges Thema - Nächstes Thema

9zehn75

Ich habe mittlerweile elf Fibaro Fenstersensoren in Betrieb. Ich bekomme es aber nicht hin, von diesen Antworten auf Anfragen wie "get neighborList" zu erhalten. Die Nachrichten werden beim Wake-Up rausgeschickt, die Readings werden aber nicht gefüllt. Das gilt für alle elf Fenstersensoren.

Hier mal exemplarisch ein list:

Internals:
   DEF        dfe4e1ee 8
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     1
   NAME       Fenster_Keller_Sport
   NR         56
   STATE      closed
   TYPE       ZWave
   ZWDongle_0_MSGCNT 1
   ZWDongle_0_RAWMSG 00040008028407
   ZWDongle_0_TIME 2016-02-22 19:22:47
   homeId     dfe4e1ee
   isWakeUp   1
   lastMsgSent 1456165367.15235
   nodeIdHex  08
   Readings:
     2016-02-21 19:29:01   basicSet        00
     2016-02-13 19:56:06   model           FIBARO System FGK101 Door Opening Sensor
     2016-02-13 19:56:06   modelConfig     fibaro/fgk001.xml
     2016-02-13 19:56:06   modelId         010f-0700-1000
     2016-02-16 19:50:39   state           TRANSMIT_NO_ACK
     2016-02-22 19:22:49   transmit        OK
     2016-02-22 19:22:47   wakeup          notification
   SendStack:
     get:80080100
Attributes:
   IODev      ZWDongle_0
   classes    SENSOR_BINARY SENSOR_ALARM ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION BASIC
   eventMap   ff:open 00:closed
   group      Fenster
   room       Fenster,Keller,ZWave
   stateFormat basicSet
   verbose    5


Die eine Nachricht, die noch da ist, habe ich gerade eben wieder abgesetzt (wiederum ein get neighborList).

Mache ich was falsch oder ist das ein Denkfehler, dass da nach dem Aufwachen was zurückgeliefert werden sollte? So hatte ich das Wiki jedenfalls verstanden.
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

krikan

Zitat von: 9zehn75 am 22 Februar 2016, 20:23:42
Ich habe mittlerweile elf Fibaro Fenstersensoren in Betrieb. Ich bekomme es aber nicht hin, von diesen Antworten auf Anfragen wie "get neighborList" zu erhalten. Die Nachrichten werden beim Wake-Up rausgeschickt, die Readings werden aber nicht gefüllt. Das gilt für alle elf Fenstersensoren.

Mache ich was falsch oder ist das ein Denkfehler, dass da nach dem Aufwachen was zurückgeliefert werden sollte? So hatte ich das Wiki jedenfalls verstanden.
Ob falsch oder nur Kommunikationsfehler (Hinweis: TRANSMIT_NO_ACK) vorliegen, kann ich ohne Log mit verbose 5 nicht wirklich beurteilen. Aber "get neighborList" sollte etwas zurückliefern. Befürchte eher (bekomme von Dir wahrscheinlich bald Antwortverbot :-[) Probleme wegen der vielen Controller...

rudolfkoenig

Ja, reading wird gefuellt, wenn Nachricht zurueckkommt.
Wenn im Zweifel, dann "attr ZWDongle_0 verbose 5" setzen, und das Log vor/nach wakeup:notification hier zeigen.

9zehn75

Die meisten meiner Versuche stammen aus der Zeit mit nur einem Controller. Außerdem liefern alle anderen Geräte fehlerfrei zurück. Im Zweifel nehme ich die Repeater auch noch mal raus.

Mache morgen mal ein Log und versuche den Fehler einzugrenzen...
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

krikan

Zitat von: 9zehn75 am 22 Februar 2016, 21:56:13
Die meisten meiner Versuche stammen aus der Zeit mit nur einem Controller. Außerdem liefern alle anderen Geräte fehlerfrei zurück.
Gut, Du hast mich überzeugt und ich werde jetzt nichts mehr so schnell auf Deine vielen Controller schieben.  :)

Habe selbst mal ein WakeUp-Gerät mit "get neigborList" getestet und bekomme eine unhandled ANSWER:
2016.02.22 22:09:01 5: ZWDongle_Write 00801f0100 (e345c452)
2016.02.22 22:09:01 5: SW: 010600801f010067
2016.02.22 22:09:02 5: ACK received, removing 010600801f010067 from dongle sendstack
2016.02.22 22:09:02 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01802900000600000000000000000000000000000000000000000000000000
2016.02.22 22:09:02 5: SW: 06
2016.02.22 22:09:02 5: ZWDongle_0 dispatch 01802900000600000000000000000000000000000000000000000000000000
2016.02.22 22:09:02 4: ZWDongle_0 unhandled ANSWER: GET_ROUTING_TABLE_LINE 2900000600000000000000000000000000000000000000000000000000

Ursache habe ich noch nicht gesucht. Wollte Dich nur schon mal informieren, dass Du nicht in falsche Richtungen analysierst.

Gruß, Christian

9zehn75

#5
Ok, danke. Bin heute sehr eingespannt. Setzte aber mal für alle einen get ab. Meine Geräte wachen heute Abend auf. Dann muss ich nur noch die Logs kopieren.

Insgesamt scheinen die Symptome denen im Thread "Z-Wave nach heutigem Update unbrauchbar" sehr zu ähneln.
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

krikan

Zitat von: 9zehn75 am 23 Februar 2016, 07:17:29
Insgesamt scheinen die Symptome denen im Thread "Z-Wave nach heutigem Update unbrauchbar" sehr zu ähneln.
Der Thread ist mMn nichtssagend und vermischt verschiedenste Probleme (Besonderheiten einer bestimmten Windows-Perl-Installation, unsaubere Controller-Nodelists, Hardwareprobleme,...). Nichts, was ich auf eine Ursache zurückführen kann.

Wenn Du im Log die "unhandled ANSWER" auf die Abfrage von "get nodelist" hast, wie ich sie oben festgestellt habe, dann ist es klar, das in den Readings nichts auftaucht. Abhilfe kommt bestimmt.

Gruß, Christian

9zehn75

#7
Zitat von: krikan am 23 Februar 2016, 09:31:04
Der Thread ist mMn nichtssagend und vermischt verschiedenste Probleme (Besonderheiten einer bestimmten Windows-Perl-Installation, unsaubere Controller-Nodelists, Hardwareprobleme,...). Nichts, was ich auf eine Ursache zurückführen kann.

Wenn Du im Log die "unhandled ANSWER" auf die Abfrage von "get nodelist" hast, wie ich sie oben festgestellt habe, dann ist es klar, das in den Readings nichts auftaucht. Abhilfe kommt bestimmt.

Wollte mit o.g. Thread auch nichts Weitergehendes sagen. Es gibt dort eben nur ein paar Parallelen.

Bei mir sind "undhandled ANSWER" bislang elf Mal vorgekommen (ich habe elf batteriebetriebene Geräte) seit ich FHEM in Betrieb genommen habe, erstmalig am 14.02.2016, um 21:03 Uhr:

2016.02.14 10:52:58 5: ZWDongle_Write 0080080100 (dfe4e1ee)
2016.02.14 10:52:58 5: SW: 0106008008010070
2016.02.14 10:52:58 5: ACK received, removing 0106008008010070 from dongle sendstack
2016.02.14 10:52:58 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01802d00000000000000000000000000000000000000000000000000000000
2016.02.14 10:52:58 5: SW: 06
2016.02.14 10:52:58 5: ZWDongle_0 dispatch 01802d00000000000000000000000000000000000000000000000000000000
2016.02.14 10:52:58 4: ZWDongle_0 unhandled ANSWER: GET_ROUTING_TABLE_LINE 2d00000000000000000000000000000000000000000000000000000000


Soweit ich das beurteilen kann, immer nur bei batteriebetriebenen Geräten. Hier mal exemplarisch ein Auszug aus meinem Log mit verbose 5 auf dem Dongle zu dem bislang letzten Eintrag:

2016.02.22 21:03:42 5: ZWDongle_Write 00800f0100 (dfe4e1ee)
2016.02.22 21:03:42 5: SW: 010600800f010077
2016.02.22 21:03:42 5: ACK received, removing 010600800f010077 from dongle sendstack
2016.02.22 21:03:42 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01800000000000000000000000000000000000000000000000000000000000
2016.02.22 21:03:42 5: SW: 06
2016.02.22 21:03:42 5: ZWDongle_0 dispatch 01800000000000000000000000000000000000000000000000000000000000
2016.02.22 21:03:42 4: ZWDongle_0 unhandled ANSWER: GET_ROUTING_TABLE_LINE 0000000000000000000000000000000000000000000000000000000000


Wenn ich irgendwie zur Fehlersuche beitragen kann, immer gerne!

Ich frage mich gerade, ob es sogar sein kann, dass auch set-Befehle nicht (mehr) bei den batteriebtriebenen Geräten ankommen. Ich habe mehrfach probiert, die Wakeup-Intervalle zu verändern bzw. neighborUpdates auszulösen. Und ich habe irgendwie den Eindruck, dass das nicht klappt. Bei den wakeUp-Intervallen kann ich das anhand der Logs der einzelnen Geräte kontrollieren, hier mal ein Beispiel eines Fenstersensors, dessen wakeUp-Intervall ich schon mehrfach auf drei Stunden heruntergestellt habe:

2016-02-21_14:57:23 Fenster_Tuer_Vorne associationAdd 1 01
2016-02-21_14:57:23 Fenster_Tuer_Vorne wakeupInterval 86400 01
2016-02-21_14:57:25 Fenster_Tuer_Vorne modelId: 010f-0700-1000
2016-02-21_14:57:25 Fenster_Tuer_Vorne model: FIBARO System FGK101 Door Opening Sensor
2016-02-21_14:57:25 Fenster_Tuer_Vorne modelConfig: fibaro/fgk001.xml
2016-02-21_14:57:56 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:57:57 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:57:59 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:00 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:58:18 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:18 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:58:18 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:19 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:21 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:58:22 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:23 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_14:58:24 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_14:58:25 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:00:47 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:00:50 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:00:51 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:00:52 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:00:53 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:00:54 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:00:55 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:00:56 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:01:02 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:01:03 Fenster_Tuer_Vorne basicSet: 00
2016-02-21_15:01:24 Fenster_Tuer_Vorne basicSet: ff
2016-02-21_15:01:29 Fenster_Tuer_Vorne basicSet: 00
2016-02-22_13:52:50 Fenster_Tuer_Vorne basicSet: open
2016-02-22_13:53:24 Fenster_Tuer_Vorne basicSet: closed
2016-02-22_15:29:17 Fenster_Tuer_Vorne wakeup: notification
2016-02-22_16:48:40 Fenster_Tuer_Vorne basicSet: open
2016-02-22_16:50:24 Fenster_Tuer_Vorne basicSet: closed
2016-02-22_19:01:32 Fenster_Tuer_Vorne basicSet: open
2016-02-22_19:02:08 Fenster_Tuer_Vorne basicSet: closed
2016-02-22_19:20:55 Fenster_Tuer_Vorne basicSet: open
2016-02-22_19:21:23 Fenster_Tuer_Vorne basicSet: closed
2016-02-23_07:43:31 Fenster_Tuer_Vorne basicSet: open
2016-02-23_07:44:32 Fenster_Tuer_Vorne basicSet: closed
2016-02-23_07:47:31 Fenster_Tuer_Vorne basicSet: open
2016-02-23_07:47:33 Fenster_Tuer_Vorne basicSet: closed
2016-02-23_07:47:40 Fenster_Tuer_Vorne basicSet: open
2016-02-23_07:51:35 Fenster_Tuer_Vorne basicSet: closed
2016-02-23_10:18:20 Fenster_Tuer_Vorne basicSet: open
2016-02-23_10:18:28 Fenster_Tuer_Vorne basicSet: closed


Wie man sieht, wacht der noch immer nur ein Mal pro Tag auf. Leider bekomme ich ja zu meinen get-Anfragen keine Antwort. Ich glaube aber nicht, dass meine set-Befehle irgendwas bewirken. Anfangs konnte ich meine batteriebetriebenen Geräte ohne Weiteres mit set-Befehlen umstellen, um z.B. die wakeUp-Periode zu verändern.

Kann das miteinander zusammenhängen?
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

krikan

@Rudi:
"get <device> neigborList" wird für Wakeup-Devices momentan (seit get-Umbau?) in den Wakeup-Sendstack gelegt und erst bei Wakeup verarbeitet. Da es ein Controllerbefehl ist, sollte es mMn wie vorher am Wakeup-Sendstack vorbei sofort verarbeitet werden. Nach meinem Verständnis verursacht das doch auch die "unhandled ANSWER"!?

@9zehn75
Bei mir funktionieren set- und get-Befehle (außer neigborList) bei den Wakeup-Geräten. Ich habe gerade mehrere Test durchgeführt; auch das (mehrfache) Umstellen des Wakeup-Intervalls ist problemlos möglich. Aus dem FileLog (Grundlage u.a. für Plots) kann man nicht erkennen. Um etwas feststellen zu können ist, brauchen wir wieder die Logs mit verbose 5. Seit wann hast Du denn das Problem, dass keine Werte mehr kommen/durchgehen? Theorie habe ich. :-X.

9zehn75

Zitat von: krikan am 23 Februar 2016, 19:11:41
@9zehn75
Bei mir funktionieren set- und get-Befehle (außer neigborList) bei den Wakeup-Geräten. Ich habe gerade mehrere Test durchgeführt; auch das (mehrfache) Umstellen des Wakeup-Intervalls ist problemlos möglich. Aus dem FileLog (Grundlage u.a. für Plots) kann man nicht erkennen. Um etwas feststellen zu können ist, brauchen wir wieder die Logs mit verbose 5. Seit wann hast Du denn das Problem, dass keine Werte mehr kommen/durchgehen? Theorie habe ich. :-X.

Ich habe alle Repeater aus meinem Netz geworfen und die Devices in fhem gelöscht. Nun gibt es nur noch einen Controller. Dann habe ich einen Fenstersensor abgebaut und sitze nun seit einer Stunde hier und teste. Wannimmer ich versuche ihn manuell zu wecken, erscheint in seinem Log eine Meldung wie die Folgende:

2016-02-23_21:01:49 Fenster_Keller_Waesche CMD: ZW_APPLICATION_UPDATE

Ich bekomme es aber nicht hin, dass er aufwacht. Ich drücke - wie im Fibaro-Video beschrieben - drei mal auf den TMP-Knopf. Dann leuchtet die LED und obige Nachricht erscheint im Log.

Dazu hier auch mal ein zeitgleicher Ausschnitt aus dem globalen Log:

2016.02.23 21:01:49 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0049840e0f042001309c857270868056847aef2b
2016.02.23 21:01:49 5: SW: 06
2016.02.23 21:01:49 5: ZWDongle_0 dispatch 0049840e0f042001309c857270868056847aef2b
2016.02.23 21:01:49 4: CMD:ZW_APPLICATION_UPDATE ID:0e ARG:0f042001309c857270868056847aef2b


Was genau bedeutet "ZW_APPLICATION_UPDATE"? Ich konnte dazu nichts finden, was ich verstehe.

Laut Log soll der Fenstersensor um 2016-02-23_20:19:38 zuletzt aufgewacht sein. Dies ist das entsprechende Log dazu:

2016.02.23 20:19:38 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000e028407
2016.02.23 20:19:38 5: SW: 06
2016.02.23 20:19:38 5: ZWDongle_0 dispatch 0004000e028407
2016.02.23 20:19:38 4: CMD:APPLICATION_COMMAND_HANDLER ID:0e ARG:028407
2016.02.23 20:19:40 5: ZWDongle_Write 00130e028408250e (dfe4e1ee)
2016.02.23 20:19:40 5: SW: 010900130e028408250e4e
2016.02.23 20:19:40 5: ACK received, WaitForAck=&gt;2 for 010900130e028408250e4e
2016.02.23 20:19:40 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.02.23 20:19:40 5: SW: 06
2016.02.23 20:19:40 5: ZWDongle_0 dispatch 011301
2016.02.23 20:19:41 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130e000006
2016.02.23 20:19:41 5: SW: 06
2016.02.23 20:19:41 5: device ack reveived, removing 010900130e028408250e4e from dongle sendstack
2016.02.23 20:19:41 5: ZWDongle_0 dispatch 00130e000006
2016.02.23 20:19:41 4: CMD:ZW_SEND_DATA ID:00 ARG:0006
2016.02.23 20:19:41 4: ZWDongle_0 transmit OK for 0e


Das sieht erstmal ok aus, oder?

Kann es sein, dass meine Sende-Stacks so voll sind, dass pro Wakeup nur ein kleiner Teil ausgeliefert wird? Hier mal ein List des Fenstersensors, der gerade neben mir liegt:

Internals:
   DEF        dfe4e1ee 14
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     32
   NAME       Fenster_Keller_Waesche
   NR         70
   STATE      open
   TYPE       ZWave
   ZWDongle_0_MSGCNT 32
   ZWDongle_0_RAWMSG 0004000e032001ff
   ZWDongle_0_TIME 2016-02-23 21:02:16
   homeId     dfe4e1ee
   isWakeUp   1
   lastMsgSent 1456257709.64623
   nodeIdHex  0e
   Readings:
     2016-02-23 21:01:49   CMD             ZW_APPLICATION_UPDATE
     2016-02-23 21:02:16   basicSet        ff
     2016-02-19 20:45:01   model           FIBARO System FGK101 Door Opening Sensor
     2016-02-19 20:45:01   modelConfig     fibaro/fgk001.xml
     2016-02-19 20:45:01   modelId         010f-0700-1000
     2016-02-23 21:02:00   state           TRANSMIT_NO_ACK
     2016-02-23 21:02:00   transmit        NO_ACK
     2016-02-23 20:19:38   wakeup          notification
Attributes:
   IODev      ZWDongle_0
   classes    SENSOR_BINARY SENSOR_ALARM ASSOCIATION MANUFACTURER_SPECIFIC CONFIGURATION VERSION BATTERY CRC_16_ENCAP WAKE_UP FIRMWARE_UPDATE_MD MARK SCENE_ACTIVATION BASIC
   eventMap   ff:open 00:closed
   group      Fenster
   room       Fenster,Keller,ZWave
   stateFormat basicSet
   verbose    5


Bedeutet "MSGCNT     32", dass noch 32 Meldungen im Stack liegen? Falls ja, wie bekomme ich die ausgeliefert, soll heißen: wie bekomme ich meine Fenstersensoren manuell aufgeweckt? Im Netz gibt es einige Berichte von Usern, die das manuelle Aufwachen nicht hinbekommen, aber leider keine Lösung.

VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

9zehn75

Kleines Update: ich habe nun vier Stunden probiert. Und plötzlich - ohne jede Änderung meinerseits - funktionieren manuelle Wake-Ups und die Readings trudeln ein. Verstehe ich zwar nicht, bin aber froh, da ich nun besser debuggen kann.
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

rudolfkoenig

Zitat"get <device> neigborList" wird für Wakeup-Devices momentan (seit get-Umbau?) in den Wakeup-Sendstack gelegt und erst bei Wakeup verarbeitet. Da es ein Controllerbefehl ist, sollte es mMn wie vorher am Wakeup-Sendstack vorbei sofort verarbeitet werden. Nach meinem Verständnis verursacht das doch auch die "unhandled ANSWER"!?

Das Problem gibts wohl seit 2015-11-27, Kommentar dazu war "10_ZWave.pm: readd neighborList".
Habs gefixt, bei mir scheint es zu funktionieren, "get battery" funktioniert auch noch :)
Und richtig, "unhandled ANSWER: GET_ROUTING_TABLE_LINE" war ein Resultat des Bugs.


9zehn75

#12
Zitat von: rudolfkoenig am 24 Februar 2016, 12:10:39
Das Problem gibts wohl seit 2015-11-27, Kommentar dazu war "10_ZWave.pm: readd neighborList".
Habs gefixt, bei mir scheint es zu funktionieren, "get battery" funktioniert auch noch :)
Und richtig, "unhandled ANSWER: GET_ROUTING_TABLE_LINE" war ein Resultat des Bugs.

Hmmm. Meistens klappt nun bei mir das neighborUpdate. Ab und an kommt aber die Antwort "Timeout reading answer for get neighborList". Kann das überhaupt sein? Wenn ich dann mit "shutdown restart" neu starte, klappt wieder alles.
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

9zehn75

Ich hole das nochmal hoch: ist das nur bei mir so oder haben andere das gleiche Problem?
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

krikan

Könntest Du das bitte noch mal erläutern:
ZitatMeistens klappt nun bei mir das neighborUpdate. Ab und an kommt aber die Antwort "Timeout reading answer for get neighborList".
Kommt bei neigborUpdate tatsächlich eine Antwort "Timeout reading answer for get neighborList"!?
Oder (vermutlich) stößt Du ein neigborUpdate an und rufst dann ohne auf das Ergbnis zu warten neigborlist ab und bekommst die Meldung?
Logs sagen manchmal mehr als tausend Worte  ;).
Gruß, Christian

9zehn75

Zitat von: krikan am 27 Februar 2016, 20:14:15
Könntest Du das bitte noch mal erläutern:Kommt bei neigborUpdate tatsächlich eine Antwort "Timeout reading answer for get neighborList"!?
Oder (vermutlich) stößt Du ein neigborUpdate an und rufst dann ohne auf das Ergbnis zu warten neigborlist ab und bekommst die Meldung?
Logs sagen manchmal mehr als tausend Worte  ;).

Na ja, irgendwann vorher habe ich sicherlich ein neigborUpdate angestoßen, sicher aber nicht kurz davor. Einen Log habe ich (bislang) nicht, da ich noch keine Zeit hatte, das nachzustellen und vom Tatzeitpunkt kein ausreichendes Log existiert. Jetzt im Moment sehe ich gerade von unterwegs, dass auf ein get neighborList gar keine Antwort mehr kommt - es passiert rein gar nichts. Ich bin aber gerade nicht zuhause und kann nicht nachsehen warum das so ist.
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

krikan

Habe es mal ausprobiert und vermute, dass das nur bei WakeUp-Geräten auftritt:

Abruf der neigborList bei leerem Wakeup-Sendstack geht. Sobald Befehle im Wakeup-Sendstack stehen, wird der neigborList-Befehl nicht per ZWDongle_Write an das Dongle geschickt. Antwort kommt daher auch nicht und das Ergebnis ist "Timeout reading answer for get neighborList". Das habe ich jetzt mehrfach für 2 WakeUp-Geräte reproduzieren können.

Log:
2016.02.27 21:05:25 2: ZWave get ZWave_GARAGE_DOOR_31 neighborList
2016.02.27 21:05:25 5: ZWDongle_Write 00801f0100 (e345c452)
2016.02.27 21:05:25 5: SW: 010600801f010067
2016.02.27 21:05:25 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2016.02.27 21:05:25 5: ACK received, removing 010600801f010067 from dongle sendstack
2016.02.27 21:05:25 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01802900000600000000000000000000000000000000000000000000000000
2016.02.27 21:05:25 5: SW: 06
2016.02.27 21:05:25 4: ZWDongle_ReadAnswer for neighborList: 01802900000600000000000000000000000000000000000000000000000000
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configAutoReportBatteryTime
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configAutoReportDoorWindowStateTime
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configAutoReportIlluminationTime
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configAutoReportTemperatureTime
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configAutoReportTickInterval
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configBasicSetLevel
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configCustomerFunction
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configIlluminationDifferentialReport
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configLightThreshold
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configMultiSensorFunctionSwitch
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configOperationMode
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configPIRReDetectIntervalTime
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configPIRSensitivity
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configTemperatureDifferentialReport
2016.02.27 21:05:35 2: ZWave get ZWave_GARAGE_DOOR_31 configTurnOffLightTime
2016.02.27 21:06:05 2: ZWave get ZWave_GARAGE_DOOR_31 neighborList
2016.02.27 21:06:05 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2016.02.27 21:06:08 5: ZWDongle_ReadAnswer: select timeout


@Rudi:
Könntest Du das mal bitte anschauen. Bin etwas verunsichert, ob das bei mir systemspezifisch ist, da ich noch ein Problem mit dem WakeUp-Sendstack habe, das ich mir noch anschauen muss.

Gruß, Christian

9zehn75

Zitat von: krikan am 27 Februar 2016, 21:23:39
Habe es mal ausprobiert und vermute, dass das nur bei WakeUp-Geräten auftritt:

Abruf der neigborList bei leerem Wakeup-Sendstack geht. Sobald Befehle im Wakeup-Sendstack stehen, wird der neigborList-Befehl nicht per ZWDongle_Write an das Dongle geschickt. Antwort kommt daher auch nicht und das Ergebnis ist "Timeout reading answer for get neighborList". Das habe ich jetzt mehrfach für 2 WakeUp-Geräte reproduzieren können.

Danke, Christian, dass Du alle Probleme immer so perfekt nachvollziehst. Auch bei mir tritt das nur bei batteriebetriebenen Geräten auf und ich konnte es gerade nochmals wieder reproduziren, allerdings noch immer ohne Log.
VG, 9zehn75

FHEM seit 02.02.2016: Raspberry Pi 2, ZME_UZB1, Fibaro WallPlugs, Fibaro Fenstersensoren, Aeon Indoor Sirene, Greenwave WallPlugs, Qubino Dimmer

krikan

Zitat von: krikan am 27 Februar 2016, 21:23:39
Sobald Befehle im Wakeup-Sendstack stehen, wird der neigborList-Befehl nicht per ZWDongle_Write an das Dongle geschickt. Antwort kommt daher auch nicht und das Ergebnis ist "Timeout reading answer for get neighborList".
Ergänzung: Der neigborList-Befehl wird, sobald der Wakeup-Sendstack Befehle enthält, in den Wakeup-Sendstack geschrieben.

rudolfkoenig

Habs gefixt.
neighborList wird jetzt separat behandelt, und nicht mehr wie ein "normales" Kommando. Wenn ich was dabei vergessen habe, bitte melden. Aus technischer Sicht war es keine gute Idee neighborList vom ZWDongle Befehl zum ZWave Befehl zu machen, ich lasse es aber erstmal so.

krikan

Danke, neigborList kommt jetzt.
Nach Austausch der beiden geänderten Dateien, erhalte ich aber folgende Perl Warning beim Aufruf der Device-Detailseite:
2016.02.28 10:57:12 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/10_ZWave.pm line 775.
2016.02.28 10:57:12 3: stacktrace:
2016.02.28 10:57:12 3:     main::__ANON__                      called by ./FHEM/10_ZWave.pm (769)
2016.02.28 10:57:12 3:     main::ZWave_Cmd                     called by ./FHEM/10_ZWave.pm (922)
2016.02.28 10:57:12 3:     main::ZWave_SCmd                    called by ./FHEM/10_ZWave.pm (927)
2016.02.28 10:57:12 3:     main::ZWave_Get                     called by fhem.pl (3147)
2016.02.28 10:57:12 3:     main::CallFn                        called by fhem.pl (1638)
2016.02.28 10:57:12 3:     main::CommandGet                    called by fhem.pl (2324)
2016.02.28 10:57:12 3:     main::getAllGets                    called by ./FHEM/01_FHEMWEB.pm (1191)
2016.02.28 10:57:12 3:     main::FW_doDetail                   called by ./FHEM/01_FHEMWEB.pm (898)
2016.02.28 10:57:12 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (446)
2016.02.28 10:57:12 3:     main::FW_Read                       called by fhem.pl (3147)
2016.02.28 10:57:12 3:     main::CallFn                        called by fhem.pl (654)


Wenn neigborList beim ZWave-Device stört, dann nimm es einfach raus. Bei ZWDongle ist es als Befehl dann immer noch vorhanden.

rudolfkoenig


MarkusAutomaticus

Hallo zusammen,

meine Erfahrungen mit batteriebetriebenen z-wave Sensoren sind auch ziemlich durchwachsen.

Während der Fibaro Bewegungsmelder (,,Das Auge") im Eingangsbereich reibungslos funktioniert,
Ist der Fibaro Door-Sensor 2,5m gegenüber äußerst unzuverlässig.
Aktuell zeigt er z.B.nur ,,closed" an (Ohne vorheriges open!)

Am Carport habe ich gestern einen Everspring Bewegungsmelder-Z-Wave (EVR_SP103) angebracht, aber bekomme
das Teil auch nach mehrfachem In- und Exkludieren nicht ans Laufen, während die Popp z-Wave Wetterstation
Mit autarker Energiegewinnung wider Erwarten wie am Schnürchen läuft und brav ihre Daten abliefert.

Der formschöne Fibaro Rauch- und Temperaturmelder liegt seit Tagen untätig auf dem Schreibtisch,
weil sich auch hier kein Gefühl der Zuverlässigkeit einstellt. Ich bekomme z.B. keinen Probealarm ausgelöst.
Die LED macht nur ein paar bunte Lichtspiele, wenn ich auf den Taster drücke.

Dass ich als ,,Chef von der Anlage" darauf warten muss, bis ein simpler Sensor ,,aufwacht" geht mir im Übrigen ziemlich gegen den Strich ;)

Alles in Allem habe ich den Eindruck, dass z-Wave eine nette Spielerei, wie etwa eine Modelleisenbahn, ist, aber mein Vertrauen in die Technik
reicht irgendwie nicht weit genug, um dem System mein Leben oder mein Hab- und Gut anzuvertrauen.

Angesichts der Summen, die ich bisher schon investiert habe, lasse ich mich aber liebend gerne eines Besseren belehren.
Als Anfänger mache ich möglicherweise auch etwas Grundsätzliches falsch?!

Soviel ich bisher mitbekommen habe, lässt sich mit ,,verbose 5" das Logging vertiefen.
Kann man sonst noch etwas tun, um die Dinger zu analysieren?
Was einer zügigen Untersuchung sicherlich nicht zuträglich ist, ist die Schlaferei.

Wenn man nach Absetzen eines set ... ständig die Antwort bekommt ,,Scheduled for sending after WAKEUP",
dann trägt das sicherlich nicht einem zügigen Arbeitsfluss bei.

Bei obigem EVR_SP103 schicke ich seit Tagen ,,set Bewegungsmelder wakeupinterval 3600 1" um ihn wenigstens zu einem stündlichen Aufwachen zu bewegen.
Bekomme bei den Readings trotzdem ,,state wakeupInterval 86400 1" und das letzte Reading ist auch noch ein Tag alt.

Aber was mich noch mehr stört, ist, dass das Teil seiner eigentlichen Aufgabe nicht nachkommt und mir sagt, wenn jemand durch den Erfassungsbereich läuft.

Ein simpler Baumarktbewegungsmelder ist für unter 10€ zu bekommen, ist ruckzuck montiert und tut dann jahrelang zuverlässig seinen Dienst.
Das z-wave-Teil kostet das fünffache, muss aufwendig konfiguriert werden und tut dann letztlich doch nicht, oder zumindest nicht zuverlässig.

Bin ich der Einzige, den das nervt?

Gruß
Markus
FHEM 5.8 |intel NUC Core i3: Ubuntu 22.04 | z-Wave: Aeon Labs USB Stick | Jeelink (v3c): LaCrosse-Sensoren | DuoFern Stick: Rademacher Gurtwickler | Philips Hue Bridge | CUNX: HomeMatic, EnOcean-Pigator

marvin78

Kurz: Bei den meisten batteriebetriebenen Z-Wave Geräten reicht ein einfacher Tastendruck, um sie aufzuwecken. Die Fibaro Rauchmelder können das, der Popp Windsensor auch und bisher hatte ich noch kein Gerät, dass das nicht schafft. Warten ist keine Oprion. Auch der Probealarm bei den Rauchmeldern ist kein Problem.

alpha1974

Die Konfiguration der Wakeup-Devices ist halt am Anfang etwas mühseliger, weil man das Device für jeden Parameter, den man "sofort" ausprobieren möchte, aufwecken muss (= Button drücken). Alternative: Wakeup-Intervall im Rahmen der Erstinstallation auf einen Wert setzen, der dem eigenen Empfinden von "ganz kurz" entspricht. Dann alles nach Gusto konfigurieren und wenn das Device macht, was es soll, das Wakeup-Intervall wieder hochsetzen. Wenn man dann etwas vergessen hat, entweder abwarten oder notfalls Wakeup-Button drücken.

Was den Vergleich mit den Baumarkt-Bewegungsmeldern angeht: Mir ist noch keiner für 10,- EUR untergekommen, der vergleichbare (und mit meinem Gesamtsystem kompatible) Funktionen mitbringt.
FHEM/Z-Wave USB-Dongle + div. Devices

krikan

Hallo Markus!
Hast Du denn die Hinweise aus Deinem Thema https://forum.fhem.de/index.php/topic,54680.0.html berücksichtigt. Von netzbetriebenen Router lese ich hier noch nichts. Dann wundern mich Deine Probleme nicht. Baue eine ausreichende Zahl Router ein.
Die technischen Unterschiede hinsichtlich Reichweite und Co. zwischen Zwave+, Zwave (SDK 4.5, 5.x) sind Dir klar? Der Everspring hat mWn nach das uralte SDK 5 und ansonsten solltest in den Foren nach dem Teil suchen. Diese Dinge musst Du berücksichtigen.
Oder kurz: Zwave braucht mMn intensivere Einarbeitung als andere Systeme,  sonst ist Enttäuschung leider vorprogrammiert.
Gruß, Christian

MarkusAutomaticus

Hallo Christian,

danke für deine Antwort.
Ich weiß, du kümmerst dich um die z-wave Thematik bei fhem.
Bitte meinen Post nicht als Kritik an deiner Arbeit verstehen.

Ich denke, die Probleme sind eher der Vielfalt der Hersteller und Geräte geschuldet, die es bei z-Wave gibt.

Ich habe eine Fibaro Zwischensteckdose neben dem Eingangsbereich und eine Aeotec Sirene im Wohnzimmer.
Beide sind jeweils in den Neighbor-Listen und dürften als Router fungieren.

Für den Carport habe ich vorhin den Fibaro Unterputzdosen-Doppelschalter bestellt, sodass dann auch im Außenbereich ein Repeater vorhanden ist.

Du siehst, ich gebe z-wave nicht auf ;) Wenn es funktioniert, ist es genial.

Gruß
Markus
FHEM 5.8 |intel NUC Core i3: Ubuntu 22.04 | z-Wave: Aeon Labs USB Stick | Jeelink (v3c): LaCrosse-Sensoren | DuoFern Stick: Rademacher Gurtwickler | Philips Hue Bridge | CUNX: HomeMatic, EnOcean-Pigator

krikan

Hallo Markus!

Es ging bei meinem Beitrag nicht um meine Befindlichkeiten :-) , sondern um Hinweise die Dir evtl. Suchansätze liefern. Wenn es anders rüberkommt habe ich schlecht formuliert. ZWave ist mMn eben recht komplex und man kann kräftig auf die Nase fallen, wenn Hintergrundinfos fehlen. Bin mal gespannt, ob Deine Routeranzahl reicht.

Zwave ist übrigens eines von Rudis FHEM "Kindern". Ihm gehört die Ehre. ich produziere als bekennender Nicht-Developer im Wesentlichen nur Text. Und Zwave kannst Du kritisieren; bin damit nicht verbandelt. Zur Info: Mein Hauptsystem ist EnOcean. ;-)

Gruß, Christian