FHEM ist besser als seine Hardware ?!

[Timmy.m]

Ich wusste es schon immer, dass Ihr aus FHEM alles raus holt, was möglich ist.
Aber ich war heute morgen schon erstaunt, dass mein Aeon MultiSensor 6 plötzlich auch einen CO2 ppm Wert anzeigt.

Code Auswählen Erweitern

Internals:
   DEF        c1c4a579 3
   HEALTH_MONITORED_BY Monitor
   HEALTH_STATE alive
   HEALTH_TIME 2016-08-22 20:38:45
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     5538
   NAME       ZWave_SENSOR_MULTILEVEL_3
   NR         1375
   STATE      TRANSMIT_NO_ACK
   TYPE       ZWave
   ZWDongle_0_MSGCNT 5538
   ZWDongle_0_RAWMSG 00040403028407
   ZWDongle_0_TIME 2016-08-22 20:38:45
   ZWaveSubDevice no
   homeId     c1c4a579
   isWakeUp   1
   lastMsgSent 1471782650.34589
   nodeIdHex  03
   wakeupAlive 1
   Readings:
     2016-07-16 19:59:01   CMD             ZW_APPLICATION_UPDATE
     2016-08-18 13:54:52   CO2-level       433.5 ppm
     2016-08-22 20:38:45   Motion          on
     2016-08-22 20:38:45   Sabotage        off
     2016-08-19 22:07:10   UNKNOWN         multilevel type  9b fl: 01 arg: 00
     2016-08-20 23:43:10   UNPARSED        SENSOR_MULTILEVEL 0531011b0100
     2016-08-22 20:36:38   alarm           HomeSecurity:  Motion Detection - Unknown Location, arg 0000
     2016-08-09 02:31:09   anglePosition   63 %
     2016-08-22 20:36:36   basicSet        255
     2016-08-22 20:30:47   battery         100 %
     2016-07-16 19:59:07   configBatteryReportingThreshold 10
     2016-07-16 19:59:09   configCommandOptions BasicSetDefault
     2016-07-16 19:59:10   configEnableDisableLockConfiguration Disable
     2016-07-16 19:59:10   configEnableMotionSensor EnabledLevel5MaximumSensitivity
     2016-07-16 19:59:36   configGroup1Interval 600
     2016-07-16 19:59:12   configGroup1Reports 241
     2016-07-16 19:59:13   configGroup2Interval 3600
     2016-07-16 19:59:14   configGroup2Reports 0
     2016-07-16 19:59:16   configGroup3Interval 3600
     2016-07-16 19:59:17   configGroup3Reports 0
     2016-07-16 19:59:18   configHumidityCalibration 0
     2016-07-16 19:59:19   configHumidityReportingThreshold 10
     2016-07-16 19:59:20   configLowBattery 20
     2016-07-16 19:59:21   configLowTempAlarm Disabled
     2016-07-16 19:59:21   configLuminanceCalibration 0
     2016-07-16 19:59:23   configLuminanceReportingThreshold 100
     2016-07-16 19:59:24   configOnTime    240
     2016-07-16 19:59:25   configReportingThreshold Disabled
     2016-07-16 19:59:29   configTemperatureReportingThreshold 5121
     2016-07-16 19:59:05   configUVReportingThreshold 2
     2016-07-16 19:59:05   configUltravioletCalibration 0
     2016-07-16 19:59:07   configWakeUp10MinutesOnPowerOn No
     2016-07-16 19:59:34   config_9        256
     2016-08-22 20:30:47   humidity        62 %
     2016-08-22 20:30:53   luminance       12 Lux
     2016-07-16 19:46:23   model           Aeotec MultiSensor 6
     2016-07-16 19:46:23   modelConfig     aeotec/multisensor6.xml
     2016-07-16 19:46:23   modelId         0086-0002-0064
     2016-08-03 20:59:03   neighborList    empty
     2016-07-23 15:10:18   neighborUpdate  failed
     2016-08-03 21:03:14   state           TRANSMIT_NO_ACK
     2016-08-22 20:30:47   temperature     24.3 C
     2016-07-19 08:47:34   timeToAck       0.168
     2016-08-03 21:03:14   transmit        NO_ACK
     2016-08-22 20:30:54   ultraviolet     0 UV
     2016-08-22 20:38:45   wakeup          notification
