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 Erweitern

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 Erweitern

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 Erweitern

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 Erweitern

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 Erweitern

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 Erweitern

ZWave routeFor_ZWave_1 => last at 100kbps
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.
Zum Testen habe ich

Code Auswählen Erweitern

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

Norbert

[krikan]

Code Auswählen Erweitern

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 Erweitern

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 Erweitern

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

Code Auswählen Erweitern

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 010e00130d0756017005160AC7259aae
Die 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 Erweitern

ZWave routeFor_HK_Kueche => last at 40kbps
und 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 Erweitern

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

Code Auswählen Erweitern

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 Erweitern

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 Erweitern

application at 40kbps

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

Code Auswählen Erweitern

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 Erweitern

application at 40kbps
Warte 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.

[krikan]

Hallo Rudi,

stacktrace liefert:

Code Auswählen Erweitern

2021.05.08 14:18:15.027 1: PERL WARNING: Use of uninitialized value $i in concatenation (.) or string at ./FHEM/10_ZWave.pm line 4885.
2021.05.08 14:18:15.027 1: stacktrace:
2021.05.08 14:18:15.027 1:     main::__ANON__                      called by ./FHEM/10_ZWave.pm (4885)
2021.05.08 14:18:15.027 1:     main::ZWAVE_parseRouteInfo          called by ./FHEM/10_ZWave.pm (5160)
2021.05.08 14:18:15.027 1:     main::ZWave_Parse                   called by fhem.pl (4083)
2021.05.08 14:18:15.028 1:     main::Dispatch                      called by ./FHEM/00_ZWDongle.pm (982)
2021.05.08 14:18:15.028 1:     main::ZWDongle_Parse                called by ./FHEM/00_ZWDongle.pm (877)
2021.05.08 14:18:15.028 1:     main::ZWDongle_Read                 called by fhem.pl (3887)
2021.05.08 14:18:15.028 1:     main::CallFn                        called by fhem.pl (773)
Wenn ich in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_ZWave.pm?rev=24394#L4874 wieder "my $i=0;" setze ist das weg.

Kannst Du https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_ZWave.pm?rev=24394#L4905 bitte ändern in

Code Auswählen Erweitern

if($f =~ m/[123]/);
Dann wird bei Direktverbindungen zwischen Controller und Gerät die Baudrate auch ausgegeben.

Patch für weitergehende Aufschlüsselung der Routeninfo versuche ich kurzfristig zu liefern.

Gruß, Christian

[rudolfkoenig]

Habe die Aenderungen eingebaut. Komisch, dass ich mit meinem Test

Code Auswählen Erweitern

{ Dispatch($defs{zwd}, "00130100000f01e07f7f7f7f0000030800000003010000", undef) }
keine Warnungen bekommen habe. Vmtl. habe ich mit den falschen Nachrichten getestet.

[krikan]

Anhängend routeInfo-Patch in dem einige Kleinigkeiten ergänzt sind. Ich hatte doch schon mehr zum damaligen Entwurf geändert als ich in Erinnerung hatte.

Besonderheit, die ich nicht in den Griff bekommen habe:
Eventgenerierung hatte ich mit DoTrigger eingebaut. Mit readingsSingleUpdate ($hash, x,x,1) wurden/werden bei mir -auch in Deiner Fassung- keine Events generiert. Darum ist Dotrigger auch im Patch eingebaut. Grund verstehe/finde ich nicht (event-on-* Attribute sind nicht gesetzt.). Log3 muss ich auch mit $ioname aufrufen; mit $hash wird nichts geloggt.

Hatte die Eventgenerierung per Attribut am ZWave-Device steuerbar gemacht. Das habe ich hier auch übernommen. Ob überhaupt sinnvoll oder bspw. Attribut an ZWDongle-Device besser ist, bin ich unsicher.

An einer minimalistischen Doku werde ich noch arbeiten. Wird aber dauern.

Gruß, Christian

[ToKa]

Hallo,

das klingt spannend und gut. Vor allem würde mich interessieren, wie das mit den Events funktioniert, wenn ein Gerät nur noch 9.6 benutzt, um dann auch ein neighborUpdate anzustoßen.

VG
Torsten

[rudolfkoenig]

Hab den Patch eingecheckt.

[krikan]

Hab den Patch eingecheckt.

