attrTemplate für ZigBee2Tasmota

Begonnen von kimbolero, 19 Juni 2020, 21:02:50

Vorheriges Thema - Nächstes Thema

Beta-User

Hmm, "A5A6" ist doch eine der Bulbs, oder?
Was du schreibst klingt danach, also würden bei FB-Schaltung doch die beteiligten Bulbs aktualisiert, und jetzt sehe ich auch, dass da der Empfang der FB-Codes durchaus quittiert wird, das kommt ja alles unter der Bulb an (irgendwie war ich auf dem Tripp, dass das von gestern die ID der FB ist, was aber falsch ist, oder?):
16:09:39 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!01":"","Power":1,"Endpoint":1,"Group":100,"LinkQuality":99}}}
Und auch der Zeitstempel paßt zur Übermittlung des empfangenen FB-Codes (0006_00).

Allerdings habe ich immer noch keine Idee, wie man das irgendwie automatisiert konsolidieren könnte. Wird vermutlich ähnlich komplex wie bei sonos, wobei wir hier ggf. in der readingList mit einer Regex auf alle beteiligten Pfade hören könnten, und die regex vermutlich auch halbautomatisiert erstellen (über eine devspec2array-Abfrage nach der Gruppenzugehörigkeit; bitte nicht irre machen lassen, das ist kryptisch und eher ein Merkposten an mich selbst).

Kannst du mal 2 Gruppen machen, in einer die FB+die beiden Aktoren, in einer nur die beiden Aktoren? Dann bitte jeweils die Gruppe mit der FB+aus FHEM bzw. (2. Gruppe) aus FHEM heraus ein- und ausschalten und dabei den MQTT-Verkehr mitschneiden?
Bitte nach dem Hinzufügen zu den beiden Gruppen auch ein RAW von beiden Aktoren (damit ich v.a. sehen kann, was dann in den gruppenbezogenen Readings drin steht, wenn es mehrere sind).

(ggf. würde mich zusätzlich interessieren, wie sich der on/off-Aktor verhält, wenn man ihn über eine Gruppe (per FHEM und/oder FB) dimmt... Ist aber ein anderes bzw. weiterführendes Thema).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

TL60

Sorry, da habe ich mich nicht präzise genug ausgdrückt und hätte dir auch den Mitschnitt aus der Tasmota Konsole mitschicken müssen
"A5A6" ist der Tradfri dimmer switch also die Remote.Und das kommt bei Taste I 15:41:32 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!01":"","Power":1,"Endpoint":1,"Group":100,"LinkQuality":31}}}
15:41:33 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":34}}}
und bei Taste0 15:42:23 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!00":"","Power":0,"Endpoint":1,"Group":100,"LinkQuality":34}}}
15:42:24 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":36}}}
. Dazu kommt noch das ich es nicht hinbekommen habe die Remote in die Gruppe aufzunehmen und zu schalten
Zitatnächster Punkt, das Hinzufügen einer Remote zu dieser Gruppe führt beim schalten der Remote zur Fehlermeldung unsupported Cluster 15:32:08 MQT: stat/zb2tasmota/RESULT = {"ZbSend":"Done"}
15:32:24 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!01":"","Power":1,"Endpoint":1,"LinkQuality":97}}}
15:32:25 MQT: tele/zb2tasmota/RESULT = {"ZbResponse":{"Device":"0xA5A6","Command":"0004!00","Status":195,"StatusMessage":"UNSUPPORTED_CLUSTER","Endpoint":1,"LinkQuality":99}} in der Konsole.
Die Remote kann ich nur per Binding an die Gruppe binden, was auch in der Doku sowohl für Zigbee2tasmota als auch für Zigbee2mqtt die richtige (einzig beschriebene) Vorgehensweise ist. Insofern sind in der Gruppe sowieso nur Lampen.
Bezüglich Wiki würde ich, weil gerade ziemlich im Thema bin, eigentlicch erst etwas zu Groups and Bindings schreiben wollen. Vielleich schaffe ich es heute Abend noch eine entsprechende Ergänzung dann in den anderen Thread zu schicken

kimbolero

Hallo,
sorry, letzte Zeit war sehr stressig, deshalb bin ich nicht großartig zum testen gekommen.
Ich habe nun nochmals alle Devices und das MQTT-Device als Bridge komplett gelöscht, ESP ausgesteckt, Update von FHEM & und anschließenden Neustart durchgeführt - Ergebnis:
1. MQTT-Devices wird angelegt
2. Nach Auswahl des Bridge-Templates kommt folgende Meldung:
Specify the unknown parameters for zigbee2mqtt_bridge:
base topic as set in configuration.yaml of the zigbee2mqtt bridge [Eingabefeld]

Hatten wir schonmal - damals hat der Neustart gefehlt, ich habe FHEM und auch den Raspberry nun mehrmals neu gestartet - ergebnislos, es werden die Devices auch nicht angelegt (was mWn eh erst funktioniert, wenn das Template für die Bridge richtig gesetzt wird)

Habe jetzt in das Eingabefeld "ZigBee2MQTT" eingetragen - dann wird das Template auch gesetzt, aber die Devices werden nur als Reading in der Bridge angelegt - hier noch das RAW:

