attrTemplate für ZigBee2Tasmota

[Beta-User]

Du brauchst dich nicht mit fremden Federn schmücken...

Es würde reichen, einfach den (sinnvollen) MQTT-Verkehr hier zu dokumentieren, dann bräuchen wir auch nicht irgendwelche suboptimalen Konstruktionen von externen (Werbe?)-Webseiten diskutieren, sondern könnten zusammen eine "vernünftige" und für andere "easy to adopt"-Lösung erarbeiten...

Was ich bisher weiß:
- Ein Tasmota-ESP dient als bridge. Dafür sollte es ein passendes attrTemplate geben, das dann z.B. auch ein "permit join" ermöglicht. Fragment:

Code Auswählen Erweitern

defmod zigbee_Tasmota MQTT2_DEVICE ZigBee2MQTT
attr zigbee_Tasmota setList permit_join:0,1,99 cmnd/ZigBee2MQTT/ZbPermitJoin $EVTPART1
attr zigbee_Tasmota readingList tele/ZigBee2MQTT/STATE json_raw_TELE\
  stat/ZigBee2MQTT/RESULT json_raw_STATE
- Da sollte eine Option dran, einzelne Geräte in passende "Detail-Geräte" auszulagern (vermutlich anhand von der ShortAddr). Ginge über "set
zigbee_Tasmota attrTemplate <passenderTemplatename>"
Dann könnte man nämlich auch Rückmeldungen auswerten, wenn z.B. deine Osram über eine Fernbedienung aus- oder eingeschaltet wird... In Senderichtung wäre z.B. dummy+DOIF in etwa gleichbedeutend mit diesem kleinen MQTT2_DEVICE-Fragment:

Code Auswählen Erweitern


defmod zigbee_Osram1 MQTT2_DEVICE 0xC1FF
attr zigbee_Osram1 setList on cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"On"}}\
  off cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"Off"}}
attr zigbee_Osram1 setStateList on off
Jetzt müßten wir "nur" noch die passende Rückmeldung haben, wenn tatsächlich dafür ein "on" oder "off" zurückkommt (ggf. muss via Backlog auch noch Kleinschriebung für on/off veranlaßt werden usw.).

Es wäre daher nett, wenn du einfach deinen MQTT-Verkehr im Zusammenhang liefern könntest. Denn ich glaube noch nicht wirklich, dass du diese Aussage so wiederholen würdest, wenn wir hier fertig sind :

Reine Readings von bspw. Xiaomi Fensterkontakten und einem Aqara Cube funktionieren bereits perfekt.

Bisher landet doch alles in einer Art "Einheitsdevice" und wird mit der Zeit sehr unübersichtlich, oder? MMn. sollte die Rohdaten vorübergehend sichtbar bleiben (siehe obige readingList), und dann alles, was einer bestimmten Hardware zugeordnet werden kann in einem eigenen MQTT2_DEVICE landen.

[Beta-User]

Nachdem heute "SetOption89" in den Fokus kam:

Bitte melden, falls jemand Interesse hat, das Thema weiterzuverfolgen; es sollte damit jedenfalls deutlich einfacher werden, eingehende Nachrichten einem speziellen Device zuzuordnen...

[Beta-User]

Zur Info: habe eben zwei attrTemplates zu tasmota2zigbee ins svn geschubst - komplett ungetestet .

Falls du testen kannst und magst: feel free, da ist vermutlich noch ein langer Weg zu gehen, bis das richtig rund läuft (auch mit dimmen und so...).

[kimbolero]

Sorry, habe nun schon ewig nicht mehr hier im Forum bzw im Beitrag reingeschaut.
@Beta-User:

Zur Info: habe eben zwei attrTemplates zu tasmota2zigbee ins svn geschubst - komplett ungetestet .

Bedeutet, ich update mein FHEM und dann?
Bin gerne bereit ein wenig zu testen - was müsste ich machen, wenn das Update erfolgreich durch ist?

[Beta-User]

