Zigbee2tasmota Erweiterungde Wiki ArtikelsMQTT2-Module-Praxisbeispiele

Begonnen von TL60, 06 August 2020, 21:24:28

Vorheriges Thema - Nächstes Thema

TL60

Hallo,
ich habe diesen Thread auf anraten  von Beta-User neu angelegt. In den letzten Tagen ist im Mqtt Bereich und dort im Thread https://forum.fhem.de/index.php/topic,112253.msg1065925.html#msg1065925 ziemlich viel in Richtung Templateentwicklung für das neue Gateway Zigbee2tasmota passiert. Beta-User meinte das man dieses neue Gateway und die Templates auch im Wiki wiederfinden sollte. Um der Community von der ich schon seit Jahren profitiere, vielleicht etwas zurück zu geben, habe ich mal einen ersten Entwurf, welcher jedoch noch lange nicht fertig ist, angefangen. Ich habe keinerlei Erfahrung im Aufsetzen solcher Artikel, keine Erfahrung mit Arbeiten an einem Wiki und würde deshalb meinen Entwurf gerne zur Ansicht und zur Diskusion stellen. Da ich nun wirklich nicht mal weiß ob ich diesen Entwurf hier einfach anhängen kann oder wie das sonst zu machen ist, hoffe ich doch wieder auf Hilfe von euch. Meiner Meinung nach wäre es am sinnvollsten den vorhandenen Eintrag https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele zu erweitern. Gerne bin ich bereit den Text zur Verfügung zu stellen und wenn er passt kann ihn jemand  ins Wiki stellen.
Danke und beste Grüße
Thomas

Beta-User

Moin!

Vorab mal Danke, dass du dich da dran machst!

Du kannst deinen Textvorschlag gerne einfach hier als Anhang beifügen oder in Quote-Tags, das ist letztlich egal, solange es die Forensoftware akzeptiert.

Was die Verortung angeht, würde ich das gerne eher wie beim EBUS machen und habe das grade dann auch entsprechend vorbereitet: Einen kurzen Hinweis oder eine Art Einführung in den Praxisbeispielen, wo der eigenständige Hauptartikel zu finden ist. Das hat den Vorteil, dass man den z.B. leichter auch unter die ZigBee-Kategorie einsortieren kann (und zusätzlich auch hier erwähnen: https://wiki.fhem.de/wiki/ZigBee#Direkt_per_MQTT).
Mittelfristig will ich die "Praxisbeispiele" eher als Übersichtsseite ausgestalten und nicht weiter aufblasen. Insbesondere zigbee2mqtt und der ESP-MiLight-Hub sollten mMn. auch eher nur als Schlagwort verbleiben und ähnlich ausgegliedert werden.
Dafür sollten ggf. in den Praxisbeispielen allgemeine "Probleme" und Vorgehensweisen etwas ausführlicher aufgenommen werden (z.B., dass man manche Leuchtmittel erst mal schalten muß, damit autocreate aktiv werden kann; das ist ein wiederkehrendes Thema bei fast allen "Bridge"-Lösungen...). (Falls du da konkrete Text-Vorschläge hast: gerne)

Ich habe daher jetzt mal https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT als Platzhalter eingefügt, und an den angegebenen Stellen verlinkt. Darüber findet man zumindest schon mal hierher (und dann weiter zum "Entwicklungsthread").

Falls du Infos brauchst wie man z.B. Abschnitte und Gliederungselemente usw. im Wiki-Format einfügen kann, einfach bei einem beliebigen Artikel mal "Quelltext anzeigen" klicken oder diesem Link folgen: https://wiki.fhem.de/w/index.php?title=MQTT2-Module_-_Praxisbeispiele&action=edit.

Hoffe, das Gesamtbild wird so jetzt auch etwas klarer?

Grüße, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TL60

Ja, so wird mir schon einiges klarer. Ich werde meinen Entwurf nochmal überarbeiten und dann hier einstellen. Ich denke als Dateianhang im Open Document Format.

Beta-User

OK, Format ist im Prinzip egal, aber verwende bitte nicht viel Zeit (=keine) in (normale) Formatierung; das kann man nämlich nicht so einfach übertragen bzw. es geht schneller, wenn man es händisch macht anhand von passenden Hinweisen. (Wiki-like Formatiserungsanweisungen darfst du gerne reinmachen, aber das ist kein "Muß").
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TL60

Sorry, hat dann doch noch etwas gedauert, aber meine Regierung hatte mich anderweitig eingeplant  ;)
Jetzt im Anhang ein sicher unvollständiger, verbesserungswürdiger erster Entwurf. Codebeispiele ist z. Bsp ein solcher Punkt, aber ihr findet sicher noch reichlich andere  :(

Beta-User

Kein Ding!

Hab's mal soweit übernommen, finde, das sieht eigentlich schon ganz passabel (Schwabe...) SEHR GUT aus :) . Nur das mit der Datenbank habe ich nicht verstanden...

Was mir ggf. noch fehlt (aber auch in den attrTemplate), sind Optionen direkt in der Bridge. Man könnte z.B. das mit ZBStatus2 direkt als getter da einbauen, und wir sollten wohl diese spezielle Info dann auch in der readingList gesondert abfangen. Kann sein, dass da noch mehr schlummert.
Weiter habe ich das mit den Gruppenfunktionen schon mal in das Template eingebaut, aber da hast du ja schon einen Platzhalter dafür eingeplant :) .
Das Thema ZbStatus2 können wir aber gerne im Haupt-Thread vertiefen, hier sollte es weniger um Funktionalität gehen, eher um das Wording und die Frage einer sinnvollen Darstellung und Einbindung in das Gesamtgefüge.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TL60

