attrTemplate für ZigBee2Tasmota

[Billy]

Das Problem von Billy dürfte gewesen sein, dass manuell angelegte MQTT2_DEVICEs in der Regel keine readingList haben => filter schlägt

Vielleicht fange ich mal von vorne an.
Ich habe mir eine Sonoff Zigbee Bridge zugelegt https://zigbee.blakadder.com/Sonoff_ZBBridge.html und mit
Tasmota geflasht. In Tasmota eingebunden habe ich:

Code Auswählen Erweitern


{"ZbStatus1":[{"Device":"0x4CB8","Name":"EZ-IKEA-Lampe"},{"Device":"0x24E2","Name":"EZ-IKEA-Button"},{"Device":"0x52D1","Name":"WZ-IKEA-Lampe"},{"Device":"0x3208","Name":"WZ-IKEA-Button
d.h. zwei IKEA Bulb die je mit einem IKEA Button verbunden sind.
https://user-images.githubusercontent.com/23422753/91439378-218a1c00-e86d-11ea-984e-80121bb9016a.png
Die Steuerung sowohl über die Sonoff Zigbee Bridge als auch über die Buttons funktioniert problemlos!

Zum Einbinden in FHEM wollte ich die Gelegenheit nutzen mich mal in mqtt2 einzuarbeiten.
Da ich den Mosquitto auf meiner Synology NAS mit zig mqtt-Devices laufen habe, kommt für mich nur die Einbindung über MQTT2_CLIENT
in Frage.

Code Auswählen Erweitern

defmod mc MQTT2_CLIENT 192.168.148.2:1883
attr mc autocreate no
attr mc room MQTT2_DEVICE

setstate mc opened
setstate mc 2020-08-30 21:26:36 state opened
Da kann ja wohl nichts falsch sein?
Habe dann verschiedene WIKIS gelesen und bin beim WIKI Zigbee2Tasmota-MQTT https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT gelandet.
Dort steht:

Aufgrund der sehr verschachtelten JSON-Strukturen, die das Gateway verwendet, ist in jedem Fall dringend anzuraten, MQTT2_DEVICE als Client-Modul zu verwenden.

Also habe ich ein MQTT2 DEVICE angelegt

Code Auswählen Erweitern

defmod MQTT2_DVES_05697B MQTT2_DEVICE DVES_05697B
attr MQTT2_DVES_05697B IODev mc
attr MQTT2_DVES_05697B autocreate 1
attr MQTT2_DVES_05697B room MQTT2_DEVICE
und war erstaunt, dass ich das im WIKI erwähnte Template set [Zigbee2tasmota] attrTemplate  tasmota_zigbee2tasmota_bridge
nicht gefunden habe.
Vermutlich habe ich was missverstanden.

Gruss Billy

[Beta-User]

Zum Einbinden in FHEM wollte ich die Gelegenheit nutzen mich mal in mqtt2 einzuarbeiten.

...da hast du dir halt einen der steilstmöglichen Einstiege überhaupt ausgesucht...

Da ich den Mosquitto auf meiner Synology NAS mit zig mqtt-Devices laufen habe, kommt für mich nur die Einbindung über MQTT2_CLIENTin Frage.

Na ja, MQTT2_SERVER auf einen anderen Port legen wäre zum Starten vermutlich auch nicht das Problem; du kannst "fertige" Devices dann auch später noch auf den CLIENT als IO umhängen .

Code Auswählen Erweitern

attr mc autocreate no

Da kann ja wohl nichts falsch sein?

Jein: das autocreate-Attribut kannst du auch löschen, das ist beim CLIENT per default aus. Das "Problem" ist, dass ohne vorhandenes readingList-Attribut halt einiges weggefiltert wird, von daher erscheint das für z2t elementare attrTemplate nicht in der drop-down-Liste. Du kannst es aber über die Kommandozeile anwenden - im Unterschied zu den übrigen, die gar nicht geladen werden und erst hinterher verfügbar sein werden. Dann erscheint eine Rückfrage zur Topic-Struktur (mehrere Parameter sind einzutragen), die sonst automatisch aufgelöst werden würde.

Vermutlich habe ich was missverstanden.

Eigentlich scheinst du nur meinen Hinweis auf das Wiki/die fehlende readingList (als Kritik, und nicht als Hilfestellung) mißverstanden zu haben.

Aber wie gesagt: es ist recht "steil", ausgerechnet mit dieser attrTemplate-Familie@CLIENT einzusteigen. Ich würde empfehlen, das LWT-Topic in die readingList des MQTT2_DVES_05697B einzutragen, der Rest sollte dann gem. Wiki funktionieren. Zu Client gibt es auch ein "Sortier-Template", mit dem man dann auch autocreate einschalten könnte; wenn du bereits einiges am Laufen hast, würde ich damit dann allerdings erst mal auf einem Testsystem rumspielen - da werden uU. sehr viele Devices erstellt, die du (erst mal ) gar nicht brauchst. Aber so könntest du auch erst mal mit "gewöhnlichen" Tasmota-Geräten usw. ein Gefühl dafür bekommen, wie welche Attribute wirken .

[TL60]

Was den BWM angeht, meine ich mich bei deconz/zigbee2mqtt zu erinnern, dass der etwas speziell ist (?)

Denke ich auch, weil mein Bruder nutzt ihn unter Deconz/Phoscon und hat auch das Problem, das er nach dem Auslösen eine Zeit gesperrt zu sein scheint, dort hat man das Problem wohl auch in der Phoscon App gelöst (soweit ich weiss). Mich stören hier die kryptischen Readingnamen, wobei occupancy unter Zigbee2Mqtt eigentlich auch nicht richtig ist, aber das nur am Rande.

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).

Also ich kann damit leben das es so ist wie es ist. Ich konnte bislang nur alles was ich brauchte über ein DOIF auf das Reading action abwickeln und würde jetzt für die beiden rotate_left/rotate_right ein eigenes DOIF bauen. Ich hatte das auch nur angesprochen, weil es ja leicht unterschiedlich zu Zigbee2Mqtt ist.

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

da kann ich erst heute nachmittag / abend etwas zu sagen

[kimbolero]

Also ich kann damit leben das es so ist wie es ist.

Mir geht es identisch - ob 1 oder 3 Readings ist schlußendlich egal, ist kein riesen Aufwand das entsprechend über DOIF abzubilden.

[TL60]

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

da kann ich erst heute nachmittag / abend etwas zu sagen

Ich vermute das es daran liegt, das noch kein Speechtemplate für farbige Lampen gibt ?   Gehe ich in die attrtemplate einer Zigbee2tasmota__cct Lampe werden mir 2 templates angeboten

speech_recognition_general_naming_master_template u. speechcontrol_general_naming_master_template

Mir ist auch noch aufgefallen, das in der Beschreibung zum template steht:

This template will call several sub-templates - dependent on the speech speechcontrol solutions which are in use in your installation

Ich nutze allerdings sowohl  Siri als auch Alexa kann das auch noch Teil des Problems sein?

[Beta-User]

...über das "Angebot" muß ich vermutlich nochmal drüber; eigentlich sind diese templates nämlich gar nicht so wirklich für Endanwender gedacht, dementsprechend ist vermutlich auch die desc. eher kryptisch.

(Die Namen sind komisch, eigentlich sollte es nur noch das 2. geben).

Dass es nichts spezielles für farbige Lampen gibt, ist der Tatsache geschuldet, dass bei der Sprachsteuerung tendenziell "weniger ist mehr" gilt. Es gibt dazu einen Thread (gestartet von TomLee), in dem auch etwas nachvollziehbarer wird, warum die Struktur der templates  so ist, wie sie ist (wenn man das im Quelltext sieht, ist es "komisch"). Das sollte eigentlich auch passen, wenn man irgendeine beliebige Kombi der drei unterstützten Varianten hat...
An sich glaube ich nicht, dass da großes Verbesserungspotential besteht: passen die setter- bzw. Reading-Namen, geht vieles automatisch (daher tendiere ich auch dazu, ganz bestimmte Namenskonventionen einzuhalten ).

[Billy]

...da hast du dir halt einen der steilstmöglichen Einstiege überhaupt ausgesucht...

Eigentlich scheinst du nur meinen Hinweis auf das Wiki/die fehlende readingList (als Kritik, und nicht als Hilfestellung) mißverstanden zu haben.

Deine Hinweise hatte ich nicht als Kritik verstanden, ich wollte eigentlich eher ausdrücken, dass ich eventuell etwas noch nicht verstanden hatte.

Ich habe mir den Einstieg jetzt erleichtert und einfach ein MQTT2 Device manuell angelegt.
Jetzt läuft alles so wie von mir gewünscht. Die Vereinzelung der Devices ist ja relativ einfach wenn man in Tasmota das Kommando setoption89 kennt.
Werde wohl für Zigbee auf MQTT2_CLIENT mit MQTT2_DEVICE setzen.
Vielen Dank für deine hervorragende Vorarbeit.
Billy

[Beta-User]

Danke für die nette Rückmeldung!

Sobald man (für die jeweilige Gruppe an Geräten bzw. eine bestimmte topic-Struktur) eine passende bridgeRegexp hat, ist es in der Tat egal, ob man MQTT2_CLIENT oder MQTT2_SERVER verwendet. V.a. bei solchen "bridge"-Konstruktionen wie hier besteht dann gar kein praktischer Unterschied mehr bei den "Enddevices"...

(Falls die json2nameValue-Frage hier was mit diesem Thread zu tun haben sollte: ist mir zu spät aufgefallen....

Habe dann verschiedene WIKIS gelesen und bin beim WIKI Zigbee2Tasmota-MQTT https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT gelandet.
Dort steht:
[...]

Ich nehme an, dass du den zitierten Satz aus dem Wiki jetzt so bestätigen kannst....? (Die json2nameValue()-Verwendung im MQTT_GENERIC_BRIDGE-Kontext kannte ich noch nicht, von daher könnte man die Unterschiede (in Teilen!) darüber wieder verringeren. Allerdings denke ich, dass es im Ergebnis einfacher ist, ggf. einfach M2_CLIENT aufzusetzen und dann halt diesen Teil über M2_DEVICE abzubilden, statt mühevoll dazu passende dummy zusammenzuschustern?)

[Billy]

Danke für die nette Rückmeldung!

ggf. einfach M2_CLIENT aufzusetzen und dann halt diesen Teil über M2_DEVICE abzubilden, statt mühevoll dazu passende dummy zusammenzuschustern?)

Gern geschehen,
was mir noch aus meinen Erfahrungen mit der Generic Bridge noch fehlen würde,
ist die Möglichkeit mit dem M2_DEVICE weitere subcribes einzurichten und den angelegten readings zuzuordnen. Das geht in der G-Bridge relativ problemlos.

[Beta-User]

Du mußt nur die readingList entsprechend ergänzen, da stehen die ganzen "abbonierten subscriptions" drin (Wildcards sind aber nicht MQTT-like, sondern normale regex). Das mapping auf die passenden Readingnamen erfolgt dann entweder im Klartext (siehe die meisten Shelly-Readings), oder via jsonMap/json2nameValue() bzw. in ganz seltenen Fällen auch durch "echtes Perl" mit Rückgabe eines Hashes.

Das ganze führt hier aber zu weit, falls da spezieller Bedarf besteht: Neuen Thread in diesem Forenbereich aufmachen... (ich suche dann ggf. die passenden Bausteinchen aus der mqtt2.template raus. Da ist vermutlich jetzt schon soviel Material zum Weiterspielen drin, dass man im Prinzip "alles" machen kann; hier ist auch "ziemlich viel" eingeflossen , das Problem ist jetzt eher, das passende Bausteinchen wiederzufinden.)

[psycho160]

ICh glaub es passt hier ganz gut dazu, ich hänge gerade bei einer IKEA Tradfri LED (HUE) die mir einfach die Farbeinstellungen nicht nehmen will.

Ich habe sie als MQTT2_Client über die Tasmota Bridge (zigbee2tasmota) und mitt dem template "tasmota_zigbee2tasmota_light_cct_hue" eingebunden.

Soweit sogut, dimmen, ein und aus haut alles hin.

Aber ich kann einfach die Farbe nicht verändern. Im Tasmota Log sehe ich dann immer

Code Auswählen Erweitern

"StatusMessage":"UNSUP_CLUSTER_COMMAND"

Das Template schickt ja

Code Auswählen Erweitern

{ "device":"0xDEV_ID", "send":{"Hue":$EVTPART1} }\ das Kommando "Hue" was die Lampe anscheinend nicht kennt.

Wenn ich es mit "color" versuche 

Code Auswählen Erweitern

ZBSEND{ "device":"0x6761", "send":{"color":"#ff0000"} } dann flackert die Lampe ganz komisch (aber in Farbe, immerhin...) und geht wieder aus.

Weiß irgendjemand den genauen Syntax den die Tradfri Lampe braucht um die Farbeinstellungen ordentlich zu übernehmen? Oder habe ich das falsche template?

lg

[Beta-User]

Hmmm, evtl. ist das attrTemplate unvollständig:

Wenn ich die Doku auf https://tasmota.github.io/docs/Zigbee/#zigbee-and-hue-emulation-for-alexa richtig interpretiere, muss man das Device erst auf der MCU als "Hue-fähig" kennzeichnen?
Danach müßte für CCT+Hue an das IO (nach Auflösung der Parameter)

Code Auswählen Erweitern

CMNDTOPIC/ZbLight 0xDEV_ID,5gesendet werden?

Falls du testen magst (vorhandenen Code ersetzen und AttrTemplate_Initialize() aufrufen):

Code Auswählen Erweitern


name:tasmota_zigbee2tasmota_light_cct_hue
prereq:{my @devices=devspec2array("model=tasmota_zigbee2tasmota_bridge");;return 1 if $devices[0];;return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*tele.*/..../SENSOR:.*
desc:This template is meant to configure a dimmable bulb device with ful hue options.<br>NOTE: Early testing version, not yet tested, just build according to https://forum.fhem.de/index.php/topic,112253.0.html<br>Might still need some changes!
order:A_01u02c
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/[^/]+/SENSOR:, ? "${1}cmnd$3" : undef }
par:DEV_ID;ZigBee short ID, hex value without leading 0x;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)/.*/([^/]+)/SENSOR?:, ? "$3" : undef }
par:IO_DEV;Currently used IO;{ InternalVal("DEVICE","LASTInputDev",AttrVal("DEVICE","IODev",undef)) }
set DEVICE attrTemplate tasmota_zigbee2tasmota_light_dimmer \CALLSPEECHRECOGN=1
set IO_DEV publish CMNDTOPIC/ZbLight 0xDEV_ID,5
attr DEVICE setList on CMNDTOPIC/ZbSend {"device":"0xDEV_ID","send":{"Power":"On"}}\
  off CMNDTOPIC/ZbSend {"device":"0xDEV_ID","send":{"Power":"Off"}}\
  brightness:colorpicker,BRI,0,5,254 CMNDTOPIC/ZbSend { "device":"0xDEV_ID", "send":{"Dimmer":$EVTPART1} }\
  dimup:noArg CMNDTOPIC/ZbSend { "device":"0xDEV_ID", "send":{"DimmerUp":""} }\
  dimdown:noArg CMNDTOPIC/ZbSend { "device":"0xDEV_ID", "send":{"DimmerDown":""} }\
  ct:colorpicker,CT,153,5,370 CMNDTOPIC/ZbSend { "device":"0xDEV_ID", "send":{"CT":$EVTPART1} }\
  hue:colorpicker,HUE,0,1,254 CMNDTOPIC/ZbSend { "device":"0xDEV_ID", "send":{"Hue":$EVTPART1} }\
  saturation:colorpicker,BRI,0,1,254 CMNDTOPIC/ZbSend { "device":"0xDEV_ID", "send":{"Sat":$EVTPART1} }