Attributes:
   IODev      ZWDongle_0
   alias      Küche Z
   classes    ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM WAKE_UP BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY MARK
   device_timeout 30
   group      Bewegungsmelder
   neighborListPos 491.6623350526494,351.8194341948848
   noWakeupForApplicationUpdate 0
   room       Sensoren
   userReadings Motion {((ReadingsVal("ZWave_SENSOR_MULTILEVEL_3","basicSet",0) eq "255" ) ? 'on' : 'off');;},Sabotage {((ReadingsVal("ZWave_SENSOR_MULTILEVEL_3","alarm",0) eq "HomeSecurity:  Tampering - product covering removed, arg 0000" ) ? 'on' : 'off');;}
   vclasses   ALARM:3 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 WAKE_UP:2 ZWAVEPLUS_INFO:2

Da ich nicht denke, dass dieser Wert wirklich aus dem Sensor kommt, vermute ich mal, dass etwas schief gelaufen ist.
Wie bekomme ich den Wert samt Eintrag aus den Readings?

Grüße Tim

[KernSani]

http://fhem.de/commandref_DE.html#deletereading ?

[A.Harrenberg]

Hi,

die Checksumme der Funknachrichten ist leider relativ "schwach" implementiert, doppelte Bit-Fehler "korrigieren" sich leider sehr schnell zu einer wieder passenden Checksumme, wodurch der Fehler unendeckt bleibt. Meist passiert das bei Funktstörungen oder schwachen Batterien.

Das Reading bekommst Du mit

Code Auswählen Erweitern

deletereading <devicename> <readingname> wieder weg.

Gruß,
Andreas.

[DeeSPe]

Ich habe dieses Phänomen auch bei einigen ZWave Geräten, habe es aber bisher nicht näher untersucht. Kann ja eigentlich nur was mit den zugewiesenen Klassen zu tun haben, aber wie gesagt, habe das bisher noch nicht ernsthaft verfolgt bzw. eine Lösung gesucht. Habe mir bisher auch immer mit deletereading und entsprechendem notify ausgeholfen, aber eine richtige Lösung ist das nicht, denn die Readings kommen ja sporadisch immer mal wieder.
Habe z.B. an 3 Fibaro Wall Plugs immer mal wieder temperature und luminance Readings.

Gruß
Dan

[A.Harrenberg]

Hi,

daran können "wir" leider nichts/wenig machen.

Nachrichten werden anhand der Checksumme als gültig erkannt. Wenn nun doppelte Bitfehler diese Checksumme wieder "korrigieren" gelangen falsche Daten in FHEM.

Gerade die "METER"-Klasse ist hier empfindlich, da hier die "gemessene Größe/Einheit" übertragen wird (Power, Energy, Temperature, ...), je nach Gerät eben. Falls hier ein falscher Wert ankommt wird ein entsprechendes, meist unsinniges Reading angelegt. Wenn bei anderen Klassen oder bei dem Wert selbst mal ein Wert falsch ist, wird der beim nächsten mal ja wieder überschrieben, das angelegte Reading bleibt aber bestehen.

Bei den neuen Versionen der METER Klasse kann man per Befehl abfragen was der Sensor überhaupt senden kann, damit "könnte" man eine Art Whitelist machen und andere Werte einfach wegwerfen. Das würde aber entsprechende Attribute benötigen und ob sich der Aufwand lohnt um die Reading zu unterdrücken wage ich zu bezweifeln. Falsche Zahlenwerte und Fehler in anderen Klassen wird es nach wie vor geben.