wegen Datenbank, da fiel mir einfach kein besseres Wort ein, was ich meinte ist der interne Speicher des Zigbee2tasmota Gateway. Darin gespeicherte Geräte werden in FHEM nicht mehr so einfach angelegt. Zyklisch sendende-ja, so vermute ich wenigstens (habe leider keine)  aber Lampen und Remote-Control nur bei Status Änderung. Ist nicht sehr glücklich formuliert :(. Ansonsten freut es mich wenn ich mal helfen kann und so dem tollen Projekt FHEM und der klasse Community hier etwas zurückgeben kann. :)

Beta-User

OK, dann warte ich jetzt erst mal ab, bis du ggf. dann eine insgesamt überarbeitete Version bringst, die auch die neuen setter berücksichtigt, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TL60

Hallo,
Ich würde vorschlagen in das Wiki an der Stelle, wo es um das nachträgliche Anlegen von Geräten geht (ziemlich am Ende) nach dem Satz
ZitatJetzt sollte in FHEM per autocreate ein neues Device im Raum MQTT2-Devices angelegt worden sein.
das hier einzufügen.
ZitatEs ist auch möglich aus FHEM heraus im Bridge-Device  die nötigen Befehle ZbStatus2 und ZbSend einzugeben. Da hier aber keine Rückmeldung, insbesondere über die Schaltbefehle zu sehen ist, sollte die Zigbee2Tasmota Konsole zu Kontrollzwecken trotzdem geöffnet sein.
Und dan habe ich noch eine Erweiterung Für Groups and Bindings.

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TL60

@ Beta-User:
Siehst du noch Dinge, welche noch ins Wiki sollen, eventuelle Beispieldefinitionen oder sonst irgendetwas ? Noch hätte ich etwas Zeit und könnte mir ein paar Gedanken machen.

Beta-User