defmod MQTT2_ZigBee2MQTT MQTT2_DEVICE ZigBee2MQTT
attr MQTT2_ZigBee2MQTT IODev myBroker
attr MQTT2_ZigBee2MQTT bridgeRegexp ZigBee2MQTT/([A-Za-z0-9._]+)[/]?.*:.* "zigbee_$1"
attr MQTT2_ZigBee2MQTT comment To check for new updates of the deamon software, you might want to use a separate HTTPMOD device. See HTTPMOD template zigbee2mqtt_daemon_updates for further details.
attr MQTT2_ZigBee2MQTT devicetopic ZigBee2MQTT
attr MQTT2_ZigBee2MQTT getList devicelist:noArg log $DEVICETOPIC/bridge/config/devices\
  networkmap_raw:noArg raw $DEVICETOPIC/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/networkmap graphviz
attr MQTT2_ZigBee2MQTT icon mqtt
attr MQTT2_ZigBee2MQTT model zigbee2mqtt_bridge
attr MQTT2_ZigBee2MQTT readingList $DEVICETOPIC/bridge/state:.* state\
  $DEVICETOPIC/bridge/config/devices:.* {}\
  $DEVICETOPIC/bridge/config/log_level:.* log_level\
  $DEVICETOPIC/bridge/config/permit_join:.* permit_join\
  $DEVICETOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  $DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
  $DEVICETOPIC/bridge/log:.* log\
  $DEVICETOPIC/bridge/networkmap:.* {}\
  $DEVICETOPIC/bridge/networkmap/graphviz:.* graphviz\
  $DEVICETOPIC/bridge/networkmap/raw:.* raw\
  $DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT) }\
ZigBee2MQTT:stat/ZigBee2MQTT/LOGGING:.* LOGGING\
ZigBee2MQTT:stat/ZigBee2MQTT/RESULT:.* { json2nameValue($EVENT) }\
ZigBee2MQTT:tele/ZigBee2MQTT/RESULT:.* { json2nameValue($EVENT) }\
ZigBee2MQTT:tele/ZigBee2MQTT/C9E7/SENSOR:.* { json2nameValue($EVENT) }\
ZigBee2MQTT:tele/ZigBee2MQTT/C1FF/SENSOR:.* { json2nameValue($EVENT) }\
ZigBee2MQTT:tele/ZigBee2MQTT/6EA4/SENSOR:.* { json2nameValue($EVENT) }\
ZigBee2MQTT:tele/ZigBee2MQTT/LWT:.* LWT\
ZigBee2MQTT:cmnd/ZigBee2MQTT/POWER:.* POWER
attr MQTT2_ZigBee2MQTT room MQTT2_DEVICE
attr MQTT2_ZigBee2MQTT setList log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1\
  permit_join:true,false $DEVICETOPIC/bridge/config/permit_join $EVTPART1\
  remove:textField $DEVICETOPIC/bridge/config/remove $EVTPART1\
  ota_update:textField $DEVICETOPIC/bridge/ota_update/update $EVTPART1\
  ota_update_check:textField $DEVICETOPIC/bridge/ota_update/check $EVTPART1\
  y_device_setting:textField $DEVICETOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
  x_bind:textField $DEVICETOPIC/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField $DEVICETOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField $DEVICETOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField $DEVICETOPIC/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField $DEVICETOPIC/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField $DEVICETOPIC/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField $DEVICETOPIC/bridge/config/elapsed $EVTPART1\
  z_last_seen:disable,ISO_8601,epoch,ISO_8601_local $DEVICETOPIC/bridge/config/last_seen $EVTPART1\
  z_ban:textField $DEVICETOPIC/bridge/config/ban $EVTPART1\
  z_rename:textField $DEVICETOPIC/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg $DEVICETOPIC/bridge/config/reset
attr MQTT2_ZigBee2MQTT setStateList on off

setstate MQTT2_ZigBee2MQTT 2020-08-12 09:31:23 LOGGING 08:31:23 WIF: Checking connection...
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:31:17 LWT Online
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:31:17 POWER
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:44 ZbConfirm_Endpoint 1
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:44 ZbConfirm_Status 233
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:44 ZbConfirm_StatusMessage NO_ACK
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:30:15 ZbReceived_Humitemp1_Battery 86
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:30:31 ZbReceived_Humitemp1_Device 0x6EA4
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:30:31 ZbReceived_Humitemp1_Endpoint 1
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:30:31 ZbReceived_Humitemp1_Humidity 69.43
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:30:31 ZbReceived_Humitemp1_LinkQuality 141
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:30:15 ZbReceived_Humitemp1_ModelId lumi.sensor_ht
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:30:31 ZbReceived_Humitemp1_Temperature 27.09
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:30:15 ZbReceived_Humitemp1_Voltage 2.975
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbReceived_Osram1_Device 0xC1FF
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbReceived_Osram1_Endpoint 3
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbReceived_Osram1_LinkQuality 70
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbReceived_Osram1_Power 1
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:46 ZbReceived_TradfriBWM_0006_42 0008070000
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:48 ZbReceived_TradfriBWM_Device 0xC9E7
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:48 ZbReceived_TradfriBWM_Endpoint 1
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:48 ZbReceived_TradfriBWM_LinkQuality 126
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:46 ZbReceived_TradfriBWM_Power 66
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbResponse_Command 0006!00
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbResponse_Device 0xC1FF
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbResponse_Endpoint 3
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbResponse_LinkQuality 68
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbResponse_Name Osram1
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbResponse_Status 0
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:57 ZbResponse_StatusMessage SUCCESS
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:56 ZbSend Done
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:49 ZbState_IEEEAddr 0x7CB03EAA0A0432DF
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:49 ZbState_PowerSource true
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:49 ZbState_ReceiveWhenIdle true
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:49 ZbState_Security false
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:49 ZbState_ShortAddr 0xC1FF
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:49 ZbState_Status 30
setstate MQTT2_ZigBee2MQTT 2020-08-12 09:29:18 attrTemplateVersion 20200701

