Ich stehe gerade vor der Herausforderung, dass ich mir ein CC2530 für Zigbee-Devices angelegt habe. Reine Readings von bspw. Xiaomi Fensterkontakten und einem Aqara Cube funktionieren bereits perfekt.
Nun habe ich mir eine Osram Smart+ A60 LED-Birne bestellt. Diese wird soweit auch erkannt & die Readings sind vorhanden.
Über die Zigbee2MQTT Tasmota Console kann ich die Birne auch bereits ein- und wieder ausschalten:
ZbSend {"Device":"Osram1","Send":{"Power":Off}}
ZbSend {"Device":"Osram1","Send":{"Power":On}}
Mir fehlt gerade nun der Ansatz, wie ich dies auch in FHEM ansteuern kann und entsprechend automatisiere.
In der Suche habe ich hierzu wenig für mich hilfreiches gefunden - evtl hat mir jemand einen Link bzw auch Codeschnipsel, der mir weiterhilft.
Danke!
Ich wuerde mit einem MQTT-Client (wie mosquitto_sub oder MQTT_CLIENT) die Kommunikation beim Schalten belauschen, und die Befehle im setList Attribut im MQTT2_DEVICE hinterlegen.
Hmm, das ist doch tasmota2zigbee, über das wir hier reden?
(Wäre nicht schlecht, wenn das irgendwie von vornherein klarer gesagt würde). Das ganze ist vermutlich nicht so einfach zu handeln, da scheint praktisch der volle content NUR in der payload verborgen zu sein: https://tasmota.github.io/docs/Zigbee/
Wie senden ginge (ob es dafür einen eigenen Topic-Pfad gibt oder man backlog verwenden muß/kann, ist ungeklärt), müssen wir erst noch lernen bzw. es wäre gut, wenn du dazu mehr Infos liefern könntest.
Insgesamt ist vermutlich zigbee2mqtt einfacher.
Ja, Du hast Recht - es handelt sich hier um Zigbee2Tasmota.
Mir ist eben aufgefallen, dass auch noch ein neues MQTT Device angelegt wurde:
defmod MQTT2_6d894b82846a45909ad468e05837f6d3 MQTT2_DEVICE 6d894b82846a45909ad468e05837f6d5
attr MQTT2_6d894b82846a45909ad468e05837f6d3 IODev myBroker
attr MQTT2_6d894b82846a45909ad468e05837f6d3 readingList 6d894b82846a45909ad468e05837f6d5:cmnd/tasmotas/:.* tasmotas\
6d894b82846a45909ad468e05837f6d5:\x2ezigbee2mqtt/0x7CB03EAA0A0432DF/set_\x7b\x22state\x22_\x22OFF\x22\x2c\x22brightness\x22_60\x7d:.* set___state___OFF___brightness__60_\
6d894b82846a45909ad468e05837f6d5:\x2ezigbee2mqtt/0x7CB03EAA0A0432DF/set_\x7b\x22state\x22_\x22OFF\x22\x7d:.* set___state___OFF__\
6d894b82846a45909ad468e05837f6d5:set\x2emyBroker\x2epublish\x2etele/ZigBee2MQTT/LWT/0x7CB03EAA0A0432DF/set\x2e\x7b\x22state\x22_\x22OFF\x22\x7d:.* set___state___OFF__\
6d894b82846a45909ad468e05837f6d5:tele/ZigBee2MQTT/LWT/0x7CB03EAA0A0432DF/set\x2e\x7b\x22state\x22_\x22OFF\x22\x7d:.* set___state___OFF__\
6d894b82846a45909ad468e05837f6d5:tele/ZigBee2MQTT/0x7CB03EAA0A0432DF/set\x2e\x7b\x22state\x22_\x22OFF\x22\x7d:.* set___state___OFF__\
6d894b82846a45909ad468e05837f6d5:ZbSend\x2e\x7b\x22Device\x22_\x22Osram1\x22\x2c\x22Send\x22_\x7b\x22Power\x22_Off\x7d\x7d:.* ZbSend___Device___Osram1___Send____Power__Off__\
6d894b82846a45909ad468e05837f6d5:cmnd/Zigbee2MQTT/POWER\x2e\x7b\x22Device\x22_\x22Osram1\x22\x2c\x22Send\x22_\x7b\x22Power\x22_Off\x7d\x7d:.* POWER___Device___Osram1___Send____Power__Off__\
6d894b82846a45909ad468e05837f6d5:tele/ZigBee2MQTT/SENSOR\x2e\x3d\x2e\x7b\x22ZbReceived\x22_\x7b\x22Osram1\x22_\x7b\x22Device\x22_\x220xC1FF\x22\x2c\x22Power\x22_0\x2c\x22Endpoint\x22_3\x2c\x22LinkQuality\x22_84\x7d\x7d\x7d:.* SENSOR_____ZbReceived____Osram1____Device___0xC1FF___Power__0__Endpoint__3__LinkQuality__84___\
6d894b82846a45909ad468e05837f6d5:CMD_\x2eZbSend\x2e\x7b\x22Device\x22_\x22Osram1\x22\x2c\x22Send\x22_\x7b\x22Power\x22_Off\x7d\x7d:.* CMD__ZbSend___Device___Osram1___Send____Power__Off__
attr MQTT2_6d894b82846a45909ad468e05837f6d3 room MQTT2_DEVICE
setstate MQTT2_6d894b82846a45909ad468e05837f6d3 2020-06-19 20:41:22 subscriptions # stat/ZigBee2MQTT/RESULT tele/ZigBee2MQTT/STATE zigbee2mqtt/Osram1/set
setstate MQTT2_6d894b82846a45909ad468e05837f6d3 2020-06-19 18:31:48 tasmotas
Mir erschließt sich lediglich nicht, wie ich in FHEM die LED-Birne schalten kann...
Na ja, wie gesagt: über den backlog-Topic sollte es gehen. Aber das ganze ist irgendwie suboptimal und wird auch nicht besser dadurch, dass du MQTT2_CLIENT als IO zu verwenden scheinst? Und irgendwas zum Testen der publishes?
Du solltest dich erst in MQTT bzw. die MQTT2-Module in FHEM mit einfacheren Devices einarbeiten und dann erst an diese Sache ran. Ansatzpunkt für die Behandlung von zigbee@tasmota sehe ich bei den Tasmota-RF und -IR-Bridges. Das müßte hier "so ähnlich" (aber komplizierter) sein...
@kimbolero: da das automatisch erzeugte readingsList reichlich merkwuerdig ausschaut, wuerde ich gerne die dazu passenden Raw-Daten sehen.
Man findet sie nach einem "attr myBroker verbose 5" und Nachrichten vom Zigbee2Tasmota im FHEM-Log.
Danke euch Beiden - bin nun nach ein wenig "rumprobieren" und Infos von anderen Seiten auf die Lösung gekommen - nachfolgende Kommandos im IO Device von MQTT-Server als set publish senden - und siehe da, die LED-Birne wird an bzw aus geschaltet.
set myBroker publish cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"Off"}}
set myBroker publish cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"On"}}
Auch wenn du das jetzt als "gelöst" markiert hattest:
Könntest du das komplette MQTT2_DEVICE zeigen incl. der setList für on/off und der passenden (gesäuberten) readingList?
Und etwas näher erläutern, wie dein MQTT-Umfeld aussieht (mosquitto+CLIENT?)?
@Rudi:
Vermutlich würde es Sinn machen, für den MQTT-Bereich noch einen "was soll ich posten"-Beitrag zu machen und den anzupinnen. Ich versuch dazu bei Gelegenheit mal was zu liefern...
Fuer ZWave hat krikan das in der Wiki gemacht: https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F
Ich habe mit keinem Verfahren ein Problem, ich haette es aber gerne einheitlich :)
OK, habe mal hier angefangen, eine entsprechende Liste zu machen: https://wiki.fhem.de/wiki/MQTT#Welche_Infos_sollten_Anfragen_im_MQTT-Forum_enthalten.3F. Ist zwar "auf die Schnelle", aber so kann es ggf. auch jeder andere "Kundige" ergänzen, besser formulieren, und wir haben erst mal was...
Ist m.E. auch deswegen besser, das im Wiki zu halten, da ist die Chance dann auch größer, dass die User "das drumrum" wahrnehmen bzw. ggf. erst mal eine Vorstellung davon zu bekommen, dass sie vermutlich nur einen sehr kleinen Ausschnitt der Möglichkeiten sehen, wenn sie auf ihr FHEM schauen :) .
Insgesamt könnte es aber trotzdem Sinn machen, einen (sehr) kurzen Link auf die Seite bzw. den Abschnitt auch hier im Forumsbereich anzupinnen (und den Thread gleich zu schließen)?
Hab kein Problem damit, am besten mit Link auf dem Wiki-Eintrag.
Klar...
Kannst du bitte pinnen: https://forum.fhem.de/index.php/topic,112327.0.html
Habs gemacht.
(Dieses neue Forum-Style mit den vielen + Menues macht mich noch wahnsinnig.)
Ich schlage vor, vom MQTT-FAQ Beitrag das Fixieren zu entfernen: es leitet die Leute in die falsche Richtung, wenn die nicht gewollt sind, bis zu deinem Beitrag weiterzulesen, und selbst danach gibt es eine Diskussion, so dass es nicht eindeutig ist, was man machen soll.
@kimbolero:
Zitat von: Beta-User am 22 Juni 2020, 11:46:21
Könntest du das komplette MQTT2_DEVICE zeigen incl. der setList für on/off und der passenden (gesäuberten) readingList?
Und etwas näher erläutern, wie dein MQTT-Umfeld aussieht (mosquitto+CLIENT?)?
Gilt weiter, laß dich durch unsere kleine Seitendiskussion nicht ablenken...
Zitat von: rudolfkoenig am 22 Juni 2020, 13:40:21
Habs gemacht.
Danke!
Zitat
(Dieses neue Forum-Style mit den vielen + Menues macht mich noch wahnsinnig.)
Bin noch auf ff-preview (?) mit dem Standardstyle, das mit den Menüs fand ich beim "custom" auch nicht gut. Allerdings macht der ff auch manche Sachen komisch (z.B. manchmal Standardschrift = gut lesbar, nächster Beitrag: scheinbar vom Autor (vermutlich unbeabsichtigt?) irgendeine Schriftgröse festgelegt => mini...)
Auch nicht befriedigend... (aber hier noch mehr OT als der Rest, komme ggf. an anderer Stelle wieder darauf zurück...).
ZitatIch schlage vor, vom MQTT-FAQ Beitrag das Fixieren zu entfernen: es leitet die Leute in die falsche Richtung, wenn die nicht gewollt sind, bis zu deinem Beitrag weiterzulesen, und selbst danach gibt es eine Diskussion, so dass es nicht eindeutig ist, was man machen soll.
Habe jetzt im Wiki den (alten) FAQ-Thread verlinkt und bin auch der Meinung, dass das meiste des Contents (Stand heute) eher irreführend sein dürfte. Manches (z.B. die Sicherheitsthemen) ist da sicher noch interessant, und da wäre es gut, wenn sich "jemand" (lies: eigentlich keiner von uns beiden) mal drum kümmern würde, das in die Wiki-Seiten an passender Stelle einzupflegen.
Von daher: Bitte wie vorgeschlagen ab-pinnen...
ZitatKönntest du das komplette MQTT2_DEVICE zeigen incl. der setList für on/off und der passenden (gesäuberten) readingList?
Und etwas näher erläutern, wie dein MQTT-Umfeld aussieht (mosquitto+CLIENT?)?
Möchte mich nun ungern mit fremden Federn schmücken, deshalb würde ich gerne auf zwei Seiten verlinken, auf welchen ich die Infos gefunden habe:
1. http://wiki.gorjup.de/doku.php?id=public:fhem_zigbee2tasmota
Thomas hat auf seiner Seite sehr schön beschrieben, wie das Zigbee2Tasmota Device (CC2530 & ESP8266) selbst konfiguriert wird - auch in Verbindung mit MQTT2 in FHEM
2. https://blog.moneybag.de/angetestet-zigbee2tasmota-gateway-mit-zigbee-cc2530-und-esp8266
Robin hat den Hinweis bzgl. Integration des Befehls, welcher mir fehlte, ganz zum Schluss in Bezug auf HUE auf seinem Blog
In dem Zigbee2MQTT Device, welches in FHEM manuell angelegt wurde, werden je Zigbee-Device Readings hinterlegt, sobald man dies über die Tasmota-Konsole pairt. Diese kann man dann lediglich auslesen, was jedoch für Fensterkontakt (Aqara/Xiaomi) bzw. Xiaomi-Cube ausreicht, um Readings weiterzuverarbeiten. (als Screenshot auch in den o.g. Links zu sehen)
ZbReceived_Osram1_Device 0xC1FF
ZbReceived_Osram1_Endpoint 3
ZbReceived_Osram1_LinkQuality 99
ZbReceived_Osram1_Manufacturer OSRAM
ZbReceived_Osram1_ModelId Classic A60 W clear - LIGHTIFY
ZbReceived_Osram1_Power 0
Auf der Seite: https://tasmota.github.io/docs/Zigbee/ kann man dann die entsprechenden unterstützten Zigbee-Devices finden - zumindest meine Osram-LED-Birne (bzw. andere Osram-Leuchtmittel, an welchen ich mich "orientiert hatte") und viele andere zu unterstützende Devices.
Ich habe diese LED-Birne mit einem einfachen DOIF iVm einem Dummy-Schalter eingebunden:
defmod di_Osram1_an_aus DOIF ([LED_Birne:"on"]) (set myBroker publish cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"On"}}) DOELSEIF ([LED_Birne:"off"]) (set myBroker publish cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"Off"}})
Hier eine Zusammenfassung von verschiedenen Befehlen:
https://tasmota.github.io/docs/Zigbee/#sending-commands
Hoffe das reicht aus um das "Konstrukt" zu verstehen.
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:
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:
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 ;) :
Zitat von: kimbolero am 19 Juni 2020, 21:02:50
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.
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...
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...).
Sorry, habe nun schon ewig nicht mehr hier im Forum bzw im Beitrag reingeschaut.
@Beta-User:
ZitatZur 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?
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).
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:
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:
Specify the unknown parameters for zigbee2mqtt_bridge:
base topic as set in configuration.yaml of the zigbee2mqtt bridge [Eingabefeld]
Hier noch ein Log vom MQTT2Zigbee Device, wenn ich die Lampe über die Konsole einschalte:
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}}}
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 ;) .
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:
ZigBee2MQTT:stat/ZigBee2MQTT/LOGGING:.* LOGGING
ZigBee2MQTT:tele/ZigBee2MQTT/STATE:.* { json2nameValue($EVENT) }
ZigBee2MQTT:tele/ZigBee2MQTT/SENSOR:.* { json2nameValue($EVENT) }
Wollte nun mit
set MQTT2_ZigBee2MQTT attrTemplate tasmota_zigbee2tasmota_bridge
setzen - nun folgt dieser Dialog:
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 (http://wiki.gorjup.de/lib/exe/detail.php?id=public%3Afhem_zigbee2tasmota&media=public:zigbee2tasmoata_mqtt1.jpg)
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:
Zitat von: Beta-User am 01 August 2020, 20:57:54
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 ;) .
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:
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.
on cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"Off"}}\
off cmnd/ZigBee2MQTT/ZbSend {"device":"Osram1","send":{"Power":"Off"}}
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:
Zitat von: Beta-User am 01 August 2020, 20:57:54
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"...
Direkt mal versucht mit dem 2. Template - es erscheint folgende Fehlermeldung:
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:
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
OK, kannst du die betreffende Klammer mal entfernen?
Zeile 1662 in /opt/fhem/FHEM/lib/AttrTemplate/mqtt2.template sollte dann so aussehen:
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):
{ AttrTemplate_Initialize() }
Erl - danach kommt folgende Meldung, wenn ich das Template setzen möchte:
<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
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)
Das mit dem "kaputten" Speechcontrol-Ding ist seltsam; das hat eigentlich nicht direkt was mit dem aufrufenden attrTemplate zu tun. Muß ich mir mal ansehen.
Dimmen klappt auch?
Ein RAW wäre trotzdem informativ; das Reading "ZbReceived_Osram1_Power" sieht komisch aus.
Das mit dem Bewegungsmelder müßte man sich auch getrennt ansehen; tendenziell gibt es dafür kein template (@tasmota).
Hi zusammen,
ich habe mich sehr gefreut das heute zu lesen und konnte nach einem FHEM Update super-easy alles einrichten.
Vielen Vielen Dank dafür!Zitat von: Beta-User am 02 August 2020, 13:38:03
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"...
Ich hatte relativ wenig Thema dass die Geräte direkt angelegt wurden - war eher dann Details. Z.b. für Aqara Cube (https://zigbee.blakadder.com/Xiaomi_MFKZQ01LM.html):
defmod MQTT2_z2t_AAD5 MQTT2_DEVICE z2t_AAD5
attr MQTT2_z2t_AAD5 DbLogExclude .*
attr MQTT2_z2t_AAD5 IODev TEC_MQTT_SERVER
attr MQTT2_z2t_AAD5 alias Cube1
attr MQTT2_z2t_AAD5 readingList tele/tasmota3/AAD5/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_AAD5 room MQTT2_DEVICE
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:03 ZbReceived_Cube1_AppVersion 5
setstate MQTT2_z2t_AAD5 2020-08-02 14:42:17 ZbReceived_Cube1_AqaraCube shake
setstate MQTT2_z2t_AAD5 2020-08-02 14:27:16 ZbReceived_Cube1_AqaraCubeFromSide 3
setstate MQTT2_z2t_AAD5 2020-08-02 14:29:53 ZbReceived_Cube1_AqaraCubeSide 1
setstate MQTT2_z2t_AAD5 2020-08-02 14:42:01 ZbReceived_Cube1_AqaraRotate -19.03
setstate MQTT2_z2t_AAD5 2020-08-02 14:42:01 ZbReceived_Cube1_Aqara_FF05 500
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_Battery 51
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_BatteryPercentage 51
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_BatteryVoltage 2.915
setstate MQTT2_z2t_AAD5 2020-08-02 14:42:17 ZbReceived_Cube1_Device 0xAAD5
setstate MQTT2_z2t_AAD5 2020-08-02 14:42:17 ZbReceived_Cube1_Endpoint 2
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_LinkQuality 150
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:03 ZbReceived_Cube1_ModelId lumi.sensor_cube.aqgl01
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_Voltage 2.915
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_Xiaomi_97 0
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_Xiaomi_98 0
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_Xiaomi_99 0
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:04 ZbReceived_Cube1_Xiaomi_9A 4
setstate MQTT2_z2t_AAD5 2020-08-02 14:42:17 ZbReceived_Cube1_Name Cube1
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:03 associatedWith MQTT2_tasmota3Und bei Temperatur/Luftfeuchte Sensoren (https://zigbee.blakadder.com/Xiaomi_WSDCGQ01LM.html):
defmod MQTT2_z2t_9442 MQTT2_DEVICE z2t_9442
attr MQTT2_z2t_9442 DbLogExclude .*
attr MQTT2_z2t_9442 IODev TEC_MQTT_SERVER
attr MQTT2_z2t_9442 alias TempHum2
attr MQTT2_z2t_9442 readingList tele/tasmota3/9442/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_9442 room MQTT2_DEVICE
setstate MQTT2_z2t_9442 2020-08-02 14:14:10 ZbReceived_TempHum2_AppVersion 2
setstate MQTT2_z2t_9442 2020-08-02 14:14:11 ZbReceived_TempHum2_Battery 92
setstate MQTT2_z2t_9442 2020-08-02 14:14:11 ZbReceived_TempHum2_BatteryPercentage 92
setstate MQTT2_z2t_9442 2020-08-02 14:14:11 ZbReceived_TempHum2_BatteryVoltage 2.985
setstate MQTT2_z2t_9442 2020-08-02 14:17:25 ZbReceived_TempHum2_Device 0x9442
setstate MQTT2_z2t_9442 2020-08-02 14:17:25 ZbReceived_TempHum2_Endpoint 1
setstate MQTT2_z2t_9442 2020-08-02 14:16:09 ZbReceived_TempHum2_Humidity 53.91
setstate MQTT2_z2t_9442 2020-08-02 14:17:25 ZbReceived_TempHum2_LinkQuality 78
setstate MQTT2_z2t_9442 2020-08-02 14:14:15 ZbReceived_TempHum2_Manufacturer LUMI
setstate MQTT2_z2t_9442 2020-08-02 14:17:25 ZbReceived_TempHum2_ModelId lumi.sensor_ht
setstate MQTT2_z2t_9442 2020-08-02 14:17:25 ZbReceived_TempHum2_Name TempHum2
setstate MQTT2_z2t_9442 2020-08-02 14:16:09 ZbReceived_TempHum2_Temperature 28.85
setstate MQTT2_z2t_9442 2020-08-02 14:14:11 ZbReceived_TempHum2_Voltage 2.985
setstate MQTT2_z2t_9442 2020-08-02 14:14:10 associatedWith MQTT2_tasmota3Gibt es hier eine Möglichkeit bei den Attributen immer dieses "ZbReceived_Cube1_" bzw. "ZbReceived_TempHum2_" weg zu lassen? Ich weiss dass ich mir weitere Readings (userreadings) oder einen state (@kimbolero meinst du stateformat?) bauen kann (welcher mir das übersetzt in ein Standardformat) - aber evtl. kennst du, Beta-User, einen besseren Weg?
Vielen Dank im Voraus!
Viele Grüße,
Uli
Hier nochmals beide Birnen im Detail:
1. TRADFRI bulb E27 WW 806lm]https://zigbee.blakadder.com/Ikea_LED1836G9-E27.html (https://zigbee.blakadder.com/Ikea_LED1836G9-E27.html)
defmod MQTT2_z2t_51FF MQTT2_DEVICE z2t_51FF
attr MQTT2_z2t_51FF IODev myBroker
attr MQTT2_z2t_51FF alias Tradfri806LmE27
attr MQTT2_z2t_51FF devStateIcon on:on@red off:off
attr MQTT2_z2t_51FF genericDeviceType light
attr MQTT2_z2t_51FF homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
attr MQTT2_z2t_51FF icon light_control
attr MQTT2_z2t_51FF jsonMap Dimmer:brightness Power:state Battery:batteryPercent
attr MQTT2_z2t_51FF model tasmota_zigbee2tasmota_light_dimmer
attr MQTT2_z2t_51FF readingList tele/ZigBee2MQTT/51FF/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_51FF room MQTT2_Device
attr MQTT2_z2t_51FF setList on cmnd/ZigBee2MQTT/ZbSend {"device":"0x51FF","send":{"Power":"On"}}\
off cmnd/ZigBee2MQTT/ZbSend {"device":"0x51FF","send":{"Power":"Off"}}\
brightness:colorpicker,BRI,0,5,254 cmnd/ZigBee2MQTT/ZbSend { "device":"0x51FF", "send":{"Dimmer":$EVTPART1} }\
dimup:noArg cmnd/ZigBee2MQTT/ZbSend { "device":"0x51FF", "send":{"DimmerUp"} }\
dimdown:noArg cmnd/ZigBee2MQTT/ZbSend { "device":"0x51FF", "send":{"DimmerDown"} }
attr MQTT2_z2t_51FF setStateList on off
setstate MQTT2_z2t_51FF set_on
setstate MQTT2_z2t_51FF 2020-08-02 15:06:18 ZbReceived_Tradfri806LmE27_Device 0x51FF
setstate MQTT2_z2t_51FF 2020-08-02 15:05:17 ZbReceived_Tradfri806LmE27_Dimmer 55
setstate MQTT2_z2t_51FF 2020-08-02 15:06:18 ZbReceived_Tradfri806LmE27_Endpoint 1
setstate MQTT2_z2t_51FF 2020-08-02 15:06:18 ZbReceived_Tradfri806LmE27_LinkQuality 76
setstate MQTT2_z2t_51FF 2020-08-02 14:08:54 ZbReceived_Tradfri806LmE27_Manufacturer IKEA of Sweden
setstate MQTT2_z2t_51FF 2020-08-02 14:08:54 ZbReceived_Tradfri806LmE27_ModelId TRADFRI bulb E27 WW 806lm
setstate MQTT2_z2t_51FF 2020-08-02 15:06:18 ZbReceived_Tradfri806LmE27_Power 1
setstate MQTT2_z2t_51FF 2020-08-02 13:06:35 associatedWith MQTT2_ZigBee2MQTT
setstate MQTT2_z2t_51FF 2020-08-02 14:09:11 attrTemplateVersion 20200718_1
setstate MQTT2_z2t_51FF 2020-08-02 15:05:16 brightness set 55
setstate MQTT2_z2t_51FF 2020-08-02 15:06:00 dimdown set
setstate MQTT2_z2t_51FF 2020-08-02 15:05:57 dimup set
setstate MQTT2_z2t_51FF 2020-08-02 15:06:17 state set_onFunktionieren tut Folgendes:
On
Off
Brightness (Schieberegler)
Off-for-timer
Off-till
On-for-timer
On-till
Nicht funktionieren tut:
toogle --> schaltet komischerweise nur an ausgeschaltete Birne ein, aber kein eingeschaltete Birne aus
dimup
dimdown
blink --> fraglich, ob hier ein Wert angegeben werden muss
intervals --> faglich, ob hier ein Wert angegeben werden muss
Nicht ausprobiert, sollte aber sicherlich auch funktionieren:
Off-till-overnite
On-till-overnite
2. Osram A60 (lt. Amazon lediglich dimmbar)defmod MQTT2_z2t_C1FF MQTT2_DEVICE z2t_C1FF
attr MQTT2_z2t_C1FF IODev myBroker
attr MQTT2_z2t_C1FF alias Osram1
attr MQTT2_z2t_C1FF devStateIcon on:on@red off:off
attr MQTT2_z2t_C1FF genericDeviceType light
attr MQTT2_z2t_C1FF homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216,delay=true
attr MQTT2_z2t_C1FF icon light_control
attr MQTT2_z2t_C1FF jsonMap Dimmer:brightness Power:state Battery:batteryPercent
attr MQTT2_z2t_C1FF model tasmota_zigbee2tasmota_light_dimmer
attr MQTT2_z2t_C1FF readingList tele/ZigBee2MQTT/C1FF/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_C1FF room MQTT2_Device
attr MQTT2_z2t_C1FF setList on cmnd/ZigBee2MQTT/ZbSend {"device":"0xC1FF","send":{"Power":"On"}}\
off cmnd/ZigBee2MQTT/ZbSend {"device":"0xC1FF","send":{"Power":"Off"}}\
brightness:colorpicker,BRI,0,5,254 cmnd/ZigBee2MQTT/ZbSend { "device":"0xC1FF", "send":{"Dimmer":$EVTPART1} }\
dimup:noArg cmnd/ZigBee2MQTT/ZbSend { "device":"0xC1FF", "send":{"DimmerUp"} }\
dimdown:noArg cmnd/ZigBee2MQTT/ZbSend { "device":"0xC1FF", "send":{"DimmerDown"} }
attr MQTT2_z2t_C1FF setStateList on off
setstate MQTT2_z2t_C1FF set_on
setstate MQTT2_z2t_C1FF 2020-08-02 14:08:35 ZbReceived_Osram1_Device 0xC1FF
setstate MQTT2_z2t_C1FF 2020-08-02 14:08:35 ZbReceived_Osram1_Endpoint 3
setstate MQTT2_z2t_C1FF 2020-08-02 14:08:35 ZbReceived_Osram1_LinkQuality 68
setstate MQTT2_z2t_C1FF 2020-08-02 14:08:35 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:57:31 attrTemplateVersion 20200718_1
setstate MQTT2_z2t_C1FF 2020-08-02 14:05:15 dimdown set
setstate MQTT2_z2t_C1FF 2020-08-02 15:05:00 state set_on
Die Lampe nimmt exakt die gleichen Befehle wie die Tradfri an
Funktionieren tut Folgendes:
On
Off
Brightness (Schieberegler)
Off-for-timer
Off-till
On-for-timer
On-till
Nicht funktionieren tut:
toogle --> schaltet komischerweise nur an ausgeschaltete Birne ein, aber kein eingeschaltete Birne aus
dimup
dimdown
blink --> fraglich, ob hier ein Wert angegeben werden muss
intervals --> faglich, ob hier ein Wert angegeben werden muss
Nicht ausprobiert, sollte aber sicherlich auch funktionieren:
Off-till-overnite
On-till-overnite
@Beta-User:
ZitatEin RAW wäre trotzdem informativ; das Reading "ZbReceived_Osram1_Power" sieht komisch aus.
Bei der Osram bzw Tradfri Birne steht im Reading Power entweder "0" für aus und "1" für an
@SirUli:
ZitatIch weiss dass ich mir weitere Readings (userreadings) oder einen state (@kimbolero meinst du stateformat?) bauen kann (welcher mir das übersetzt in ein Standardformat) - aber evtl. kennst du, Beta-User, einen besseren Weg?
Vollkommen richtig - Tippfehler, habe es oben direkt geändert
Hallo,
lese mal mit :-)
@Beta-User:
ZitatGgf. 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"...
Hier noch die RAWs der weiteren Devices, welche ich habe:
1. Tradfri Bewegungsmelderhttps://zigbee.blakadder.com/Ikea_E1745.html (https://zigbee.blakadder.com/Ikea_E1745.html)
defmod MQTT2_z2t_C9E7 MQTT2_DEVICE z2t_C9E7
attr MQTT2_z2t_C9E7 IODev myBroker
attr MQTT2_z2t_C9E7 alias TradfriBWM
attr MQTT2_z2t_C9E7 readingList tele/ZigBee2MQTT/C9E7/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_C9E7 room MQTT2_Device
setstate MQTT2_z2t_C9E7 2020-08-02 16:28:57 ZbReceived_TradfriBWM_0006_42 0008070000
setstate MQTT2_z2t_C9E7 2020-08-02 16:28:57 ZbReceived_TradfriBWM_Device 0xC9E7
setstate MQTT2_z2t_C9E7 2020-08-02 16:28:57 ZbReceived_TradfriBWM_Endpoint 1
setstate MQTT2_z2t_C9E7 2020-08-02 16:28:57 ZbReceived_TradfriBWM_LinkQuality 115
setstate MQTT2_z2t_C9E7 2020-08-02 13:07:12 ZbReceived_TradfriBWM_Manufacturer IKEA of Sweden
setstate MQTT2_z2t_C9E7 2020-08-02 13:07:12 ZbReceived_TradfriBWM_ModelId TRADFRI motion sensor
setstate MQTT2_z2t_C9E7 2020-08-02 16:28:57 ZbReceived_TradfriBWM_Power 66
setstate MQTT2_z2t_C9E7 2020-08-02 12:57:42 associatedWith MQTT2_ZigBee2MQTT
2. Xiaomi Temp/Humidity Sensorhttps://zigbee.blakadder.com/Xiaomi_MCCGQ01LM.html (https://zigbee.blakadder.com/Xiaomi_MCCGQ01LM.html)
defmod MQTT2_z2t_6EA4 MQTT2_DEVICE z2t_6EA4
attr MQTT2_z2t_6EA4 IODev myBroker
attr MQTT2_z2t_6EA4 alias Xiaomi_Humitemp1
attr MQTT2_z2t_6EA4 readingList tele/ZigBee2MQTT/6EA4/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_6EA4 room MQTT2_Device
attr MQTT2_z2t_6EA4 stateFormat T: ZbReceived_Humitemp1_Temperature°C | H: ZbReceived_Humitemp1_Humidity% | B: ZbReceived_Humitemp1_Battery%
setstate MQTT2_z2t_6EA4 T: 25.65°C | H: 57.91% | B: 100%
setstate MQTT2_z2t_6EA4 2020-08-02 16:01:56 ZbReceived_Humitemp1_Battery 100
setstate MQTT2_z2t_6EA4 2020-08-02 16:01:56 ZbReceived_Humitemp1_Device 0x6EA4
setstate MQTT2_z2t_6EA4 2020-08-02 16:01:56 ZbReceived_Humitemp1_Endpoint 1
setstate MQTT2_z2t_6EA4 2020-08-02 16:01:56 ZbReceived_Humitemp1_Humidity 57.91
setstate MQTT2_z2t_6EA4 2020-08-02 16:01:56 ZbReceived_Humitemp1_LinkQuality 147
setstate MQTT2_z2t_6EA4 2020-08-02 13:07:32 ZbReceived_Humitemp1_ModelId lumi.sensor_ht
setstate MQTT2_z2t_6EA4 2020-08-02 16:01:56 ZbReceived_Humitemp1_Temperature 25.65
setstate MQTT2_z2t_6EA4 2020-08-02 16:01:56 ZbReceived_Humitemp1_Voltage 3.015
setstate MQTT2_z2t_6EA4 2020-08-02 13:07:32 associatedWith MQTT2_ZigBee2MQTT
3. Xiaomi/Aqara Cubehttps://zigbee.blakadder.com/Xiaomi_MFKZQ01LM.html (https://zigbee.blakadder.com/Xiaomi_MFKZQ01LM.html)
defmod MQTT2_z2t_0289 MQTT2_DEVICE z2t_0289
attr MQTT2_z2t_0289 IODev myBroker
attr MQTT2_z2t_0289 alias Xiaomi_Cube
attr MQTT2_z2t_0289 readingList tele/ZigBee2MQTT/0289/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_0289 room MQTT2_Device
setstate MQTT2_z2t_0289 2020-08-02 13:43:55 ZbReceived_Cube1_AqaraCube slide
setstate MQTT2_z2t_0289 2020-08-02 13:43:55 ZbReceived_Cube1_AqaraCubeSide 3
setstate MQTT2_z2t_0289 2020-08-02 13:43:53 ZbReceived_Cube1_AqaraRotate 11.24
setstate MQTT2_z2t_0289 2020-08-02 13:43:53 ZbReceived_Cube1_Aqara_FF05 500
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_Battery 100
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_Device 0x0289
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_Endpoint 1
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_LinkQuality 141
setstate MQTT2_z2t_0289 2020-08-02 13:43:55 ZbReceived_Cube1_MultiInValue 259
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_Voltage 3.005
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_Xiaomi_97 0
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_Xiaomi_98 148
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_Xiaomi_99 142
setstate MQTT2_z2t_0289 2020-08-02 15:43:28 ZbReceived_Cube1_Xiaomi_9A 4
setstate MQTT2_z2t_0289 2020-08-02 13:02:11 associatedWith MQTT2_ZigBee2MQTT
4. Xiaomi Tür/Fenster-Kontakthttps://zigbee.blakadder.com/Xiaomi_MCCGQ01LM.html (https://zigbee.blakadder.com/Xiaomi_MCCGQ01LM.html)
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 geschlossen:fts_door@green offen:fts_door_open@red
attr MQTT2_z2t_BEF7 eventMap 0:geschlossen 1:offen
attr MQTT2_z2t_BEF7 group Anzeige
attr MQTT2_z2t_BEF7 readingList tele/ZigBee2MQTT/BEF7/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_BEF7 room Fensterkontakte,MQTT2_Device
attr MQTT2_z2t_BEF7 stateFormat ZbReceived_Fenster1_Power
setstate MQTT2_z2t_BEF7 geschlossen
setstate MQTT2_z2t_BEF7 2020-08-02 16:16:49 ZbReceived_Fenster1_DateCode 0
setstate MQTT2_z2t_BEF7 2020-08-02 14:38:49 ZbReceived_Fenster1_DateCode2 null
setstate MQTT2_z2t_BEF7 2020-08-02 16:18:39 ZbReceived_Fenster1_Device 0xBEF7
setstate MQTT2_z2t_BEF7 2020-08-02 16:18:39 ZbReceived_Fenster1_Endpoint 1
setstate MQTT2_z2t_BEF7 2020-08-02 16:16:49 ZbReceived_Fenster1_HWVersion null
setstate MQTT2_z2t_BEF7 2020-08-02 16:18:39 ZbReceived_Fenster1_LinkQuality 63
setstate MQTT2_z2t_BEF7 2020-08-02 16:18:39 ZbReceived_Fenster1_Power 0
setstate MQTT2_z2t_BEF7 2020-08-02 15:39:00 ZbReceived_Fenster1_StackVersion null
setstate MQTT2_z2t_BEF7 2020-08-02 16:16:49 ZbReceived_Fenster1_ZCLVersion 382
setstate MQTT2_z2t_BEF7 2020-08-02 13:43:20 associatedWith MQTT2_ZigBee2MQTT@Beta-User: Zunächst aber auch
vielen vielen Dank für Deine Unterstützung und Geduld ;-)
Sag mir Bescheid, wenn Du weitere Infos benötigst.
:) Danke erst mal für das nette Feedback!
Nachdem wir ja jetzt den Pfad pro Endgerät haben, müßte man ggf. erst mal hergehen und noch ein paar Bausteinchen neu zusammenpuzzeln:
- Zum einen sollte "^.*(..Device.+)..$" als Regex den "inneren JSON" liefern, um nur noch den an json2nameValue() zu übergeben. Ist vermutlich einfacher, als den "Umbenennungsnamen" zu ermitteln...
- Das Umbenennen der Readings geht dann mit jsonMap, damit sollte man es eigentlich hinbekommen, dass die Rückgabewerte auch wieder sauber auf die setter passen...
- Das mit der "1" in Power ist unschön. Kann mal jemand nachforschen, ob man das ggf. auf der Tasmota-Seite bereinigt bekommt? (Sonst müssen wir ggf. eine Ersetzungs-Vor-Schleife drehen; tendenziell etwas einfacher wie hier: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template?rev=22513#L2617)
Würde daher vorschlagen, erst mal die ersten beiden Punkte anzugehen. Dazu hatte ich mal für die A60 was vorbereitet gehabt, was bei euch aber wohl (kommentarlos...?!?) rausgeflogen ist, weil es mit umbenannten Devices nicht funktioniert hatte... TELETOPIC/SENSOR:.* { $EVENT =~ m,0xDEV_ID.:(.[^}]+.), ? json2nameValue($1,'',$JSONMAP) : undef }
Mag mal wer diese Version testen und dann auch Rückmeldung geben...?
TELETOPIC/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : undef }
Die müßte eigentlich für alle Hardware-Varianten passen, die Details (dimUp etc.) müssen wir uns dann später ansehen, ich hatte teils nur eben auf die Schnelle zusammengeklaubt, was an anderer Stelle als funktionierend genannt gewesen war.
Vielleicht im Nachgang zu dem hier
Zitat von: Beta-User am 03 August 2020, 11:20:33- Zum einen sollte "^.*(..Device.+)..$" als Regex den "inneren JSON" liefern, um nur noch den an json2nameValue() zu übergeben. Ist vermutlich einfacher, als den "Umbenennungsnamen" zu ermitteln...
[...]
Dazu hatte ich mal für die A60 was vorbereitet gehabt, was bei euch aber wohl (kommentarlos...?!?) rausgeflogen ist, weil es mit umbenannten Devices nicht funktioniert hatte... TELETOPIC/SENSOR:.* { $EVENT =~ m,0xDEV_ID..[^}]+.), ? json2nameValue($1,'',$JSONMAP) : undef }Mag mal wer diese Version testen und dann auch Rückmeldung geben...?
nochmal eine Frage betreffend einzuhaltende Konventionen:
1. Soweit das hier erkennbar war, haben praktisch alle ihre Devices umbenannt, die "Technamen" (kurze HEX-ID) verwendet praktisch keiner. Mit umbenannten Devices klappt das aber nicht mit der Ausgangsregex, was vermutlich der Grund für kimbolero war, einfach wieder die "einfache" Variante von json2nameValue() einzubauen
2. Teils wurde SetOption83 gesetzt, teils nicht. Ohne klappt das mit "^.*(..Device.+)..$" aber nicht...
Ich würde daraus jetzt den Schluss ziehen, dass wir (analog zu SetOption89) auch SetOption83 automatisiert setzen, damit die, die erst ohne die attrTemplates unterwegs waren, nicht wieder zu den Technamen zurück müssen (was eigentlich einfacher wäre). Unterschiedliche Varianten würde ich jedenfalls ungern via attrTemplate unterstützen wollen.
Einverstanden?
Ansonsten hatte ich beim Durchsehen von https://tasmota.github.io/docs/Zigbee/ den Eindruck, dass da 1/true/"true" usw. ziemlich bunt durcheinandergehen. Ich hoffe mal, das täuscht, sonst wird das blöd in der vorbereitenden Aufarbeitung...
Zitat von: Beta-User am 03 August 2020, 13:42:31Soweit das hier erkennbar war, haben praktisch alle ihre Devices umbenannt, die "Technamen" (kurze HEX-ID) verwendet praktisch keiner.
Würde ich als Konvention so setzen - sehe ich wie du.
Zitat von: Beta-User am 03 August 2020, 13:42:31Ich würde daraus jetzt den Schluss ziehen, dass wir (analog zu SetOption89) auch SetOption83 automatisiert setzen
Sehe ich auch so.
Zitat von: Beta-User am 03 August 2020, 11:20:33
Mag mal wer diese Version testen und dann auch Rückmeldung geben...?
TELETOPIC/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : undef }
Für meine Devices passt das und funktioniert:
Cube:
defmod MQTT2_z2t_AAD5 MQTT2_DEVICE z2t_AAD5
attr MQTT2_z2t_AAD5 DbLogExclude .*
attr MQTT2_z2t_AAD5 IODev TEC_MQTT_SERVER
attr MQTT2_z2t_AAD5 alias Cube1
attr MQTT2_z2t_AAD5 readingList tele/tasmota3/AAD5/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_AAD5 room MQTT2_DEVICE
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:13 AqaraCube shake
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:11 AqaraCubeFromSide 1
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:11 AqaraCubeSide 0
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:23 AqaraRotate 148.03
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:23 Aqara_FF05 500
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:23 Device 0xAAD5
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:23 Endpoint 3
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:23 LinkQuality 132
setstate MQTT2_z2t_AAD5 2020-08-03 20:54:23 Name Cube1
setstate MQTT2_z2t_AAD5 2020-08-02 14:24:03 associatedWith MQTT2_tasmota3Und Temperatur/Luftfeuchte Sensor:
defmod MQTT2_z2t_9442 MQTT2_DEVICE z2t_9442
attr MQTT2_z2t_9442 DbLogExclude .*
attr MQTT2_z2t_9442 IODev TEC_MQTT_SERVER
attr MQTT2_z2t_9442 alias TempHum2
attr MQTT2_z2t_9442 readingList tele/tasmota3/9442/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_9442 room MQTT2_DEVICE
attr MQTT2_z2t_9442 stateFormat T: Temperature °C, H: Humidity %rH
attr MQTT2_z2t_9442 userReadings alive { return "ok" if ( (time_str2num(ReadingsTimestamp($NAME,"Temperature","0")) - time_str2num(OldTimestamp($NAME))) < 3600 );; return "dead" }
setstate MQTT2_z2t_9442 T: 27.03 °C, H: 52.78 %rH
setstate MQTT2_z2t_9442 2020-08-03 20:48:59 Battery 100
setstate MQTT2_z2t_9442 2020-08-03 20:48:59 BatteryPercentage 100
setstate MQTT2_z2t_9442 2020-08-03 20:48:59 BatteryVoltage 3.025
setstate MQTT2_z2t_9442 2020-08-03 20:49:14 Device 0x9442
setstate MQTT2_z2t_9442 2020-08-03 20:49:14 Endpoint 1
setstate MQTT2_z2t_9442 2020-08-03 20:49:14 Humidity 52.78
setstate MQTT2_z2t_9442 2020-08-03 20:49:14 LinkQuality 135
setstate MQTT2_z2t_9442 2020-08-03 20:48:59 ModelId lumi.sensor_ht
setstate MQTT2_z2t_9442 2020-08-03 20:49:14 Name TempHum2
setstate MQTT2_z2t_9442 2020-08-03 20:49:14 Temperature 27.03
setstate MQTT2_z2t_9442 2020-08-03 20:48:59 Voltage 3.025
setstate MQTT2_z2t_9442 2020-08-03 20:49:14 alive ok
setstate MQTT2_z2t_9442 2020-08-02 14:14:10 associatedWith MQTT2_tasmota3Vielen Dank dafür!
Moin zusammen,
mit dem update von heute kommen dann ein paar neue attrTemplate, die allerdings nur dann geladen werden, wenn das bridge-Device vorhanden ist. So ist wenigstens halbwegs sichergestellt, dass die beiden SetOption auch wirklich gesetzt wurden (wer noch nicht hat: jetzt wäre es Zeit...).
webCmd wäre ggf. bei den diversen light-Varianten noch zu ergänzen, und ich hoffe mal, dass jetzt auch die Rückmeldung zu state=on/off paßt (dann sollte z.B. toggle auch gehen...).
Für die diversen "Sensoren" gibt's erst mal ein generisches template. Die Idee dahinter ist, das für alle Varianten dann intern aufzurufen und nur noch die Teile zu ergänzen, die jeweils anders sind (jsonMap, ggf. stateFormat); das wird noch eine ziemliche Fleißaufgabe werden, und meine Hoffnung dazu wäre, das dann demnächst an einem Beispiel so demonstrieren zu können, dass ihr dann recht unkompliziert vollends zuarbeiten könnt. Dazu würde ich vorschlagen, den temp/hum-Xiaomi zu verwenden, da gibt's auch schon ein RAW, das zu der readingList paßt...
Um das kompatibel mit den vorhandenen Namenskonventionen zu machen: z.B. Temperature und Humidity klein schreiben?
@kimbolero:
Villeicht magst du den Titel ändern (ersten Post editieren), z.B. in "attrTemplate für ZigBee2Tasmota"
Moin,
vielen Dank mal wieder!
Ich habe die Bridge abgesteckt, alle MQTT2_z2t devices und die bridge gelöscht, gespeichert und dann FHEM aktualisiert. Dann wieder die Bridge angesteckt womit sich das Gerät via MQTT gemeldet hat. Dann attrTemplate drauf, was nun so aussieht:
defmod MQTT2_tasmota3 MQTT2_DEVICE tasmota3
attr MQTT2_tasmota3 DbLogExclude .*
attr MQTT2_tasmota3 IODev TEC_MQTT_SERVER
attr MQTT2_tasmota3 bridgeRegexp tele/tasmota3/([^/]+)/SENSOR:.* "z2t_$1"
attr MQTT2_tasmota3 icon mqtt
attr MQTT2_tasmota3 model tasmota_zigbee2tasmota_bridge
attr MQTT2_tasmota3 readingList tasmota3:stat/tasmota3/RESULT:.* { json2nameValue($EVENT) }\
tasmota3:tele/tasmota3/STATE:.* { json2nameValue($EVENT) }\
tasmota3:tele/tasmota3/LWT:.* LWT\
tasmota3:cmnd/tasmota3/POWER:.* POWER\
tasmota3:tele/tasmota3/INFO1:.* { json2nameValue($EVENT) }\
tasmota3:tele/tasmota3/INFO2:.* { json2nameValue($EVENT) }\
tasmota3:tele/tasmota3/INFO3:.* { json2nameValue($EVENT) }\
tasmota3:tele/tasmota3/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_tasmota3 room MQTT2_DEVICE
attr MQTT2_tasmota3 setList permit_join:0,1,99 cmnd/tasmota3/ZbPermitJoin $EVTPART1\
x_ZbSend:textField cmnd/tasmota3/zbsend {"device":"0x$EVTPART1","send":{"$EVTPART2":"$EVTPART3"}}
setstate MQTT2_tasmota3 2020-08-04 10:41:43 FallbackTopic cmnd/tasmota3_fb/
setstate MQTT2_tasmota3 2020-08-04 10:41:43 GroupTopic cmnd/tasmotas/
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Heap 26
setstate MQTT2_tasmota3 2020-08-04 10:41:43 Hostname tasmota3-2271
setstate MQTT2_tasmota3 2020-08-04 10:41:43 IPAddress XXXXXX
setstate MQTT2_tasmota3 2020-08-04 10:42:42 LWT Online
setstate MQTT2_tasmota3 2020-08-04 10:41:47 LoadAvg 19
setstate MQTT2_tasmota3 2020-08-04 10:41:43 Module Zigbee
setstate MQTT2_tasmota3 2020-08-04 10:41:47 MqttCount 1
setstate MQTT2_tasmota3 2020-08-04 10:42:42 POWER
setstate MQTT2_tasmota3 2020-08-04 09:39:19 Restart Restarting
setstate MQTT2_tasmota3 2020-08-04 09:39:26 RestartReason Software/System restart
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_1 40101674
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_10 4026a61f
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_11 40000f58
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_12 4026a092
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_13 402737f3
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_14 402730b3
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_15 4025147c
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_16 40000f49
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_17 40000f49
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_18 40000e19
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_19 40105aed
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_2 4026cdfb
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_20 40105af3
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_21 4010000d
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_22 40271f98
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_23 40271f49
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_24 40101160
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_25 40102738
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_26 401059e7
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_27 401032cb
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_28 401034ac
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_29 4010396e
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_3 4026cd90
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_30 40101160
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_31 40102b69
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_4 4026cd37
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_5 4026be94
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_6 4026bebd
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_7 40269928
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_8 4010396e
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_CallChain_9 40265c91
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_DEPC 00000000
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_EPC_1 4000df64
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_EPC_2 00000000
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_EPC_3 00000000
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_EXCVADDR 00000000
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_Exception 29
setstate MQTT2_tasmota3 2020-08-04 10:41:43 RestartReason_Reason Exception
setstate MQTT2_tasmota3 2020-08-04 09:39:21 SaveData on
setstate MQTT2_tasmota3 2020-08-04 09:39:20 SetOption26 on
setstate MQTT2_tasmota3 2020-08-04 09:39:21 SetOption83 on
setstate MQTT2_tasmota3 2020-08-04 09:39:21 SetOption89 on
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Sleep 50
setstate MQTT2_tasmota3 2020-08-04 10:41:47 SleepMode Dynamic
setstate MQTT2_tasmota3 2020-08-04 09:39:19 StateText1 off
setstate MQTT2_tasmota3 2020-08-04 09:39:20 StateText2 on
setstate MQTT2_tasmota3 2020-08-04 09:39:20 StateText3 toggle
setstate MQTT2_tasmota3 2020-08-04 09:39:20 StateText4 hold
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Time 2020-08-04T09:41:48
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Uptime 0T00:00:13
setstate MQTT2_tasmota3 2020-08-04 10:41:47 UptimeSec 13
setstate MQTT2_tasmota3 2020-08-04 10:41:43 Version 8.4.0(tasmota)
setstate MQTT2_tasmota3 2020-08-04 10:41:43 WebServerMode Admin
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Wifi_AP 1
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Wifi_BSSId XXXXXX
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Wifi_Channel 1
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Wifi_Downtime 0T00:00:07
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Wifi_LinkCount 1
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Wifi_RSSI 42
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Wifi_SSId XXXXXX
setstate MQTT2_tasmota3 2020-08-04 10:41:47 Wifi_Signal -79
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_AssocDevicesList_1 0x12F8
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_AssocDevicesList_2 0x9442
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_AssocDevicesList_3 0x280A
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_AssocDevicesList_4 0x9F29
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_AssocDevicesList_5 0xAAD5
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_AssocDevicesList_6 0x874F
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_DeviceState 9
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_DeviceType 7
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_IEEEAddr 0x00124B001F320B47
setstate MQTT2_tasmota3 2020-08-04 10:41:48 ZbState_MaintRel 3
setstate MQTT2_tasmota3 2020-08-04 10:41:48 ZbState_MajorRel 2
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_Message Started
setstate MQTT2_tasmota3 2020-08-04 10:41:48 ZbState_MinorRel 6
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_NewState 9
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_NumAssocDevices 6
setstate MQTT2_tasmota3 2020-08-04 10:41:48 ZbState_RestartReason Watchdog
setstate MQTT2_tasmota3 2020-08-04 10:41:48 ZbState_Revision 20190608
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_ShortAddr 0x0000
setstate MQTT2_tasmota3 2020-08-04 10:41:50 ZbState_Status 0
setstate MQTT2_tasmota3 2020-08-04 09:39:19 attrTemplateVersion 20200804
setstate MQTT2_tasmota3 2020-08-04 09:58:31 subscriptions cmnd/tasmota3/# cmnd/tasmota3_fb/# cmnd/tasmotas/#Diese hat dann begonnen die TemperaturSensoren wie folgt zu erstellen:
defmod MQTT2_z2t_12F8 MQTT2_DEVICE z2t_12F8
attr MQTT2_z2t_12F8 DbLogExclude .*
attr MQTT2_z2t_12F8 IODev TEC_MQTT_SERVER
attr MQTT2_z2t_12F8 readingList tele/tasmota3/12F8/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_12F8 room MQTT2_DEVICE
setstate MQTT2_z2t_12F8 2020-08-04 10:13:48 ZbReceived_TempHum4_Battery 100
setstate MQTT2_z2t_12F8 2020-08-04 10:13:48 ZbReceived_TempHum4_BatteryPercentage 100
setstate MQTT2_z2t_12F8 2020-08-04 10:13:48 ZbReceived_TempHum4_BatteryVoltage 3.015
setstate MQTT2_z2t_12F8 2020-08-04 10:42:50 ZbReceived_TempHum4_Device 0x12F8
setstate MQTT2_z2t_12F8 2020-08-04 10:42:50 ZbReceived_TempHum4_Endpoint 1
setstate MQTT2_z2t_12F8 2020-08-04 10:42:50 ZbReceived_TempHum4_Humidity 54.07
setstate MQTT2_z2t_12F8 2020-08-04 10:42:50 ZbReceived_TempHum4_LinkQuality 122
setstate MQTT2_z2t_12F8 2020-08-04 10:42:50 ZbReceived_TempHum4_Name TempHum4
setstate MQTT2_z2t_12F8 2020-08-04 10:42:50 ZbReceived_TempHum4_Temperature 23.22
setstate MQTT2_z2t_12F8 2020-08-04 10:13:48 ZbReceived_TempHum4_Voltage 3.015
setstate MQTT2_z2t_12F8 2020-08-04 09:49:53 associatedWith MQTT2_tasmota3Das war nicht ganz so wie geplant vermute ich. Zudem kann ich in diesem Device das neue Template tasmota_zigbee2tasmota_generic_battery_sensor nicht auswählen (obwohl ich mit einem "list model=tasmota_zigbee2tasmota_bridge" eigentlich das bridge device finde). Ich tippe dass es am readingList regex liegt, da diese bei mir "tele/tasmota3/12F8/SENSOR" zeigt und in deiner regex nach
TYPE=MQTT2_DEVICE:FILTER=readingList=.*tele.*/..../SENSOR gesucht wird?
Zitat von: Beta-User am 04 August 2020, 06:59:38
Um das kompatibel mit den vorhandenen Namenskonventionen zu machen: z.B. Temperature und Humidity klein schreiben?
Ja bitte - bin ich unbedingt dafür. Für den Cube muss man sich mal ausdenken wie das funktionieren kann, da dieser nicht immer alles in die gleichen Werte schreibt. Ich überlege mal (mein Beitrag zum zuarbeiten ;) )
Viele Grüße,
Uli
Kannst du nach dem ":" im Filter noch ein ".*" anhängen (dann neu Initialisieren)?
Dann müßte es eigentlich da sein.
Hallo,
auch von mir nochmal ein fettes Dankeschön an Beta-User für einen unermüdlichen Einsatz hier im Forum und besonders im MQTT-Bereich. Nachdem das hier eine ziemliche Dynamik entwickelt, will ich auch versuchen ein bischen was beizutragen. Darum habe ich heute ein Testsystem in Virtualbox mit einem tagesaktuellen Debian Buster und Fhem mit update von heute mittag aufgesetzt.MQTT2_Server definiert:
defmod MQTT2server MQTT2_SERVER 1884 global
attr MQTT2server autocreate simple
attr MQTT2server room Gatewayund mein Zigbee2tasmota Gateway (https://forum.fhem.de/index.php/topic,112502.0.html) darauf losgelassen. Die Bridge wurde auch per autocreate angelegt. Das Anwenden des Brigde Templates hat auch funktioniert, hier erhalte ich aber immer folgende Meldung:attr MQTT2_DVES_AAFFC1 readingList: attribute value is missing
Unknown command tele/zb2tasmota/LWT:.*, try help.
Raw Definition der Bridge:defmod MQTT2_DVES_AAFFC1 MQTT2_DEVICE DVES_AAFFC1
attr MQTT2_DVES_AAFFC1 IODev MQTT2server
attr MQTT2_DVES_AAFFC1 bridgeRegexp tele/zb2tasmota/([^/]+)/SENSOR:.* "z2t_$1"
attr MQTT2_DVES_AAFFC1 icon mqtt
attr MQTT2_DVES_AAFFC1 model tasmota_zigbee2tasmota_bridge
attr MQTT2_DVES_AAFFC1 readingList DVES_AAFFC1:stat/zb2tasmota/RESULT:.* { json2nameValue($EVENT) }\
DVES_AAFFC1:tele/zb2tasmota/LWT:.* LWT\
DVES_AAFFC1:cmnd/zb2tasmota/POWER:.* POWER\
DVES_AAFFC1:tele/zb2tasmota/INFO1:.* { json2nameValue($EVENT) }\
DVES_AAFFC1:tele/zb2tasmota/INFO2:.* { json2nameValue($EVENT) }\
DVES_AAFFC1:tele/zb2tasmota/INFO3:.* { json2nameValue($EVENT) }\
DVES_AAFFC1:tele/zb2tasmota/STATE:.* { json2nameValue($EVENT) }\
DVES_AAFFC1:tele/zb2tasmota/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_AAFFC1 room MQTT2_DEVICE
attr MQTT2_DVES_AAFFC1 setList permit_join:0,1,99 cmnd/zb2tasmota/ZbPermitJoin $EVTPART1\
x_ZbSend:textField cmnd/zb2tasmota/zbsend {"device":"0x$EVTPART1","send":{"$EVTPART2":"$EVTPART3"}}
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 FallbackTopic cmnd/DVES_AAFFC1_fb/
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 GroupTopic cmnd/tasmotas/
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Heap 27
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 Hostname zb2tasmota-8129
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 IPAddress 192.168.178.166
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 LWT Online
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 LoadAvg 19
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 Module Zigbee
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 MqttCount 1
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 POWER
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:21 Restart Restarting
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 RestartReason Software/System restart
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:23 SaveData on
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:22 SetOption26 on
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:22 SetOption83 on
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:22 SetOption89 on
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Sleep 50
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 SleepMode Dynamic
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:21 StateText1 off
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:21 StateText2 on
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:22 StateText3 toggle
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:22 StateText4 hold
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Time 2020-08-04T15:14:33
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Uptime 0T00:00:09
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 UptimeSec 9
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 Version 8.3.0(tasmota)
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:29 WebServerMode Admin
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Wifi_AP 1
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Wifi_BSSId E8:DF:70:D1:B9:02
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Wifi_Channel 9
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Wifi_Downtime 0T00:00:03
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Wifi_LinkCount 1
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Wifi_RSSI 90
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Wifi_SSId easybell DSL
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:33 Wifi_Signal -55
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_AssocDevicesList_1 0xA5A6
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_AssocDevicesList_2 0x0187
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_AssocDevicesList_3 0xF6F8
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_DeviceState 9
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_DeviceType 7
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_IEEEAddr 0x00124B001BAA5ADB
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:37 ZbState_MaintRel 3
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:37 ZbState_MajorRel 2
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_Message Started
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:37 ZbState_MinorRel 6
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_NewState 9
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_NumAssocDevices 3
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:37 ZbState_RestartReason Watchdog
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:37 ZbState_Revision 20190608
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_ShortAddr 0x0000
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:38 ZbState_Status 0
setstate MQTT2_DVES_AAFFC1 2020-08-04 15:14:21 attrTemplateVersion 20200804
Ein über die Tasmota Konsole geschalteter GU10 Spot, dimmbar und mit weiss Spektrum wurde automatisch angelegt. Nachdem ich wie oben beschrieben das Template geändert hatte habe ich das ...light_cct template darauf angewendet. Auch das hat prinzipell geklappt, allerdings bekomme ich kein vernünftiges Status Icon, der Wertebereich für das Weißspektrum liegt zwischen 153 und 370. Niedrigere Werte werden auf 153 angehoben, höhere Werte auf 370 gekappt.Als Beispiel hab ich mal in der Tasmota Konsole den CT Wert 400 probiert14:37:43 CMD: ZbSend { "device":"0xF6F8", "send":{"CT":"400"} }
14:37:43 MQT: stat/zb2tasmota/RESULT = {"ZbSend":"Done"}
14:37:43 MQT: tele/zb2tasmota/RESULT = {"ZbResponse":{"Device":"0xF6F8","Command":"0300!0A","Status":0,"StatusMessage":"SUCCESS","Endpoint":1,"LinkQuality":63}}
14:37:45 MQT: tele/zb2tasmota/F6F8/SENSOR = {"ZbReceived":{"0xF6F8":{"X":29991,"Y":26872,"CT":370,"ColorMode":2,"Endpoint":1,"LinkQuality":63}}}
man sieht CT:370. Ich weiss allerdings nicht, ob das bei anderen Lampen andere Werte hat. Außerdem springt der Slider für den ct Wert immer wieder zurück auf den untersten Wert. Dimmer funktioniert soweit ich das sehe korrekt, dafür geht der toggle Befehl wie schon von anderen erwähnt nur in Richtung on
Fehlt noch die RAW Definition vom GU10 Spot
defmod MQTT2_z2t_F6F8 MQTT2_DEVICE z2t_F6F8
attr MQTT2_z2t_F6F8 IODev MQTT2server
attr MQTT2_z2t_F6F8 icon light_control
attr MQTT2_z2t_F6F8 jsonMap Dimmer:brightness Power:state Device:0 Hue:hue Sat:saturation CT:ct
attr MQTT2_z2t_F6F8 model tasmota_zigbee2tasmota_light_cct
attr MQTT2_z2t_F6F8 readingList tele/zb2tasmota/F6F8/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_F6F8 room MQTT2_DEVICE
attr MQTT2_z2t_F6F8 setList on cmnd/zb2tasmota/ZbSend {"device":"0xF6F8","send":{"Power":"On"}}\
off cmnd/zb2tasmota/ZbSend {"device":"0xF6F8","send":{"Power":"Off"}}\
brightness:colorpicker,BRI,0,5,254 cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"Dimmer":$EVTPART1} }\
dimup:noArg cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"DimmerUp"} }\
dimdown:noArg cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"DimmerDown"} }\
ct:colorpicker,CT,153,10,370 cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"CT":$EVTPART1} }
attr MQTT2_z2t_F6F8 setStateList on off
attr MQTT2_z2t_F6F8 webCmd on:off:brightness:ct
setstate MQTT2_z2t_F6F8 set_off
setstate MQTT2_z2t_F6F8 2020-08-04 14:58:42 ZbReceived_0xF6F8_CT 223
setstate MQTT2_z2t_F6F8 2020-08-04 14:58:42 ZbReceived_0xF6F8_ColorMode 2
setstate MQTT2_z2t_F6F8 2020-08-04 14:56:55 ZbReceived_0xF6F8_Dimmer 250
setstate MQTT2_z2t_F6F8 2020-08-04 15:35:13 ZbReceived_0xF6F8_Endpoint 1
setstate MQTT2_z2t_F6F8 2020-08-04 15:35:13 ZbReceived_0xF6F8_LinkQuality 57
setstate MQTT2_z2t_F6F8 2020-08-04 15:35:13 ZbReceived_0xF6F8_Power 0
setstate MQTT2_z2t_F6F8 2020-08-04 14:58:42 ZbReceived_0xF6F8_X 23841
setstate MQTT2_z2t_F6F8 2020-08-04 14:58:42 ZbReceived_0xF6F8_Y 24103
setstate MQTT2_z2t_F6F8 2020-08-04 13:56:44 associatedWith MQTT2_DVES_AAFFC1
setstate MQTT2_z2t_F6F8 2020-08-04 14:29:08 attrTemplateVersion 20200804
setstate MQTT2_z2t_F6F8 2020-08-04 14:56:53 brightness set 250
setstate MQTT2_z2t_F6F8 2020-08-04 14:58:40 ct set 223
setstate MQTT2_z2t_F6F8 2020-08-04 15:35:12 state set_off UFF, das war ein ganz schöner Roman, hoffe aber es hilft weiter.
Nochmals danke und beste Grüße
Thomas
Hmm, da sind noch ein paar kleine Fehlerchen drin (da fehlt z.B. ein Zeilenumbruch nach dem rL-attr). Bugfix folgt ggf. vor morgen früh, allerdings kann ich das nicht versprechen, ggf. bitte selbst mal drübersehen.
Grundsätzlich ist es ok, wenn die automatisch erstellten Devices dann erst mal die "komischen" Readings haben, nach Anwenden der weiteren Templates sollte das aber weg sein (sonst paßt jsonMap auch nicht dazu).
Wertebereiche, z.B. für ct (0-254) hatte ich aus der Tasmota-z2t-Seite, wenn da "Müll" steht, sollten wir es in attrTemplate bereinigen und auch Feedback in Richtung von Theo&Co geben (die Slider anzupassen, ist nicht schwer, bitte im Wiki nach Color sehen, falls was unklar ist). Da ist es aber wirklich einfacher, ihr nehmt euch das template vor und testet das etwas aus, sonst ist das hin- und her fehleranfällig...
Bis demnächst!
Hi,
ich habe noch etwas weiter rumprobiert und dabei festgestellt, das
dimup:noArg cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"DimmerUp"} } keineAuswirkung hat und auf der Tasmota Konsole invalid Json usgegeben wird.
erweitert man den Befehl so dimup:noArg cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"DimmerUp":""} } wird erwartungsgemäß 10% hoch bzw. bei dimdown 10% runter gedimmt. Vielleicht kann man das ja noch einfließen lassen
Gruß Thomas
eiliges update ist drin, die gröbsten Schnitzer sollten raus sein und dim.* jetzt funktionieren, THX!
ct-Wertebereich etc. ist noch offen...
...ganz grosses Kino !!
Alles gelöscht und nach FHEM Update nochmal angefangen, die Bridge wird angelegt, inklusive der Meldung über Enstellungsveränderungen und autocreate zu aktivieren. Dann über die Tasmota Konsole einen Schaltbefehl für meine GU10LED abgesetzt, wird auch automatisch angelegt. Auf das angelegte device das Template ...tasmota_light_cct angwendet keine (Fehler-)Meldungen. An, Aus, Dimup, Dimdown und Dimmer mit Slider funktionieren korrekt. CT (weiss Spektrum)funktioniert out of the box schlecht bis gar nicht. Die Darstellung im Slider ist genau umgekehrt wie die Lichtwiedergabe meiner Lampe und wie gestern schon erwähnt werden die Werte unter 153 auf 153 angehoben und die Werte über 370 auf 370 gedeckelt. Hier vermute ich das Problem aber eher auf Tasmota Seite. Leider springt hier der Slider auch immer noch auf den kleinsten Wert zurück keine Ahnung warum. Mit den Einstellungenct:colorpicker,CT,153,5,370 cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"CT":$EVTPART1} }funktioniert der CTBereich der GU10 bei mir gut (Es bleibt das Slider Problem) Das Problem DevStateIcon habe ich für mich über stateFormat und die definition des DevStateIcon gelöst. jetzt nochmal eine komplette RAW Defintion der GU10
defmod MQTT2_z2t_F6F8 MQTT2_DEVICE z2t_F6F8
attr MQTT2_z2t_F6F8 IODev MQTT2server
attr MQTT2_z2t_F6F8 devStateIcon 1:light_light_dim_100@orange:off 0:light_light_dim_00@red:on
attr MQTT2_z2t_F6F8 icon light_control
attr MQTT2_z2t_F6F8 jsonMap Dimmer:brightness Power:state Device:0 Hue:hue Sat:saturation CT:ct
attr MQTT2_z2t_F6F8 model tasmota_zigbee2tasmota_light_cct
attr MQTT2_z2t_F6F8 readingList tele/zb2tasmota/F6F8/SENSOR/SENSOR:.* { $EVENT =~ s/"Power":1/"Power":"on"/g;;;; $EVENT =~ s/"Power":0/"Power":"off"/g;;;; $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : undef }\
tele/zb2tasmota/F6F8/SENSOR:.* { json2nameValue($EVENT) }
attr MQTT2_z2t_F6F8 room MQTT2_DEVICE
attr MQTT2_z2t_F6F8 setList on cmnd/zb2tasmota/ZbSend {"device":"0xF6F8","send":{"Power":"On"}}\
off cmnd/zb2tasmota/ZbSend {"device":"0xF6F8","send":{"Power":"Off"}}\
brightness:colorpicker,BRI,0,5,254 cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"Dimmer":$EVTPART1} }\
dimup:noArg cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"DimmerUp":""} }\
dimdown:noArg cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"DimmerDown":""} }\
ct:colorpicker,CT,153,5,370 cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"CT":$EVTPART1} }
attr MQTT2_z2t_F6F8 setStateList on off
attr MQTT2_z2t_F6F8 stateFormat ZbReceived_0xF6F8_Power
attr MQTT2_z2t_F6F8 webCmd on:off:brightness:ct
setstate MQTT2_z2t_F6F8 0
setstate MQTT2_z2t_F6F8 2020-08-05 16:41:54 ZbReceived_0xF6F8_CT 228
setstate MQTT2_z2t_F6F8 2020-08-05 16:41:54 ZbReceived_0xF6F8_ColorMode 2
setstate MQTT2_z2t_F6F8 2020-08-05 16:41:50 ZbReceived_0xF6F8_Dimmer 220
setstate MQTT2_z2t_F6F8 2020-08-05 16:42:30 ZbReceived_0xF6F8_Endpoint 1
setstate MQTT2_z2t_F6F8 2020-08-05 16:42:30 ZbReceived_0xF6F8_LinkQuality 84
setstate MQTT2_z2t_F6F8 2020-08-05 16:42:30 ZbReceived_0xF6F8_Power 0
setstate MQTT2_z2t_F6F8 2020-08-05 16:41:54 ZbReceived_0xF6F8_X 24082
setstate MQTT2_z2t_F6F8 2020-08-05 16:41:54 ZbReceived_0xF6F8_Y 24262
setstate MQTT2_z2t_F6F8 2020-08-05 16:19:33 associatedWith MQTT2_DVES_AAFFC1
setstate MQTT2_z2t_F6F8 2020-08-05 16:19:19 attrTemplateVersion 20200804_1
setstate MQTT2_z2t_F6F8 2020-08-05 16:41:48 brightness set 220
setstate MQTT2_z2t_F6F8 2020-08-05 16:41:52 ct set 228
setstate MQTT2_z2t_F6F8 2020-08-05 16:22:16 dimdown set
setstate MQTT2_z2t_F6F8 2020-08-05 16:22:51 dimup set
setstate MQTT2_z2t_F6F8 2020-08-05 16:42:29 state set_off und das Bridge device:
defmod MQTT2_DVES_AAFFC1 MQTT2_DEVICE DVES_AAFFC1
attr MQTT2_DVES_AAFFC1 IODev MQTT2server
attr MQTT2_DVES_AAFFC1 bridgeRegexp tele/zb2tasmota/([^/]+)/SENSOR:.* "z2t_$1"
attr MQTT2_DVES_AAFFC1 devStateIcon Online:10px-kreis-gruen Offline:10px-kreis-rot
attr MQTT2_DVES_AAFFC1 icon mqtt
attr MQTT2_DVES_AAFFC1 model tasmota_zigbee2tasmota_bridge
attr MQTT2_DVES_AAFFC1 readingList tele/zb2tasmota/LWT:.* LWT\
stat/zb2tasmota/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/zb2tasmota/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/zb2tasmota/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
DVES_AAFFC1:cmnd/zb2tasmota/POWER:.* POWER\
DVES_AAFFC1:tele/zb2tasmota/STATE:.* { json2nameValue($EVENT) }\
DVES_AAFFC1:tele/zb2tasmota/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_AAFFC1 room MQTT2_DEVICE
attr MQTT2_DVES_AAFFC1 setList permit_join:0,1,99 cmnd/zb2tasmota/ZbPermitJoin $EVTPART1\
x_ZbSend:textField cmnd/zb2tasmota/zbsend {"device":"0x$EVTPART1","send":{"$EVTPART2":"$EVTPART3"}}
attr MQTT2_DVES_AAFFC1 stateFormat LWT\
<br>\
ZbState_Message\
<br>\
<a href="http://IPAddress" target="_blank">IPAddress</a>
setstate MQTT2_DVES_AAFFC1 Online\
<br>\
Started\
<br>\
<a href="http://192.168.178.166" target="_blank">192.168.178.166</a>
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 FallbackTopic cmnd/DVES_AAFFC1_fb/
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 GroupTopic cmnd/tasmotas/
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Heap 25
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 Hostname zb2tasmota-8129
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 IPAddress 192.168.178.166
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 LWT Online
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 LoadAvg 26
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 Module Zigbee
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 MqttCount 1
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 POWER
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:03 Restart Restarting
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 RestartReason Software/System restart
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:05 SaveData on
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:04 SetOption26 on
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:05 SetOption83 on
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:05 SetOption89 on
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Sleep 50
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 SleepMode Dynamic
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:04 StateText1 off
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:04 StateText2 on
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:04 StateText3 toggle
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:04 StateText4 hold
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Time 2020-08-05T17:39:15
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Uptime 0T01:30:09
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 UptimeSec 5409
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 Version 8.3.0(tasmota)
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:11 WebServerMode Admin
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Wifi_AP 1
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Wifi_BSSId E8:DF:70:D1:B9:02
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Wifi_Channel 9
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Wifi_Downtime 0T00:00:03
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Wifi_LinkCount 1
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Wifi_RSSI 82
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Wifi_SSId easybell DSL
setstate MQTT2_DVES_AAFFC1 2020-08-05 17:39:15 Wifi_Signal -59
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:42:29 ZbResponse_Command 0006!00
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:42:29 ZbResponse_Device 0xF6F8
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:42:29 ZbResponse_Endpoint 1
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:42:29 ZbResponse_LinkQuality 86
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:42:29 ZbResponse_Status 0
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:42:29 ZbResponse_StatusMessage SUCCESS
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:42:29 ZbSend Done
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:20 ZbState_AssocDevicesList_1 0x0187
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:20 ZbState_AssocDevicesList_2 0xF6F8
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:20 ZbState_DeviceState 9
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:20 ZbState_DeviceType 7
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:20 ZbState_IEEEAddr 0x00124B001BAA5ADB
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:19 ZbState_MaintRel 3
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:19 ZbState_MajorRel 2
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:21 ZbState_Message Started
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:19 ZbState_MinorRel 6
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:20 ZbState_NewState 9
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:20 ZbState_NumAssocDevices 2
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:19 ZbState_RestartReason Watchdog
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:19 ZbState_Revision 20190608
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:20 ZbState_ShortAddr 0x0000
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:21 ZbState_Status 0
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:09:03 attrTemplateVersion 20200804_1
setstate MQTT2_DVES_AAFFC1 2020-08-05 16:18:48 subscriptions cmnd/DVES_AAFFC1_fb/# cmnd/tasmotas/# cmnd/zb2tasmota/#
wie man sehen kann habe ich das auch auf meine (Anzeige-) Verhältnisse angepasst. Sensor Geräte habe ich keine. Ich werde mir nachher nochmal den Ikea On/Off Switch (https://www.zigbee2mqtt.io/devices/E1743.html) anschauen
Gruß Thomas
:)
Dann sind wir einen großen Schritt weiter...
Was immer noch nicht paßt ist der readingList-Eintrag. Da sollte nur eine Zeile stehen, und zwar die erste, allerdings ohne den 2. "SENSOR". Bitte das mal löschen ;) .
So, habe eben mal die neuesten Erkenntnisse eingecheckt :) .
Bringt dann auch gleich ein dynamisches/farbiges devStateIcon und setExtensionEvents :) .
Falls das mit CT optisch "falsch rum" ist: Das kann man afaik auch drehen, also so herum notieren: ct:colorpicker,CT,370,-5,153 ...
Der Wertebereich an sich scheint Hue-Bridge-like zu sein...
Ich hoffe ich habe das richtig verstanden, aus dem Readinglist den 2. Eintrag entfernen und im ersten aus doppelt SENSOR ein einfaches machen? ReadingList sieht dann so aus tele/zb2tasmota/F6F8/SENSOR:.* { $EVENT =~ s/"Power":1/"Power":"on"/g;; $EVENT =~ s/"Power":0/"Power":"off"/g;; $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : undef }
Wenn ich das so schreibe werden keine Readings mehr aktualisiert :( . Nehme ich hingegen nur den 2Teil tele/zb2tasmota/F6F8/SENSOR:.* { json2nameValue($EVENT) } ist alles schick.Bezüglich des CT Sliders: der ist interessanterweise nur dann falsch herum wenn ich die Werte aus dem Template nehme, nehme ich die von mirct:colorpicker,CT,153,5,370 cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"CT":$EVTPART1} } ist alles ok und es bleibt nur das Problem des zurückspringenden Sliders und wenn ich das hier im Wiki richtig gelesen habe, könnte das ein Problem mit dem entsprechenden Reading sein. Heute werde ich aber nichts mehr machen (können). Morgen dann mal schauen was es mit CT und Mired auf sich hat. Dann vielleicht auch was zum On/Off Switch von Ikea
Schönen Abend noch
Hmm, da scheint SetOption83 genau das Gegenteil von dem zu bewirken wie das, was ich bisher angenommen hatte. Kannst du das mal auf "0" stellen?
(Das mit dem springenden Slider usw. hängt tatsächlich damit zusammen das die Rückmeldung noch nicht da landet, wo sie hin soll, wir sind da dran, keine Sorge ;) ).
Im svn ist jetzt eine Version, die hoffentlich mit beiden Fassungen der gesendeten JSON-Struktur klarkommen sollte...
Für eventuelle Tester: man kann das auch direkt runterladen und aktualisieren mit:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
Zitat von: Beta-User am 05 August 2020, 21:17:52
Im svn ist jetzt eine Version, die hoffentlich mit beiden Fassungen der gesendeten JSON-Struktur klarkommen sollte...
Für mich tut es das - sowohl bridge als auch generic sensor sind nun wunderbar. Nun wäre maximal noch das Thema der readings - also temperature etc alles in lowercase. Wegen mir könnten auch alle readings in lowercase sein, aber weiß nicht wie das andere sehen ;)
War leider die letzten Abende etwas abgelenkt - melde mich für den Cube nochmal!
Puh, was eine Geburt...
Das mit lowercase ist so eine Sache: Man könnte theoretisch den ganzen JSON erst durch lc() schicken, aber dann werden auch die Modellbezeichnungen lc(). => nicht das Gelbe vom Ei.
Manche Readings sind auch in FHEM nicht lc(), z.B. batteryPercent.
Mein Vorschlag wäre daher, alles "gängige" zu sammeln und dann entweder bei dem "generic sensor" alles auf einmal zu erschlagen, oder eben dann spezielle Dinge bei speziellen attrTemplate zu verwalten (da könnte man dann auch stateFormat passend setzen usw.).
Für's erste wäre für den Temp/hum-Sensor z.B. das hier noch in jsonMap zu ergänzen:
Temperature:temperature Humidity:humidity
ich habe mal etwas recherchiert. Die meisten (alle die ich so im Internet gefunden habe) Lampen mit Weiss Spektrum liegen im Bereich 1500K(warmweiss) bis 7000K(tageslicht). durch dieUmrechnung in Mireds (1000000 / Kelvinwert)ergeben sich Mired Werte zwischen knapp 700 und 140, wobei Werte (Mired) über 600 sehr selten sind. Meiner Meinung nach ist die Einstellung 0-65534 für den CT Bereich viel zu weit gefasst. Die GU10 Spots von Müllerlicht, welche ich hier habe, haben z.Bsp. 2700K (370Mired) bis 6500K(153Mired). Eine generelle Lösung für alle wird da sicher schwer :(
nochmal ich ;).
Gerade die neuen Templates ausprobiert.Bridge und CCT template funktionieren nun für mich perfekt. Riesen danke für die Mühe und Daumen hoch. Es bleibt die generelle Frage : Welche Werte stellt man im ct Bereich ein ?
Gruß und nochmals vielen Dank
Thomas
Na ja, abschließend lösen werden wir das mit ct im Moment wohl nicht können. Im Zweifel sollten wir in den attrTemplate zwei Dinge tun: Zum einen einen "sinnvollen" Vorschlag liefern, also schlicht was, das häufig paßt (die range lt. Doku scheint wohl in der Tat etwas sehr großzügig zu sein...), zum anderen Hinweise geben, wie man es ggf. anpassen kann. Für's erste lassen wir also deine Werte drin...
Dazu könnte man z.B. einen Hinweis an den User in ein "farewell" einbauen, gerne mit ein paar erprobten Werten für bekannte Varianten (du hattest zwei verschiedene Typen, oder? Paßt der aktuelle Wert für beide? Dann ist es evtl. unter ZigBee irgendwie normiert, und der Programmierer hat halt den Wertebereich lt. Datentyp da hingeschrieben, ohne sich um die Praxis weiter zu kümmern...?). Dazu einen Link ins Wiki in "comment" hinterlegen?
Konntest du denn die aktuell im svn/via update verfügbaren attrTemplates testen? Paßt jetzt das mapping?
OK, das scheint ja jetzt auch zu passen, *freu*.
Wiki ist noch ein spezielles Thema.
Eigentlich wollte ich das eher stiefmütterlich behandeln, aber wie es aussieht, gibt es durchaus potentere Hardware als die CC253x, die durch Tasmota unterstützt wird bzw. werden wird, und via ESP32 dann auch LAN-basiert. Damit hätte man dann in der Tat eine echte Alternative zu "vollwertigen" Lösungen wie zigbee2mqtt (unterstellt, es gäbe auch firmwareupdate-Optionen), was der Sache eine ganz neue Facette gibt...
Es wäre super, wenn sich jemand die Mühe machen würde, mal einen separaten Wiki-Artikel zu dem Thema anzufangen (also jemand, der das auch nutzt...). Das würde ich dann aus den Praxisbeispielen raus verlinken...
ja, die von mir verwendeten Templates für Brigde und cct devices passten out of the box hervorragend. Ich habe tatsächlich 2 Typen, der 2. ist aber nur einfach ein Schalter on/off (https://www.zigbee2mqtt.io/devices/404021.html). Auf den habe ich das Dimmer Template losgelassen und anschliesend das Icon durch ein einfaches light Icon ersetzt und aus dem Setlist alle Kommandos im Bezug auf Dimmer rausgeschmissen und das wars, läuft. Jetzt liegt hier noch, wie schon erwähnt, ein Tradfri On/off Switch ( https://www.zigbee2mqtt.io/devices/E1743.html), aber das scheint nochmal ne andere Hausnummer zu sein.
Was den on/off-Aktor angeht, erstelle ich bei Gelegenheit noch ein passendes attrTemplate, der ist auch sprachsteuerungsmäßig was anderes; ist aber kein Hexenwerk.
Die Tradfri-Fernbedienung ist vermutlich einfach ein Sensor, da solltest du ers mal mit dem "general sensor" template starten. Vermutlich macht der dann einfach eine Reihe "seltsamer" Readings (aber ander seltsam als bisher...). Was da dran ggf. interessant wäre, wäre das "peering" im Hardwaresystem, dort wohl "binding" genannt (siehe https://tasmota.github.io/docs/Zigbee/#zigbee-binding (https://tasmota.github.io/docs/Zigbee/#zigbee-binding)). Das wäre eine Sache, die dann über die bridge zu erledigen wäre und so ähnlich "ticken" würde wie "x_ZbSend". Das ist dann aber ein advanced feature...
Was on/off-Aktor und die cct-Bulb angeht würde mich noch interessieren, ob das mit dem Rückmelden von "on" bzw. "off" auch sauber klappt, oder ob da noch die "1" etc. drin steht. Wäre nett, wenn du mal einen Schaltvorgang von FHEM aus im Event-Monitor mitschneiden könntest. Das sollte "off" -> "set_on" -> "on" gehen.(Und wie sieht devStateIcon der Bulb aus, wenn sie nicht erreichbar (stromlos) ist, wie bei laufendem on-for-timer, blink usw.?)
ich hab mal den Schaltvorgang des Smartswitches im Eventmonitor mitgeschnitten
2020-08-06 13:56:53 MQTT2_DEVICE MQTT2_z2t_0187 set_on
2020-08-06 13:56:53 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbSend: Done
2020-08-06 13:56:53 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Endpoint: 1
2020-08-06 13:56:53 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Device: 0x0187
2020-08-06 13:56:53 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_LinkQuality: 105
2020-08-06 13:56:53 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Command: 0006!01
2020-08-06 13:56:53 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Status: 0
2020-08-06 13:56:53 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_StatusMessage: SUCCESS
2020-08-06 13:56:54 MQTT2_DEVICE MQTT2_z2t_0187 on
2020-08-06 13:56:54 MQTT2_DEVICE MQTT2_z2t_0187 LinkQuality: 105
2020-08-06 13:56:54 MQTT2_DEVICE MQTT2_z2t_0187 Endpoint: 1
2020-08-06 13:56:56 MQTT2_DEVICE MQTT2_z2t_0187 set_off
2020-08-06 13:56:56 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbSend: Done
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Status: 0
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_StatusMessage: SUCCESS
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_LinkQuality: 102
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Command: 0006!00
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Device: 0x0187
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Endpoint: 1
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_z2t_0187 LinkQuality: 102
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_z2t_0187 off
2020-08-06 13:56:57 MQTT2_DEVICE MQTT2_z2t_0187 Endpoint: 12020-08-06 14:00:14 MQTT2_DEVICE MQTT2_z2t_F6F8 set_on
2020-08-06 14:00:14 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbSend: Done
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Device: 0xF6F8
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Endpoint: 1
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_StatusMessage: SUCCESS
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Status: 0
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_LinkQuality: 68
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Command: 0006!01
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_z2t_F6F8 Endpoint: 1
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_z2t_F6F8 on
2020-08-06 14:00:15 MQTT2_DEVICE MQTT2_z2t_F6F8 LinkQuality: 68
2020-08-06 14:00:21 MQTT2_DEVICE MQTT2_z2t_F6F8 brightness: set 60
2020-08-06 14:00:21 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbSend: Done
2020-08-06 14:00:21 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_StatusMessage: SUCCESS
2020-08-06 14:00:21 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Status: 0
2020-08-06 14:00:21 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_LinkQuality: 70
2020-08-06 14:00:21 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Command: 0008!04
2020-08-06 14:00:21 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Device: 0xF6F8
2020-08-06 14:00:21 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Endpoint: 1
2020-08-06 14:00:23 MQTT2_DEVICE MQTT2_z2t_F6F8 brightness: 60
2020-08-06 14:00:23 MQTT2_DEVICE MQTT2_z2t_F6F8 LinkQuality: 68
2020-08-06 14:00:23 MQTT2_DEVICE MQTT2_z2t_F6F8 Endpoint: 1
2020-08-06 14:00:30 MQTT2_DEVICE MQTT2_z2t_F6F8 brightness: set 220
2020-08-06 14:00:30 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbSend: Done
2020-08-06 14:00:31 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Status: 0
2020-08-06 14:00:31 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Command: 0008!04
2020-08-06 14:00:31 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_LinkQuality: 68
2020-08-06 14:00:31 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Device: 0xF6F8
2020-08-06 14:00:31 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_StatusMessage: SUCCESS
2020-08-06 14:00:31 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Endpoint: 1
2020-08-06 14:00:32 MQTT2_DEVICE MQTT2_z2t_F6F8 LinkQuality: 68
2020-08-06 14:00:32 MQTT2_DEVICE MQTT2_z2t_F6F8 brightness: 220
2020-08-06 14:00:32 MQTT2_DEVICE MQTT2_z2t_F6F8 Endpoint: 1
2020-08-06 14:00:33 MQTT2_DEVICE MQTT2_z2t_F6F8 set_off
2020-08-06 14:00:33 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbSend: Done
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Endpoint: 1
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_StatusMessage: SUCCESS
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Device: 0xF6F8
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_LinkQuality: 68
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Command: 0006!00
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbResponse_Status: 0
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_z2t_F6F8 Endpoint: 1
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_z2t_F6F8 LinkQuality: 70
2020-08-06 14:00:34 MQTT2_DEVICE MQTT2_z2t_F6F8 off
Im Betrieb waren die Icons während der ganzen Zeit konsistent
Stromlosmachen des Smartswitches hatte keine Auswirkung auf die Darstellung des Gerätes. Auch ein schalten ein/aus sah vom devstateicon aus erstmal so aus als ob alles funktioniert hätte, lediglich im Event Monitor sah das anders aus 2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 MqttCount: 1
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Uptime: 0T02:40:09
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 UptimeSec: 9609
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Time: 2020-08-06T14:03:58
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Wifi_Signal: -59
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Wifi_BSSId: E8:DF:70:D1:B9:02
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Wifi_RSSI: 82
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Heap: 25
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Wifi_SSId: easybell DSL
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 SleepMode: Dynamic
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Wifi_LinkCount: 1
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Wifi_AP: 1
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 LoadAvg: 20
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Wifi_Channel: 9
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Sleep: 50
2020-08-06 14:03:59 MQTT2_DEVICE MQTT2_DVES_AAFFC1 Wifi_Downtime: 0T00:00:03
2020-08-06 14:05:43 MQTT2_DEVICE MQTT2_z2t_0187 set_on
2020-08-06 14:05:43 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbSend: Done
2020-08-06 14:05:44 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbConfirm_StatusMessage: NO_ACK
2020-08-06 14:05:44 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbConfirm_Status: 233
2020-08-06 14:05:44 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbConfirm_Endpoint: 1
2020-08-06 14:05:44 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbConfirm_StatusMessage: NO_ACK
2020-08-06 14:05:44 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbConfirm_Status: 233
2020-08-06 14:05:44 MQTT2_DEVICE MQTT2_DVES_AAFFC1 ZbConfirm_Endpoint: 1
Bei Blink sieht es so aus, das je nach intervall die Icon Aktualisierung an/aus nicht schnell genug ist (Intervalle 10 Sekunden oder kleiner). On-for-timer off-for-timer normale (richtige) Anzeige. Bezüglich Wiki habe ich mal versucht was zusammen zu schreiben. Ich bin aber absoluter Neuling auf dem Gebiet, kann also total daneben liegen. Soll ich dir den Text mal per PM zukommen lassen oder ?
:)
Danke für die Rückmeldung. Dann ist zumindest mal das mit dem Ersetzen von Power auch "gegessen" :) :) :) . Und man kann am Bridge-Device sehen, was an welchen Endpoint geht; das ist dann hilfreich, wenn man das mit den Bindings durchführen will... Sind halt alles in allem viele Events, k.A., ob man die im Normalbetrieb wirklich alle benötigt.
Schön ist auch, dass die Rückmeldung - soweit z.B. bei brightness ersichtlich - 1:1 zum Kommando paßt, also nicht irgendwas hin- und hergerundet wird.
Dass das "NACK" nicht sichtbar ist, ist nicht soooo toll, aber ich nehme an, dass wenigstens der Dimmzustand (so in etwa) an dem devStateIcon abgelesen werden kann? Uncool ist auch, dass man wohl keine effektive Möglichkeit hat rauszufinden, welches Device ein NO_ACK ggf. eigentlich betrifft (falls man mehrere schaltet; so ist es ja noch einfach... Oder ich übersehe was?).
Dass FHEMWEB-Aktualisierung immer erst irgendwann erfolgt, ist halt so, aber kein Beinbruch, was die "richtige" Anzeige eines laufenden Timers ist, ist Interpretationsfrage. Ich meine, es müßte eigentlich ein "Timerkreis" in der Bulb eingeblendet werden, also nicht das normale on/off/dimm-Bulb-Symbol kommen?
Was das Wiki angeht: es gibt da kein richtiges "daneben liegen"... Meine "Erstlinge" waren auch schlichte copy/paste+Überarbeitungs-"Machwerke" von vorhandenen ähnlichen Sachen (z.B. EnOcean-Starter-Guide nach MySensors), da kommt man irgendwann rein (oder zumindest halbwegs, ich weiß z.B. auch nicht alles, was im Wiki so "geht"). Für den Anfang brauchst du dir jedenfalls keinen Kopf zu machen, was Formatierung etc. angeht.
Du darst mir das per pm schicken, allerdings fände ich es besser, wenn du einfach im Wiki-Bereich einen neuen Thread aufmachst. Das hat den großen Vorteil, dass dann auch andere einen "Ort" haben, die ggf. Verbesserungsvorschläge oder Fragen dazu anbringen wollen, aber keine Schreibrechte im Wiki haben (falls du magst, kannst du die aber auch beantragen).
Bezüglich NACK sehe ich auch keine Möglichkeit das enzugrenzen. Ich habe gerade auch nochmal die tasmota Konsole angeschaut, die meiner Meinung nach aber auch nichts hergibt, oder ?15:53:57 MQT: stat/zb2tasmota/RESULT = {"ZbSend":"Done"}
15:53:57 MQT: tele/zb2tasmota/RESULT = {"ZbConfirm":{"Endpoint":1,"Status":233,"StatusMessage":"NO_ACK"}}
15:53:57 MQT: tele/zb2tasmota/RESULT = {"ZbConfirm":{"Endpoint":1,"Status":233,"StatusMessage":"NO_ACK"}}.
Bezüglich Wiki werde ich dann deinem Vorschlag folgen und im Wiki-Bereich einen neuen Thread aufmachen.
Dann habe ich wie schon erwähnt den Tradri On/off Switch angelegt und das ...generic_battery_senor Template angewendet. Raw definition defmod MQTT2_z2t_A5A6 MQTT2_DEVICE z2t_A5A6
attr MQTT2_z2t_A5A6 IODev MQTT2server
attr MQTT2_z2t_A5A6 icon temperature_humidity
attr MQTT2_z2t_A5A6 jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0
attr MQTT2_z2t_A5A6 readingList tele/zb2tasmota/A5A6/SENSOR:.* { $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xA5A6.:(.*).., ? json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_A5A6 room MQTT2_DEVICE
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:24 0006_00
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:20 0006_01
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:50 0008_01 01530000
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:34 0008_05 0053
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:52 0008_07
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:50 DimmerMove 1
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:52 DimmerStop true
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:55 Endpoint 1
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:55 LinkQuality 94
setstate MQTT2_z2t_A5A6 2020-08-06 14:26:24 Power 0
setstate MQTT2_z2t_A5A6 2020-08-06 14:24:11 associatedWith MQTT2_DVES_AAFFC1
Hier wird bei einem kurzen Tastendruck auf I das Reading Power auf 1 bzw. bei druck auf 0 das Reading Power auf 0 gesetzt, ansonsten soll das Verhalten lt. zigbee2mqtt Doku so sein:Ikea ON/OFF Switch
"ModelId":"TRADFRI on/off switch","Manufacturer":"IKEA of Sweden"
Short press O - 0006!00
Short press I - 0006!01
Long press O - 0008!01
Long press I - 0008!05
Long press release O or I - 0008!07
Dieses Verhalten kenne ich so nicht. Z.Bsp. Deconz liefert unter einem Reading mit unterschiedlichen Werten die Daten aus.Zigbee2Mqtt ebenso, oder täusche ich mich da?
Bzgl. NO_ACK scheint die Tasmota-Konsole in der Tat keinen Erkenntnisgewinn zu bieten.
Was das Mapping der Tasten-Events angeht, liefert Tasmota hier scheinbar eben _auch_ die unbearbeiteten Werte. An sich wäre es wohl kein Problem, ein Fernbedienungs-Template zu basteln, das die "Roh"-Codes anders verarbeitet. Allerdings scheint mir das bzgl. der nummerishen Angaben keinen großen Mehrwert zu bieten, da wohl auch "bessere" (aufbearbeitete) Infos geliefert werden (siehe Ende des Abschnitts https://tasmota.github.io/docs/Zigbee/#receiving-commands; das paßt zu dem, was du hier postest). Am ehesten sollten wir versuchen, die "nummerischen" direkt auszublenden (jsonMap auf :0 oder ein negativer Filter).
Dass es nicht ganz trivial ist, mit den FB-Codes was vernünftiges anzufangen, die eben auf mind. 3 "lesbare" Readings verteilt sind, ist eine andere Geschichte, eventuell wäre es noch eine interessante Sache, den "lastClick" irgendwie einzufangen und daraus dann nur eine Info (oder was zusätzliches) zu extrahieren...
(Kann versuchen, da bei Gelegenheit etwas rumzuspielen, aber dann bräuchte ich eine Ladung Roh-Daten vom MQTT-Verkehr).
ich muss zugeben, jetzt habe ich zum grossenTeil nur Bahnhof verstanden. Mit MQTT Rohdaten meintest du sowas wie das hier:17:44:37 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0008!05":"0053","DimmerMove":0,"Endpoint":1,"LinkQuality":78}}}
17:44:38 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0008!07":"","DimmerStop":true,"Endpoint":1,"LinkQuality":84}}}
17:44:39 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":49}}}
17:44:41 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":92}}} das ist ein Auszug aus der Tasmota Konsole beim längeren Drücken der I Taste und so sieht längerer Druck auf 0 aus 17:49:22 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0008!01":"01530000","DimmerMove":1,"Endpoint":1,"LinkQuality":52}}}
17:49:24 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0008!07":"","DimmerStop":true,"Endpoint":1,"LinkQuality":70}}}
17:49:24 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":89}}}
17:49:27 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":110}}} Interessant ist noch, wie ich finde das bei Druck auf 0 Dimmermove:1 und bei Druck auf I Dimmermove:0 kommt, also genau andersrum wie zumindest ich es erwartet hätte.
Hallo,
der Anfang ist gemacht, https://forum.fhem.de/index.php/topic,113374.0.html, da ich keine Ahnung habe wie das dann jetzt abläuft bin ich sehr gespannt. :)
So, seit eben gibt es auch den "smart switch" und ein erstes template für Remote-Control-Devices (und einige Kleinigkeiten beim Bridge-Device). Das sollte einfach die Taste in state schreiben, leider bekomme ich nicht ohne weiteres ein "hübscheres mapping" hin (die Idee war gewesen, dazu auch die Paare in jsonMap zu nutzen). Aber auch so sollte es ähnlich benutzbar sein wie z.B. das, was über HUEDevice zu sehen ist.
Ggf. können wir das Ausrufezeichen da noch eliminieren, das ist für regex-Ausdrücke bei der Weiterverarbeitung ggf. hinderlich, und das ganze dann ähnlich formatieren wie HUEDevice (das liefert sowas wie z.B. "8007").
Jetzt aber erst mal austesten, bitte...
Hallo gerade das template für das Remote-Control device probiert. Folgende Fehlermeldung: syntax error at (eval 180) line 1, near "? :", wobei at (eval 180 ) sich mit jedem Aufruf ändert, also z.Bsp. at (eval 215) at (eval219) usw. Ach ja und by the way der Tradfri Dimmer Switch hat mitlerweile ein eigenes Icon spendiert bekommen, heisst : tradfri_dimmerswitch. :) Das Template für das Bridge Device habe ich jetzt noch nicht angeschaut, oder hätte ich das vorher aktualisiern müssen?
Gruß Thomas
Argh, da machst du bitte das Fragezeichen vor dem Doppelpunkt aus der readingList, war vom Testen/Übertragen noch über... Sollte so anfangen:
{ $EVENT =~ m,([0-9]{4}![0-9]{2}), ? { 'state'=>$1 } : $EVENT =~ m [...]
Das mit dem Icon ist Absicht, das template sollte für alle Arten FB's passen und auch z.B. den Cube.
Das bridge_attrTemplate müßtest du nochmal anwenden, dann wäre dieses Device dann bei dir auf dem aktuellen Stand (bitte vorher eine RAW-Sicherungskopie anlegen, falls was schiefgeht).
Mache ich so, da ich sowieso auf einem Testsystem arbeite ist das mit dem schiefgehen nicht so schlimm ;).
Wegen ZbStatus hätte ich mich auch noch gemeldet, weil das, soweit ich gesehen habe, die einzige Möglichkeit darstellt mit dem Gateway gepairte Geräte sichtbar zu machen. Hier fände ich persönlich es schön, wenn man ähnlich wie bei Zigbee2mqtt über den get **** devicelist ein neues Fenster mit den Informationen angezeigt bekommt. Gemäß zigbee2tasmota doku besteht aber die Gefahr, dass die maximale Mqtt message Größe überschritten wird. (von mir frei übersetzt). Ansonsten habe ich während des Probierens hier viel damit an der Tasmota Konsole gearbeitet.
So, gerne wieder ein svn-update machen:
- getList@bridge gibt vielleicht schon die passenden Rückmeldungen...
Was die Länge angeht, ist das evtl. eher eine Beschränkung auf der Tasmota-Seite; daher habe ich die Option vorgesehen, da für "2" auch Zahlen einzugeben, es müßte aber auch ohne gehen?
- Die Tasten-Regex für die FB's habe ich nochmal geändert (ist ungetestet), die sollte jetzt ein "einfaches" 8007 oder 8001 etc. in state schreiben. (Geht erst mal davon aus, dass das eigentlich immer "000a!0b" entspricht, kann man aber bei Bedarf erweitern).
- Was mir jetzt noch gedanklich aus der z2t-Doku fehlt, ist das mit den Gruppen. Das ist da aber nicht so klar, wohin denn ggf. die Rückmeldungen gehen. Wenn möglich, würde ich setter in jeder Bulb+FB vorsehen, mit denen man Gruppen beitreten kann oder diese wieder verlassen? Dazu einen/zwei setter an der bridge, um Gruppen zu erstellen bzw. zu löschen? Wenn du das nicht alleine hinbekommst (das scheint mir jetzt in Reichweite zu sein, kann aber gerne unterstützen), würde ich gerne wissen wollen, wo in welchem Fall welche Nachricht hin muß (alles über den normalen cmnd-Pfad, nehme ich an), und vor allem: wohin die zugehörige Rückmeldung jeweils geht.
Was die Vorgehensweise angeht, ist es m.E. sehr zielführend, auch immer einen Blick auf die "low level"-Kommunikation zu werfen; das war u.a. der Grund, warum ich hier mal nach dem MQTT-Verkehr gefragt hatte. Ob das die Tasmota-Konsole ist oder "nur" ein MQTT-Werkzeug, ist dann nicht so entscheidend... ;)
Soo, in Kurzform: ich bin schwer begeistert !!
In Langform: da ich ja sowieso auf einem Testsystem arbeite, habe ich in diesem heute abend alles gelöscht ein FHEM update gemacht, sicherheitshalber die Templates auch nochmal aus dem svn upgedatet.
Das erste Device (die zigbee2tasmota bridge) wurde sofort automatisch angelegt, darauf das bridge Template ohne Probleme angewendet. Befehle wie permt _join, ZbStatus1oder ZbStatus2 probiert, genauso hatte ich mir das vorgestellt, echt super. Nur beim ZbSend komme ich irgendwie nicht auf einen grünen Zweig, will heissen auf den richtigen Syntax für die Eingabe. Aber sonst alles schick. Jetzt könnte man das neu angelegte Wiki schon das erste Mal überarbeiten, weil über die Konsole von Zigbee2tasmota braucht man ja jetzt nicht mehr gehen ;).
Weiter im Text: wie im Wiki beschrieben das erste Device (tasmota_zigbee2tasmota_light_cct )angelegt und wieder das Template erfolgreich darauf angewendet. Funktionen on/off dimup/down dim mit Slider und Ct mit Slider getestet keine Fehler gefunden auch die Icon Darstellung war i.O. zu guter Letzt den Tradfri Dimmer- Switch einmal die I Taste und einmal 0 Taste gedrückt, auch der wurde korrekt angelegt und wieder das entsprechende Template ohne Fehler angewendet die Readings für state kommen so wie du dir das vorgestellt hast: Also 6000,6001,8001,8005,8007 damit kann man dann sicher mittels notify oder doif reagieren. Also ich würde sagen:Perfekt :)
Bezüglich Gruppen: zum Anlegen von Gruppen brauche ich mindestens2 gleiche Lampen und eine Remote, korrekt? Vielleicht beschreibst mal etwas konkreter was ich machen soll/kann und ich versuche parallel dazu die Doku in Zigbee2tasmota zu verstehen. Wenn du noch irgendwelche Raw definitions oder so brauchst, einfach melden!
und für heute dann Gute Nacht ;)
:) 8)
Hatte doch angekündigt, dass man da was draus machen kann:
Zitat von: Beta-User am 22 Juni 2020, 16:11:56
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...
Von daher: Auch wenn kimbolero da irgendwie sehr zögerlich reagiert hatte: Ziel (fast) erreicht! 8) 8) 8)
Was Gruppen angeht: Ich weiß letztlich auch nicht mehr wie du, aber lt. der Doku @z2t würde ich annehmen, dass man nur eine FB und ein schaltbares Gerät braucht, von daher sollte der tint+FB gehen oder tint+Bulb oder tint+beides, gleich brauchen die Zielgeräte mAn. nicht zu sein.
Wg. der Syntax: Da hatte ich mich an dem orientiert, was in dem Hardware-Thread von locutus steht, mAn. solltest du da einfach ein wenig mit rumspielen, dann wird auch klarer, was das ggf. etwas erklärungsbedürftige "$EVTPARTx" eigentlich ist. (Ich habe da noch einen kleinen "Anschlag" betr. Wiki auf dich vor, aber nur, wenn du magst... Meine bisherigen Versuche waren leider noch nicht von (sichtbarem) Erfolg gekrönt).
Dass der Wiki-Artikel leben würde, war klar, aber es ist nach meiner Erfahrung einfacher, für sowas erst mal einen Wurf zu machen und das dann nach und nach umzubauen, wenn neue Erkenntnisse oder Wege da sind. Btw.: Ein- und Ausschalten sollten nicht erforderlich sein, eines sollte schon ausreichen, oder täuscht mich das?
Das RAW von der FB würde mich übrigens in der Tat interessieren, denn eigentlich sollten da auch andere Readings vorhanden sein, z.B. für Batterie. Wäre schade, wenn wir die jetzt versehentlich komplett rausgefiltert hätten...
Hallo,
hier die RAW-definition des Schalters, ich muss sagen, tatsächlich kein Reading battery. Ich frage mich nur, ob es überhaupt übrmittelt wird, denn im ganzenMqtt Verkehr auf der Zigbee2tasmota taucht nichts dergleichen auf, weder beim schalten noch mit ZbStatus2.defmod MQTT2_z2t_A5A6 MQTT2_DEVICE z2t_A5A6
attr MQTT2_z2t_A5A6 IODev MQTT2server
attr MQTT2_z2t_A5A6 icon tradfri_remote
attr MQTT2_z2t_A5A6 jsonMap Battery:batteryPercent Device:0 BatteryPercentage:0
attr MQTT2_z2t_A5A6 model tasmota_zigbee2tasmota_remote_control
attr MQTT2_z2t_A5A6 readingList tele/zb2tasmota/A5A6/SENSOR:.* { $EVENT =~ m,([0-9]{3}([0-9])), ? { 'state'=>"${2}00$3" } : $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xA5A6.:(.*).., ? json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_A5A6 room MQTT2_DEVICE
setstate MQTT2_z2t_A5A6 8007
setstate MQTT2_z2t_A5A6 2020-08-08 14:09:51 Endpoint 1
setstate MQTT2_z2t_A5A6 2020-08-08 14:09:51 LinkQuality 99
setstate MQTT2_z2t_A5A6 2020-08-08 14:06:44 Manufacturer IKEA of Sweden
setstate MQTT2_z2t_A5A6 2020-08-08 14:06:44 ModelId TRADFRI on/off switch
setstate MQTT2_z2t_A5A6 2020-08-07 22:23:58 associatedWith MQTT2_DVES_AAFFC1
setstate MQTT2_z2t_A5A6 2020-08-07 22:24:41 attrTemplateVersion 20200807_1
setstate MQTT2_z2t_A5A6 2020-08-08 14:09:47 state 8007
und die Konsolenausgabe bei ZbStatus2 14:24:46 CMD: ZbStatus2 2
14:24:46 MQT: stat/zb2tasmota/RESULT = {"ZbStatus2":[{"Device":"0xA5A6","IEEEAddr":"0x588E81FFFE144884","ModelId":"TRADFRI on/off switch","Manufacturer":"IKEA of Sweden","Endpoints":["0x01"]}]} durch die 2te 2 wird nur der Schalter ausgegeben. Und nochmal ein Tastendruck 14:27:54 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!01":"","Power":1,"Endpoint":1,"LinkQuality":92}}}
14:27:56 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":94}}}
Bezüglich Gruppen werde ich heute nachmittag / früher Abend mal was probieren.
Bezüglich Wiki will ich gerne was beitragen / probieren wenn ich weiss worum es geht.
Neue Erkenntisse bezüglich Groups und Bindings. Mit dem Befehl ZbSend {"device":"0xF6F8","Send":{"AddGroup":100}} wird eine Gruppe 100erstellt und das Device 0xF&F(tasmota_zigbee2tasmota_light_cct1) zu dieser Gruppe hinzugefügt. Der Befehl ZbSend {"device":"0xF5A6","Send":{"AddGroup":100}} fügt das Device 0XF5A6(tasmota_zigbee2tasmota_light_cct2) zu dieser Gruppe hinzu.ZbSend { "group":"100", "send":{"Power":"ON"} } schaltet beide Lampen ein bzw. Power:Off beide Lampen aus. Soweit so gut, der Zustand beider Lampen in FHEM get auf on bzw off, weil der Zustand auch über Mqtt gepublished wird 15:48:20 MQT: stat/zb2tasmota/RESULT = {"ZbSend":"Done"}
15:48:21 MQT: tele/zb2tasmota/F6F8/SENSOR = {"ZbReceived":{"0xF6F8":{"Power":1,"Endpoint":1,"LinkQuality":55}}}
15:48:21 MQT: tele/zb2tasmota/F5A6/SENSOR = {"ZbReceived":{"0xF5A6":{"Power":1,"Endpoint":1,"LinkQuality":84}}}. Zu keiner Zeit ist in FHEM irgendwie die Group 100 als eigenständiges Gerät sichtbar, man sieht jediglich in den einzelnen Lampen neue Readings AddGroup,AddGroupStatus und AddGroupStatusMsg. Hier exemplarisch die RAW-definition einer Lampe, die andere Lampe sieht in dem Bereich genauso aus. defmod MQTT2_z2t_F6F8 MQTT2_DEVICE z2t_F6F8
attr MQTT2_z2t_F6F8 IODev MQTT2server
attr MQTT2_z2t_F6F8 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_z2t_F6F8 icon light_control
attr MQTT2_z2t_F6F8 jsonMap Dimmer:brightness Power:state Device:0 Hue:hue Sat:saturation CT:ct
attr MQTT2_z2t_F6F8 model tasmota_zigbee2tasmota_light_cct
attr MQTT2_z2t_F6F8 readingList tele/zb2tasmota/F6F8/SENSOR:.* { $EVENT =~ s/"Power":1/"Power":"on"/g;; $EVENT =~ s/"Power":0/"Power":"off"/g;; $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xF6F8.:(.*).., ? json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_F6F8 room MQTT2_DEVICE
attr MQTT2_z2t_F6F8 setExtensionsEvent 1
attr MQTT2_z2t_F6F8 setList on cmnd/zb2tasmota/ZbSend {"device":"0xF6F8","send":{"Power":"On"}}\
off cmnd/zb2tasmota/ZbSend {"device":"0xF6F8","send":{"Power":"Off"}}\
brightness:colorpicker,BRI,0,5,254 cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"Dimmer":$EVTPART1} }\
dimup:noArg cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"DimmerUp":""} }\
dimdown:noArg cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"DimmerDown":""} }\
ct:colorpicker,CT,153,5,370 cmnd/zb2tasmota/ZbSend { "device":"0xF6F8", "send":{"CT":$EVTPART1} }
attr MQTT2_z2t_F6F8 setStateList on off
attr MQTT2_z2t_F6F8 webCmd on:off:brightness:ct
setstate MQTT2_z2t_F6F8 off
setstate MQTT2_z2t_F6F8 2020-08-08 15:01:03 0004_00 006400
setstate MQTT2_z2t_F6F8 2020-08-08 15:01:03 AddGroup 100
setstate MQTT2_z2t_F6F8 2020-08-08 15:01:03 AddGroupStatus 0
setstate MQTT2_z2t_F6F8 2020-08-08 15:01:03 AddGroupStatusMsg SUCCESS
setstate MQTT2_z2t_F6F8 2020-08-07 22:18:02 ColorMode 2
setstate MQTT2_z2t_F6F8 2020-08-08 15:52:15 Endpoint 1
setstate MQTT2_z2t_F6F8 2020-08-08 15:52:15 LinkQuality 55
setstate MQTT2_z2t_F6F8 2020-08-07 22:18:02 X 21202
setstate MQTT2_z2t_F6F8 2020-08-07 22:18:02 Y 22152
setstate MQTT2_z2t_F6F8 2020-08-07 22:15:26 associatedWith MQTT2_DVES_AAFFC1
setstate MQTT2_z2t_F6F8 2020-08-07 22:16:02 attrTemplateVersion 20200805
setstate MQTT2_z2t_F6F8 2020-08-07 22:18:57 brightness 250
setstate MQTT2_z2t_F6F8 2020-08-07 22:18:02 ct 168
setstate MQTT2_z2t_F6F8 2020-08-07 22:18:43 dimdown set
setstate MQTT2_z2t_F6F8 2020-08-07 22:18:55 dimup set
setstate MQTT2_z2t_F6F8 2020-08-08 15:52:15 state off
, da stellt sich natürlich die Frage, wie man aus FHEM heraus die Gruppe findet, oder erstellt um sie zu schalten.
Nä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. Füge ich die Remote über den Befehl ZbBind ZbBind {"Device":"0xA5A6","ToGroup":100,"Endpoint":1,"Cluster":6} hinzu funktioniert das Schalten der Gruppe (beider Lampen) mit der Remote zum Erfolg, allerdings bekommt FHEM hiervon nichts mit, ich denke weil der Zustand der beiden Lampen nicht gepublished wird, oder? das was gepublishet wird beim drücken der I Taste sieht so aus 16:09:39 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!01":"","Power":1,"Endpoint":1,"Group":100,"LinkQuality":99}}}
16:09:40 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":99}}} oder so bei Taste0 16:11:10 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"0006!00":"","Power":0,"Endpoint":1,"Group":100,"LinkQuality":99}}}
16:11:11 MQT: tele/zb2tasmota/A5A6/SENSOR = {"ZbReceived":{"0xA5A6":{"Endpoint":1,"LinkQuality":99}}}
Ich schätze heute nachmittag sind mehr offene Fragen aufgetaucht als Lösungen .
Trotzdem schönes (Rest-) Wochenende
Thomas
Vorab mal Danke für den RAW-Remote-Code. Das scheint insgesamt zu funktionieren, wie es soll, jedenfalls sind Teile der "anderen" Readings da; vermute battery wird ggf. nicht oder nur gelegentlich gesendet.
Was Gruppen angeht: hab's gesehen und jetzt eine Zeitlang drüber nachgedacht, bin aber zu keiner wirklichen Lösung gekommen... Hatte auch nicht erwartet, dass das ein "Spaziergang" wird, Gruppenfunktionen sind mAn. nämlich auch in deconz ein etwas undurchsichtiges Thema. Vermutlich muß man irgendwie den Weg Remote -(Rückmeldung) -> (Hilfsdevice für die) Gruppe -> Leuchtmittel gehen, wenn man da irgendwelche Schlussfolgerungen draus ziehen will.
Gibt es ggf. die Möglichkeit, eine Art Statusupdate von den Bulbs anzufordern? Dann könnte man das im Nachgang zum Empfang eines (Gruppen-) Fernbedienungscodes anschubsen.
(Das ganze dürfte aber dann schnell Richtung "Fortgeschrittene" gehen).
Ich habe nochmal etwas mit Groups und Bindings herumexperimentiert. Folgendes händisch angelegtes Gruppendevice lässt sich aus FHEM heraus ein und aus schalten und zeigt den Status der Gruppe korrekt an wenn über die Remote geschaltet wird.Allerdings wird nach wie vor der Zustand der einzelnen Lampen nicht aktualisiert.defmod MQTT2_z2t_Group100 MQTT2_DEVICE Group100
attr MQTT2_z2t_Group100 IODev MQTT2server
attr MQTT2_z2t_Group100 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_z2t_Group100 icon light_control
attr MQTT2_z2t_Group100 jsonMap Dimmer:brightness Power:state Device:0 Hue:hue Sat:saturation CT:ct
attr MQTT2_z2t_Group100 model tasmota_zigbee2tasmota_group
attr MQTT2_z2t_Group100 readingList tele/zb2tasmota/A5A6/SENSOR:.* { $EVENT =~ s/"Power":1/"Power":"on"/g;; $EVENT =~ s/"Power":0/"Power":"off"/g;; $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0xA5A6.:(.*).., ? json2nameValue($1,'',$JSONMAP) : undef }
attr MQTT2_z2t_Group100 room MQTT2_DEVICE
attr MQTT2_z2t_Group100 setExtensionsEvent 1
attr MQTT2_z2t_Group100 setList on cmnd/zb2tasmota/ZbSend {"group":"100","send":{"Power":"On"}}\
off cmnd/zb2tasmota/ZbSend {"group":"100","send":{"Power":"Off"}}\
attr MQTT2_z2t_Group100 setStateList on off
attr MQTT2_z2t_Group100 webCmd on:off
setstate MQTT2_z2t_Group100 off
setstate MQTT2_z2t_Group100 2020-08-10 12:51:26 0006_00
setstate MQTT2_z2t_Group100 2020-08-10 12:51:23 0006_01
setstate MQTT2_z2t_Group100 2020-08-10 12:51:27 Endpoint 1
setstate MQTT2_z2t_Group100 2020-08-10 12:51:26 Group 100
setstate MQTT2_z2t_Group100 2020-08-10 12:51:27 LinkQuality 44
setstate MQTT2_z2t_Group100 2020-08-10 12:51:26 state off
Achtung das ganze ist eigentlich nur unsauberes Copy and Paste, ob und wie man das generalisieren kann keine Ahnung. Außerdem müsste man wenn man in Richtung Group Befehle mit ZbSend geben will entweder den Setlist anpassen oder ein neues ZbSend für Gruppen etwa in dieser Art:gr_ZbSend:textField cmnd/zb2tasmota/ZbSend {"group":"$EVTPART1","send":{"$EVTPART2":"$EVTPART3"}} einbauen, ich weiss aber auch nicht wie weit man da gehen kann und gehen soll.
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}}}
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).
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
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
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 (https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT), da ist auch die genaue Benennung des attrTemplate zu finden ;) . (Rückmeldungen zu dem Wiki-Artikel hier (http://forum.fhem.de/index.php/topic,113374.0.html)).
::) 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.
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 onSetzte halt voraus, dass die Zugehörigkeit zu mehreren Gruppen in "AddGroup" zu erkennen wäre...?
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 kann
defmod 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
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.
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.
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)
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 20200814Und 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...).
Hallo zusammen, fyi: die template-Vorschläge sind per update verfügbar, Rückmeldung wäre nett.
@BetaUser: ich bin die kommenden 2 Wochen im Urlaub, aber danach gerne.
@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 ;)
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-SensorHier 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-SensorHier 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?
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:
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 :P .
Hallo,
ich hatte hier
ZitatObwohl 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.
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
Zitat von: Beta-User am 30 August 2020, 15:28:31
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:
Device:0 Battery:batteryPercent Temperature:temperature Humidity:humidityDanach legt er mir auch das Battery-Reading an - mit 86% sollte es auch passen
ZitatZum 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
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 ;) .
Zitat von: Beta-User am 30 August 2020, 17:24:52
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.
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 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 (https://github.com/arendst/Tasmota/issues/9157) ich kann aber nicht sagen ob das hier hilft
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
ZitatWas mache ich falsch?
Kein aktuelles FHEM(-mqtt2.template).
Gruß
Thomas
Zitat von: TomLee am 30 August 2020, 21:56:51
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. ;)
ZitatUnter /fhem/FHEM/lib/AttrTemplate habe ich das neueste liegen!
Hast du seit dem es dort liegt zwischenzeitlich ein
{ AttrTemplate_Initialize() } oder Neustart des Servers gemacht ?
Vielleicht auch das Wiki zu Zigbee2Tasmota lesen.https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT (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 :)
ZitatDie templates für die einzelnen Geräte erscheinen erst
Das war mir auch nicht bewusst, nutze z2t nicht.
Aber um
Zitatwenn 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 ? :P ;D
Nein, das ist richtig das bridge template sollte eigentlich sofort zur Verfügung stehen
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 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
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?
Zitat von: Beta-User am 31 August 2020, 08:06:43
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 (https://zigbee.blakadder.com/Sonoff_ZBBridge.html) und mit
Tasmota geflasht. In Tasmota eingebunden habe ich:
{"ZbStatus1":[{"Device":"0x4CB8","Name":"EZ-IKEA-Lampe"},{"Device":"0x24E2","Name":"EZ-IKEA-Button"},{"Device":"0x52D1","Name":"WZ-IKEA-Lampe"},{"Device":"0x3208","Name":"WZ-IKEA-Buttond.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 (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.
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 openedDa kann ja wohl nichts falsch sein?
Habe dann verschiedene WIKIS gelesen und bin beim WIKI Zigbee2Tasmota-MQTT https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT (https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT) gelandet.
Dort steht:
ZitatAufgrund 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
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_DEVICEund 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
Zitat von: Billy am 31 August 2020, 09:02:38
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...
ZitatDa 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 ;) .
Zitatattr 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.
Zitat
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 ;) .
ZitatWas 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.
ZitatZum 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.
ZitatWas 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
Zitat von: TL60 am 31 August 2020, 10:43:05
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.
ZitatWas 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
Zitatspeech_recognition_general_naming_master_template u. speechcontrol_general_naming_master_template
Mir ist auch noch aufgefallen, das in der Beschreibung zum template steht:
ZitatThis 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?
...ü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 ;) ).
Zitat von: Beta-User am 31 August 2020, 09:58:14
...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
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 (https://forum.fhem.de/index.php/topic,91984.msg1082229.html#msg1082229) was mit diesem Thread zu tun haben sollte: ist mir zu spät aufgefallen....
Zitat von: Billy am 31 August 2020, 09:02:38
Habe dann verschiedene WIKIS gelesen und bin beim WIKI Zigbee2Tasmota-MQTT https://wiki.fhem.de/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?)
Zitat von: Beta-User am 01 September 2020, 16:56:18
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.
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 8) , das Problem ist jetzt eher, das passende Bausteinchen wiederzufinden.)
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 "StatusMessage":"UNSUP_CLUSTER_COMMAND"
Das Template schickt ja { "device":"0xDEV_ID", "send":{"Hue":$EVTPART1} }\ das Kommando "Hue" was die Lampe anscheinend nicht kennt.
Wenn ich es mit "color" versuche 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
Hmmm, evtl. ist das attrTemplate unvollständig:
Wenn ich die Doku auf https://tasmota.github.io/docs/Zigbee/#zigbee-and-hue-emulation-for-alexa (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)
CMNDTOPIC/ZbLight 0xDEV_ID,5gesendet werden?
Falls du testen magst (vorhandenen Code ersetzen und AttrTemplate_Initialize() aufrufen):
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
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:
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 ::) :o
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 (https://community.openhab.org/t/solved-convert-hsbtype-to-cie-xy-needed-for-ikea-tradfri-control-through-deconz-rest/48825)
Ganz Dirty:
Hab mir daweil im Template
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..
Zitat von: psycho160 am 30 September 2020, 14:05:38
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...
ZitatEDIT: 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 (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)...
In der Color.pm gibts auch nur xyY2rgb und xyY2hex leider nix umgekerhtes wie z.B. hex2xy oder rgb2xy
Auf der Tasmota Seite "passt alles".. Der Workarround war nur weil das template falsche Werte für die Tradfri Lampe liefert.
Fürs erste kann ich es nur so belassen, weil ich nicht weiß wie man von RGB oder HEX auf X und Y kommt.
Zitat von: psycho160 am 01 Oktober 2020, 14:08:17
In der Color.pm gibts auch nur xyY2rgb und xyY2hex leider nix umgekerhtes wie z.B. hex2xy oder rgb2xy
...das ist mir durchaus klar, aber ggf. _kann man_ (du?) den Code mal durchsehen, ob man daraus den "Rückweg" ableiten kann...?!? Warum schreibe ich denn sonst, dass man einen patch brauchen könnte...?
Zitat
Auf der Tasmota Seite "passt alles".. Der Workarround war nur weil das template falsche Werte für die Tradfri Lampe liefert.
Da wäre ich mir nicht so sicher. Der ESP sollte (lt. der Wiki-Seite zu z2t) eine "Hue-Emulation" können, aber das muss man irgendwie aktivieren. Die erste Frage wäre also, _ob_ das denn aktiviert ist oder nicht (und wenn nein, wie man es ggf. aktivieren kann). Wenn die Emulation möglich ist und auch aktiviert, ist ggf. der "Vorwurf" korrekt, dass das template "falsch" ist, ansonsten ist es eben noch nicht so, dass auf der Tasmota-Seite "alles paßt".
(Sorry, bin grade etwas unzufrieden, weil mein Geschreibsel scheinbar unverständlich ist. Bitte berücksichtige, dass das ganze Thema z2t ziemlich "jung" ist und auch etwas "tricky", so dass ich die (ggf. nur von mir so empfundene) Erwartungshaltung, dass alles gleich ootb funktioniert, etwas "überzogen" finde und an der Stelle nur was sinnvolles bereitstellen kann, wenn der eine oder andere, der die jeweilige Hardware hat, auch entsprechend mit "um die Ecke" denkt. Bitte versuche also nochmal rauszufinden, ob der Tasmota den Konfigurationsbefehl für diese Bulb "gefressen" hat oder nicht - und nein, ich habe keine Ahnung, wie das ggf. geht...).
Hi nochmal, ich hab nun die Konvertierung selbst (fürs erste nur in der 99_myUtils.pm) programmiert und nach ersten Tests funktioniert das sehr gut. IKEA Lampe gibt die Fabren des FHEM Colorpickers wieder :-)
Sub für die Umrechung:
99_myUtils.pm
sub ColorConvert($)
{
my ($hex) = @_;
my $red = 0;
my $green= 0;
my $blue = 0;
if ( uc($hex) =~ /^(..)(..)(..)$/ ) {
( $red, $green, $blue ) = ( hex($1), hex($2), hex($3) );
}
# debug
#print "red: " . $red . " green: " .$green . " blue " . $blue ."\n";
$red = $red/255;
$green = $green/255;
$blue = $blue/255;
$red=$red**2.19921875;
$green=$green**2.19921875;
$blue=$blue**2.19921875;
$red=$red*100;
$green=$green*100;
$blue=$blue*100;
# X, Y and Z output refer to a D65/2° standard illuminant.
my $x=$red * 0.7161046 + $green * 0.1009296 + $blue * 0.1471858;
my $y=$red * 0.2581874 + $green * 0.7249378 + $blue * 0.0168748;
# z wird nicht benötigt
# my $z=$red * 0.0000000 + $green * 0.0517813 + $blue * 0.7734287;
# conversation to XY colorspace for IKEA blub
$x = ($x / 100) * 65534;
$y = ($y / 100) * 65534;
return (int($x),int($y));
}
PS: Die Formel hab ich von diesem Forum (https://community.openhab.org/t/solved-convert-hsbtype-to-cie-xy-needed-for-ikea-tradfri-control-through-deconz-rest/48825/13 (https://community.openhab.org/t/solved-convert-hsbtype-to-cie-xy-needed-for-ikea-tradfri-control-through-deconz-rest/48825/13)) und hab es nur nach Perl übersetzt.
Vielleicht kann ich damit ja jemandem weiterhelfen der den gleichen Systemaufbau (IKEA Tradfri direkt mit zigbee2tasmota steuern) hat und auch vor dem Problem steht, dass er die Farbe einer IKEA RGB LED (LED1624G9) nicht einstellen kann.
Für mich ist das Problem nun gelöst :D
lg
Will mich da gar nicht groß einmischen aber evtl. kann ich etwas klarheit bringen:
Zitat von: Beta-User am 01 Oktober 2020, 14:20:54Der ESP sollte (lt. der Wiki-Seite zu z2t) eine "Hue-Emulation" können
Wenn du damit die Hue Emulation als "Kann eine Hue Bridge emulieren" meinst (was Tasmota bereit stellt), dann würde das hier nicht helfen - das ist wirklich nur für die Steuerung einer "On-Off" Funktion via Alexa.
Zitat von: SirUli am 01 Oktober 2020, 22:35:51
Wenn du damit die Hue Emulation als "Kann eine Hue Bridge emulieren" meinst (was Tasmota bereit stellt), dann würde das hier nicht helfen - das ist wirklich nur für die Steuerung einer "On-Off" Funktion via Alexa.
Hmm, die möglichen Stufen
10-5, die in https://tasmota.github.io/docs/Zigbee/#zigbee-and-hue-emulation-for-alexa (https://tasmota.github.io/docs/Zigbee/#zigbee-and-hue-emulation-for-alexa) genannt sind, deuten eher auf mehr wie "on/off" hin, aber zugegebenermaßen stochere ich da auch nur im Nebel rum. Meine Arbeitshypothese ist die: Wenn man das Setzen kann, kann man das Ergebnis irgendwo sehen und auch feststellen, ob es Auswirkungen hat... (Und wenn nein, _könnte_ man an der Quelle (beim Tasmota-Team) nachfragen, welchen Fehler man gemacht hat, oder ob die Doku da nicht passt...)
Was den Code angeht: Glückwunsch, dass das geklappt hat. Nett wäre, wenn du zum einen einen patch-Vorschlag bei "Sonstiges" platzieren könntest (justme1968 sieht das hier sonst vermutlich nicht, evtl. müsste man den etwas dynamisieren, dass man den/die Bulb-Spezifischen Anpassungsfaktor(en) (65534) mit übergeben kann?), und zum anderen dann ein RAW-list von dem fertigen Device (oder besser gleich: ein attrTemlate?) liefern könntest, das zu dieser Bulb passt.
Hallo,
ich hole das mal wieder hoch, denn die neuen Zigbee2Tasmota Versionen (>Vers.9) bringen doch einige Veränderungen mit sich. Meiner Meinung nach bedeutet das auch, das zumindest am Bridge template kleinere(?) Anpassungen vorgenommen werden sollten. Bislang konnte über den Befehl ZbStatus1bzw.2oder3 (ohne Angabe einer short id) eine Liste aller angelernten Devices mit mehr oder weniger Detailangaben ausgegeben werden. Das funktioniert so nicht mehr, lediglich ZbStatus1 liefert noch:
11:23:53 MQT: stat/zb2tasmota/RESULT = {"ZbStatus1":[{"Device":"0x235E"},{"Device":"0x1469"},{"Device":"0xF6F8"},{"Device":"0xF5A6"},{"Device":"0x35ED"},{"Device":"0x6301"},{"Device":"0xC2BC"},{"Device":"0xAA21"},{"Device":"0x4B21"},{"Device":"0x6AC1"},{"Device":"0x15A5"},{"Device":"0x20E4"},{"Device":"0x3C11"}]} eine relativ nichtssagende Liste der short ids. Die anderen beiden Befehle ZBStatus2 und ZbStatus3 benötigen nun zwingend die Angabe einer Short id, sind also zur Darstellung einer Übersicht ungeeignet. Ersatz für die vorgenannten Befehle ist der Befehl ZbInfo (ohne Parameter), dieser liefert jedoch
ZitatZbInfo
<device> = display all information known about a device, equivalent to ZbStatus3 with a simpler JSON output
einen anderen Json String nämlich
11:15:30.406 CMD: ZbInfo
11:15:30.414 MQT: tele/tasmota/62ED/SENSOR = {"ZbInfo":{"0x62ED":{"Device":"0x62ED","IEEEAddr":"0x00158D000572E78B","ModelId":"lumi.sensor_magnet.aq2","Manufacturer":"LUMI","Endpoints":[1],"Config":["O01.1","A01"],"ZoneStatus":0,"Reachable":true,"BatteryPercentage":100,"LastSeen":1188,"LastSeenEpoch":1610358942,"LinkQuality":170}}}
11:15:30.421 MQT: tele/tasmota/888A/SENSOR = {"ZbInfo":{"0x888A":{"Device":"0x888A","IEEEAddr":"0x00158D00045CF803","ModelId":"lumi.sensor_magnet.aq2","Manufacturer":"LUMI","Endpoints":[1],"Config":["O01.1","A01"],"ZoneStatus":0,"Reachable":true,"BatteryPercentage":100,"LastSeen":1210,"LastSeenEpoch":1610358920,"LinkQuality":175}}}
11:15:30.426 MQT: tele/tasmota/8502/SENSOR = {"ZbInfo":{"0x8502":{"Device":"0x8502","IEEEAddr":"0x14B457FFFE71DC4A","ModelId":"TRADFRI on/off switch","Manufacturer":"IKEA of Sweden","Endpoints":[1],"Config":[],"Reachable":true,"LastSeen":4137,"LastSeenEpoch":1610355993,"LinkQuality":149}}}
11:15:30.431 MQT: tele/tasmota/AB10/SENSOR = {"ZbInfo":{"0xAB10":{"Device":"0xAB10","IEEEAddr":"0x000B57FFFED6277A","ModelId":"TRADFRI bulb GU10 W 400lm","Manufacturer":"IKEA of Sweden","Endpoints":[1],"Config":["O01","L01"],"Power":0,"Dimmer":250,"Reachable":true,"LastSeen":4140,"LastSeenEpoch":1610355990,"LinkQuality":86}}}
11:15:30.433 MQT: stat/tasmota/RESULT = {"ZbInfo":"Done"} Davon sieht man im Bridge Device von FHEM nach Ausführung nur
1:33:15.020 MQT: stat/tasmota_3809AB/RESULT = {"ZbInfo":"Done"} was auch logisch ist und sich aus den Topics ergibt. Daraus ergibt sich die Frage : Kann man das attrTemplate für di Zigbee2Tasmota Bridge erweitern, so daß man in FHEM wieder detailierte Infos zu den angelernten Geräten erhalten kann oder sollte man nur im Wiki einen entsprechenden Abschnitt mit Hinweise auf die Konsole und den Befehl ZbInfo geben?
Der 2.Punkt betrifft den neuen Befehl ZbMap, der direkt im Webinterface von Tasmota als Button hinterlegt ist und eine grafische Anzeige des Zigbee-Netzes zeigt, aber auch über die Konsole eingegeben werden kann, hier kann man vielleicht, ähnlich wie bei Zigbee2mqtt eine grafische Darstellung des Zigbee-Netzes in FHEM realisieren.
Gruß Thomas
Aua...
Das ist ja mal wieder so eine Geschichte. Das auszuwerten wird relativ kompliziert. Kann Sinn machen, wenn man einen wirklichen Mehrwert hat, das kann ich im Moment nicht überblicken. Tendenziell sind die Infos bei den einzelnen Geräten "besser" aufgehoben als in der bridge (ich weiß aber grade nicht, ob die dort ausgepackt werden).
Kochrezept könnte sein, den 12CD/SENSOR-Topic in der bridge per regex zu abonnieren, und dann payload auf Start mit ZbInfo zu checken und dann die Device-Short-ID als Präfix für's Auspacken des inneren JSON zu verwenden... (Alles klar...?!?)
ZbMap existiert nur intern/im Web-Interface und nicht als MQTT-Topic? Dann können wir da relativ wenig machen (und es wäre die Frage, ob man diese Art der Funktionalität doppelt braucht). Würde den Inhalt dazu auch nicht im Wiki doppeln, sondern nur zeigen, dass es geht und dann auf das Tasmota-Wiki verweisen (so es da erklärt ist....).
Der Mehrwert hält sich sicher in Grenzen, die Liste der am Zigbee Gateway angelernten Geräte ist ja auch im Webinterface sichtbar, man hat dann natürlich keine Übersicht über alle Geräte in FHEM. ZbMap schau ich mir nachher zu Hause an, meine aber das was per Mqtt ein Output erfolgt.
Gruß Thomas
Na ja, man kann den JSON auch komplett von json2nameValue() zerlegen lassen, das sollte auch "lesbare" Readings ergeben, aber eben viele...
Was die map-Daten angeht, sollte man vermutlich den JSON unausgepackt lassen, das dürfte "ähnlich" aussehen wie bei zigbee2mqtt; dafür hatte aber Rudi (?) dann eine Funktion geschrieben, die die Daten visualisiert.
Hallo
die Eingabe von
ZbMap in die Konsole vom Bridge Device führt zu folgender Ausgabe
15:12:24.289 CMD: ZbMap
15:12:24.296 MQT: stat/tasmota_3809AB/RESULT = {"ZbMap":"Done"}
15:12:24.372 ZIG: sending `ZbMap 0x0000`
15:12:24.486 MQT: tele/tasmota_3809AB/RESULT = {"ZbMap":{"Device":"0x0000","Status":0,"StatusMessage":"SUCCESS","Total":6,"Start":1,"Map":[{"Device":"0xC5ED","DeviceType":"Router","RxOnWhenIdle":true,"Relationship":"Child","PermitJoin":null,"Depth":1,"LinkQuality":0},{"Device":"0x2F64","DeviceType":"Device","RxOnWhenIdle":false,"Relationship":"Child","PermitJoin":null,"Depth":1,"LinkQuality":170},{"Device":"0x6557","DeviceType":"Device","RxOnWhenIdle":false,"Relationship":"Child","PermitJoin":null,"Depth":1,"LinkQuality":170}]}}
15:12:24.587 MQT: tele/tasmota_3809AB/RESULT = {"ZbMap":{"Device":"0x0000","Status":0,"StatusMessage":"SUCCESS","Total":6,"Start":4,"Map":[{"Device":"0x1DD1","DeviceType":"Router","RxOnWhenIdle":true,"Relationship":"Child","PermitJoin":null,"Depth":1,"LinkQuality":146},{"Device":"0x9B47","DeviceType":"Router","RxOnWhenIdle":null,"Relationship":"None","PermitJoin":null,"Depth":255,"LinkQuality":124},{"Device":"0x6B3E","DeviceType":"Router","RxOnWhenIdle":null,"Relationship":"None","PermitJoin":null,"Depth":255,"LinkQuality":109}]}}
15:12:26.331 ZIG: sending `ZbMap 0x1DD1`
15:12:26.487 MQT: tele/tasmota_3809AB/RESULT = {"ZbMap":{"Device":"0x1DD1","Status":0,"StatusMessage":"SUCCESS","Total":4,"Start":1,"Map":[{"Device":"0x0000","DeviceType":"Coordinator","RxOnWhenIdle":true,"Relationship":"Parent","PermitJoin":null,"Depth":0,"LinkQuality":255},{"Device":"0x6B3E","DeviceType":"Router","RxOnWhenIdle":true,"Relationship":"Sibling","PermitJoin":null,"Depth":15,"LinkQuality":255},{"Device":"0x9B47","DeviceType":"Router","RxOnWhenIdle":true,"Relationship":"Sibling","PermitJoin":null,"Depth":15,"LinkQuality":255}]}}
15:12:26.637 MQT: tele/tasmota_3809AB/RESULT = {"ZbMap":{"Device":"0x1DD1","Status":0,"StatusMessage":"SUCCESS","Total":4,"Start":4,"Map":[{"Device":"0xA2F1","DeviceType":"Device","RxOnWhenIdle":false,"Relationship":"Child","PermitJoin":false,"Depth":2,"LinkQuality":201}]}}
15:12:28.339 ZIG: sending `ZbMap 0xA2F1`
15:12:30.302 ZIG: sending `ZbMap 0x6B3E`
15:12:30.458 MQT: tele/tasmota_3809AB/RESULT = {"ZbMap":{"Device":"0x6B3E","Status":0,"StatusMessage":"SUCCESS","Total":3,"Start":1,"Map":[{"Device":"0x0000","DeviceType":"Coordinator","RxOnWhenIdle":true,"Relationship":"Sibling","PermitJoin":null,"Depth":0,"LinkQuality":203},{"Device":"0x1DD1","DeviceType":"Router","RxOnWhenIdle":true,"Relationship":"Parent","PermitJoin":null,"Depth":15,"LinkQuality":255},{"Device":"0x9B47","DeviceType":"Router","RxOnWhenIdle":true,"Relationship":"Sibling","PermitJoin":null,"Depth":15,"LinkQuality":255}]}}
15:12:32.341 ZIG: sending `ZbMap 0x9B47`
15:12:32.497 MQT: tele/tasmota_3809AB/RESULT = {"ZbMap":{"Device":"0x9B47","Status":0,"StatusMessage":"SUCCESS","Total":3,"Start":1,"Map":[{"Device":"0x1DD1","DeviceType":"Router","RxOnWhenIdle":true,"Relationship":"Parent","PermitJoin":false,"Depth":1,"LinkQuality":255},{"Device":"0x0000","DeviceType":"Coordinator","RxOnWhenIdle":true,"Relationship":"None","PermitJoin":false,"Depth":0,"LinkQuality":252}]}}
15:12:32.646 MQT: tele/tasmota_3809AB/RESULT = {"ZbMap":{"Device":"0x9B47","Status":0,"StatusMessage":"SUCCESS","Total":3,"Start":3,"Map":[{"Device":"0x6B3E","DeviceType":"Router","RxOnWhenIdle":true,"Relationship":"None","PermitJoin":false,"Depth":2,"LinkQuality":255}]}}
15:12:38.339 ZIG: ZbMap done Dabei fällt mir das Device 0X000 auf welches gar nicht existent ist. es wird jedenfalls nicht mitgelistet beim Befehl ZbStatus
15:26:07.275 CMD: ZbStatus
15:26:07.284 MQT: stat/tasmota_3809AB/RESULT = {"ZbStatus1":[{"Device":"0x1DD1"},{"Device":"0xA2F1"},{"Device":"0x6B3E"},{"Device":"0x9B47"}]} Vieles ist komisch in den neuen Versionen. Ach ja folgenden Syntax habe ich für den Befehl ZbMap gefunden
ZitatZbMap<n> Asks the device for its view of the Zigbee topology
<device> the device to query
<n> the start index for the request, 1 is the default. This is used to scan through all values since devices usually return only 3 values per request.
...das wieder zusammenzubasteln, ist vermutlich lustig, aber wenn es eine halbwegs ordentliche Option gibt, das auf dem ESP anzusehen, sollten wir uns mit Map-Daten wohl eher nicht rumschlagen (es sei denn, es hat jemand Lust und Muße dazu...).
Man "muss" ja nicht alles verwerten, von dem jemand glaubt, dass man es via MQTT unbedingt auch versenden muss... (von daher ist dann nur die Frage, ob das unnütze Events generiert bzw. wie man die ggf. verhindern kann).
was da reinkommtist schon einiges
Zitat021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap: Done
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_LinkQuality: 0
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_DeviceType: Device
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_DeviceType: Device
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_RxOnWhenIdle: true
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_Depth: 1
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_Relationship: Child
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_Device: 0xC5ED
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Total: 6
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Device: 0x0000
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_Relationship: Child
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_StatusMessage: SUCCESS
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Status: 0
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_Device: 0x6557
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Start: 1
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_RxOnWhenIdle: false
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_Depth: 1
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_Relationship: Child
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_Depth: 1
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_RxOnWhenIdle: false
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_Device: 0x2F64
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_DeviceType: Router
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_LinkQuality: 170
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_LinkQuality: 170
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_Device: 0x9B47
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_Depth: 255
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_Relationship: Child
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_Depth: 255
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Start: 4
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_Device: 0x6B3E
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Status: 0
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_StatusMessage: SUCCESS
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_LinkQuality: 124
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_DeviceType: Router
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_LinkQuality: 109
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_DeviceType: Router
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_DeviceType: Router
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_LinkQuality: 146
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_2_Relationship: None
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Device: 0x0000
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_Device: 0x1DD1
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Total: 6
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_3_Relationship: None
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_RxOnWhenIdle: true
2021-01-11_15:12:24 MQTT2_DVES_3809AB ZbMap_Map_1_Depth: 1
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_2_LinkQuality: 255
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_DeviceType: Coordinator
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_3_LinkQuality: 255
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_2_Depth: 15
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_2_RxOnWhenIdle: true
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_2_Device: 0x6B3E
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_StatusMessage: SUCCESS
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Status: 0
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_3_Device: 0x9B47
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Start: 1
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_3_Depth: 15
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_3_RxOnWhenIdle: true
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_Relationship: Parent
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_2_Relationship: Sibling
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_Depth: 0
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_RxOnWhenIdle: true
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_3_Relationship: Sibling
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Total: 4
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_Device: 0x0000
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Device: 0x1DD1
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_2_DeviceType: Router
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_LinkQuality: 255
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_3_DeviceType: Router
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_RxOnWhenIdle: false
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_Depth: 2
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_PermitJoin: false
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Total: 4
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_DeviceType: Device
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_Device: 0xA2F1
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Device: 0x1DD1
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_StatusMessage: SUCCESS
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Status: 0
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_LinkQuality: 201
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Start: 4
2021-01-11_15:12:26 MQTT2_DVES_3809AB ZbMap_Map_1_Relationship: Child
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Total: 3
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_1_Device: 0x0000
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Device: 0x6B3E
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_3_Relationship: Sibling
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_1_Depth: 0
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_1_RxOnWhenIdle: true
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_2_Relationship: Parent
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_1_LinkQuality: 203
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_3_DeviceType: Router
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_2_DeviceType: Router
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_3_LinkQuality: 255
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_1_DeviceType: Coordinator
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_2_LinkQuality: 255
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Start: 1
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_1_Relationship: Sibling
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_3_Depth: 15
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_3_RxOnWhenIdle: true
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_StatusMessage: SUCCESS
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_3_Device: 0x9B47
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Status: 0
2021-01-11_15:12:30 MQTT2_DVES_3809AB ZbMap_Map_2_Device: 0x1DD1
Ausschnitt aus dem log von heute :)
Ich brauche mal Lesetipps. Ich habe gedacht diese Fakedevice 0x0000 zu missbrauchen um dort die Readings Device Manufacturer und ModelID zu sammeln und darzustellen,(quasi als Übersicht) funktioniert prinzipell auch,(1Gerät) ich hatte nur nicht bedacht, das wenn ich mehrere Geräte definiere, das letzte Gerät alle anderen überschreibt, weil die Readings ja gleich heissen. D.h. ich müsste irgendwas finden was den Json aufteilt und den Devicenamen entweder vor das Reading setzt oder ihn anhängt. Geht sowas überhaupt ? Und wenn ja hast du Stichworte bzw.Links.
Danke und Gruß
Thomas
Das geht schon... Bausteinchen für sowas sind m.E. am ehesten in den OpenMQTTGateway-attrTemplates zu finden, wobei da in der Regel der $TOPIC durchsucht wird; hier kannst du aber m.E. auch mehr oder weniger direkt $EVENT verwenden; man ermittelt eben den Prefix für json2nameValue(), da steht dann in der Regel im 2. Parameter $1 bzw. ${1}_, also das Ergebnis aus der Suche mit capturing group.
Hallo,
ich hätte da auch nochmal eine Frage und zwar zu dem Quick Fix in Post #122
Die Zeilen wurden in die Myutils pm eingetragen.
Ich habe so eine Datei bisher nicht angelegt, würde das dann aber versuchen, jedoch wollte ich vorab fragen, ob der code es schon irgendwie in das normale Repository geschafft hat, so wie Beta-User es vorgeschlagen hat.
Ich habe hier das selbe Phänomen, das ein LED Streifen keine Hue Werte akzeptiert aber die X und Y Koordinate im Raum von 0-65000.
Ich könnte auch mithelfen, bei der Entwicklung des Templates obwohl ich vom coden keinen Plan habe, kann ich beim debuggen hilfreich sein.
Besten Dank
Martin
Hallo,
Ich habe deine SubRoutine von User psycho160 (RGB Color to XZ) umgeschrieben das gleich die Werte so rauskommen z.b. 46930,16922.
99_myUtils.pm
# ZigBee RGB Led Convert
# https://forum.fhem.de/index.php/topic,112253.msg1089165.html#msg1089165
sub
ZbRGBColorConvert($) {
my ($hex) = @_;
my $red = 0;
my $green= 0;
my $blue = 0;
if ( uc($hex) =~ /^(..)(..)(..)$/ ) {
( $red, $green, $blue ) = ( hex($1), hex($2), hex($3) );
}
# debug
# printf("R:*%s* G:*%s* B:*%s*\n",$red, $green, $blue);
$red = $red/255;
$green = $green/255;
$blue = $blue/255;
$red=$red**2.19921875;
$green=$green**2.19921875;
$blue=$blue**2.19921875;
$red=$red*100;
$green=$green*100;
$blue=$blue*100;
# X, Y and Z output refer to a D65/2° standard illuminant.
my $x=$red * 0.7161046 + $green * 0.1009296 + $blue * 0.1471858;
my $y=$red * 0.2581874 + $green * 0.7249378 + $blue * 0.0168748;
# z wird nicht benötigt
# my $z=$red * 0.0000000 + $green * 0.0517813 + $blue * 0.7734287;
# conversation to XY colorspace for IKEA blub
$x = ($x / 100) * 65534;
$y = ($y / 100) * 65534;
# debug
# printf("X:*%s* Y:*%s*\n",int($x),int($y));
my $xy_color = sprintf("%d,%d",int($x),int($y));
# return (int($x),int($y));
return ($xy_color);
}
setlist:
rgb:colorpicker,RGB {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert($EVTPART1). '"}}'}
Mein Device schaut jetzt so aus
ZigBee Bridge (SONOFF ZBBridge mit Tasmota)
defmod mqtt2.og.zbridge1 MQTT2_DEVICE DVES_22EE5F
attr mqtt2.og.zbridge1 IODev mqtt2.raspberry
attr mqtt2.og.zbridge1 bridgeRegexp tele/DVES_22EE5F/([^/]+)/SENSOR:.* "z2t_$1"
attr mqtt2.og.zbridge1 devStateIcon Online:10px-kreis-gruen@green Offline:10px-kreis-rot@red
attr mqtt2.og.zbridge1 getList ZbStatus1:noArg ZbStatus1 cmnd/DVES_22EE5F/ZbStatus1\
ZbStatus2:textField ZbStatus2 cmnd/DVES_22EE5F/ZbStatus2 $EVTPART1
attr mqtt2.og.zbridge1 group ZigBee
attr mqtt2.og.zbridge1 icon zigbee_1
attr mqtt2.og.zbridge1 model tasmota_zigbee2tasmota_bridge
attr mqtt2.og.zbridge1 readingList tele/DVES_22EE5F/LWT:.* LWT\
tele/DVES_22EE5F/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/DVES_22EE5F/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/DVES_22EE5F/STATE:.* { json2nameValue($EVENT) }\
tele/DVES_22EE5F/RESULT:.* { json2nameValue($EVENT) }\
stat/DVES_22EE5F/RESULT:.* { $EVENT =~ m,(ZbStatus.), ? { $1=>$EVENT } : json2nameValue($EVENT,'',$JSONMAP) }\
stat/DVES_22EE5F/POWER:.* LED\
stat/DVES_22EE5F/UPGRADE:.* { json2nameValue($EVENT, 'UPGRADE_', $JSONMAP) }\
stat/DVES_22EE5F/POWER1:.* POWER1
attr mqtt2.og.zbridge1 room MQTT
attr mqtt2.og.zbridge1 setList permit_join:0,1,99 cmnd/DVES_22EE5F/ZbPermitJoin $EVTPART1\
x_Reboot:noArg cmnd/DVES_22EE5F/restart 1\
x_ZbSend:textField cmnd/DVES_22EE5F/ZbSend {"device":"0x$EVTPART1","send":{"$EVTPART2":"$EVTPART3"}}\
z_ZbBind_single:textField cmnd/DVES_22EE5F/ZbBind {"Device":"$EVTPART1","ToDevice":"0x$EVTPART2","Endpoint":$EVTPART3,"ToEndpoint":$EVTPART4,"Cluster":$EVTPART5}\
z_ZbBind_group:textField cmnd/DVES_22EE5F/ZbBind {"Device":"$EVTPART1","ToGroup":"0x$EVTPART2","Endpoint":$EVTPART3,"Cluster":$EVTPART4}\
join cmnd/DVES_22EE5F/ZbPermitJoin 1\
reboot cmnd/DVES_22EE5F/restart 1\
zbinfo cmnd/DVES_22EE5F/ZbInfo\
x_setFwOtaUrl:noArg cmnd/DVES_22EE5F/OtaUrl http://ota.tasmota.com/tasmota/release/tasmota-zbbridge.bin\
x_FwUpgrade:noArg cmnd/DVES_22EE5F/upgrade 1
attr mqtt2.og.zbridge1 setStateList on off
attr mqtt2.og.zbridge1 stateFormat LWT\
<a href="http://IPAddress" target="_blank">Hostname</a><br>
attr mqtt2.og.zbridge1 webCmd join:zbinfo:reboot
Lidl ZigBee Lampe
defmod mqtt2.zb.og.br.led MQTT2_DEVICE z2t_99A1
attr mqtt2.zb.og.br.led IODev mqtt2.raspberry
attr mqtt2.zb.og.br.led devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr mqtt2.zb.og.br.led group ZigBee
attr mqtt2.zb.og.br.led icon light_control
attr mqtt2.zb.og.br.led jsonMap Dimmer:brightness Power:state Device:0 Hue:hue Sat:saturation CT:ct
attr mqtt2.zb.og.br.led model tasmota_zigbee2tasmota_light_cct_hue
attr mqtt2.zb.og.br.led readingList tele/DVES_22EE5F/63E8/SENSOR:.* { $EVENT =~ s/"Power":1/"Power":"on"/g;; $EVENT =~ s/"Power":0/"Power":"off"/g;; $EVENT =~ m,^.*(..Device.+)..$, ? json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0x99A1.:(.*).., ? json2nameValue($1,'',$JSONMAP) : undef }
attr mqtt2.zb.og.br.led room MQTT
attr mqtt2.zb.og.br.led setExtensionsEvent 1
attr mqtt2.zb.og.br.led setList brightness:colorpicker,BRI,0,5,254 cmnd/DVES_22EE5F/ZbSend { "device":"0x99A1", "send":{"Dimmer":$EVTPART1} }\
dimup:noArg cmnd/DVES_22EE5F/ZbSend { "device":"0x99A1", "send":{"DimmerUp":""} }\
dimdown:noArg cmnd/DVES_22EE5F/ZbSend { "device":"0x99A1", "send":{"DimmerDown":""} }\
saturation:colorpicker,BRI,0,1,254 cmnd/DVES_22EE5F/ZbSend { "device":"0x99A1", "send":{"Sat":$EVTPART1} }\
on cmnd/DVES_22EE5F/ZbSend {"device":"0x99A1","send":{"Power":"On"}}\
off cmnd/DVES_22EE5F/ZbSend {"device":"0x99A1","send":{"Power":"Off"}}\
ct:colorpicker,CT,153,5,370 cmnd/DVES_22EE5F/ZbSend { "device":"0x99A1", "send":{"CT":$EVTPART1} }\
red:noArg {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert("FF0000"). '"}}'}\
green:noArg {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert("00FF00"). '"}}'}\
blue:noArg {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert("0000FF"). '"}}'}\
yellow:noArg {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert("FFFF00"). '"}}'}\
orange:noArg {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert("FF6600"). '"}}'}\
cyan:noArg {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert("00FF99"). '"}}'}\
lila:noArg {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert("FF00BF"). '"}}'}\
rgb:colorpicker,RGB {'cmnd/DVES_22EE5F/ZbSend '. '{ "device":"0x99A1", "send":{"color":"' . ZbRGBColorConvert($EVTPART1). '"}}'}
attr mqtt2.zb.og.br.led setStateList on off
attr mqtt2.zb.og.br.led webCmd on:off:rgb
Danke Ncom für diese hilfreichen Infos.
Meine Deckenleuchte von NLG reagiert leider nur auf die Werte von rot, grün und blau.
Die umgerechneten anderen Farbwerte werden scheinbar nicht akzeptiert.
Sind vielleicht je nach Hersteller auch noch abweichende Formeln zu benutzen?
Hallo,
ich habe vor kurzen ein paar SONOFF SNZB-04/DS01 Tür/Fenstersensoren gekauft.
Leider klappt die Einbindung in FHEM via Zbbridge/MQTT nicht.
Koppeln der Sensoren mit der Bridge hat geklappt, in den Readings der Zbbridge in FHEM taucht der Sensor auch auf, aber Autocreate legt mir kein Device an.
Alle andereren Geräte, wie Lampen oder Bewegungsmelder wurden direkt als neues Device angelegt, da musste ich nur das passende Template auswählen.
Habt ihr noch einen Tipp, was ese sein kann?
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_Name: UG.HR.Rechts
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_ZoneStatusChange: 0
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_0500_00: 000000000000
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_Device: 0x2936
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_Endpoint: 1
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_Contact: 0
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_LinkQuality: 6
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_0500_00: 010000000000
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_Endpoint: 1
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_Device: 0x2936
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_Name: UG.HR.Rechts
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_ZoneStatusChange: 1
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_LinkQuality: 19
MQTT2_DEVICE ZbBridge SENSOR_ZbReceived_UG.HR.Rechts_Contact: 1
sieh Dir das mal an: https://forum.fhem.de/index.php/topic,115963.msg1133547.html#msg1133547 (https://forum.fhem.de/index.php/topic,115963.msg1133547.html#msg1133547)
VG Achim
Zitat von: der2of6 am 26 Mai 2022, 15:07:01
Habt ihr noch einen Tipp, was ese sein kann?
Ohne list/raw-list vom Gerät mit der bridgeRegexp und einer eingehenden Message (=>MQTT-Traffic) von dem Sensor ist es "Stochern im Nebel"...
Vielen Dank für die Hinweise - mein MQTT Server Setup hat anscheinend über die Jahre "gelitten".
Ich hab jetzt MQTT mal komplett mit den aktuellen Modulen neu aufgesetzt - und schon klappt alles :)
Moin moin,
von Xiaomi gibt es ja diese schönen Wireless-Taster, welche im original Gateway die Funktionen Einfach-, Doppel- und Langklick haben.
Im z2t Gateway kommt jedoch leider nur der Power-Wert, den man von ,,1" für Einfachklick bis zu ,,4" für einen Vierfachklick bekommt. Den Long-Press bekommt man nicht raus.
Hat jemand mit diesem Tastern und z2t schon Erfahrungen gemacht ?
VG, Chris