Na ja, eigentlich fehlt noch was zum Thema batteriebetriebene Geräte (FB's, Sensoren usw.). Der Bereich "Vereinzeln der Geräte" könnte eigentlich einen Folgebereich vertragen, in dem es um verschiedene Gerätegruppen geht (Bulbs/on-off-Aktoren), Fernbedienungen, Sensoren.

Aber da sind wir irgendwie noch nicht ganz soweit, und es kommt mir auch teilweise noch "unausgegoren" vor, was z2t da macht, aber evtl. hilft es auch, diese Dinge zu vervollständigen, wenn du sie erst mal kategorisierst.

Das Thema "Binding..." könnte man m.E. dann auch eine Ebene hochstufen?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TL60

ok, ich werde mal am Wochenende versuchen Gedanken zu verschiedenenen Geätebereichen zu machen. Irgendwas im Wiki hier, was ich mir als Beipiel mal angucken kann? Betteriebetriebne Geräte (Ausser Remote) sehe ich jetzt erstmal für mich noch nicht, ich habe selber bis auf die eine Remote (IKEA Dimmerswitch) keine und wie ich gerade im anderen Thread gelesen habe  https://forum.fhem.de/index.php/topic,112253.msg1077307.html#msg1077307 (Antwort85) bist du mit dem Ergebniss so auch noch nicht zufrieden. Groups und Bindings, da bin ich mir gar nicht sicher, ob das ein Thema für Templates ist, ich habe ja z.Bsp. eine Gruppe mit 2 GU10 Lampen angelegt und ein Binding zumIKEA Dimmerswitch eingerichtet, seit Sonntag steuere ich die beiden Lampen direkt über diese Verknüpfung ohne das meine Testinstanz überhaupt läuft, weder FHEM noch Zigbee2Mqtt. Wäre also, meiner Meinung nach im Wiki allgemein als Möglichkeit(evtl mit Beispiel) höchstens zu erwähnen. Wobei, wenn ich meinen eher geringen Englischkenntnissen trauen kann, es zumindest bei Fernbedienungen Unterschiede gibt, wie Bindings unterstützt werden. Aber ich schaue mal.

Beta-User

Na ja, auf die Schnelle fällt mir da keine 100% passende Referenz ein, aber ich kenne auch bei weitem nicht alles... Eventuell am ehesten noch ZWave. Aber auch da gehe ich davon aus, dass der Artikel auch erst nach und nach entstanden ist, weil es eben Bedarf für das weitere Details gab. (Was konkrete Geräte angeht, ist dieser Artikel total unvollständig; macht aber fast nichts ;) .)

Die Struktur, die ich heute morgen im Kopf hatte, ergibt sich schlicht aus dem, was ich aus dem anderen Thread weiß (iVm. etwas allgemeiner ZigBee-Erfahrung mit zigbee2mqtt und deconz) bzw. anhand der Message-Struktur "rate". Im Zweifel würde ich im Moment eher auch mal eine noch nicht zu beantwortende Frage aufwerfen (Koppelung eines Bewegungsmelders an einen Aktor unter "Binding"; ob das dann z.B. (technisch) eine gute Idee ist, das jeweils nur so lange zu machen wie es Dunkel ist, wäre eine weitere Frage (EEPROM-wear-out)...)

Was ich ggf. zu erreichen hoffe: 80/20 der Fragen beantwortet zu haben, bevor sie jemand ein 2. Mal stellt und die Vorgehensweise klarer zu haben, wenn jemand mit was neuem kommt - z.B. sollte klar sein, dass für ein unbekanntes batteriebetriebenes Gadget erst mal das "generic-battery" zu verwenden ist (damit keine überlangen Readingnamen entstehen).
Ist zwar nicht ganz so schön, wie eine fertige Lösung für jeden Spezialfall zu haben, aber so werden ggf. auch die Grundzüge besser verständlich?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TL60

Hallo,
ich möchte jetzt mal folgende Ergänzung zum Wiki in Richtung Gerätebeispiele vorschlagen
ZitatBeispieldefinitionen verschiedener Geräte
Alle Devices wurden nach dem Zurücksetzen auf Werkseinstellung (siehe jeweilige Bedienungsanleitung) wie oben beschrieben über die Zigbee2tasmota Konsole mit dem Befehl ZbSend { "device":"0x1234", "send":{"Power":"ON"} } geschaltet und auch erfolgreich automatisch in FHEM im Raum MQTT2_DEVICE erstellt.
1.Müller Licht: tint smart switch
https://zigbee.blakadder.com/Muller_Licht_404021.html
Das dann angewendete template trägt die Bezeichnung ,,tasmota_zigbee2tasmota_single_switch". Daraus ergibt sich folgende Definition:
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
Bitte Beachten: Das Standard Icon der dimmbaren Lampe wurde durch ein einfaches Lampen Icon ersetzt. Genauso können auch andere Geräteattribute nachträglich verändert werden. Bitte Vorsicht walten lassen , durch falsches Setzen von Attributen kann ein Device unbrauchbar werden.
@Beta-User, ginge sowas in die richtige Richtung, oder bin ich total falsch? Wenn nicht würde ich in ähnlicher Weise weitere Geräte beschreiben.