Du speicherst deine beiden (?) vorhandenen Devices als RAW-Definitionen weg und löschst sie dann. Dann den ESP neu starten => autocreate erstellt ein Device.
Darauf dann das "bridge"-template anwenden. Dann über die Tasmota-Konsole oder den "Freitext"-Setter mal die Lampe anschalten (es gibt im ESP-Bereich einen Thread von locutus, da steht, wie); dann sollte autocreate auch die Lampe als neues Device anlegen, auf das du dann das 2. template anwenden kannst. Dann solltest du eine "normale" Leuchte haben, die man auch dimmen kann...

(Falls das zu kurz war, einfach nachfragen; die Vorgehensweise ist hier dann im Prinzip genau das, was auch zu zugbee2mqtt im Wiki zu finden ist).

[kimbolero]

Hört sich einfacher an als es ist
Ich habe die beiden Devices (Lampe und Dummy) glöscht - mein Zigbee2MQTT Device (Tasmoata2Zigbee) ist weiterhin vorhanden und zeigt weiterhin das Reading der Osram-Lampe. Denke das ist so i.O.
Nach Neustart vom ESP wird per Autocreate in FHEM nichts angelegt. Lampe habe ich über die Tasmota Konsole wie folgt ein/ausgeschaltet:

Code Auswählen Erweitern

ZbSend {"device":"Osram1","send":{"Power":"On"}}
ZbSend {"device":"Osram1","send":{"Power":"Off"}}

Die zwei Templates soll/kann ich ja erst nutzen, wenn das Device automatisch in FHEM angelegt wurde.

Jetzt mal anders rum gefragt: soll ein eigenes separates Device per autocreate angelegt werden, oder das Device unter dem Zigbee2MQTT Device als Reading erscheinen?

Habe jetzt noch gesehen, dass im Zigbee2MQTT Device das Bridge template auswählbar ist, klicke ich auf "set" kommt folgende Meldung:

Code Auswählen Erweitern

Specify the unknown parameters for zigbee2mqtt_bridge:
base topic as set in configuration.yaml of the zigbee2mqtt bridge [Eingabefeld]

[kimbolero]

Hier noch ein Log vom MQTT2Zigbee Device, wenn ich die Lampe über die Konsole einschalte:

Code Auswählen Erweitern

2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 CMD: ZbSend {"device":"Osram1","send":{"Power":"On"}}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 SRC: WebConsole from 192.168.178.21
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 CMD: Group 0, Index 1, Command "ZBSEND", Data "{"device":"Osram1","send":{"Power":"On"}}"
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 SendZCLCommand_P: zcl_cmd =
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZigbeeZCLSend device: 0xC1FF, group: 0x0000, endpoint:0, cluster:0x0006, cmd:0x01, send:""
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZbSend: shortaddr 0xC1FF, groupaddr 0x0000, cluster 0x0006, endpoint 0x03, cmd 0x01, data
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: ZbZNPSent 240202FFC100000000000003000001060017301E0300011701
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT ZbSend: Done
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 MQT: stat/ZigBee2MQTT/RESULT = {"ZbSend":"Done"}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: Bytes follow_read_metric = 2920
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: {"ZbZNPReceived":"640200"}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: Bytes follow_read_metric = 2927
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: {"ZbZNPReceived":"45C4FFC100"}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: Bytes follow_read_metric = 2956
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: {"ZbZNPReceived":"4480000117"}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: Bytes follow_read_metric = 2956
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: {"ZbZNPReceived":"45C4FFC100"}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: ZbZNPSent 240202FFC100000000000003000001060018301E05000018000000
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: Bytes follow_read_metric = 2961
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: {"ZbZNPReceived":"448100000600FFC10301004E0044207700000518170B0100FFC11D"}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":6,"srcaddr":"0xC1FF","srcendpoint":3,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":78,"securityuse":0,"seqnumber":0,"timestamp":7807044,"fc":"0x18","manuf":"0x0000","transact":23,"cmdid":"0x0B","payload":"0100"}}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT ZbResponse_LinkQuality: 78
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT ZbResponse_Device: 0xC1FF
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT ZbResponse_Name: Osram1
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT ZbResponse_Command: 0006!01
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT ZbResponse_Status: 0
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT ZbResponse_StatusMessage: SUCCESS
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT ZbResponse_Endpoint: 3
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 MQT: tele/ZigBee2MQTT/RESULT = {"ZbResponse":{"Device":"0xC1FF","Name":"Osram1","Command":"0006!01","Status":0,"StatusMessage":"SUCCESS","Endpoint":3,"LinkQuality":78}}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: Bytes follow_read_metric = 2968
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:13 ZIG: {"ZbZNPReceived":"640200"}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: Bytes follow_read_metric = 2982
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: {"ZbZNPReceived":"45C4FFC100"}
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: Bytes follow_read_metric = 3014
2020-08-01_21:47:14 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: {"ZbZNPReceived":"4480000118"}
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: Bytes follow_read_metric = 3014
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: {"ZbZNPReceived":"45C4FFC100"}
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: Bytes follow_read_metric = 3014
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: {"ZbZNPReceived":"448100000600FFC103010051002423770000081818010000001001FFC11D"}
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":6,"srcaddr":"0xC1FF","srcendpoint":3,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":81,"securityuse":0,"seqnumber":0,"timestamp":7807780,"fc":"0x18","manuf":"0x0000","transact":24,"cmdid":"0x01","payload":"0000001001"}}
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 ZIG: ZbZCLRawReceived: {"0xC1FF":{"0006/0000":1}}
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT ZbReceived_Osram1_Endpoint: 3
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT ZbReceived_Osram1_LinkQuality: 81
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT ZbReceived_Osram1_Power: 1
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT ZbReceived_Osram1_Device: 0xC1FF
2020-08-01_21:47:15 MQTT2_ZigBee2MQTT LOGGING: 20:47:14 MQT: tele/ZigBee2MQTT/SENSOR = {"ZbReceived":{"Osram1":{"Device":"0xC1FF","Power":1,"Endpoint":3,"LinkQuality":81}}}