Du hast gleichzeitig eine FHEMWEB-Änderung eingecheckt, die nicht von mir stammt. Wenn das beabsichtigt war, dann ist das ok.

Vor allem würde mich interessieren, wie das mit den Events funktioniert, wenn ein Gerät nur noch 9.6 benutzt, um dann auch ein neighborUpdate anzustoßen.

Ab morgigen Update:
Aktivierung der Eventgenerierung pro ZWave-Device mit:

Code Auswählen Erweitern

attr <device> generateRouteInfoEvents 1

Nach der Aktivierung wird bei Befehlen von FHEM an das Gerät aus der Callback-Nachricht ein Event generiert der mMn hinsichtlich der Baudrate selbsterklärend ist. Darauf dann mit einem notify/DOIF/.. reagieren.

Voraussetzung ist ein Controller mit aktuellem SDK. Habe es mit einem UZB mit Firmware 5.27 getestet. Sollte es bei neueren Firmwareversionen nicht funktionieren, bräuchte ich ein kurzes verbose 5 Log von einem Befehl mit Rückantwort.

[rudolfkoenig]

Wenn das beabsichtigt war, dann ist das ok.

Ja, war etwas faul. Die FHEMWEB Aenderung beinhaltet nur Leerzeichen wg. Lesbarkeit.

[krikan]

Anhängend kurzer commandref-Vorschlag. Eventaufbau habe ich nicht dokumentiert; war mir zu lang. Wenn Du ihn dennoch gerne hättest. liefere ich den nach.
Habe gleichzeitig die Links zu den ZWave Specs korrigiert.

[Nobbynews]

Guten Morgen,

nachdem ich hier den Thread ja losgetreten habe, wollte ich mit einem Test dazu beitragen.
Aber irgendwie klappt das nicht. Nach dem Update habe ich an meinem Wallplug

Code Auswählen Erweitern

attr ZWave_1 generateRouteInfoEvents 1
entsprechend konfiguriert.
Ich kann aber machen was ich will, im Log habe ich keinen neuen Eintrag.

Voraussetzung ist ein Controller mit aktuellem SDK. Habe es mit einem UZB mit Firmware 5.27 getestet. Sollte es bei neueren Firmwareversionen nicht funktionieren, bräuchte ich ein kurzes verbose 5 Log von einem Befehl mit Rückantwort.

Hier ein List vom UZB1:

Code Auswählen Erweitern

Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/serial/by-id/usb-0658_0200-if00@115200
   DeviceName /dev/serial/by-id/usb-0658_0200-if00@115200
   FD         152
   FUUID      5f89a146-f33f-8873-47be-133bd37c462e236a
   FVERSION   00_ZWDongle.pm:0.237270/2021-02-12
   MaxSendRetries 3
   NAME       ZWave
   NR         515
   PARTIAL   
   RAWMSG     0004000d0a32022144000002fa0000b500
   ReadTime   1620885413.06367
   STATE      Initialized
   SendRetries 0
   SendTime   1620885076.28227
   TYPE       ZWDongle
   WaitForAck 0
   ZWave_MSGCNT 138
   ZWave_TIME 2021-05-13 07:56:53
   homeId     d246e259
   nodeIdHex  01
   nrNAck     0
   setReadingOnAck 1
   showSetInState 1
   MatchList:
     1:ZWave    .*
   READINGS:
     2021-05-09 08:55:16   backgroundRSSI  ch1:-83 dBm ch2:-83 dBm
     2021-05-13 07:29:51   caps            Vers:5 Rev:37 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a SERIAL_API_SETUP ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET ZW_NVR_GET_VALUE NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE UNKNOWN_2e ZW_CLEAR_TX_TIMERS ZW_GET_TX_TIMERS CLEAR_NETWORK_STATS GET_NETWORK_STATS GET_BACKGROUND_RSSI REMOVE_NODEID_FROM_NETWORK ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_ASSIGN_PRIORITY_RETURN_ROUTE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_ASSIGN_PRIORITY_SUC_RETURN_ROUTE ZW_EXPLORE_REQUEST_INCLUSION ZW_EXPLORE_REQUEST_EXCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 ZW_FIRMWARE_UPDATE_NVM GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS ZW_SET_PROMISCUOUS_MODE PROMISCUOUS_COMMAND_HANDLER WATCHDOG_START WATCHDOG_STOP ZW_SET_ROUTING_MAX UNKNOWN_ee UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH ZME_CAPABILITIES UNKNOWN_f7 UNKNOWN_f8
     2021-05-13 07:29:51   ctrlCaps        PRIMARY
     2021-05-13 07:29:51   homeId          HomeId:d246e259 CtrlNodeIdHex:01
     2021-01-14 15:58:46   isFailedNode_1  no
     2020-12-24 09:29:28   isFailedNode_11 yes
     2021-01-14 15:58:51   isFailedNode_14 no
     2021-01-31 06:57:30   isFailedNode_16 yes
     2020-12-26 07:32:04   neighborList_10 ZWave HK_Flur HK_Kueche
     2020-12-26 07:31:21   neighborList_12 ZWave HK_Flur HK_Kueche
     2020-12-26 07:31:32   neighborList_2  empty
     2021-05-10 07:02:09   neighborList_HK_Flur ZWave HK_Keller ZWave_1 HK_Kueche HK_GaesteWC
     2021-05-10 07:02:25   neighborList_HK_GaesteWC ZWave HK_Flur ZWave_1 HK_Kueche
     2021-05-10 07:02:34   neighborList_HK_Keller ZWave HK_Flur ZWave_1
     2021-05-10 07:02:16   neighborList_HK_Kueche ZWave HK_Flur ZWave_1 HK_GaesteWC
     2021-05-10 11:13:40   neighborList_ZWave HK_Flur HK_Keller Fenster_Kueche HK_Kueche HK_GaesteWC
     2021-05-10 11:19:39   neighborList_ZWave_1 ZWave HK_Flur HK_Keller HK_Kueche HK_GaesteWC
     2020-12-26 07:29:43   nodeInfo_1      ProtocolVers:SDK4.5x+6.0x listening routing maxBaud:40kbps Controller SpecificDev BeamCap SpeedExt:100kbps RoleType:N/A BasicDevClass:STATIC_CONTROLLER GenericDevClass:STATIC_CONTROLLER SpecificDevClass:01
     2020-12-26 07:29:51   nodeInfo_12     ProtocolVers:SDK4.5x+6.0x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:SENSOR_NOTIFICATION SpecificDevClass:01
     2021-05-06 13:09:06   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
     2021-05-10 07:01:27   nodeInfo_ZWave_1 ProtocolVers:SDK4.5x+6.0x listening routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc SpeedExt:100kbps RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:SWITCH_BINARY SpecificDevClass:01
     2021-05-10 07:01:15   nodeList        ZWave HK_Flur HK_Keller Fenster_Kueche ZWave_1 HK_Kueche HK_GaesteWC
     2021-05-13 07:29:51   random          b961e61b658ff71f257739a844552dcc19e09edcfded4e33c4f945fa071db67c
     2021-05-06 13:06:55   routeFor_HK_Flur last at 40kbps
     2021-05-02 21:10:44   routeFor_HK_GaesteWC last at 40kbps
     2021-05-02 21:10:07   routeFor_HK_Keller last at 40kbps
     2021-05-05 06:53:01   routeFor_HK_Kueche last at 40kbps
     2021-05-13 07:44:43   routeFor_ZWave_1 last at 100kbps
     2021-05-13 07:29:51   state           Initialized
     2021-05-05 06:48:02   statistics      Transmitted:4943 BackOffs:109 ReceivedNoErrors:4748
                    ChecksumErrors:48 CRC16Errors:15 ForeignHomeId:0
     2021-05-13 07:29:51   sucNodeId       no
     2021-05-08 13:06:55   version         Z-Wave 6.02 STATIC_CONTROLLER
   SendStack:
Attributes:
   comment    networkkey e598b089a9ac246011b9a05e1a1ffb67
   homeId     d246e259
   networkKey e598b089a9ac246011b9a05e1a1ffb67
   room       10_I/O-Geräte
   setReadingOnAck 1
   showSetInState 1
   verbose    5

Das Log mit verbose=5 für UZB1 und ZWave_1 sieht u.a. für den Befehl get neighbourList so aus:

Code Auswählen Erweitern