CUL 868, Jeelink 868 Clone, NanoCUL 868, HM-CC-RT-DN,  max! Fensterkontakte, Zigbee, GoogleAssistant, GHoma Wifi-Steckdosen, Telegram etc.....

Beta-User

Ja, hatten wir schon ::) : Du bist im falschen Template-Bereich.
Für die zigbee2tasmota-Bridge darfst du NICHT die Templates für zigbee2mqtt verwenden, es gibt dazu einen eigenen "Satz" im Tasmota-Bereich!
Wie es geht, steht übrigens auch schon im Wiki: https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT, da ist auch die genaue Benennung des attrTemplate zu finden ;) . (Rückmeldungen zu dem Wiki-Artikel hier).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

kimbolero

 ::) wow - da hat sich einiges getan - jetzt legt er die Devices an. Ich schaue mir das mal spätestens heute Abend je Device in Ruhe an.

Super Arbeit Beta-User!! Danke.
CUL 868, Jeelink 868 Clone, NanoCUL 868, HM-CC-RT-DN,  max! Fensterkontakte, Zigbee, GoogleAssistant, GHoma Wifi-Steckdosen, Telegram etc.....

Beta-User

#80
Zitat von: kimbolero am 12 August 2020, 09:52:25
::) wow - da hat sich einiges getan - jetzt legt er die Devices an. Ich schaue mir das mal spätestens heute Abend je Device in Ruhe an.

Super Arbeit Beta-User!! Danke.
Danke für die nette Rückmeldung!
Da war aber auch vor allem TL60 mit seinen Rückmeldungen (und dem Wiki-Beitrag) nicht ganz unbeteiligt ;) .



@TL60, im Nachgang zu dem hier:
Zitat von: TL60 am 10 August 2020, 16:23:26
"A5A6" ist der Tradfri dimmer switch also die Remote.Und das kommt bei Taste I 15:41:32 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!01":"","Power":1,"Endpoint":1,"Group":100,"LinkQuality":31}}}
15:41:33 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":34}}}
und bei Taste0 15:42:23 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!00":"","Power":0,"Endpoint":1,"Group":100,"LinkQuality":34}}}
15:42:24 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":36}}}
.
Bin jetzt an zwei Enden am Grübeln:
- zum einen: Gäbe es Unterschiede, wenn der Gruppenbefehl nicht an alle Mitglieder (Aktoren) übermittelt worden wäre? Wenn ja, könnten wir ggf. zumindest bei Erfolg einfach alle beteiligten Bulbs in FHEM auf den richtigen Status setzen?

- Das könnte über ein devspec-setreading klappen (hier für Gruppe 100):setreading model=tasmota_zigbee2tasmota.*:FILTER=AddGroup=.*\b100\b.* state on
Setzte halt voraus, dass die Zugehörigkeit zu mehreren Gruppen in "AddGroup" zu erkennen wäre...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

TL60

Hallo,
@Beta-User, du hattest hier mal angefragt:
Zitat(ggf. würde mich zusätzlich interessieren, wie sich der on/off-Aktor verhält, wenn man ihn über eine Gruppe (per FHEM und/oder FB) dimmt... Ist aber ein anderes bzw. weiterführendes Thema).
das habe ich dann mal probiert und den Müller single switch auch zur schon bekannten Gruppe 100 hinzugefügt. Der Singleswitch wird, wie auch die beiden GU10 Spots ein und ausgeschaltet. Dimmer Kommandos werden nur von den GU10 ausgeführt  und ansonsten ignoriert. Ich habe auch nirgendwo Fehlermeldungen im Log gefunden.
Und dann um das
Zitat- Das könnte über ein devspec-setreading klappen (hier für Gruppe 100):
Code: [Auswählen]

setreading model=tasmota_zigbee2tasmota.*:FILTER=AddGroup=.*\b100\b.* state on

Setzte halt voraus, dass die Zugehörigkeit zu mehreren Gruppen in "AddGroup" zu erkennen wäre...?
zu testen habe ich den Single-Switch zur Gruppe200 hinzugefügt 17:26:58 CMD: ZbSend {"device":"0x0187","Send":{"AddGroup":200}} Jetzt reagiert er auf Befehle für die Gruppe 100 als auch für die Gruppe 200. Leider steht im entsprechenden Reading, wie man im Ausschnitt aus den RAW Defintions sehen kanndefmod MQTT2_z2t_0187 MQTT2_DEVICE z2t_0187
attr MQTT2_z2t_0187 IODev MQTT2server
attr MQTT2_z2t_0187 icon light_light
attr MQTT2_z2t_0187 jsonMap Power:state Device:0
attr MQTT2_z2t_0187 readingList tele/zb2tasmota/0187/SENSOR:.* { $EVENT =~ s/"Power":1/"Power":"on"/g;; $EVENT =~ s/"Power":0/"Power":"off"/g;; $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0x0187.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef  }
attr MQTT2_z2t_0187 room MQTT2_DEVICE
attr MQTT2_z2t_0187 setExtensionsEvent 1
attr MQTT2_z2t_0187 setList on cmnd/zb2tasmota/ZbSend {"device":"0x0187","send":{"Power":"On"}}\
  off cmnd/zb2tasmota/ZbSend {"device":"0x0187","send":{"Power":"Off"}}
