Readings von Aktoren werden diversen Wakeup Devices zugeordnet

[Deckoffizier]

Hallo,

hoffentlich habe ich jetzt nicht alles zum Thema falsch verstanden.

Habe auch schon mal öfter gesehen das Readings logischer Weise nicht zu den Geräten passen.
Unter anderen aktuell mal ein List von einer Steckdose mit Reading             setpointTemp 20.00 C heating  ??

Code Auswählen Erweitern

Internals:
   DEF        e769ab5c 24
   FUUID      5cc0ca9c-f33f-cca1-7732-7a4e91569cae82fa
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     8025
   NAME       Flur_ZW_STECKDOSE1
   NR         262
   STATE      on
   TYPE       ZWave
   ZWDongle_0_MSGCNT 8025
   ZWDongle_0_RAWMSG 000400180a3202a14a0000012d0000
   ZWDongle_0_TIME 2021-12-14 18:48:30
   ZWaveSubDevice no
   homeId     e769ab5c
   isWakeUp   
   nodeIdHex  18
   READINGS:
     2021-12-08 10:29:18   IODev           ZWDongle_0
     2021-02-14 00:14:43   UNPARSED        SENSOR_MULTILEVEL 063101012200b5
     2019-10-15 13:40:27   assocGroup_1    Max 5 Nodes ZWDongle_0
     2019-10-15 13:40:27   assocGroup_2    Max 5 Nodes
     2019-10-15 13:40:27   assocGroup_3    Max 5 Nodes
     2019-10-15 13:40:27   assocGroups     3
     2019-10-15 13:38:19   configButtonOnOff Enable
     2019-10-15 13:38:19   configConfigureMaximumAlarmCurrent 12
     2019-10-15 13:38:19   configConfigureMaximumOverLoadCurrent 13
     2019-10-15 13:38:19   configConfigurePlugTimeSwitchFunction Disable
     2019-10-15 13:38:19   configConfigurePowerReport 5
     2019-10-15 13:38:20   configConfigureTimeSwitchPeriod 150
     2019-10-15 13:38:20   configLedDisplay Enable
     2019-10-15 13:38:20   configMeterReportInterval 300
     2019-10-15 13:38:20   configRememberRelayONOFFStatus Enable
     2019-10-15 13:38:20   configSendMeterReport Enable
     2019-10-06 03:21:04   cooling         228.14  previous: 228.23 delta_time: 301 s
     2021-12-14 18:48:30   current         0 A previous: 0 delta_time: 301 s
     2021-12-14 18:48:27   energy          0 kWh previous: 0 delta_time: 301 s
     2019-04-24 22:44:17   model           Neo CoolCam Power plug 12A
     2019-04-24 22:44:17   modelConfig     shenzen_neo/nas-wr01z.xml
     2019-04-24 22:44:17   modelId         0258-0003-1087
     2019-10-10 22:26:45   neighborList    ZWDongle_0 Thermostat_Buero SZ_DECKE_ZW_DIM WOH_ZW_THERMOSTAT_OST Thermostat1_UG_WZ ZWave_SWITCH_BINARY_10 Steckd_POPP Thermostat_Bad ZWave_SWITCH_BINARY_16 BUERO_ZW_FK_WEST SZ_ZW_THERMOSTAT SZ_ZW_STECKDOSE1 BEDROOM_ZW_FK ZWave_WALL_CONTROLLER_29 BUERO_ZW_TEMPSENSOR
     2021-01-15 23:01:17   neighborUpdate  done
     2021-12-14 18:48:28   power           0 W previous: 0 delta_time: 301 s
     2021-02-17 10:24:18   reportedState   on
     2019-09-10 14:12:07   setpointTemp    20.00 C heating
     2021-02-17 10:24:18   state           on
     2021-10-07 05:42:55   temperature     17.8 C
     2019-10-15 13:40:27   timeToAck       0.031
     2019-10-15 13:40:27   transmit        OK
     2020-09-16 15:26:04   undef           0 undef previous: 0 delta_time: 301 s
     2021-02-09 13:50:25   velocity        0.0 m/s
     2021-12-14 18:48:29   voltage         224.26 V previous: 224.7 delta_time: 301 s
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO MANUFACTURER_SPECIFIC VERSION ASSOCIATION ASSOCIATION_GRP_INFO DEVICE_RESET_LOCALLY POWERLEVEL CONFIGURATION SWITCH_BINARY SWITCH_ALL ALARM METER BASIC
   generateRouteInfoEvents 0
   icon       black_Steckdose.on
   room       Wohnung->Flur,ZWave
   vclasses   ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 MANUFACTURER_SPECIFIC:2 METER:4 POWERLEVEL:1 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2

