[attrTemplate?] AEON Labs ZW100 MultiSensor 6

[Beta-User]

Hallo zusammen,

nachdem mir o.g. Modell "zugeflogen" ist (ein Gerät, mit dem ein anderer User nicht zufrieden war), fang' ich hier mal einen Thread zu dem Ding an - vielleicht gibt es am Ende ein attrTemplate dazu, vielleicht auch nicht, mal schauen.

Plan ist jedenfalls, mal meine Erfahrungen mit einem konkreten (batteriebetriebenen) Gerät "from the scratch" aufzuschreiben, und ggf. die Erfahrungen und Erkenntnisse, die man so sammeln kann, irgendwie zu "verstetigen", dass ggf. jemand anderes direkt was damit anfangen kann.

Daher habe ich ziemlich bewußt weder das Wiki noch das Forum nach Infos zu dem Ding durchsucht, also bitte keine RTFM-Kommentare hier ....


Inklusion:
Unproblematisch...
IO in onNw versetzt (ja, ich wollte es wissen, daher waren die nächstgelegenen Repeater-fähigen Geräte auch keine Plus-Geräte...), das Ding an USB-Power geklemmt und mal den Knopf hinten gedrückt und da war auch schon das FHEM-Device. (k.A., ob das mit dem Knopf erforderlich war, vermutlich nicht, und wenn, dann eigentlich 3x, s.u.).
(Ich hatte allerdings das Teil nicht vorher bewußt in den Auslieferungszustand zurückgesetzt, ist mir leider raus, es scheinen aber alle Werte auf default gestanden zu haben, s.u.).


Erster Eindruck:
Gesendet werden Messwerte wie temp/hum/uv eher in "homäopathischen Dosen", wenn man es mit CUL_HM-Geräten vergleicht, nur alle Stunde, wie der nebenher geöffnete Event-Monitor verrät.
Die Meldungen für Bewegung sind auch ungewohnt; irgendwie geht "diverses" in das "alarm"-Reading: dort taucht dann u.A. auch sowas wie "HomeSecurity: Motion Detection - Unknown Location" auf, ohne dass in den config-Geschichten irgendwas erkennbar wäre, womit man die Location irgendwie festlegen könnte und keine Bewegung mehr dann "alarm" erst nach 4 Minuten auf das eher unspezifische "HomeSecurity: Event cleared: Previous Events cleared" springen lässt.
Aber immerhin ist nachvollziehbar, dass "0" in  "basicSet" keine Bewegung mehr bedeuten soll und "255" für Bewegung steht; gewöhnungsbedürftig, aber verwertbar...

Habe dann noch ein "get configAll" und "get associationAll" abgesetzt und das ganze dann über Nacht in Ruhe gelassen, heute am Nachmittag waren dann Werte da.

Soweit also alles ok.


Da es vorhin auch einen Thread zum Thema 'wie schalte ich beim "Auge" die LED aus?" gab, dachte ich, das sei eine gute Idee - und prompt will das nicht klappen...
Vorgehensweise: Klartextbefehle über FHEMWEB abgesetzt, dann gleich ein entsprechendes getConfig hinterhergeschickt, Tasterchen 3x gedückt (etwas frickelig, wenn man das Ding an USB hat...). Es kommen zwar Rückmeldungen, und die "pending" gehen auch ordnungsgemäß auf 0, aber die LED blinkt weiter (was auch mit der entsprechenden Info im Reading zusammenpaßt). Dann beides getrennt abgesetzt (erst der config-Befehl, dann 3x Knopf, nix pending, dann getConfig, 3xKnopf...).