attr MQTT2_z2t_0187 setStateList on off

setstate MQTT2_z2t_0187 on
setstate MQTT2_z2t_0187 2020-08-12 17:26:59 0004_00 00C800
setstate MQTT2_z2t_0187 2020-08-12 17:26:59 AddGroup 200
setstate MQTT2_z2t_0187 2020-08-12 17:26:59 AddGroupStatus 0
setstate MQTT2_z2t_0187 2020-08-12 17:26:59 AddGroupStatusMsg SUCCESS
setstate MQTT2_z2t_0187 2020-08-12 17:29:54 Endpoint 1
setstate MQTT2_z2t_0187 2020-08-12 17:29:54 LinkQuality 94
setstate MQTT2_z2t_0187 2020-08-07 22:21:01 associatedWith MQTT2_DVES_AAFFC1
setstate MQTT2_z2t_0187 2020-08-12 17:29:54 state on
nur noch AddGroup 200 funktioniert also so wohl nicht.
Hier, wie ein On Befehl über die Remote 17:39:34 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!01":"","Power":1,"Endpoint":1,"Group":100,"LinkQuality":70}}}
17:39:36 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":42}}}
auf der Tasmota Konsole aussieht und hier der entsprechende Befehl aus FHEM heraus 17:43:43 MQT: tele/zb2tasmota/F5A6/SENSOR = {"ZbReceived":{"0xF5A6":{"Power":1,"Endpoint":1,"LinkQuality":68}}}
17:43:43 MQT: tele/zb2tasmota/F6F8/SENSOR = {"ZbReceived":{"0xF6F8":{"Power":1,"Endpoint":1,"LinkQuality":55}}}
17:43:43 MQT: tele/zb2tasmota/0187/SENSOR = {"ZbReceived":{"0x0187":{"Power":1,"Endpoint":1,"LinkQuality":94}}}
ebenfalls aus der Tasmota Konsole. Interessanterweise scheint, obwohl lt. FHEM-log der Befehl 2020.08.12 17:43:43 3: MQTT2_DEVICE set MQTT2_z2t_Group100 on auch an die Gruppe ging, alle beteiligten Geräte eine Rückmeldung bringen. Warum das Verhalten beim schalten über eine Remote anders ist, als über den ZbSend Befehl kann eigentlich nur damit zu tun haben, das die Direktanbindung Remote->Gruppe (Binding) von Zigbee2Tasmota anders behandelt wird. Das macht das ganze natürlich zusätzlich kompliziert. Ich denke es wird hier keine einfache Lösung geben  :(
Zum dritten:
ZitatBin jetzt an zwei Enden am Grübeln:
- zum einen: Gäbe es Unterschiede, wenn der Gruppenbefehl nicht an alle Mitglieder (Aktoren) übermittelt worden wäre? Wenn ja, könnten wir ggf. zumindest bei Erfolg einfach alle beteiligten Bulbs in FHEM auf den richtigen Status setzen?
Dazu habe ich ein Gerät mal vom Strom genommen und dann die Gruppe geschaltet der Gruppenzustand wurde korrekt gesetzt. D.h. in meinen Augen man müsste man  dann aus dem Gruppenzustand heraus die einzelnen Geräte passend setzen, oder ? Ganz schön kompliziert das Ganze.
Die Gruppenzugehörigkeit eines Gerätes kann über den Befehl 18:08:33 CMD: ZbSend {"device":"0x0187","Send":{"GetAllGroups":true}} ermittelt werden 8:08:34 MQT: tele/zb2tasmota/0187/SENSOR = {"ZbReceived":{"0x0187":{"0004<02":"FF026400C800","GetGroupCapacity":255,"GetGroupCount":2,"GetGroup":[100,200],"Endpoint":1,"LinkQuality":99}} lautet dann die Antwort. In diesem Fall gehört der Single-Switch also zu den Gruppen 100 und 200. Ich wüsste aber nicht, wie uns das weiterhilft.
Damit will ich erstmal bewenden lassen, sonst wird es noch komplizierter

kimbolero

Gibt es bereits ein Template für einen Xiaomi Temp/Humi-Sensor, Xiaomi Fensterkontakt, den Tradfri Bewegungsmelder und den Aqara Cube?
Habe nun alle vorhandenen Tasmota_Zigbee-Templates angeschaut, dazu nichts passendes gefunden.

Soweit ich Beta-User jetzt verstanden habe, benötigst man die Mitschnitte der Tasmota-Konsole wenn ein Device funkt?

1. Xiaomi Temp/Humi Sensor

18:46:32 ZIG: Bytes follow_read_metric = 8666
18:46:32 ZIG: {"ZbZNPReceived":"448100000000A46E01010071007775C000002618B70A01FF421F01219F0B0421A84305210900062402000000006429E40A65212F160A210000A46E1D"}
18:46:32 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":0,"srcaddr":"0x6EA4","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":113,"securityuse":0,"seqnumber":0,"timestamp":12612983,"fc":"0x18","manuf":"0x0000","transact":183,"cmdid":"0x0A","payload":"01FF421F01219F0B0421A84305210900062402000000006429E40A65212F160A210000"}}
18:46:32 ZIG: ZbZCLRawReceived: {"0x6EA4":{"0000/FF01":"01219F0B0421A84305210900062402000000006429E40A65212F160A210000"}}
18:46:32 MQT: tele/ZigBee2MQTT/6EA4/SENSOR = {"ZbReceived":{"Humitemp1":{"Device":"0x6EA4","Voltage":2.975,"Battery":86,"Temperature":27.88,"Humidity":56.79,"Endpoint":1,"LinkQuality":113}}}


2. Xiaomi Fensterkontakt
Auf und Zu
18:54:04 ZIG: Bytes follow_read_metric = 8873
18:54:04 ZIG: {"ZbZNPReceived":"448100000600F7BE0101002F0028FED500000718C10A00001001F7BE1D"}
18:54:04 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":6,"srcaddr":"0xBEF7","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":47,"securityuse":0,"seqnumber":0,"timestamp":14024232,"fc":"0x18","manuf":"0x0000","transact":193,"cmdid":"0x0A","payload":"00001001"}}
18:54:04 ZIG: ZbZCLRawReceived: {"0xBEF7":{"0006/0000":1}}
18:54:04 MQT: tele/ZigBee2MQTT/BEF7/SENSOR = {"ZbReceived":{"Fenster1":{"Device":"0xBEF7","Power":1,"Endpoint":1,"LinkQuality":47}}}
18:54:07 ZIG: Bytes follow_read_metric = 8904
18:54:07 ZIG: {"ZbZNPReceived":"448100000600F7BE0101004E00801DD600000718C20A00001000F7BE1D"}
18:54:07 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":6,"srcaddr":"0xBEF7","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":78,"securityuse":0,"seqnumber":0,"timestamp":14032256,"fc":"0x18","manuf":"0x0000","transact":194,"cmdid":"0x0A","payload":"00001000"}}
18:54:07 ZIG: ZbZCLRawReceived: {"0xBEF7":{"0006/0000":0}}
18:54:07 MQT: tele/ZigBee2MQTT/BEF7/SENSOR = {"ZbReceived":{"Fenster1":{"Device":"0xBEF7","Power":0,"Endpoint":1,"LinkQuality":78}}}


3. Tradfri Bewegungsmelder

18:48:40 ZIG: Bytes follow_read_metric = 8742
18:48:40 ZIG: {"ZbZNPReceived":"448100000600E7C90101005C00C68BC6000008014F420008070000FFC10A"}
18:48:40 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":6,"srcaddr":"0xC9E7","srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":92,"securityuse":0,"seqnumber":0,"timestamp":13011910,"fc":"0x01","manuf":"0x0000","transact":79,"cmdid":"0x42","payload":"0008070000"}}
18:48:40 ZIG: ZbZCLRawReceived: {"0xC9E7":{"0006!42":"0008070000","Power":66}}
18:48:40 MQT: tele/ZigBee2MQTT/C9E7/SENSOR = {"ZbReceived":{"TradfriBWM":{"Device":"0xC9E7","0006!42":"0008070000","Power":66,"Endpoint":1,"LinkQuality":92}}}
18:48:40 ZIG: ZbZNPSent 240202E7C9000000000000010000010600A0301E050000A0000000
18:48:40 ZIG: Bytes follow_read_metric = 8747
18:48:40 ZIG: {"ZbZNPReceived":"640200"}


4. Aqara Cube
FLIP90
18:55:40 ZIG: Bytes follow_read_metric = 9005
18:55:40 ZIG: {"ZbZNPReceived":"448100001200890202010088008495DA00000818440A550021650089021D"}
18:55:40 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":18,"srcaddr":"0x0289","srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":136,"securityuse":0,"seqnumber":0,"timestamp":14325124,"fc":"0x18","manuf":"0x0000","transact":68,"cmdid":"0x0A","payload":"5500216500"}}
18:55:40 ZIG: ZbZCLRawReceived: {"0x0289":{"0012/0055":101}}
18:55:41 MQT: tele/ZigBee2MQTT/0289/SENSOR = {"ZbReceived":{"Cube1":{"Device":"0x0289","MultiInValue":101,"AqaraCube":"flip90","AqaraCubeSide":5,"AqaraCubeFromSide":4,"Endpoint":2,"LinkQuality":136}}}
18:55:43 ZIG: Bytes follow_read_metric = 9012
18:55:43 ZIG: {"ZbZNPReceived":"4480F001A3"}
18:55:43 MQT: tele/ZigBee2MQTT/RESULT = {"ZbConfirm":{"Endpoint":1,"Status":240,"StatusMessage":""}}


Shake:
18:56:14 ZIG: Bytes follow_read_metric = 9044
18:56:14 ZIG: {"ZbZNPReceived":"448100001200890202010073005232DC00000818450A550021000089021D"}
18:56:14 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":18,"srcaddr":"0x0289","srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":115,"securityuse":0,"seqnumber":0,"timestamp":14430802,"fc":"0x18","manuf":"0x0000","transact":69,"cmdid":"0x0A","payload":"5500210000"}}
18:56:14 ZIG: ZbZCLRawReceived: {"0x0289":{"0012/0055":0}}
18:56:15 MQT: tele/ZigBee2MQTT/0289/SENSOR = {"ZbReceived":{"Cube1":{"Device":"0x0289","MultiInValue":0,"AqaraCube":"shake","Endpoint":2,"LinkQuality":115}}}


Rotate
18:56:43 ZIG: Bytes follow_read_metric = 9083
18:56:43 ZIG: {"ZbZNPReceived":"448100000C0089020301006600B48EDD00000F18460A05FF21F40155003953B818C389021D"}
18:56:43 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":12,"srcaddr":"0x0289","srcendpoint":3,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":102,"securityuse":0,"seqnumber":0,"timestamp":14519988,"fc":"0x18","manuf":"0x0000","transact":70,"cmdid":"0x0A","payload":"05FF21F40155003953B818C3"}}
18:56:43 ZIG: ZbZCLRawReceived: {"0x0289":{"000C/FF05":500,"000C/0055":-152.72}}
18:56:43 MQT: tele/ZigBee2MQTT/0289/SENSOR = {"ZbReceived":{"Cube1":{"Device":"0x0289","Aqara_FF05":500,"AqaraRotate":-152.72,"Endpoint":3,"LinkQuality":102}}}


