Fibaro Wall plug Messfunktion energy

[Nobbynews]

Guten Morgen zusammen,

ich habe hier in Ergänzung div. ShellyPlug/Plug S auch einen Fibaro Wall Plug Gen5 am Start.
Soweit erst einmal alles OK.

Beim Erfassen des Energieverbrauches vom TV ist mir jedoch aufgefallen, dass immer mal wieder für mich nicht erklärbare Sprünge im gemessenen Energieverbrauch auftreten. Zunächst hatte ich mein UserReading in Verdacht.

Code: [Auswählen]

attr ZWave_1 userReadings energyTotal:energy:.* monotonic { ReadingsNum($name,'energy',0)}
Das erwies sich allerdings als falsch. Zusätzlich zum UserReading habe ich dann mal die Datenquelle geloggt mit folgendem Ergebnis:

Code: [Auswählen]

2021-05-01_13:22:14 ZWave_1 energy: 3 kWh
2021-05-01_13:27:13 ZWave_1 energy: 3 kWh
2021-05-01_13:30:38 ZWave_1 energy: 3.01 kWh
2021-05-01_13:35:37 ZWave_1 energy: 3.01 kWh
2021-05-01_13:39:02 ZWave_1 energy: 3.02 kWh
2021-05-01_13:44:01 ZWave_1 energy: 3.02 kWh
2021-05-01_13:46:14 ZWave_1 energy: 10529.75 kWh
2021-05-01_13:51:13 ZWave_1 energy: 3.03 kWh
2021-05-01_13:54:38 ZWave_1 energy: 3.04 kWh
2021-05-01_14:03:02 ZWave_1 energy: 3.05 kWh
2021-05-01_14:36:02 ZWave_1 energy: 3.09 kWh
2021-05-01_14:41:01 ZWave_1 energy: 3.09 kWh
Kein Wunder also, warum das UserReading ab 13:46:14 Müll anzeigt.
Die Messwerte für power in diesem Zeitraum sind unauffällig.

Code: [Auswählen]

2021-05-01_13:24:22 ZWave_1 power: 70.0 W
2021-05-01_13:27:06 ZWave_1 power: 77.2 W
2021-05-01_13:32:06 ZWave_1 power: 74.0 W
2021-05-01_13:33:13 ZWave_1 power: 66.5 W
2021-05-01_13:34:16 ZWave_1 power: 59.6 W
2021-05-01_13:34:55 ZWave_1 power: 65.9 W
2021-05-01_13:36:00 ZWave_1 power: 72.9 W
2021-05-01_13:36:30 ZWave_1 power: 60.4 W
2021-05-01_13:36:32 ZWave_1 power: 75.6 W
2021-05-01_13:36:33 ZWave_1 power: 84.2 W
2021-05-01_13:37:26 ZWave_1 power: 75.4 W
2021-05-01_13:38:21 ZWave_1 power: 83.0 W
2021-05-01_13:38:51 ZWave_1 power: 74.2 W
2021-05-01_13:39:39 ZWave_1 power: 82.3 W
2021-05-01_13:44:39 ZWave_1 power: 78.4 W
2021-05-01_13:45:39 ZWave_1 power: 70.4 W
2021-05-01_13:50:39 ZWave_1 power: 73.7 W
2021-05-01_13:52:11 ZWave_1 power: 66.2 W
Was mich allerdings sehr verwundert, ist die Tatsache, dass im Fibaro selbst auch nach diesem Ausreißer noch der richtige Werte gespeichert ist und weiter verwendet wird.

Ich kann mir es nur so erklären, dass bei der Übertragung bzw. bei der Auswertung durch das Modul da etwas schief läuft.
Hat jemand hierzu eine Idee zur weiteren Ursachenforschung?
Hier dann noch ein List vom device:

Code: [Auswählen]