[Beta-User]

OK, war wohl zu kurz, meine Kurzfassung; dann doch etwas ausführlicher:

Das mit den zwei war so gemeint, dass alle MQTT2_DEVICE-Geräte gelöscht werden, die mit diesem Tasmota zusammenhängen. Sonst gibt es keine Aktivität von autocreate, weil das (vereinfacht gesagt) nur aktiv wird, wenn ein Topic kommt, der noch in keiner readingList auftaucht.

Im Prinzip kannst du auch auf das vorhandene MQTT2_DEVICE das attrTemplate "tasmota_zigbee2tasmota_bridge" anwenden, ich wollte durch das Löschen nur sicherstellen, dass du ggf. Schwachstellen aufdeckst (wie das Erscheinen eines Dialogfelds wie das zu zigbee2mqtt; sowas passiert in der Regel nur, wenn bestimmte Parameter nicht aufgelöst werden können).

Was man im Ergebnis haben sollte, wäre 1+n (MQTT2_DEVICE-TYPE-) Devices, nämlich die tasmota_zigbee2tasmota_bridge (steht für den ESP+CC253x und erlaubt z.B. permit join einzuschalten) und je ein eigenes Device für jedes ZigBee-Gerät (wie die A60; diese Devices sollten dann über die Bridge - genauer: die dortige bridgeRegexp - automatisch angelegt werden). Die A60 wird in diesem Konzept also in der Regel nicht über das Bridge-FHEM-Device gesteuert, sondern über ein anderes, eigenes Device .

[kimbolero]

Habe nun das MQTT-Device ebenfalls gelöscht - direkt im Anschluss wurde dies auch erneut automatisch gefunden und angelegt.
Im ReadingList steht nun automatisch folgendes drin:

Code Auswählen Erweitern

ZigBee2MQTT:stat/ZigBee2MQTT/LOGGING:.* LOGGING
ZigBee2MQTT:tele/ZigBee2MQTT/STATE:.* { json2nameValue($EVENT) }
ZigBee2MQTT:tele/ZigBee2MQTT/SENSOR:.* { json2nameValue($EVENT) }

Wollte nun mit

Code Auswählen Erweitern

