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.
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
http://fhem.de/commandref_DE.html#deletereading ?
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 deletereading <devicename> <readingname> wieder weg.
Gruß,
Andreas.
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
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.
Vielen Dank für Eure Antworten. Schade, dass es keinen günstigen MultiSensor mit Co2 Werten gibt. :P
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.
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?
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.
100k ist zwingend 16bit Checksumme (da bin ich sicher).
ZWave+ ist aber nicht zwingend 100kBaud (da bin ich nicht ganz sicher).
Zitat von: rudolfkoenig am 23 August 2016, 14:40:21
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).