Internals:
   DEF        d246e259 13
   FUUID      5ffa9b85-f33f-8873-a3b5-3e6a7cf6397e517d
   FVERSION   10_ZWave.pm:0.237270/2021-02-12
   IODev      ZWave
   LASTInputDev ZWave
   MSGCNT     1588
   NAME       ZWave_1
   NR         559
   STATE      configStandardPowerLoadReporting 10
   TYPE       ZWave
   ZWaveSubDevice no
   ZWave_MSGCNT 1588
   ZWave_RAWMSG 0004000d0631050422029bbe00
   ZWave_TIME 2021-05-02 05:50:10
   homeId     d246e259
   isWakeUp   
   nodeIdHex  0d
   OLDREADINGS:
   READINGS:
     2021-04-24 10:32:02   DOffset         0
     2021-05-01 23:59:00   DTage           7
     2021-05-02 05:34:42   Gesamtverbrauch 3.42
     2021-05-01 08:01:00   IODev           ZWave
     2021-05-02 05:33:21   VDurchschnitt   0.48
     2021-05-02 05:34:04   Verbrauch       0.96
     2021-05-01 23:59:00   Verbrauch_gestern 2.45
     2021-05-01 07:02:43   assocGroup_1    Max 1 Nodes ZWave
     2021-05-01 07:02:44   assocGroup_2    Max 10 Nodes
     2021-05-01 07:02:44   assocGroup_3    Max 10 Nodes
     2021-05-01 07:02:43   assocGroups     3
     2021-01-10 07:15:46   associationAdd  1 1
     2021-04-30 16:41:29   configActiveAlarms AllAlarms
     2021-04-30 16:41:29   configAlarmStateDuration 600
     2021-04-30 16:41:29   configAlwaysOnFunction Inactive
     2021-04-30 16:41:29   configAssociationsInZWaveNetwork50 2ndAnd3rdGroupSendAsSecure
     2021-04-30 16:41:29   configControlOfOnOffButtonAssociation20 ControlAsTheWallplug
     2021-04-30 16:41:30   configDOWNValueOnOffPowerAssociation21 300
     2021-01-18 17:18:01   configEnergyReportingThreshold 1
     2021-04-30 16:41:30   configHighPriorityPowerReport 80
     2021-04-30 16:41:30   configLEDRingIlluminationColourAtTheZ43 LEDRingFlashesRedBlueWhite
     2021-04-30 16:41:30   configLEDRingIlluminationColourWhen41 ColourChangesContinuously1
     2021-04-30 16:41:30   configLEDRingIlluminationColourWhen42 illuminationTurnedOffCompletely
     2021-04-30 16:41:30   configMeasuringEnergyConsumedByTheWall15 Inactive
     2021-04-30 16:41:30   configOverloadSafetySwitch 0
     2021-04-30 16:41:30   configPowerAndEnergyPeriodicReports 300
     2021-04-30 16:41:30   configPowerLoadWhichWhenExceededMakes40 25000
     2021-04-30 16:41:30   configPowerReportingInterval 30
     2021-04-30 16:41:30   configRememberDeviceStatusAfterAPower2 WallPlugMemorizesItsStateAfterA1
     2021-04-30 16:41:31   configResponseToAlarmFrames 0
     2021-04-30 16:41:31   configStandardPowerLoadReporting 10
     2021-04-30 16:41:32   configSwitchONValueOnOffAssociation24 255
     2021-04-30 16:41:33   configTheResponseAfterExceedingDefined23 2And3Combined
     2021-01-18 17:18:02   configUPValueOnOffPowerAssociation22 500
     2021-05-02 05:47:59   energy          3.47 kWh
     2021-05-02 05:47:59   energy2         3.47
     2021-05-02 05:47:59   energyTotal     3.46
     2021-01-10 07:22:11   fwMd            fwMdManId: 010f, fwMdFwId_0: 0612, fwMdChkSum_0: 2692, fwMdUpgradeable: ff, fwMdNrTarg: 01, fwMdFrqSize: 0028, fwMdFwId_1: 0612
     2021-04-30 16:43:41   model           FIBARO System FGWPE/F Wall Plug Gen5
     2021-04-30 16:43:41   modelConfig     fibaro/fgwpfzw5.xml
     2021-04-30 16:43:41   modelId         010f-0602-1003
     2021-05-02 00:48:36   neighborList    ZWave HK_Flur
     2021-05-02 05:50:10   power           66.7 W
     2021-01-10 07:24:23   powerlvl        current 0 remain 0
     2021-04-25 06:13:30   reportedState   on
     2021-04-25 11:35:26   state           configStandardPowerLoadReporting 10
     2021-05-01 07:02:44   timeToAck       0.031
     2021-05-01 07:02:44   transmit        OK
     2021-04-04 20:45:07   version         Lib 3 Prot 4.24 App 3.2 HW 2 FWCounter 1 FW 3.2
     2021-01-10 07:15:46   zwavePlusInfo   version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0700 userIcon:0700