2021.05.13 07:51:10 4: ZWDongle_Read ZWave: rcvd 0004000d0631050422028ab000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2021.05.13 07:51:10 5: SW: 06
2021.05.13 07:51:10 5: ZWave: dispatch 0004000d0631050422028ab000
2021.05.13 07:51:10 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:0631050422028ab000 CB:00
2021.05.13 07:51:16 5: ZWDongle_Write 00800d0100 ()
2021.05.13 07:51:16 5: SW: 010600800d010075
2021.05.13 07:51:16 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2021.05.13 07:51:16 5: ACK received, removing 010600800d010075 from dongle sendstack
2021.05.13 07:51:16 4: ZWDongle_Read ZWave: rcvd 01802142010000000000000000000000000000000000000000000000000000 (answer GET_ROUTING_TABLE_LINE), sending ACK
2021.05.13 07:51:16 5: SW: 06
2021.05.13 07:51:16 4: ZWDongle_ReadAnswer for neighborList: 01802142010000000000000000000000000000000000000000000000000000
2021.05.13 07:52:52 4: ZWDongle_Read ZWave: rcvd 0004000d0a32022144000002f90000b600 (request APPLICATION_COMMAND_HANDLER), sending ACK
2021.05.13 07:52:52 5: SW: 06
2021.05.13 07:52:52 5: ZWave: dispatch 0004000d0a32022144000002f90000b600
2021.05.13 07:52:52 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:0a32022144000002f90000b600 CB:00
2021.05.13 07:55:50 4: ZWDongle_Read ZWave: rcvd 0004000a06310501420791bb00 (request APPLICATION_COMMAND_HANDLER), sending ACK
2021.05.13 07:55:50 5: SW: 06
2021.05.13 07:55:50 5: ZWave: dispatch 0004000a06310501420791bb00
2021.05.13 07:55:50 4: CMD:APPLICATION_COMMAND_HANDLER ID:0a ARG:06310501420791bb00 CB:00
2021.05.13 07:55:59 4: ZWDongle_Read ZWave: rcvd 0004000f0631050142085dca00 (request APPLICATION_COMMAND_HANDLER), sending ACK
2021.05.13 07:55:59 5: SW: 06
2021.05.13 07:55:59 5: ZWave: dispatch 0004000f0631050142085dca00
2021.05.13 07:55:59 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:0631050142085dca00 CB:00
2021.05.13 07:56:10 4: ZWDongle_Read ZWave: rcvd 0004000d063105042202c2b600 (request APPLICATION_COMMAND_HANDLER), sending ACK
2021.05.13 07:56:10 5: SW: 06
2021.05.13 07:56:10 5: ZWave: dispatch 0004000d063105042202c2b600
2021.05.13 07:56:10 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:063105042202c2b600 CB:00
2021.05.13 07:56:53 4: ZWDongle_Read ZWave: rcvd 0004000d0a32022144000002fa0000b500 (request APPLICATION_COMMAND_HANDLER), sending ACK
2021.05.13 07:56:53 5: SW: 06
2021.05.13 07:56:53 5: ZWave: dispatch 0004000d0a32022144000002fa0000b500
2021.05.13 07:56:53 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:0a32022144000002fa0000b500 CB:00

Hier noch ein Log-Auszug für einen der HK-Thermostate:

Code Auswählen Erweitern

2021.05.13 08:03:19 3: ZWave set HK_Kueche desired-temp 22.0
2021.05.13 08:03:19 5: ZWDongle_Write 00130f064301012200dc251f (d246e259)
2021.05.13 08:03:19 5: SW: 010d00130f064301012200dc251f6f
2021.05.13 08:03:19 5: ACK received, WaitForAck=>2 for 010d00130f064301012200dc251f6f
2021.05.13 08:03:19 4: ZWDongle_Read ZWave: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2021.05.13 08:03:19 5: SW: 06
2021.05.13 08:03:19 5: ZWave: dispatch 011301
2021.05.13 08:03:21 4: no response from device, removing 010d00130f064301012200dc251f6f from dongle sendstack
2021.05.13 08:03:22 4: ZWDongle_Read ZWave: rcvd 00131f00016b00ca7f7f7f7f0101030000000042050000 (request ZW_SEND_DATA), sending ACK
2021.05.13 08:03:22 5: SW: 06
2021.05.13 08:03:22 5: ZWave: dispatch 00131f00016b00ca7f7f7f7f0101030000000042050000
2021.05.13 08:03:22 4: CMD:ZW_SEND_DATA ID:00 ARG:016b00ca7f7f7f7f0101030000000042050000 CB:1f
2021.05.13 08:03:22 4: ZWave transmit OK for CB 1f, target HK_Kueche
2021.05.13 08:03:22 5: HK_Kueche: timeToCb:3.63 repeaters:0 rssi0:-54 dBm ackCh:1 lastCh:1 scheme:LastWorkingRoute rep:at 100kbps routeTries:5 lastFailed:
2021.05.13 08:05:17 4: ZWDongle_Read ZWave: rcvd 0004000d0a32022144000002fb0000b800 (request APPLICATION_COMMAND_HANDLER), sending ACK
2021.05.13 08:05:17 5: SW: 06
2021.05.13 08:05:17 5: ZWave: dispatch 0004000d0a32022144000002fb0000b800
2021.05.13 08:05:17 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:0a32022144000002fb0000b800 CB:00