Flip180
18:57:15 ZIG: Bytes follow_read_metric = 9115
18:57:15 ZIG: {"ZbZNPReceived":"44810000120089020201008D00CF1ADF00000818470A550021820089021D"}
18:57:15 ZIG: {"ZbZCLReceived":{"groupid":0,"clusterid":18,"srcaddr":"0x0289","srcendpoint":2,"dstendpoint":1,"wasbroadcast":0,"LinkQuality":141,"securityuse":0,"seqnumber":0,"timestamp":14621391,"fc":"0x18","manuf":"0x0000","transact":71,"cmdid":"0x0A","payload":"5500218200"}}
18:57:15 ZIG: ZbZCLRawReceived: {"0x0289":{"0012/0055":130}}
18:57:16 MQT: tele/ZigBee2MQTT/0289/SENSOR = {"ZbReceived":{"Cube1":{"Device":"0x0289","MultiInValue":130,"AqaraCube":"flip180","AqaraCubeSide":2,"Endpoint":2,"LinkQuality":141}}}


Hoffe das diese Infos hilfreich sind.
CUL 868, Jeelink 868 Clone, NanoCUL 868, HM-CC-RT-DN,  max! Fensterkontakte, Zigbee, GoogleAssistant, GHoma Wifi-Steckdosen, Telegram etc.....