Attributes:
   IODev      ZWave
   classes    ZWAVEPLUS_INFO APPLICATION_STATUS ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION CRC_16_ENCAP DEVICE_RESET_LOCALLY FIRMWARE_UPDATE_MD MANUFACTURER_SPECIFIC METER MULTI_CHANNEL_ASSOCIATION ALARM POWERLEVEL SECURITY SENSOR_MULTILEVEL SWITCH_BINARY VERSION
   comment    powerTest:power:.* {ReadingsNum($name,"power",0)},
energyTotal:energy:.* monotonic { ReadingsNum($name,"energy",0)}
   event-on-change-reading power,energy,energy2,energyTotal,VDurchschnitt,Verbrauch
   event-on-update-reading power,energy,energy2,energyTotal,VDurchschnitt,Verbrauch
   room       ZWave
   userReadings energy2:energy:.* {ReadingsNum($name,'energy',0)},
energyTotal:energy2:.* monotonic { ReadingsNum($name,'energy2',0)}
   vclasses   ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 METER:2 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SECURITY:1 SENSOR_MULTILEVEL:5 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2
Schönen Sonntag noch,

Norbert

[rudolfkoenig]

Was mich allerdings sehr verwundert, ist die Tatsache, dass im Fibaro selbst auch nach diesem Ausreißer noch der richtige Werte gespeichert ist und weiter verwendet wird.

Wer ist "Fibaro" genau? Das Geraet selbst? Die FHEM-Instanz?

Wenn das die FHEM-Instanz ist, dann ist es vmtl ein Uebertragungsfehler.
Falls die Uebertragungsrate 9.6 oder 40kb ist, dann wird nur ein Byte Checksum verwendet (== sehr wenig), bei 100kb 2-Byte (16 bit CRC).
Die Datenrate kann man laut Doku mit "set ZWDongle routeFor ZWaveDevice ..." beeinflussen, und die Ergebnisse mit "get ZWDongle routeFor ZWaveDevice" abfragen. Bin unsicher, ob der Dongle das tatsaechlich verwendet.

Mit "attr ZWveDevice useCRC16 1" kann man fuer Geraete mit der Klasse CRC_16_ENCAP die gesendeten Pakete zusaetzlich sichern. Ob die Geraete dann die spontenen Meldungen auch so gesichert schicken, weiss ich nicht, das FHEM Modul kann das aber korrekt auswerten.

[Nobbynews]

Wer ist "Fibaro" genau? Das Geraet selbst? Die FHEM-Instanz?

Na ja, da hier events geloggt werden, müsste es sich ja eigentlich um die neue Meldung (event) des Gerätes selbst handeln.

Code: [Auswählen]

defmod FileLog_ZWave1_energy FileLog /Festplatte/FHEM/log/ZWave_1_eneryg-%Y-%m-%d.log ZWave_1:energy:.*

Die Datenrate kann man laut Doku mit "set ZWDongle routeFor ZWaveDevice ..." beeinflussen, und die Ergebnisse mit "get ZWDongle routeFor ZWaveDevice" abfragen. Bin unsicher, ob der Dongle das tatsaechlich verwendet.

Die Abfrage ergibt für "get ZWDongel routeFor ZWaveDevice" folgendes:

Code: [Auswählen]

ZWave routeFor_ZWave_1 => last at 100kbpsWenn ich über "set ZWDongle routeFor ....." die Datenrate einstellen möchte (wäre für 100kbps als letzer Parameter die Zahl 3) kommt die Meldung, dass 6 Parameter gebaucht werden. Aktuell habe ich aber keine weiteren ZWave-Geräte die als Repeater fungieren könnten und bin mir daher für die Angabe der hob1 bis hob4 nicht im klaren.
Zum Testen habe ich

Code: [Auswählen]

attr ZWave_1 useCRC16 1aktiviert.
Schau´ ich mir mal an.
Danke für die Rückmeldung.

Norbert

[krikan]

Code: [Auswählen]

ZWave routeFor_ZWave_1 => last at 100kbps

Besser geht es mit Deiner Konstellation nicht: direkte Verbindung zwischen Controller und Gerät mit 100kbbs.