attr DEVICE model tasmota_zigbee2tasmota_light_cct_hue
setreading DEVICE attrTemplateVersion 20200930

[psycho160]

Danke für den Tipp mit dem ZbLight, aber das hat nix geholfen.
Ich bin aber nun schon etwas weitergekommen:

Bei der Tradfri Lampe sind mir 2 Readings aufgefallen: X und Y

Dann habe ich da Kommando versucht:

Code Auswählen Erweitern

ZBSEND{ "device":"0x6761", "send":{"color":"65534,65534"} }

.. und siehe da, die Lampe hat auf orange gewechselt. Anscheinend kann man mit X und Y in einem Wertebereich von 0-65534 die Farbe einstellen.

Ich hab aber absolut keine Ahnung wie ich das nun in einen Colorpicker bekomme. Das Template müsste dann für die Tradfri extra angepasst werden, damit diese Umrechnung funktioniert.

zurzeit kann ich nur random Werte versuchen und freue mich dann über die neu entdeckten Farben 


EDIT: CIE XY heißt der Farbraum anscheinend den die Ikea Tradfri verwenden -> https://community.openhab.org/t/solved-convert-hsbtype-to-cie-xy-needed-for-ikea-tradfri-control-through-deconz-rest/48825

[psycho160]

Ganz Dirty:

Hab mir daweil im Template

Code Auswählen Erweitern

hue:colorpicker,HUE,0,1,65000 cmnd/tasmota_10CD56/ZbSend { "device":"0x6761", "send":{"color":"$EVTPART1,65000"}
einen HUE Colorpicker mit Wertebereich 0-65000 gemacht und Y Wert static auf 65000 und kann jetzt wenigstens mit dem Fancy Schieberegler Farbspiele machen.

Vielleicht mag sich mal jemand den Kopf über eine Umrechnungsfunktion zerbrechen..

[Beta-User]

Danke für den Tipp mit dem ZbLight, aber das hat nix geholfen.

...das war nur ein "Schuss ins Blaue", bitte vor irgendwelchen Workarounds in FHEM erst nochmal schauen, ob die Syntax passt, das ggf. direkt über die Tasmota-Konsole einzugeben wäre usw.. Denn alles, was das Zieldevice "von sich aus" richtig macht, ist besser als Fixes auf der FHEM-Seite.

Kann aber sein, dass wir dann doch unterschiedliche templates brauchen, falls die Ziel-Devices wirklich unterschiedliche Kommandos für dasselbe Ergebnis haben müssen...

EDIT: CIE XY heißt der Farbraum anscheinend den die Ikea Tradfri verwenden -> https://community.openhab.org/t/solved-convert-hsbtype-to-cie-xy-needed-for-ikea-tradfri-control-through-deconz-rest/48825

In Color.pm sind ein paar Umrechnungen drin, evtl. kann man davon was nutzen und ggf. eine rgb2xyY-Konvertierung durchführen (und den rgb-Colorpicker verwenden?). (ggf. könnte man das dann auch dem Maintainer von Color.pm als Patchvorschlag liefern.)
Insgesamt ist das Thema aber m.E. nicht trivial, denn dann muss man z.B. auch den setList-Eintrag "in Perl schreiben" und beide Parameter (x,y) übergeben (es gibt dazu aber ein paar Beispiele in der attrTemplate-file)...