Norbert

[krikan]

Die Informationen zur routeInfo bekommt FHEM nur, wenn der Controller/FHEM Funkbefehle an das ZWave-Gerät verschickt.
Technisch genauer: routeInfo wird aus dem Callback einer ZW_SENDDATA-Nachricht des Controllers/FHEM an das Gerät generiert.

"get neighbourList" ist ein Befehl, der Daten aus dem Controller ausliest. Eine Kommunikation des Controllers mit dem Gerät per ZW_SENDDATA findet nicht statt. Daher kann hier für den ZWave_1 keine routeInfo geliefert werden. Anders sollte das bspw. bei jedem ein- und ausschalten durch FHEM per set sein.

Beim HK-Thermostate wurde die routeInfo auf den set-Befehl gemäß Log geliefert:

Code Auswählen Erweitern


2021.05.13 08:03:22 5: HK_Kueche: timeToCb:3.63 repeaters:0 rssi0:-54 dBm ackCh:1 lastCh:1 scheme:LastWorkingRoute rep:at 100kbps routeTries:5 lastFailed:
= direkte Kommunikation des Controllers mit dem HK_Küche mit 100kbps und 5 routeTries; genutzt wurde die zuletzt funktionierende Route.

Gruß, Christian

[rudolfkoenig]

Anhängend kurzer commandref-Vorschlag.

Da ich die Funktionsweise erst nach deinem letzten Beitrag verstanden habe, habe ich den Text etwas umformuliert.

generateRouteInfoEvents
if set (to 1) a timeToCb event with additional information regarding the controller to device communication is generated, after sending data to the device.
Notes:

• A controller with SDK 6.60 or higher is required. (tested with UZB1/Razberry firmware 5.27)
• 
  Additional Information in Silicon Lab documents: "Appl. Programmers Guide" and "Z-Wave Network Installation and maintenance Procedures User Guide"
• ReadingFnAttributes are not supported for this event.

Wenn es falsch ist, bitte korrigieren.

[krikan]

Wenn es falsch ist, bitte korrigieren.

Falsch würde ich nicht behaupten; nur ungenau.
Grundsätzlich ist das anwenderverständlicher, aber es gibt eben auch Controller-Geräte-Kommunikation, die nicht über ZW_SENDDATA und den routeInfo-liefernden Callback abgewickelt wird (bspw. neighborUpdate). Das mag zwar die Minderheit sein, aber kommt vor. Den technischen Hinweis auf txStatusReport und ZW_SENDDATA hatte ich zudem aufgenommen, damit man (eher ich) mich erinnere, wo die Infos in den genannten Dokumenten von silabs zu finden sind. Die Dokumente sind lang und enthalten die Infos gut verteilt. (Jetzt ist es jedoch auch hier -noch mal- dokumentiert und darum stört es mich nicht.  )

[ToKa]

Kurzes Feedback, bei mir funktioniert es und ich glaube auch schon einen Übeltäter gefunden zu haben, der die Kommunikation auf 9.6 drosselt.

Kann es "schaden" bei alle ZWave Geräten generateRouteInfoEvents zumindest mal für eine Zeit lang zu aktivieren, um alle Werte im Überblick zu haben?

VG
Torsten

[rudolfkoenig]

Damit wird pro passenden Sendevorgang (s.o.) ein zusaetzliches Event generiert.
Das stoert normalerweise nicht, es sei denn irgendwelche Notifies/FileLogs laufen deswegen Amok.

[krikan]

Kann es "schaden" bei alle ZWave Geräten generateRouteInfoEvents zumindest mal für eine Zeit lang zu aktivieren, um alle Werte im Überblick zu haben?