Wenn ich über "set ZWDongle routeFor ....." die Datenrate einstellen möchte (wäre für 100kbps als letzer Parameter die Zahl 3) kommt die Meldung, dass 6 Parameter gebaucht werden. Aktuell habe ich aber keine weiteren ZWave-Geräte die als Repeater fungieren könnten und bin mir daher für die Angabe der hob1 bis hob4 nicht im klaren.

Ungenutzte mit 0 angeben. Wie oben geschrieben, ist das aber überflüssig, da es keine bessere Route als Direktverbindung mit 100kbps gibt.

Vor Experimenten mit routeFor würde ich es grds. mit "neighborUpdate" probieren. routeFor bzw. die zugrundeliegende zwapi-Funktion ist mEn mittlerweile als "unerwünscht" markiert.

Gruß, Christian

[rudolfkoenig]

routeFor bzw. die zugrundeliegende zwapi-Funktion ist mEn mittlerweile als "unerwünscht" markiert.

Das hatte ich auch dunkel so in Erinnerung, habe aber keine andere Stelle gefunden, wo die Datenrate gemeldet wird.
Habe ich etwas uebersehen?

[krikan]

Das hatte ich auch dunkel so in Erinnerung, habe aber keine andere Stelle gefunden, wo die Datenrate gemeldet wird.
Habe ich etwas uebersehen?

Die Abfrage mit get-routeFor halte ich "gefühlt" für unkritisch.

Bei passendem SDK des Controllers bekommt man die Datenrate und mehr über die 0013-Rückmeldungen geliefert. Analyse hatte ich mal in https://forum.fhem.de/index.php/topic,79893.msg829426.html#msg829426 als groben Patchentwurf gepostet. Eine entsprechend modifizierte 10_ZWave.pm läuft bei mir seitdem ohne ersichtliche Probleme.

Gruß, Christian

[Nobbynews]

Guten Morgen,

nachdem ich

Code: [Auswählen]

attr ZWave_1 useCRC16 1

aktiviert habe, scheint es jetzt ohne Probleme zu funktionieren.
Zur Kontrolle habe ich mal im ZW-Dongle die Statistik gelöst und jetzt folgende Ausgabe:

Code: [Auswählen]

ZWave statistics => Transmitted:4943 BackOffs:109 ReceivedNoErrors:4748
                    ChecksumErrors:48 CRC16Errors:15 ForeignHomeId:0Die CRC16 Errors habe ich mir bei Abfragen des device eingefangen.

Code: [Auswählen]