Beta-User

Na ja, für's erste hatte ich das so gedacht, dass man das "generic-battery"-template für alle diese Sensoren nehmen kann und dann das jsonMap entsprechend erweitern. Hab's jetzt noch nicht im Detail angesehen, aber du könntest mal darüber nachdenken, wo was in state soll und wo eine "einfache" Umbenennung Sinn macht.
Danach wäre zu entscheiden, ob bzw. für welche ein "gemeinsames" template reicht und wo man was spezielles haben sollte.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

kimbolero

Für den Temp/Humi Sensor von Xiaomi gebe ich Dir recht, er setzt dazu auch eigene Readings, welche ich mit StateFormat sauber darstellen kann.

defmod MQTT2_z2t_6EA4 MQTT2_DEVICE z2t_6EA4
attr MQTT2_z2t_6EA4 IODev myBroker
attr MQTT2_z2t_6EA4 alias Xiaomi_HumiTemp
attr MQTT2_z2t_6EA4 icon temperature_humidity
attr MQTT2_z2t_6EA4 jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0
attr MQTT2_z2t_6EA4 readingList tele/ZigBee2MQTT/6EA4/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0x6EA4.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_6EA4 room MQTT2_DEVICE
attr MQTT2_z2t_6EA4 stateFormat T:  Temperature°C | H: Humidity% | B: batteryPercent%

setstate MQTT2_z2t_6EA4 T:  26.48°C | H: 67.09% | B: 86%
setstate MQTT2_z2t_6EA4 2020-08-13 08:37:19 Endpoint 1
setstate MQTT2_z2t_6EA4 2020-08-13 08:37:19 Humidity 67.09
setstate MQTT2_z2t_6EA4 2020-08-13 08:37:19 LinkQuality 102
setstate MQTT2_z2t_6EA4 2020-08-13 08:35:38 ModelId lumi.sensor_ht
setstate MQTT2_z2t_6EA4 2020-08-13 08:37:19 Temperature 26.48
setstate MQTT2_z2t_6EA4 2020-08-13 08:35:38 Voltage 2.975
setstate MQTT2_z2t_6EA4 2020-08-12 09:51:01 associatedWith MQTT2_ZigBee2MQTT
setstate MQTT2_z2t_6EA4 2020-08-13 08:35:38 batteryPercent 86


Für den Aqara Cube habe ich vorerst gar kein Template ausgewählt - hier werden ebenfalls sauber entsprechend readings bereits gesetzt, welche man dann für eine Aktion auslesen kann.

