attrTemplate für ZigBee2Tasmota

[Beta-User]

Hmmm, für die batteryPercent-Geschichte habe ich grade noch keine Idee, außer dass evtl. der falsche jsonMap-Filter gesetzt ist. Könnte evtl. so klappen:

Code Auswählen Erweitern

attr MQTT2_z2t_6EA4 jsonMap Battery:0 Device:0 BatteryPercentage:batteryPercent Temperature:temperature Humidity:humidity
Sonst würde ich nochmal den MQTT-Verkehr haben wollen, soweit er "battery" (im weiteren Sinne) betrifft (ich meine, da gab es auch Diskussionen auf der Tasmota-Entwickler-Seite, inwieweit das überhaupt sinnvolle Werte sind; kann aber auch falsch liegen).

Was die beiden anderen Batterie-Geräte angeht: Evtl. ist das battery-Ding generisch genug, um mit beiden klarzukommen (damit würde ich mal anfangen), evtl. kann man den Cube auch als Remote ansehen und den Bewegungsmelder als Kontakt-Sensor. Eigentlich war meine Hoffnung, euch (wo erforderlich) soviele Bausteinchen zu liefern, dass ihr auch selber ein bisschen spielen könnt und den Rest dann vollends als getestete attrTemplates beisteuert .

[TL60]

Hallo,
ich hatte hier

Obwohl ich bin fast soweit, mein produktive Zigbee2Mqtt auf einem Raspberry auf die Tasmota Lösung umzustellen. Mal schauen, was das Wochenende noch so bringt 

ja angedeutet, das ich Zigbee2tasmota mal produktiv nehem möchte. Was ich dann auch gemacht habe mit (wie der Zufall es will)  einem Aqara Cube und einem Ikea Trafri Bewegungsmelder sowie einem Tint Smart light LED strip color+white. Alle Geräte wurden wie gehabt auf Werkseinstellungen gesetzt und mit set XXX permit join 1 eingebunden. Zum Cube: Nach dem das template tasmota_zigbee2tasmota_generic_battery_sensor gesetzt wurde kamen alle relevanten Readings inkl. Batteriereading rein.

Code Auswählen Erweitern

Internals:
   CID        z2t_35ED
   DEF        z2t_35ED
   DEVICETOPIC MQTT2_z2t_35ED
   FUUID      5f38090b-f33f-22fe-148b-c4bfb4849fba1cf7
   IODev      MQTTBroker
   LASTInputDev MQTTBroker
   MQTTBroker_MSGCNT 30
   MQTTBroker_TIME 2020-08-30 16:11:35
   MSGCNT     30
   NAME       MQTT2_z2t_35ED
   NR         80
   STATE      wakeup
   TYPE       MQTT2_DEVICE
   JSONMAP:
     Battery    batteryPercent
     BatteryPercentage 0
     Device     0
     Humidity   humidity
     Temperature temperature
   READINGS:
     2020-08-30 13:07:29   AqaraCube       wakeup
     2020-08-18 21:46:04   AqaraCubeFromSide 1
     2020-08-29 10:54:43   AqaraCubeSide   0
     2020-08-26 20:28:14   AqaraRotate     20.98001
     2020-08-26 20:28:14   Aqara_FF05      930
     2020-08-30 16:11:35   Endpoint        1
     2020-08-30 16:11:35   LinkQuality     70
     2020-08-30 13:07:29   MultiInValue    2
     2020-08-30 16:11:35   Voltage         3.005
     2020-08-30 16:11:35   Xiaomi_97       0
     2020-08-30 16:11:35   Xiaomi_98       196
     2020-08-30 16:11:35   Xiaomi_99       104
     2020-08-30 16:11:35   Xiaomi_9A       4
     2020-08-15 18:10:51   associatedWith  MQTT2_DVES_AAFFC1
     2020-08-15 19:46:39   attrTemplateVersion 20200814
     2020-08-30 16:11:35   batteryPercent  100