Heißt wohl, dass ich doch mal die Doku von AEOTEC aufsuchen muss, was sich dazu finden läßt. Dazu dann aber ein andermal, für's erste muß ein list von dem Ding im aktuellen Zustand ausreichen:

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   DEF        12345678 19
   FUUID      5f6e34a1-f33f-d171-2ebf-cb699014cdca9ddc
   IODev      zwaveme
   LASTInputDev zwaveme
   MSGCNT     375
   NAME       ZWave_SENSOR_MULTILEVEL_19
   NR         553
   STATE      wakeupInterval 86400 1
   TYPE       ZWave
   ZWaveSubDevice no
   cmdsPending 0
   homeId     12345678
   isWakeUp   1
   lastMsgSent 1601127595.82966
   nodeIdHex  13
   zwaveme_MSGCNT 375
   zwaveme_RAWMSG 00040013057006510100
   zwaveme_TIME 2020-09-26 15:39:53
   .attraggr:
   .attrminint:
   .vclasses:
     ALARM      3
     ASSOCIATION 2
     CONFIGURATION 1
     DEVICE_RESET_LOCALLY 1
     FIRMWARE_UPDATE_MD 2
   READINGS:
     2020-09-26 15:39:53   CMD             ZW_APPLICATION_UPDATE
     2020-09-25 20:19:24   SEND_DATA       failed:00
     2020-09-26 15:39:48   alarm           HomeSecurity: Tampering - product covering removed
     2020-09-25 21:19:34   assocGroup_1    Max 5 Nodes zwaveme
     2020-09-25 21:19:19   assocGroups     1
     2020-09-26 15:35:02   basicSet        255
     2020-09-26 15:35:00   battery         100 %
     2020-09-26 15:35:00   batteryPercent  100
     2020-09-26 15:35:00   batteryState    ok
     2020-09-26 15:36:02   configAwakeTimeout 15
     2020-09-26 15:36:03   configBatteryReportingThreshold 10
     2020-09-25 21:19:20   configCommandOptions BasicSet
     2020-09-26 15:36:04   configCurrentPowerMode 2
     2020-09-26 15:36:04   configEnableDisableLockConfiguration Disable
     2020-09-26 15:36:04   configEnableDisableToSendAReportOn48 0
     2020-09-26 15:36:05   configEnableMotionSensor EnabledLevel5
     2020-09-26 15:36:05   configGetTheOutOfLimitStateOfThe61 0
     2020-09-26 15:36:05   configGroup1Interval 3600
     2020-09-26 15:36:06   configGroup1Reports 241
     2020-09-26 15:36:06   configGroup2Interval 3600
     2020-09-26 15:36:07   configGroup2Reports 0
     2020-09-26 15:36:07   configGroup3Interval 3600
     2020-09-26 15:36:07   configGroup3Reports 0
     2020-09-26 15:36:08   configHumidityCalibration 0
     2020-09-26 15:36:08   configHumidityReportingThreshold 10
     2020-09-26 15:39:53   configLEDBlinkingReport EnableLEDBlinking
     2020-09-26 15:36:09   configLowBattery 20
     2020-09-26 15:36:09   configLowTempAlarm Disabled
     2020-09-26 15:36:11   configLuminanceCalibration 0
     2020-09-26 15:36:19   configLuminanceReportingThreshold 100
     2020-09-25 21:19:27   configOnTime    240
     2020-09-26 15:36:17   configReportOnlyOnThresholds Disabled
     2020-09-25 21:19:28   configSetTheLowerLimitValueOf50 256
     2020-09-26 15:36:47   configSetTheLowerLimitValueOf56 4
     2020-09-26 15:36:47   configSetTheLowerLimitValueOfHumidity52 50
     2020-09-26 15:36:48   configSetTheLowerLimitValueOfLighting54 100
     2020-09-25 21:19:29   configSetTheRecoverLimitValueOf57 5121
     2020-09-26 15:36:50   configSetTheRecoverLimitValueOf58 5
     2020-09-26 15:37:37   configSetTheRecoverLimitValueOf59 10
     2020-09-26 15:37:37   configSetTheRecoverLimitValueOf60 2
     2020-09-26 15:37:37   configSetTheUpperLimitValueOf49 18350336
     2020-09-26 15:37:37   configSetTheUpperLimitValueOf55 8
     2020-09-26 15:37:38   configSetTheUpperLimitValueOfHumidity51 60
     2020-09-25 21:19:31   configSetTheUpperLimitValueOfLighting53 1000
     2020-09-26 15:37:38   configTemperatureCalibration 1
     2020-09-26 15:37:38   configTemperatureReportingThreshold 1310976
     2020-09-26 15:37:38   configTemperatureScale Celsius
     2020-09-26 15:37:38   configUVReportingThreshold 2
     2020-09-26 15:37:39   configUltravioletCalibration 0
     2020-09-26 15:37:39   configWakeUp10MinutesOnPowerOn Disable
     2020-09-26 15:34:59   humidity        58 %
     2020-09-26 15:35:00   luminance       29 Lux
     2020-09-25 20:19:17   model           AEON Labs ZW100 MultiSensor 6
     2020-09-25 20:19:17   modelConfig     aeotec/zw100.xml
     2020-09-25 20:19:17   modelId         0086-0002-0064
     2020-09-25 20:19:15   state           wakeupInterval 86400 1
     2020-09-26 15:34:59   temperature     23.3 C
     2020-09-26 15:39:55   timeToAck       0.053
     2020-09-26 15:39:55   transmit        OK
     2020-09-26 15:35:01   ultraviolet     0 UV
     2020-09-26 15:19:00   wakeup          notification