2021.05.04 06:35:46 3: ZWave get ZWave_1 configActiveAlarms
2021.05.04 06:35:46 3: ZWave get ZWave_1 configAlarmStateDuration
2021.05.04 06:35:46 3: ZWave get ZWave_1 configAlwaysOnFunction
2021.05.04 06:35:46 3: ZWave get ZWave_1 configAssociationsInZWaveNetwork50
2021.05.04 06:35:46 3: ZWave get ZWave_1 configControlOfOnOffButtonAssociation20
2021.05.04 06:35:46 3: ZWave get ZWave_1 configDOWNValueOnOffPowerAssociation21
2021.05.04 06:35:46 3: ZWave get ZWave_1 configEnergyReportingThreshold
2021.05.04 06:35:46 3: ZWave get ZWave_1 configHighPriorityPowerReport
2021.05.04 06:35:46 3: ZWave get ZWave_1 configLEDRingIlluminationColourAtTheZ43
2021.05.04 06:35:46 3: ZWave get ZWave_1 configLEDRingIlluminationColourWhen41
2021.05.04 06:35:46 3: ZWave get ZWave_1 configLEDRingIlluminationColourWhen42
2021.05.04 06:35:46 3: ZWave get ZWave_1 configMeasuringEnergyConsumedByTheWall15
2021.05.04 06:35:46 3: ZWave get ZWave_1 configOverloadSafetySwitch
2021.05.04 06:35:46 3: ZWave get ZWave_1 configPowerAndEnergyPeriodicReports
2021.05.04 06:35:46 3: ZWave get ZWave_1 configPowerLoadWhichWhenExceededMakes40
2021.05.04 06:35:46 3: ZWave get ZWave_1 configPowerReportingInterval
2021.05.04 06:35:46 3: ZWave get ZWave_1 configRememberDeviceStatusAfterAPower2
2021.05.04 06:35:46 3: ZWave get ZWave_1 configResponseToAlarmFrames
2021.05.04 06:35:46 3: ZWave get ZWave_1 configStandardPowerLoadReporting
2021.05.04 06:35:46 3: ZWave get ZWave_1 configSwitchONValueOnOffAssociation24
2021.05.04 06:35:46 3: ZWave get ZWave_1 configTheResponseAfterExceedingDefined23
2021.05.04 06:35:46 3: ZWave get ZWave_1 configUPValueOnOffPowerAssociation22
2021.05.04 06:35:48 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d0756017005153AA4258aee
2021.05.04 06:35:49 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d07560170050dA99D258b5d
2021.05.04 06:35:50 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d07560170050aD97A258cca
2021.05.04 06:35:51 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d07560170052bED39258d9d
2021.05.04 06:35:52 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d075601700529CD7B258efe
2021.05.04 06:35:53 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d07560170052aFD18258faf
2021.05.04 06:35:54 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d0756017005034853259166
2021.05.04 06:35:55 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d07560170050e99FE259214
2021.05.04 06:35:56 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d075601700528DD5A2593d3
2021.05.04 06:35:57 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d07560170050cB9BC259472
2021.05.04 06:35:59 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d0756017005025872259552
2021.05.04 06:36:00 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d07560170051f9BEE259613
2021.05.04 06:36:01 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d07560170050bC95B2597e1
2021.05.04 06:36:02 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d075601700518EB0925988d
2021.05.04 06:36:03 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d0756017005171AE625999d
2021.05.04 06:36:03 2: ZWDongle_ProcessSendStack: no ACK, resending message 010e00130d0756017005160AC7259aaeDie anderen CRC-Fehler kommen wohl von den Eurotronic Spirit bzw. Aeotec. Bei Abfrage von 'get routeFor' erhalte ich nämlich bei alle 4 devices nur

Code: [Auswählen]

ZWave routeFor_HK_Kueche => last at 40kbpsund da jeweils die Class CRC_16_ENCAP nicht unterstützt wird entfällt auch das Attribut useCRC16.

Die Standorte vom Fibaro und auch vom ZW-Dongel dürften daher alles andere als optimal sein.

Norbert

[krikan]

Die anderen CRC-Fehler kommen wohl von den Eurotronic Spirit bzw. Aeotec.

Das Spirit ist ein FLIRS-Geräte. Nach meiner (schwachen) Erinnerung unterstützten FLiRS-Geräte nur maximal 40kbps und somit keine 100kbps. Leider finde ich die Quelle dazu bei Sigma gerade nicht. Irritierend ist, dass die Antwort auf "get <ZWdongle> nodeinfo <SpiritdezNodeId>" die Info auf 100kbps speedExtension liefert. 

Gruß, Christian

[rudolfkoenig]

Nach meiner (schwachen) Erinnerung unterstützten FLiRS-Geräte nur maximal 40kbps und somit keine 100kbps.

Diese Entscheidung wuerde mich wundern: 100k Nachrichten sind deutlich kuerzer als die langsameren, es spart also Batterie.

[Nobbynews]

Das Spirit ist ein FLIRS-Geräte. Nach meiner (schwachen) Erinnerung unterstützten FLiRS-Geräte nur maximal 40kbps und somit keine 100kbps. Leider finde ich die Quelle dazu bei Sigma gerade nicht. Irritierend ist, dass die Antwort auf "get <ZWdongle> nodeinfo <SpiritdezNodeId>" die Info auf 100kbps speedExtension liefert. 

Der Spirit liefert bei mir mit get routefor

Code: [Auswählen]

ZWave routeFor_HK_Flur => last at 40kbpsund mit get ZW-Dongel  nodeInfo

Code: [Auswählen]

ZWave nodeInfo_HK_Flur => ProtocolVers:SDK4.5x+6.0x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap FrequentListen1000ms OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:THERMOSTAT SpecificDevClass:06
Norbert

[krikan]

Diese Entscheidung wuerde mich wundern: 100k Nachrichten sind deutlich kuerzer als die langsameren, es spart also Batterie.

Habe eine halbe Stunde erfolglos gesucht und bin dann auf Experimente mit einem Spirit umgestiegen.