Attributes:
   IODev      MQTTBroker
   alias      Aqara_Cube
   comment    For forther configuration use e.g. stateFormat attribtue like T: temperature°C | H: humidity% | B: batteryPercent%
   group      Zigbee2Tasmota
   icon       cube
   jsonMap    Battery:batteryPercent Device:0 BatteryPercentage:0 Temperature:temperature Humidity:humidity
   model      tasmota_zigbee2tasmota_generic_battery_sensor
   readingList tele/zb2tasmota/35ED/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0x35ED.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef }
   room       MQTT2_DEVICE
   stateFormat AqaraCube Im direkten Vergleich (der Cube lief vorher unter Zigbee2mqtt) fällt auf: Das bei Zibgee2mqtt alle Aktionen (shake, wakeup, fall, tap, slide, flip180, flip90, rotate_left and rotate_right) unter dem reading action auflaufen. Bei Zigbee2Tasmota erkennt man rotate_left bzw rotate_right nicht wie alle anderen Aktionen im Reading AqaraCube sondern im reading AqaraRotate (Rechtsdrehung Zahlenwert ohne Vorzeichen, Linksdrehung Zahlenwert mit negativem Vorzeichen). DOIF oder notify müssen dann halt entsprechend angepasst werden. Zum Rest (BWM u. Light-Strip) schreibe ich gleich noch was

[kimbolero]

Hmmm, für die batteryPercent-Geschichte habe ich grade noch keine Idee, außer dass evtl. der falsche jsonMap-Filter gesetzt ist. Könnte evtl. so klappen:

Hab nun die den MQTT-Verkehr nochmals geprüft - muss wie folgt unter "jsonMap" hinterlegt werden:

Code Auswählen Erweitern

Device:0 Battery:batteryPercent Temperature:temperature Humidity:humidity
Danach legt er mir auch das Battery-Reading an - mit 86% sollte es auch passen

Zum Cube: Nach dem das template tasmota_zigbee2tasmota_generic_battery_sensor gesetzt wurde kamen alle relevanten Readings inkl. Batteriereading rein.

Klasse, er legt mir auch die drei Readings an - danke Dir TL60

[Beta-User]

OK; könnte man das einheitlich machen bei allen Battery-Geräten? Oder kommt da entweder auf dem einen _oder_ dem anderen Weg der jeweilige Wert? (Dann könnte man beides mappen; kommt es doppelt, gäbe es doppelte Events, sowas will ich eigentlich vermeiden...).

Was den Cube angeht: Man könnte AqaraRotate auch (zusätzlich) auf AqaraCube mappen, (bzw. ggf. beides nach state) ich kann allerdings nicht sagen, ob das dann ein sinnvolles Gesamtergebnis gibt bzw. ob das dann besser dem entspricht, was zigbee2mqtt machen würde. Wünschenswert wäre es, wenn man das irgendwie vereinheitlichen könnte .

[kimbolero]

OK; könnte man das einheitlich machen bei allen Battery-Geräten? Oder kommt da entweder auf dem einen _oder_ dem anderen Weg der jeweilige Wert? (Dann könnte man beides mappen; kommt es doppelt, gäbe es doppelte Events, sowas will ich eigentlich vermeiden...).

Erst nachdem ich es geändert habe, wurde das Reading angezeigt.

[TL60]

Also, wie ich schon schrieb: Unter Zigbee2Mqtt laufen unter dem Reading action alle Aktionen wie: shake, wakeup, fall, tap, slide, flip180, flip90, rotate_left and rotate_right  rein. Wenn man es also einheitlich haben möchte sollte man diese aktionen unter einem Reading zusammenfassen. Zigbee2Mqtt liefert unter dem Reading angle zwar auch die Zahlenwerte, wie auch Zigbee2Tasmota unter dem Reading Aqara_rotate aber das wäre dann ja auch egal, oder?
Nun zu meinem Problemkind  der Tradfri Bewegungsmelder ist unter Zigbee2tasmota doch sehr rudimär eingebunden. Auf die Inbetriebnahme des Sensors gehe ich nicht mehr ein, einfach auch problemlos. Bei erkannter Bewegung liefert Zibgee2Mqtt folgendes Mqtt

Code Auswählen Erweitern

17:43:59 MQT: tele/zb2tasmota/C2BC/SENSOR = {"ZbReceived":{"0xC2BC":{"0006!42":"0008070000","Power":66,"Endpoint":1,"LinkQuality":84}}}
17:44:01 MQT: tele/zb2tasmota/C2BC/SENSOR = {"ZbReceived":{"0xC2BC":{"Endpoint":1,"LinkQuality":84}}} Dann ist erstmal Ruhe, d.h. eine erneute Bewegung innerhalb kurzer Zeit (ca.2 Minuten führt) zu keiner Meldung. Erst nach Ablauf dieser Zeit wird bei Bewegung wieder die schon gezeigte Meldung gepublisht. Hier ist Zigbee2Mqtt deutlich weiter: Bei Bewegung wird das Reading occupancy auf true gesetzt um dann nach einer gewissen Zeit wieder auf false gesetzt zu werden.Somit ist es bei Zigbee2Mqtt deutlich einfacher eine BWM gesteuerte Beleuchtung zu initiieren. Bezüglich des Lightstrips-Color würde ich mich noch etwas in Homebridgemapping einlesen wollen, um damit auch vielleicht den Einstieg in speechtemplates für Zigbee2Tasmota zu machen  Bezüglich Batterie Readings für Tür/Fensterkontakte gab es ein Issue auf Tasmota https://github.com/arendst/Tasmota/issues/9157 ich kann aber nicht sagen ob das hier hilft