Sorry falls ich jetzt daneben liege...

Gruß
Hans-Jürgen
   

[krusi]

Genau richtig verstanden - diesen Effekt meinte ich.
Außer setpointTemp dürften bei diesem Device auch die "temperature" und "velocity" Readings vermutlich von anderen Quellen stammen.

So etwas kann sicher passieren, wenn es sich um Übertragungsfehler handelt und z.B. die ID nicht stimmt, bei der genauen Betrachtung der RAW-Messages konnte ich dies bei mir aber für den Großteil der Fälle ausschließen. Speziell bei Wakeup-Geräten hatte ich nachweislich im Log, dass ohne ersichtlichen Grund ein Reading zugeordnet wurde welches bereits einige Zeit zuvor von einem anderen Device gesendet und eigentlich auch schon abgearbeitet war.

Das Problem besteht bei mir schon längere Zeit, wollte der Sache jetzt aber mal richtig auf den Grund gehen. Ein setpointTemp auf einem Lichtschalter ist noch "unschön", wenn aber der automatische Schaltvorgang nicht mehr klappt, da durch falsch zugeordnete Readings eine Bedingung nicht mehr erfüllt ist oder umgekehrt ein Vorgang fälschlicherweise getriggert wird, dann wird es nervig (und man läuft Gefahr mit der gut gemeinten Hausautomatisierung mal wieder den Ärger der ganzen Familie auf sich zu ziehen  )

Also Logs gesammelt, analysiert und Debug-Meldungen eingebaut, freundlicherweise hat sich auch Rudolf der Sache angenommen und Hilfestellung zur Eingrenzung geliefert.
Jetzt der Brüller: seit im aktuellen Release optimierte Log-Möglichkeiten vorhanden sind ist bei mir der Fehler in den letzten 24h nicht mehr reproduzierbar (zuvor hatte es keine 2h gedauert).
Im Code wurden auf den ersten Blick aber wirklich nur Inhalte verändert welche sich auf das Logging auswirken.

Werde die Sache jetzt weiter beobachten und ggf. am WE nochmals den eingefrorenen Zustand einspielen, sowie die Code-Changes der vergangenen 2 Wochen vergleichen...

[Deckoffizier]

Hallo krusi,

Danke DIR und Rudi für die Mühe!

Das Problem besteht bei mir schon längere Zeit, wollte der Sache jetzt aber mal richtig auf den Grund gehen. Ein setpointTemp auf einem Lichtschalter ist noch "unschön", wenn aber der automatische Schaltvorgang nicht mehr klappt, da durch falsch zugeordnete Readings eine Bedingung nicht mehr erfüllt ist oder umgekehrt ein Vorgang fälschlicherweise getriggert wird, dann wird es nervig (und man läuft Gefahr mit der gut gemeinten Hausautomatisierung mal wieder den Ärger der ganzen Familie auf sich zu ziehen  )

Genau so auch meine denke....

Habe jetzt noch mal ein update gemacht und in einigen Geräten die unpassenden Readings gelöscht, hatte sich doch schon einiges angesammelt.

Mal sehen was noch kommt?

Eine angenehme Vorweihnachtszeit wünscht

Hans-Jürgen

[Wolfgang Hochweller]

Wohl wahr !

Ich habe jetzt 3 Tage mit diesem Problem zugebracht.
Letztlich konnte ich alles auf Kommunikationsprobleme zurueckfuehren, auch das woanders erwaehnte dubiose  'ERROR: cannot SEND_DATA to FlurObenSensor: transmit queue overflow'

Wenn irgendetwas dazwischenfunkt, passieren merkwuerdige Dinge, wobei dann erkannte Uebertragungsprobleme das kleinere Problem darstellen.

Am Ende habe ich mir  einen Platz weit genug entfernt von Router, Servern oder anderen 'Funkern' gesucht.

[Wolfgang Hochweller]

Das hat zwar das Problem ertraeglich gemacht, zufriedenstellend ist das aber nicht.
Oder , um es mal andersherum zu formulieren : Eine Alarmanlage koennte ich so nicht betreiben.