Habe mit set-routeFor eine Direktkommunikation des Spirit mit dem Controller per 100 kbps erzwungen (per neigborUpdate funktionierte das trotz Abstand von ca. 2m nicht):
Bei einem Befehl mit einem Funktelegramm an das Spirit bekomme ich dann über Callback-Analyse die Info:

Code: [Auswählen]

timeToCb:1.27 repeaters:0 rssi0:-54 dBm ackCh:0 lastCh:1 scheme:LastWorkingRoute rep:at 100kbps routeTries:4 lastFailed:Die 100kbps werden demnach tatsächlich genutzt; es werden aber 4 routeTries benötigt.
Der anschließende Befehl get-routeFor liefert jedoch zurück:

Code: [Auswählen]

application at 40kbps
Bei mehreren hintereinander abgesetzten Funktelegrammen (bspw. per get-configAll) ist laut Callback-Analyse der Ablauf:

Code: [Auswählen]

timeToCb:1.27 repeaters:0 rssi0:-54 dBm ackCh:0 lastCh:1 scheme:LastWorkingRoute rep:at 100kbps routeTries:4 lastFailed:
timeToCb:0.03 repeaters:0 rssi0:-54 dBm ackCh:0 lastCh:1 scheme:LastWorkingRoute rep:at 40kbps routeTries:1 lastFailed:Der erste Befehl erfolgt immer mit 100kbps; alle weiteren mit 40kbps.
Der anschließende Befehl get-routeFor liefert zurück:

Code: [Auswählen]

application at 40kbpsWarte ich einige Sekunden und schicke dann einen neuen Befehl, so erfolgt der erste wieder mit 100kbps.

Also funktioniert nach dem Callback tatsächlich eine 100kbps-Verbindung bei FLIRS-Geräten. Das Heruntergehen bei direkt folgenden Telegrammen auf 40kbps kann ich anhand 4 routeTries grundsätzlich verstehen. Mir ist nur unklar, warum anschließend nach Pause wieder mit 100kbps verschickt wird. Merkwürdig ist auch, dass get-routeFor bei 40 kbps bleibt. Das alte Verhalten mit nur 40kbps-Nachrichten wie vor set-RouteFor bekomme ich auch mit erneutem routeFor auf 40 kpbs nicht wieder hergestellt; es bleibt derzeit immer bei 100kbps beim ersten Funktelegramm. Was hier der Einfluß des "unerwünschten" set-routeFor-Befehls ist, kann ich nicht feststellen.

[rudolfkoenig]

Analyse hatte ich mal in https://forum.fhem.de/index.php/topic,79893.msg829426.html#msg829426 als groben Patchentwurf gepostet.

Kannst Du mir ein paar Roh-Daten aus dem "attr ZWDongl verbose 4" Log leifern, damit ich nach dem Einbau die Funktionalitaet pruefen kann?

[krikan]

Kannst Du mir ein paar Roh-Daten aus dem "attr ZWDongl verbose 4" Log leifern, damit ich nach dem Einbau die Funktionalitaet pruefen kann?

Hängt an. Die ersten beiden geloggten Geräte sind ZWavePlus und können 100kbps und nutzen normalerweise Direktkommunikation mit dem Controller. Das 3. geloggte Geräte ist Zwave ohne Plus und kann daher nur 40 kbps und wird regelmäßig über Repeater angesprochen.

Abweichend vom Patchentwurf lasse ich mittlerweile Events erzeugen statt nur zu loggen. Per notify wird ein "neigborUpdate" abgesetzt, wenn ein Gerät auf 9.6 kbps heruntertakte. Habe ein Gerät, das in ungleichmäßigen Abständen auf 9.6 kbps geht und sich nicht von selbst erholt, sondern nur per neigborUpdate. Bei anderen Geräten konnte ich das nicht feststellen. Ob das sinnvoll ist: ?

Gruß, Christian

PS: Der loggende UZB1 hat Firmware 5.27


edit: Anhang war falsch; korrekte Fassung angehängt.

[krikan]

@Rudi: Anhang war falsch. Richtige Fassung (= Log) jetzt oben angehängt (ausgetauscht).

[rudolfkoenig]

Hab dein Patch eingebaut, mit den Daten aus dem Log kurz getestet und eingecheckt.