[Billy]

Hallo,
bin dabei mich gerade in das Thema ZigBee2Tasmota einzuarbeiten.
Habe ein MQTT2_DEVICE angelegt und finde das attrTemplate  tasmota_zigbee2tasmota_bridge in der Template Auflistung nicht.
Was mache ich falsch?
Billy

[TomLee]

Was mache ich falsch?

Kein aktuelles FHEM(-mqtt2.template).

Gruß

Thomas

[Billy]

Kein aktuelles FHEM(-mqtt2.template).

Gruß

Thomas

Unter /fhem/FHEM/lib/AttrTemplate habe ich das neueste liegen!
Muß das verschoben werden?
habe bisher nicht mit mqtt2 gearbeitet.

[TomLee]

Unter /fhem/FHEM/lib/AttrTemplate habe ich das neueste liegen!

Hast du seit dem es dort liegt  zwischenzeitlich ein

Code Auswählen Erweitern

{ AttrTemplate_Initialize() } oder Neustart des Servers gemacht ?

[TL60]

Vielleicht auch das Wiki zu Zigbee2Tasmota lesen.https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT. Die  templates für die einzelnen Geräte erscheinen erst, wenn auf das erste automatisch angelegte zigbee2tasmota device das tasmota_zigbee2tasmota_bridge template erfolgreich angewendet wurde. Wie gesagt Wiki lesen  . Sollte dort etwas unverständlich oder verbesserungswürdig sein immer melden und her mit Verbesserungen 

[TomLee]

Die  templates für die einzelnen Geräte erscheinen erst

Das war mir auch nicht bewusst, nutze z2t nicht.

Aber um

wenn auf das erste automatisch angelegte zigbee2tasmota device das tasmota_zigbee2tasmota_bridge template erfolgreich angewendet wurde

zu erfüllen, sollte das Bridge-Template doch schon zuvor Auswahl gestanden haben, oder versteh ich was falsch ? 

[TL60]

Nein, das ist richtig das bridge template sollte eigentlich sofort zur Verfügung stehen

[TL60]

Wie oben schon mal erwähnt, kann ich zum Testen der templates einen Tint LED-Strip Color+White beitragen,  ich habe diesen über den bekannten Weg in FHEM eingebunden und darauf (nachdem ich heute um21:50 Uhr ein FHEM update gemacht habe) das tasmota_zigbee2tasmota_light_cct_hue template angewendet. Soweit so gut. Es hat im Prinzip auch alles funktioniert bis auf ein paar Kleinigkeiten. Wenn ich das alles richtig gelesen habe sollte nach Aufruf und abarbeiten des templates, das  speechrecognization template automatisch aufgerufen werden das ist nicht passiert. Weiterhin ist es so, das im Devstateicon die Symbolfarbe sich nicht mit der eingestellten Farbe ändert. Ausserdem ist mir noch aufgefallen das der Slider für die HUE Einstellungen ein wenig springt, d.h. ich stelle z.Bsp. am Slider den HUE Wert 124 ein der Slider springt aber einen Moment später wieder um einige Stellen zurück auf z.Bsp.113. Alles nichts hochdramatisches, aber vielleicht sollte man da nochmal drauf schauen. Hier noch die RAW Definition des Gerätes

Code Auswählen Erweitern