set MQTT2_ZigBee2MQTT attrTemplate tasmota_zigbee2tasmota_bridge
setzen - nun folgt dieser Dialog:

Code Auswählen Erweitern

Specify the unknown parameters for tasmota_zigbee2tasmota_bridge:
Command topic prefix, without trailing / [Eingabefeld]
info topic prefix, without trailing / [Eingabefeld]
ack topic prefix, without trailing / [Eingabefeld]

Topics gibt es in der Tasmota-MQTT-Einstellung einige, jedoch im anderen Wortlaut - wird im nachfolgenden Link als Bild dargestellt:
http://wiki.gorjup.de/lib/exe/detail.php?id=public%3Afhem_zigbee2tasmota&media=public:zigbee2tasmoata_mqtt1.jpg

[Beta-User]

Der Neustart fehlte, oder?

Daher gab es keinen "LWT"-Pfad in der readingList, was zu genau der Rückfrage führt (wie bei allen Tasmota-Geräten)...
Ich schreibe nicht ganz umsonst wenigstens die Stichworte auf:

Dann den ESP neu starten => autocreate erstellt ein Device.
Darauf dann das "bridge"-template anwenden.

Generell versuche ich, bei allen attrTemplate mit vergleichbarer Funktionalität auch die Vorgehensweise vergleichbar zu halten, und das bedeutet: Den jeweiligen Dienst/Microcontroller/... neu starten, damit die "typischen" Elemente _vollständig_ da sind .

[kimbolero]

In der Tat - der Neustart wurde nicht gemacht, da das MQTT-Device direkt nach dem Löschen angelegt wurde. Habe nun
1. den ESP ausgesteckt
2. Alle MQTT Devices gelöscht (war nur eins mit dem dazugehörigen Log-File)
3. FHEM Neustart
4. ESP wieder eingesteckt und es wurde automatisch erneut das Device angelegt

Nun werden die Devices, welche zuvor nur als Readings vorhanden waren, als eigenständige MQTT2_Devices angelegt 

Wie sind die nächsten Schritte, damit ich für die A60 nun ein-/ausschalten kann? Muss ich hierfür ein Template einspielen?

Als Beispiel im Device wird folgendes angezeigt:

Code Auswählen Erweitern

attr dev setList\
    on tasmota/sonoff/cmnd/Power1 on\
    off tasmota/sonoff/cmnd/Power1 off

Wie muss das setList aufgebaut sein, damit die folgenden Befehle funktionieren? Aus dem Wiki werde ich leider nicht schlau.

Code Auswählen Erweitern

on cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"Off"}}\
off cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"Off"}}

[Beta-User]

OK, dann hat der Hauptteil geklappt, nämlich SetOption89 zu setzen, damit jedes Device seinen eigenen Topic bekommt .
Zum Rest hatte ich mal das hier in Kurzform geschrieben:

dann sollte autocreate auch die Lampe als neues Device anlegen, auf das du dann das 2. template anwenden kannst. Dann solltest du eine "normale" Leuchte haben, die man auch dimmen kann...

Das 2. template war: "tasmota_zigbee2tasmota_light_dimmer"