Glaube ich kaum, außer Dein System läuft jetzt schon am Limit. So systembelastend sind Events nicht.
Ich selbst habe das auf einem Raspi 2 mehrere Monate mit Eventgenerierung an allen ZWave-Devices betrieben und nichts Negatives festgestellt. Erst als ich das Problem aus meiner Sicht erkannt hatte (ein Geräte, dass immer heruntertaktet) habe ich die Device-abhängige Begrenzung eingebaut, da mir die vielen Events nicht gefielen.

Gruß, Christian

[krikan]

Ohne die Events kann man die Readings routeInfo aller ZWave-Devices mittels readingsGroup im Blick behalten:

Code Auswählen Erweitern

define ZWaveQuality readingsGroup TYPE=ZWave:routeInfo

[ToKa]

Prima, danke für den Tipp.

[Nobbynews]

"get neighbourList" ist ein Befehl, der Daten aus dem Controller ausliest. Eine Kommunikation des Controllers mit dem Gerät per ZW_SENDDATA findet nicht statt. Daher kann hier für den ZWave_1 keine routeInfo geliefert werden. Anders sollte das bspw. bei jedem ein- und ausschalten durch FHEM per set sein.

Ich war der Meinung, es auch mit einem Schaltbefehl ausprobiert zu haben. War wohl ein Freud'scher Fehler.
Jetzt klappt es.

Code Auswählen Erweitern

2021.05.13 14:05:01 3: ZWave set ZWave_1 on
2021.05.13 14:05:01 5: ZWDongle_Write 00130d0756012501FF1F3A2526 (d246e259)
2021.05.13 14:05:01 5: SW: 010e00130d0756012501FF1F3A252642
2021.05.13 14:05:01 5: ACK received, WaitForAck=>2 for 010e00130d0756012501FF1F3A252642
2021.05.13 14:05:01 4: ZWDongle_Read ZWave: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2021.05.13 14:05:01 5: SW: 06
2021.05.13 14:05:01 5: ZWave: dispatch 011301
2021.05.13 14:05:01 4: ZWDongle_Read ZWave: rcvd 00132600000200be7f7f7f7f0000030000000003010000 (request ZW_SEND_DATA), sending ACK
2021.05.13 14:05:01 5: SW: 06
2021.05.13 14:05:01 5: device ack reveived, removing 010e00130d0756012501FF1F3A252642 from dongle sendstack
2021.05.13 14:05:01 5: ZWave: dispatch 00132600000200be7f7f7f7f0000030000000003010000
2021.05.13 14:05:01 4: CMD:ZW_SEND_DATA ID:00 ARG:000200be7f7f7f7f0000030000000003010000 CB:26
2021.05.13 14:05:01 4: ZWave transmit OK for CB 26, target ZWave_1
2021.05.13 14:05:01 5: ZWave_1: timeToCb:0.02 repeaters:0 rssi0:-66 dBm ackCh:0 lastCh:0 scheme:LastWorkingRoute rep:at 100kbps routeTries:1 lastFailed:
2021.05.13 14:05:01 4: ZWDongle_Read ZWave: rcvd 0004000d032503ffbc00 (request APPLICATION_COMMAND_HANDLER), sending ACK
2021.05.13 14:05:01 5: SW: 06
2021.05.13 14:05:01 5: ZWave: dispatch 0004000d032503ffbc00
2021.05.13 14:05:01 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:032503ffbc00 CB:00

Norbert

[krikan]

2021.05.13 14:05:01 5: ZWave_1: timeToCb:0.02 repeaters:0 rssi0:-66 dBm ackCh:0 lastCh:0 scheme:LastWorkingRoute rep:at 100kbps routeTries:1 lastFailed:

Die Werte sind gut. Erklärung für die Ausreißer in den übermittelten Daten ergibt sich so erst mal nicht. Entweder ist jetzt die Verbindung nicht immer so gut (=100kbps) mit der Folge von Übertragungsfehlern oder Gerät/Firmware liefert ab und an falsche Werte oder ...
Ursache Deines Problems bleibt also leider unklar.

[Nobbynews]

Ursache Deines Problems bleibt also leider unklar.

Ironie des Schicksals, seit dem ist das Problem nicht mehr aufgetreten.
Aber dafür hat man ja jetzt eine ganz gute Übersicht über die Verbindungen.
Danke für die Mühen.

Norbert