Xiaomi Fenstersensor habe ich ebenfalls das Generic-Battery-Template genommen, dort werden ebenfalls die Readings gesetzt und diese stelle ich dann über folgende Einstellungen dar:
attr MQTT2_z2t_BEF7 devStateIcon geschlossen:fts_door@green offen:fts_door_open@red
attr MQTT2_z2t_BEF7 eventMap 0:geschlossen 1:offen
attr MQTT2_z2t_BEF7 stateFormat ZbReceived_Fenster1_Power


Somit bin ich erstmal glücklich - alle Devices als eigenständiges Device zu haben und nicht wie ursprünglich alle als eigene Readings im MQTT-Tasmota-Device

8)
CUL 868, Jeelink 868 Clone, NanoCUL 868, HM-CC-RT-DN,  max! Fensterkontakte, Zigbee, GoogleAssistant, GHoma Wifi-Steckdosen, Telegram etc.....

Beta-User

Hmm, ich schau mir das nochmal etwas intensiver an, Readingnamen wie "ZbReceived_Fenster1_Power" gefallen mir noch nicht so recht ::) . Das kommt mir auch nicht so vor, als wäre das ein Ergebnis, das sich mit dem "generic-battery" ergibt.

Um z.B. den Temp/Hum noch FHEM-kompatibler zu machen, würde ich den "generic-battery" mal so erweitern:
name:tasmota_zigbee2tasmota_generic_battery_sensor
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 an arbitrary battery powered ZigBee sensor.<br>NOTE: jsonMap also is ok for Xiaomi Temp/Humi Sensor
order:A_01u04
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*/[^/]+/SENSOR)?:, ? "${1}tele$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:ICON;ICON as set, defaults to temperature_humidity;{ AttrVal("DEVICE","icon","temperature_humidity") }
par:CALLSPEECHRECOGN;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
attr DEVICE icon ICON
attr DEVICE comment For forther configuration use e.g. stateFormat attribtue like T: temperature°C | H: humidity% | B: batteryPercent%
attr DEVICE readingList \
TELETOPIC:.* { $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xDEV_ID.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef }
attr DEVICE jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0 Temperature:temperature Humidity:humidity
deletereading -q DEVICE (?!associatedWith).*
option:{ CALLSPEECHRECOGN }
attr DEVICE model tasmota_zigbee2tasmota_generic_battery_sensor
setreading DEVICE attrTemplateVersion 20200814


Für den Fenstersensor macht wohl in der Tat ein eigenes template Sinn. Wie wäre es mit:
name:tasmota_zigbee2tasmota_window_contact
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 window contact, e.g. like Xiaomi MCCGQ01LM.<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_01u04b
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*/[^/]+/SENSOR)?:, ? "${1}tele$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:ICON;ICON as set, defaults to light_control;{ AttrVal("DEVICE","icon","light_control") }
par:CALLSPEECHRECOGN;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
attr DEVICE icon ICON
attr DEVICE readingList \
TELETOPIC:.* { $EVENT =~ s/"Power":1/"state":"open"/g; $EVENT =~ s/"Power":0/"state":"closed"/g; $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xDEV_ID.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef  }
attr DEVICE jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0
deletereading -q DEVICE (?!associatedWith).*
option:{ CALLSPEECHRECOGN }
set DEVICE attrTemplate speechcontrol_gdt_and_mapping GENERICDEVTYPE=contact HOMEBRIDGEMAPPING="ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED"
attr DEVICE model tasmota_zigbee2tasmota_window_contact
setreading DEVICE attrTemplateVersion 20200814


Der Bewegungsmelder ist "komisch", da liegt die Vermutung nahe, dass der auf Tasmota-Seite noch nicht ausentwickelt ist (da mal nachfragen?).  Sowas wie "0006!42" klingt mir danach, als wäre da schlicht was nicht bekannt (setzt sich aus cluster und cmdid zusammen), und "66" als "Power" ist auch eher rätselhaft. Könnte ein brightness-Wert oder (wahrscheinlicher) die Batterie sein...
Für's erste würde ich das allg. FB-Template da mal aufbohren:
name:tasmota_zigbee2tasmota_remote_control
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 an arbitrary zigbee remote control unit.<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_01u04a
par:TELETOPIC;info topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*/[^/]+/SENSOR)?:, ? "${1}tele$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:ICON;ICON as set, defaults to tradfri_remote;{ AttrVal("DEVICE","icon","tradfri_remote") }
attr DEVICE icon ICON
attr DEVICE readingList \
TELETOPIC:.* { $EVENT =~ m,(([0-9])([0-9])([0-9])([0-9])!([0-9][0-9])), ? { 'state'=>"${5}${4}${3}${2}$6" } : $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xDEV_ID.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef }
attr DEVICE jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model tasmota_zigbee2tasmota_remote_control
setreading DEVICE attrTemplateVersion 20200814
Und dann in jsonMap (auch) "Power:batteryPercent" setzen (der kann  keine Helligkeit- jedenfalls meiner@deconz nicht -)?

