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