Attributes:
   IODev      zwaveme
   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
   room       ZWave
   vclasses   ALARM:3 ASSOCIATION:2 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2

[tux75at]

Hallo Beta User,

Kleine Anmerkungen zu deinen Erfahrungen:

Anlernen um USB- oder Batterie-Betrieb ... ich vermute (ich kann hier falsch liegen, bzw. FW Versionsabhängig) dass ein Anlernen mit USB Versorgung ein Bit setzt dass es permanent versorgt ist. Dies führt zu erhöhtem Strombedarf. Tauschen auf Batterien hat eventuell keine Auswirkung. Es gibt eine Konfiguration mit der man dies auslesen kann.

LED deaktivieren. Sollte funktionieren, kann ich aber auch nicht richtig setzen.
Das gleiche mit dem Bewegungsmelder, dieser sollte deaktivierbar sein, sollte auch deaktiviert sein, aber ich merke dass bei Bewegung immer wieder die LED aufleuchtet (wäre mir ohne obiges Problem nicht aufgefallen) --> erhöhter Energiebedarf!

Meine Gewünschte Konfiguration ist Temperatur und Luftfeuchtemessung, sowie auch noch die Helligkeit, die restlichen Funktionen sind mir (derzeit) nicht wichtig. Meine gewünschte Funktion habe ich, aber die Batterielaufzeit könnte optimiert werden, wenn man andere Funktionen deaktivieren könnte. Da ich viele dieser Sensoren habe, könnte es ein Problem bei ein paar einzelnen sein, bzw falsch gesetzte Konfiguration bei den einzelnen Geräten.

Derzeit kümmere ich mich nicht darum, da ich zu viele andere Dinge zu erledigen habe, ist dann etwas für den Winter.

Gruß
Tux

[krikan]