defmod MQTT2_z2t_AA21 MQTT2_DEVICE z2t_AA21
attr MQTT2_z2t_AA21 IODev MQTTBroker
attr MQTT2_z2t_AA21 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_z2t_AA21 icon light_control
attr MQTT2_z2t_AA21 jsonMap Dimmer:brightness Power:state Device:0 Hue:hue Sat:saturation CT:ct
attr MQTT2_z2t_AA21 model tasmota_zigbee2tasmota_light_cct_hue
attr MQTT2_z2t_AA21 readingList tele/zb2tasmota/AA21/SENSOR:.* { $EVENT =~ s/"Power":1/"Power":"on"/g;; $EVENT =~ s/"Power":0/"Power":"off"/g;; $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xAA21.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef  }
attr MQTT2_z2t_AA21 room MQTT2_DEVICE
attr MQTT2_z2t_AA21 setExtensionsEvent 1
attr MQTT2_z2t_AA21 setList on cmnd/zb2tasmota/ZbSend {"device":"0xAA21","send":{"Power":"On"}}\
  off cmnd/zb2tasmota/ZbSend {"device":"0xAA21","send":{"Power":"Off"}}\
  brightness:colorpicker,BRI,0,5,254 cmnd/zb2tasmota/ZbSend { "device":"0xAA21", "send":{"Dimmer":$EVTPART1} }\
  dimup:noArg cmnd/zb2tasmota/ZbSend { "device":"0xAA21", "send":{"DimmerUp":""} }\
  dimdown:noArg cmnd/zb2tasmota/ZbSend { "device":"0xAA21", "send":{"DimmerDown":""} }\
  ct:colorpicker,CT,153,5,370 cmnd/zb2tasmota/ZbSend { "device":"0xAA21", "send":{"CT":$EVTPART1} }\
  hue:colorpicker,HUE,0,1,254 cmnd/zb2tasmota/ZbSend { "device":"0xAA21", "send":{"Hue":$EVTPART1} }\
  saturation:colorpicker,BRI,0,1,254 cmnd/zb2tasmota/ZbSend { "device":"0xAA21", "send":{"Sat":$EVTPART1} }
attr MQTT2_z2t_AA21 setStateList on off

setstate MQTT2_z2t_AA21 off
setstate MQTT2_z2t_AA21 2020-08-30 22:15:15 ColorMode 0
setstate MQTT2_z2t_AA21 2020-08-30 22:26:07 Endpoint 1
setstate MQTT2_z2t_AA21 2020-08-30 22:26:07 LinkQuality 65
setstate MQTT2_z2t_AA21 2020-08-30 22:15:15 X null
setstate MQTT2_z2t_AA21 2020-08-30 22:15:15 Y null
setstate MQTT2_z2t_AA21 2020-08-30 22:10:14 associatedWith MQTT2_DVES_AAFFC1
setstate MQTT2_z2t_AA21 2020-08-30 22:10:59 attrTemplateVersion 20200805
setstate MQTT2_z2t_AA21 2020-08-30 22:15:15 ct 370
setstate MQTT2_z2t_AA21 2020-08-30 22:15:15 hue 35
setstate MQTT2_z2t_AA21 2020-08-30 22:15:15 saturation 254
setstate MQTT2_z2t_AA21 2020-08-30 22:26:07 state off


[Beta-User]

Wow, hier war ja einiges los...

Also: Ein paar der aufgetauchten Fragen (v.a.: was wird angezeigt) sind über den Link https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Allgemeine_Hinweise zu finden. Das Problem von Billy dürfte gewesen sein, dass manuell angelegte MQTT2_DEVICEs in der Regel keine readingList haben => filter schlägt zu...

Dass es Unterschiede zwischen Anweisung und Rückmeldung geben kann, ist auch ein gelegentliches Phänomen und hängt vermutlich mit Rundungen bei Umrechnungen (HEX<=>dezimal bzw. ZigBee-interner Wert) auf den verschiedenen Ebenen zusammen; ~5% Abweichung sind mir allerdings bisher nicht über den Weg gelaufen; HUE ist in der Hinsicht aber auch speziell, weil wohl jedes Leuchtmittel irgendeinen anderen Wertebereich haben will (?; gemeint ist die Kommunikation auf der ZigBee-Seite).

Was den BWM angeht, meine ich mich bei deconz/zigbee2mqtt zu erinnern, dass der etwas speziell ist (?); man könnte zwar einen Timer (z.B. watchdog) nutzen, um den auf "nomotion" zu setzen, ist dann aber auch nicht viel weiter wie wenn man einfach alle Events durchläßt (kein eocr-Attribut  setzt) und dann eben auf jede eingehende Nachricht reagiert.

Zum Cube kann ich weiter wenig sagen, aber das klingt danach, als wäre es ggf. einfacher, den rotate-Teil via userReading in das "allgemeine" Event-Format zu übersetzen; im Rahmen von readingList ist es sehr viel komplizierter... (falls das zu kryptisch ist: bitte nachfragen).

Was Sprachsteuerung angeht, habe ich grade keine Idee. Funktioniert es, wenn das Sprachsteuerungs-template "solo" angewendet wird?