Bitte bei Fragen ab jetzt immer ein komplettes RAW-listing liefern (unten auf der Detailansicht des Gerätes gibt es einen entsprechenden Link, siehe auch https://wiki.fhem.de/wiki/Import_von_Code_Snippets).

Ggf. können wir dann - wenn jetzt so langsam das Prinzip erkennbar wird - gerne auch die weiteren Devices "vertemplaten", die du so hast; ich bräuchte dazu jeweils halt ein "RAW"...

[kimbolero]

Direkt mal versucht mit dem 2. Template - es erscheint folgende Fehlermeldung:

Code Auswählen Erweitern

ERROR executing perl-code { AttrVal("MQTT2_z2t_C1FF","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)/.*/([^/]+)/SENSOR)?:, ? "$3" : undef } for param DEV_ID: Unmatched ) in regex; marked by <-- HERE in m/([^:]*)\b(tele|cmnd|stat)/.*/([^/]+)/SENSOR) <-- HERE ?:/ at (eval 4384) line 1.

Hier die RAW Definition:

Code Auswählen Erweitern

defmod MQTT2_z2t_C1FF MQTT2_DEVICE z2t_C1FF
attr MQTT2_z2t_C1FF IODev myBroker
attr MQTT2_z2t_C1FF alias Osram1
attr MQTT2_z2t_C1FF readingList tele/ZigBee2MQTT/C1FF/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_C1FF room MQTT2_DEVICE

setstate MQTT2_z2t_C1FF on
setstate MQTT2_z2t_C1FF 2020-08-02 13:00:28 ZbReceived_Osram1_Device 0xC1FF
setstate MQTT2_z2t_C1FF 2020-08-02 13:00:28 ZbReceived_Osram1_Endpoint 3
setstate MQTT2_z2t_C1FF 2020-08-02 13:00:28 ZbReceived_Osram1_LinkQuality 76
setstate MQTT2_z2t_C1FF 2020-08-02 13:00:28 ZbReceived_Osram1_Power 0
setstate MQTT2_z2t_C1FF 2020-08-02 13:00:24 associatedWith MQTT2_ZigBee2MQTT
setstate MQTT2_z2t_C1FF 2020-08-02 13:39:46 state on

[Beta-User]

OK, kannst du die betreffende Klammer mal entfernen?
Zeile 1662 in /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template sollte dann so aussehen:

Code Auswählen Erweitern

par:DEV_ID;BT short ID, hex value without leading 0x;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)/.*/([^/]+)/SENSOR?:, ? "$3" : undef }

danach AttrTemplate neu laden mit (FHEM-Kommandozeile):

Code Auswählen Erweitern


{ AttrTemplate_Initialize() }

[kimbolero]

Erl - danach kommt folgende Meldung, wenn ich das Template setzen möchte:

Code Auswählen Erweitern

<html><input type='hidden' value='set MQTT2_z2t_C1FF attrTemplate speechcontrol_alexa_specials'>
<p>Specify the unknown parameters for speechcontrol_alexa_specials:</p>
<table class='block wide'>
<tr>
<td>Set a new alexaName</td>
<td><input type='radio' name='s' value='RADIO_SETalexaNAME'></tr>
<tr>
<td>Leave alexaName attribute empty</td>
<td><input type='radio' name='s' value='RADIO_DoNotSetalexaName'>
</tr>
<tr>
<td>Discard genericDeviceType attribute</td>
<td><input type='radio' name='s' value='RADIO_Delete_gDT'>
</tr>
<tr>
<td>Skipp setting speech controll specific attributes</td>
<td><input type='radio' name='s' value='RADIO_SKIPP_SCONTROLL'>
</tr>
</table>
<script>

Sollte mit dem Fehler nun nicht zusammenhängen, aber einige TD´s in der Table werden nicht geschlossen (</td>)

Edit: Das Template scheint er übernommen zu haben (trotz der obigen Fehlermeldung/dem Hinweis), ein/ausschalten über den Button funktioniert einwandfrei (ich habe die Lampe in einer Stehlampe drin, welche ich über den Hauptschalter wohl vorhin ausgeschaltet hatte - hat mit den vorherigen Einträgen jedoch keinen Zusammenhang)

Edit1: Ein An- bzw. Ausschalten über die Tasmota Konsole mit entsprechendem Befehl verändert auch das Power-Reading in FHEM

Code Auswählen Erweitern

ZbReceived_Osram1_Power

Edit2: Eine Trafri E27 Birne funktioniert identisch, auch über das von Dir genannte Template.

Weitere Geräte:
Xiaomi Temperatur/Humidity Sensor --> gibt nur Werte aus, habe ich mit SetFormat schön angepasst
Xiaomi Cube --> gibt auch nur Werte aus (bisher nur Spielerei)
Xiaomi Fensterkontakt --> gibt nur Wert aus --> StateFormat macht´s schöner
Tradfri Bewegungsmeldung --> bisher noch kein Einsatzzweck - hier gibt´s im Wiki ein Template (sofern ih mich richtig erinnere)