Gruß,
Andreas.

[Timmy.m]

Vielen Dank für Eure Antworten. Schade, dass es keinen günstigen MultiSensor mit Co2 Werten gibt. 

[rudolfkoenig]

Habe das Bestellen der mit separaten CRC gesicherten Nachrichten auf meinem (langfristiges) TOD genommen.
Da gehoert erstmal auch eine Untersuchung dazu, ob das ueberhaupt moeglich ist, also nicht zu viele / schnelle Hioffnungen machen.

[krikan]

Mich würde interessieren, ob (mögliche) Ursachen bekannt sind, wodurch diese seltsamen Nachrichten in den speziellen Fällen entstanden sind. Beim TE sind über mehrere Tage verteilt fehlerhafte Telgramme eingegangen. War die Batterie leer? Gab es Besonderheiten beim FHEM-Server? ...

Ich nutze den AEOTEC auch, habe derartiges noch nicht im Normalbetrieb erlebt. Auch bei anderen Sensoren/Aktoren kenne ich das im Normalbetrieb nicht. Selbst im Testnetz tritt das seltenst auf und dann zumeist nur bei "wilden" Inklusionen o.ä.

Mir ist es aufgrund meiner Erfahrungen mit ZWave zu "einfach" dies auf die schwache Checksumme zu schieben. Vielleicht gibt es bei den betroffenen Netzen andere Probleme.

CRC würde beim AEOTEC mangels entsprechender CC (anders als bei Fibaro) nicht helfen. Ich hatte aber gelesen, dass bei 100 kb die Checksumme verbessert wurde und daher bei ZWave+ mit 100k-Nachrichten CRC unnötig ist. Ist das falsch; gibt es bei 100 kb keine bessere Ckecksumme?

[A.Harrenberg]

Hi Christian,

hmm, jetzt wo Du es sagst, 100kB müsste eine CRC16 haben... Muss ich noch mal nachschauen, vielleicht kann Rudi das aber auch direkt bestätigen.

Ich meine mich daran zu erinnern (sehr vage) das ich damals mal so eine Nachricht bitweise auseinandergenommen habe und das dort zwei Bitfehler zu identifieren waren die sich gegenseitig aufgehoben haben. Damals war dann auch eine wilde Messgröße entstanden und der Zahlenwert war ebenfalls in Mitleidenschaft gezogen.

Na ja, wenn man mit "unserem" ZWave_Cul mal loggt und dabei z.B. die Präambel ausschaltet bekommt man kontinuirlich Datenmüll angezeigt der immer noch oberhalb der Schwelle für eine erkanntes Signal liegt. Das meiste wird in unserem CUL ausgefiltert weil die Präambel fehlt. Verworfene Pakete aufgrund von falscher CS habe ich bei meinen Tests jetzt nicht ausdrücklich geloggt, ich würde aber vermuten das der Anteil relativ gering ist.

Wie die Filterung in dem ZWave-Chip aussieht können wir natürlich nicht wissen, ich würde aber davon ausgehen das die Filterung dort sogar besser funktioniert.

Gruß,
Andreas.

[rudolfkoenig]

100k ist zwingend 16bit Checksumme (da bin ich sicher).
ZWave+ ist aber nicht zwingend 100kBaud (da bin ich nicht ganz sicher).

[krikan]

ZWave+ ist aber nicht zwingend 100kBaud (da bin ich nicht ganz sicher).

ZWave+ (500er Chipsatz) setzt 100k Unterstützung voraus. ZWave+ schaltet von 100k auf 40k, wenn es Kommunikations-Probleme gibt. So hatte ich es damals bei ZWCul-Logs mit AEOTEC Sirene festgestellt. Wenn heruntergeschaltet wird, hätten wir wohl wieder schlechte Checksumme.
Auch 400er Chipsatz kann übrigens 100k (bspw. Greenwave Schaltsteckdose).