LED deaktivieren/aktivieren:
Ist abhängig von der Firmwareversion und wird erst in neueren Firmwareversionen unterstützt (siehe bspw. https://aeotec.freshdesk.com/helpdesk/attachments/6085201197). Die XMLs für die Klartext-config-Befehle in FHEM unterscheiden nicht zwischen Firmwareversionen. Für den Sensor ist eine XML für Firmware 1.13 eingecheckt. Damit funktioneren unter Umständen bei älteren Firmwareversionen vor 1.13 Klartext-config-Befehle nicht oder nicht richtig. Man muss ggfs. auf configByte und Co ausweichen.

USB- oder Batteriebetrieb:
Beim Wechsel zwischen USB- und Batteriebetrieb wurde -zumindest bei der von mir getesteten Firmwareversion- das entsprechende "Bit" für die Unterscheidung ohne Eingriffe neu gesetzt. Es wird aber von FHEM nicht automatisch ausgewertet; Attribut classes muss manuell bzgl. WAKEUP angepasst werden.
In der Doku von Aeotec finde ich auch keinen Hinweis auf eine notwendige Neuinklusion bei Versorgungswechsel. Nur auf die Anpassung der config-Werte. Vermute bisher keine Beeinflußung beim Wechsel, aber das ist eben nur eine Vermutung. Frage mal bei Aeotec an.

Gruß, Christian

[rudolfkoenig]

dort taucht dann u.A. auch sowas wie "HomeSecurity: Motion Detection - Unknown Location" auf, ohne dass in den config-Geschichten irgendwas erkennbar wäre, womit man die Location irgendwie festlegen könnte

Location kann man in ZWave bei Vorhandensein der NODE_NAMING Klasse festlegen, in FHEM mit set/get location.

Ich gehe davon aus, dass in diesem Fall um was Anderes geht, in unser Dekodier-Tabelle steht naemlich

Code Auswählen Erweitern

...
  "0701"=>"Intrusion",
  "0702"=>"Intrusion - Unknown Location",
  "0703"=>"Tampering - product covering removed",
  "0704"=>"Tampering - Invalid Code",
  "0705"=>"Glass Breakage",
  "0706"=>"Glass Breakage - Unknown Location",
  "0707"=>"Motion Detection",
  "0708"=>"Motion Detection - Unknown Location",
...

[krikan]

Ich gehe davon aus, dass in diesem Fall um was Anderes geht, in unser Dekodier-Tabelle steht naemlich

Nein, Du liegst richtig.
Bei den Events bis ALARM aka NOTIFICATION V4 steckt immer " - Unknown Location" im Event, wenn die location unbekannt/nicht festgelegt ist; selbst wenn sie mangels Classs NODE_NAMING nicht festgelegbar ist. Ab Alarmtypen für ALARM V5 habe ich in meinem dazu in FHEM eingebauten Patch das anders und entsprechend den aktuellen Specs umgesetzt: Unbekannte location->kein Hinweis im Eventtext; bekannte location->Hinweis auf bekannte location im Eventtext. Siehe meinen Hinweis zum Patch: https://forum.fhem.de/index.php/topic,111587.msg1063423.html#msg1063423 und die Tabelle der Events im verlinkten Thread.

@Beta-User:
(Nicht nur) bei Templates könnte es sinnvoll sein, das Attribut extendedAlarmReadings auf 1 zu setzen. Dann hat man verschiedene Readings für verschiedene Alarmtypen, die sich nicht mehr überschreiben. Events sind mMn auch besser unterscheidbar.

Gruß, Christian

[Beta-User]

Danke euch für eure Tipps.

Kurze Zwischeninfo:
- "version" (den Befehl um das zu bekommen hatte ich erst mal übersehen...) meint u.a. "App 1.12", das Ding scheint also unter der LED-Abschaltung die "2" noch nicht zu kennen (=>Beipackzettel ist aktueller als die firmware, kaum von FHEM aus vermeidbar...). Mit "1" konnte ich die LED bei "motion" zum Schweigen bringen .
(Exkurs: AEOTEC bietet immerhin FW-updates an, werde das mal in den "Segment-Trenner" der attrTemplate-file aufnehmen. Blöd ist nur, dass man zu diesem Gerät entweder eine .hec findet (mit der FHEM lt. einem anderen Thread hier nichts anfangen kann (? notfalls würde ich mal den Test machen, ob das wirklich ein spezielles Format ist oder doch nur eine umbenannte hex? Kann man sowas irgendwie anders rausfinden?!?)) oder man braucht Windo.*, was ich grade nicht passend zur Hand hatte)...

- "extendedAlarmReadings" ist sinnvoll, bringt allerdings statt der Erschütterung (?) eine "openCover" (oder so) -Warnung. Aber immerhin ist "basicSet" weiter erhalten für motion... (mAn. auch keine Aktion erforderlich, ist halt auch so eine Sache, die man "wissen" sollte.)

- Das mit "location" ist im Prinzip völlig egal, es irritiert halt nur im ersten Moment; im Moment habe ich keine fundierte Meinung dazu, ob man da im Code was tun sollte. Vermute, dass das ggf. backwards-Kompabilitätsprobleme geben kann und würde das eher lassen, wie es ist...

- configCurrentPowerMode scheint auf BatteryPowerSleepingModeAfterRe256 zu stehen, was ich so interpretiere, als hätte das Ding erkannt, dass es nicht mehr an USB hängt (scheint readonly zu sein). (frage mich nur, warum das überhaupt aktualisiert wurde; meine, ich hätte kein "get" mehr angestoßen nach dem Umstöpseln...? Kann mich aber auch täuschen).

- UV ist im Innenbereich eigentlich wenig zielführend, oder? Und für den Außenbereich gibt es Hinweise, dass der Bewegungsmelder ggf. durch direkte Sonneneinstrahlung irritiert wird. Ja was denn nun...?!?

(OT zu den attrTemplate: bin dabei, mal noch ein etwas erweitertes Paket zu schnüren, will aber erst noch ein paar Dinge selbst (an-)testen, was noch etwas dauern wird.)

[krikan]

(Exkurs: AEOTEC bietet immerhin FW-updates an, werde das mal in den "Segment-Trenner" der attrTemplate-file aufnehmen. Blöd ist nur, dass man zu diesem Gerät entweder eine .hec findet (mit der FHEM lt. einem anderen Thread hier nichts anfangen kann (? notfalls würde ich mal den Test machen, ob das wirklich ein spezielles Format ist oder doch nur eine umbenannte hex? Kann man sowas irgendwie anders rausfinden?!?)) oder man braucht Windo.*, was ich grade nicht passend zur Hand hatte)...

.hec ist ein Homeseer Spezial (http://help.homeseer.com/help/Z-Flash/static/#.adding_firmware_files). Ich konnte mit der Datei nichts anfangen, da "encrypted". Einziger mir bekannter Weg für ein Update geht über Windows. Aeotec will die .hex nicht herausgeben bzw. nur gegen NDA.

- configCurrentPowerMode scheint auf BatteryPowerSleepingModeAfterRe256 zu stehen, was ich so interpretiere, als hätte das Ding erkannt, dass es nicht mehr an USB hängt (scheint readonly zu sein).

Laut Rückmeldung: Der Sensor erkennt automatisch seine Stromversorgung (USB oder Batterie) und passt sich an; eine neue Inklusion ist überflüssig. Nur die config-Werte und das Attribut classes muss man bei FHEM manuell an die jeweilige Stromversorgung anpassen. Die Details dazu hat AEOTEC auf  https://aeotec.freshdesk.com/ veröffentlicht. Eine Automatisierung durch FHEM beim Wechsel wäre wohl auch möglich, habe ich aber nicht weiter hinterfragt und angeschaut.

[Beta-User]

.hec ist ein Homeseer Spezial (http://help.homeseer.com/help/Z-Flash/static/#.adding_firmware_files).

Danke für die Info, dann bleibt nur der Weg via Win.* (irgendwie schade, dass fw-updates bei ZWave herstellerseits insgesamt so restriktiv gehandhabt zu werden scheinen; das untergräbt die "Wahl aus vielen Produkten"-Philisophie total .)

Nur die config-Werte und das Attribut classes muss man bei FHEM manuell an die jeweilige Stromversorgung anpassen. Die Details dazu hat AEOTEC auf  https://aeotec.freshdesk.com/ veröffentlicht. Eine Automatisierung durch FHEM beim Wechsel wäre wohl auch möglich, habe ich aber nicht weiter hinterfragt und angeschaut.

Hm, sowas könnte man via attrTemplate über eine "radio option" lösen (und dann m.E. auch in einem Eventhandler entsprechend direkt ansteuern, ist via Eventhandler allerdings ggf. etwas Schreibarbeit).
Muss ich mir in jedem Fall nochmal ansehen, wie die Settings jetzt im Ergebnis sind, will ja die Batterie nicht vergeuden.

[Beta-User]

Nur die config-Werte und das Attribut classes muss man bei FHEM manuell an die jeweilige Stromversorgung anpassen.

So, jetzt sind im svn zumindest mal zwei Versionen drin, die config-Werte entsprechend https://aeotec.freshdesk.com/support/solutions/articles/6000115071-difference-between-usb-and-battery-power-and-recommendations-multisensor-6-zw100- anpassen müßte (von den classes habe ich die Finger gelassen)...
Da UV im Haus keinen großen Sinn macht, habe ich die Radio-Option jetzt für das Ausschalten verwendet, daher doch zwei templates. (Ob das alles so paßt, wird man sehen, irgendwie wollte der Sensor vorhin nicht auf Tastendruck aufwachen...).

Zum Rest schreibe ich im allg. zwave.template-Thread noch was.