Und was genau spricht dagegen, für den Cube das allg. FB-Template oder generic-battery zu nehmen? Damit sollten doch zumindest die Readings kürzer werden, oder? (Das ist jetzt nicht das wichtigste, aber die Readingnamen ohne die Präfixe von Entpacken sind doch deutlich besser lesbar...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

Hallo zusammen, fyi: die template-Vorschläge sind per update verfügbar, Rückmeldung wäre nett.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

kimbolero

@BetaUser: ich bin die kommenden 2 Wochen im Urlaub, aber danach gerne.
CUL 868, Jeelink 868 Clone, NanoCUL 868, HM-CC-RT-DN,  max! Fensterkontakte, Zigbee, GoogleAssistant, GHoma Wifi-Steckdosen, Telegram etc.....

TL60

@Beta-User. Die Änderungen bezogen sich auf batteribetriebene Sensoren, wie kimbolero sie hier in Antwort 82 beschrieben hat. Da kann ich dann leider nicht helfen  :( . 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  ;)

kimbolero

Zitat von: Beta-User am 15 August 2020, 13:30:42
Hallo zusammen, fyi: die template-Vorschläge sind per update verfügbar, Rückmeldung wäre nett.

Habe nun nochmals alles gelöscht, ZigBee2MQTT Bridge wurde problemlos gefunden und automatisch generiert.

1. zigbee2tasmota_generic_battery_sensor --> Xiaomi Temp/Humi-Sensor
Hier wird kein Battery Reading angelegt - Rest passt

defmod MQTT2_z2t_6EA4 MQTT2_DEVICE z2t_6EA4
attr MQTT2_z2t_6EA4 IODev myBroker
attr MQTT2_z2t_6EA4 comment For forther configuration use e.g. stateFormat attribtue like T: temperature°C | H: humidity% | B: batteryPercent%
attr MQTT2_z2t_6EA4 icon temperature_humidity
attr MQTT2_z2t_6EA4 jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0 Temperature:temperature Humidity:humidity
attr MQTT2_z2t_6EA4 model tasmota_zigbee2tasmota_generic_battery_sensor
attr MQTT2_z2t_6EA4 readingList tele/ZigBee2MQTT/6EA4/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0x6EA4.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_6EA4 room MQTT2_DEVICE
attr MQTT2_z2t_6EA4 stateFormat T: temperature°C | H: humidity% | B: batteryPercent%

setstate MQTT2_z2t_6EA4 T: 23.67°C | H: 67.43% | B: batteryPercent%
setstate MQTT2_z2t_6EA4 2020-08-30 14:28:21 Endpoint 1
setstate MQTT2_z2t_6EA4 2020-08-30 14:28:21 LinkQuality 128
setstate MQTT2_z2t_6EA4 2020-08-30 14:25:41 associatedWith MQTT2_ZigBee2MQTT
setstate MQTT2_z2t_6EA4 2020-08-30 14:27:38 attrTemplateVersion 20200814
setstate MQTT2_z2t_6EA4 2020-08-30 14:28:21 humidity 67.43
setstate MQTT2_z2t_6EA4 2020-08-30 14:28:21 temperature 23.67


2. tasmota_zigbee2tasmota_window_contact --> Xiaomi Fenster-Sensor
Hier habe ich noch ein devStateIcon hinzugefügt, ein Battery-Reading wird hier ebenfalls nicht automatisch erzeugt

defmod MQTT2_z2t_BEF7 MQTT2_DEVICE z2t_BEF7
attr MQTT2_z2t_BEF7 IODev myBroker
attr MQTT2_z2t_BEF7 alias Kontakt_Büro_Tür
attr MQTT2_z2t_BEF7 devStateIcon closed:fts_door@green open:fts_door_open@red
attr MQTT2_z2t_BEF7 genericDeviceType contact
attr MQTT2_z2t_BEF7 homebridgeMapping "ContactSensorState=state,values=closed:CONTACT_DETECTED;;;;open:CONTACT_NOT_DETECTED"
attr MQTT2_z2t_BEF7 icon light_control
attr MQTT2_z2t_BEF7 jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0
attr MQTT2_z2t_BEF7 model tasmota_zigbee2tasmota_window_contact
attr MQTT2_z2t_BEF7 readingList tele/ZigBee2MQTT/BEF7/SENSOR:.* { $EVENT =~ s/"Power":1/"state":"open"/g;; $EVENT =~ s/"Power":0/"state":"closed"/g;; $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xBEF7.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef  }
attr MQTT2_z2t_BEF7 room MQTT2_DEVICE

setstate MQTT2_z2t_BEF7 closed
setstate MQTT2_z2t_BEF7 2020-08-30 14:45:40 Endpoint 1
setstate MQTT2_z2t_BEF7 2020-08-30 14:45:40 LinkQuality 73
setstate MQTT2_z2t_BEF7 2020-08-30 14:29:09 associatedWith MQTT2_ZigBee2MQTT
setstate MQTT2_z2t_BEF7 2020-08-30 14:35:34 attrTemplateVersion 20200814
setstate MQTT2_z2t_BEF7 2020-08-30 14:45:40 state closed



Für den Xiaomi Cube und den Tradfi Bewegungsmelder gibt es kein Template, richtig?
CUL 868, Jeelink 868 Clone, NanoCUL 868, HM-CC-RT-DN,  max! Fensterkontakte, Zigbee, GoogleAssistant, GHoma Wifi-Steckdosen, Telegram etc.....