Eine Frage, die eine Antwort braucht :

Passieren die Modfikationen einer Message
auf dem Wege vom Device zum Dongle
oder
in der Kommunikation Dongle-FHEM

?

@krusi:

Was ist dein Status zur Zeit ?

Eine Beschreibung dessen was passiert, ist gar nicht so einfach :

1. Bei einem FHEM-Device kommen Messages an, die nicht interpretierbar zu sein scheinen.
Resultat ist wohl dann ein UNPARSED, etc
2. Es kommen Messages an, die syntaktisch korrekt sind, aber z. B. nicht existierende Parameter betreffen.
Resultat : UNKNOWN_17, etc.
3. Es kommen Messages an, die korrekt sind, aber Readings erzeugen, die bei diesem Device nicht vorhanden sein sollte.
Etwa ein Reading fuer das Magnetfeld bei einem Switch.
4. Es kommen Messages an, die sinnvoll sind, aber mit unsinnigen Werten.
Etwa ein Power-Reading mit einem Wert, den es im ganzen System nicht geben kann, etwa oberhalb von 3600 Watt.
Ausnahmen sind Devices eines Herstellers, die wirklich ab und an falsche Zahlen liefern.
5. Es kommen Messages an, die korrekt und sinnvoll sind, aber offenbar mit Werten eines anderen Devices


In vielen Faellen erledigt sich das bei der naechsten Uebertragung, etwa alles unter 1.,2. und 3.
4. und 5. sind teilweise richtig unangenehm.

Ausserdem  bedeutet es, dass Messages verloren gehen - nicht gut !

Aus meiner Erfahrung heraus glaube ich sagen zu koennen, dass das nicht Dongle-Probleme sind,
ich habe sowohl mal ein Razberry, ein Z-Wave.Me USB Stick und ein Aeotec Z-Stick Gen5+ im Einsatz (gehabt), alle mit vergleichbaren Problemen

[rudolfkoenig]

Passieren die Modfikationen einer Message

Was ist damit gemeint?

Ich rate: die mit setReadingOnAck gesetzte Readings.

Das laeuft so: jede vom Modul an dem Controller uebergebene Befehl enthaelt eine 8-bit ID. Wenn das ZWave-Geraet den Empfang bestaetigt, sendet der Controller den ACK zusammen mit dieser ID an das Modul.
Das Modul merkt zu jede ID den dazugehoerigen Befehl. Bei WakeUp Geraeten kann es vorkommen, dass bis zum Aufwachen 256 _andere_ Nachrichten versendet wurden, deswegen wurde das ACK dem falschen Geraet+Befehl zugeordnet.
Ich habe das Problem gefixt (jedenfalls meine ich), und das Logging erweitert.
Bei Problemen brauche ich das Log.

[Wolfgang Hochweller]

ok.

Mit Modifizieren meine ich die Aenderung einer Message.
Beispiel :

Wenn ein Power-Sensor die Wattzahl zum Kontroller schickt, etwa 1250 W, gehe ich davon aus, dass diese Message erstmal korrekt abgeschickt wurde.
IN FHEM kommt etwa 3624 W an, also ist die Message unterwegs geaendert worden, richtig ?
Es geht nicht nur um falsche IDs !
Noch zur Info : Das betrifft nicht nur Wake-up Devices, sondern kann ueberall auftreten, ohne dass ich wirklich ein System erkennen koennte ( Hersteller, Platzierung , etc )

Wenn es bei mir Devices gibt, bei denen das haeufiger auftritt, dann sind es die Fibaro Wall Plugs FGWPF-102.

[rudolfkoenig]

Es geht nicht nur um falsche IDs !

Dann ist das hier das falsche Thema.

Es werden oefter Probleme mit falschen Daten gemeldet, die Ursache ist mW dass die Nachrichten mit Bitfehler dekodiert wurden.
Bei 9.6k und 40k Datenrate wird ein Byte CRC verwendet, bei 100k zwei.
Falls das Geraet CRC_16_ENCAP unterstuetzt, und das Attribut useCRC16 gesetzt ist, dann versieht das Modul alle Befehle zusaetzlich mit CRC16. Weiss aber nicht, ob daraufhin das Geraet nur die Antwort oder auch die regelmaessigen Meldungen so einpackt.

[Wolfgang Hochweller]

Danke, verstanden.