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.

Beta-User

Hab's mal eingepflegt und auch die Binding-Ebene geändert. Sieht mit lan=Perl etwas seltsam aus, mal sehen, ob ich da noch eine bessere Lösung finde.

Ansonsten will ich mich mit Kommentaren eher zurückhalten - ich bin vermutlich schlicht betriebsblind ;D .

Wenn du das so gut findest, ist es für mich auch ok.

Was gut wäre: vielleicht magst du dir den Quelltext aus dem Wiki ansehen und dann die weiteren Teile entsprechend bereits vorformatieren?
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

Ich habe mir den Quelltext jetzt mal angeschaut und vielleicht auch etwas verstanden, bin mir aber nicht sicher. Wenn ich den Text
Zitat==Beispieltext unterstrichen==
===Beispieltext fett====
Normaler Text   
so übermittele ist es einfacher ihn zu übernehmen?
Gruß Thomas

Beta-User

Das sind Überschriften bzw. Gliederungselemente; aber sonst: ja, ist einfacher.
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 habe mal versucht die Hinweise auf die Quelltextformatierung im WIKI einzubauen
Herausgekommen ist folgeende Ergänzung als Praxisbeispiel  Definition eine Müller GU10 Spots
Zitat=== Müller Licht: tint GU10 Spot warm- bis tageslichtweiß 350lm ===
Gerätebeschreibung beim [https://zigbee.blakadder.com/Muller_Licht_404006.html blakadder.com]. Das dann angewendete template trägt die Bezeichnung ,,tasmota_zigbee2tasmota_light_cct ".
Daraus ergibt sich folgende Definition:
<syntaxhighlight lang="perl">defmod MQTT2_z2t_6301 MQTT2_DEVICE z2t_6301
attr MQTT2_z2t_6301 IODev MQTTBroker
attr MQTT2_z2t_6301 alias Deckenlampe1
attr MQTT2_z2t_6301 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_z2t_6301 group Zigbee2Tasmotagroup100
attr MQTT2_z2t_6301 icon light_control
attr MQTT2_z2t_6301 jsonMap Dimmer:brightness Power:state Device:0 Hue:hue Sat:saturation CT:ct
attr MQTT2_z2t_6301 model tasmota_zigbee2tasmota_light_cct
attr MQTT2_z2t_6301 readingList tele/zb2tasmota/6301/SENSOR:.* { $EVENT =~ s/"Power":1/"Power":"on"/g;; $EVENT =~ s/"Power":0/"Power":"off"/g;; $EVENT =~ m,^.*(..Device.+)..$, ?  json2nameValue($1,'',$JSONMAP) : $EVENT =~ m,0x6301.:(.*).., ?  json2nameValue($1,'',$JSONMAP) : undef  }
attr MQTT2_z2t_6301 room MQTT2_DEVICE
attr MQTT2_z2t_6301 setExtensionsEvent 1
attr MQTT2_z2t_6301 setList on cmnd/zb2tasmota/ZbSend {"device":"0x6301","send":{"Power":"On"}}\
  off cmnd/zb2tasmota/ZbSend {"device":"0x6301","send":{"Power":"Off"}}\
  brightness:colorpicker,BRI,0,5,254 cmnd/zb2tasmota/ZbSend { "device":"0x6301", "send":{"Dimmer":$EVTPART1} }\
  dimup:noArg cmnd/zb2tasmota/ZbSend { "device":"0x6301", "send":{"DimmerUp":""} }\
  dimdown:noArg cmnd/zb2tasmota/ZbSend { "device":"0x6301", "send":{"DimmerDown":""} }\
  ct:colorpicker,CT,153,5,370 cmnd/zb2tasmota/ZbSend { "device":"0x6301", "send":{"CT":$EVTPART1} }
attr MQTT2_z2t_6301 setStateList on off
attr MQTT2_z2t_6301 webCmd on:off:brightness:ct</syntaxhighlight>
Hier wurde das Attribut webCmd um die Befehle brightness und ct erweitert. 3 dieser Lampen wurden mittels des Befehls
<syntaxhighlight lang="perl"> ZbSend {"device":"0x6301",,"Send":{"AddGroup":100}}</syntaxhighlight>
zu einer Gruppe (group:100) zusammengefasst und haben deshalb die Readings: AddGroup, AddGroupStatus, AddGroupStatusMessage und das Attribut group.
Geht das in die richtige Richtung oder war das ganze eher Kontraproduktiv? Auch habe ich mir mit 2 Tagen Abstand nochmal angeschaut, was ich zum Thema Binding verzapft habe. Ganz abgesehen von den Rechtschreibfehlern, war es doch wohl nicht mein bester Tag  :(. Aber das Wiki lebt ja vom mitmachen und vielleicht kann jemand ander das ganze verständlicher formulieren.
PS: Warum jetzt das smiley in dem Zitat erscheint, erschließt sich mir nicht wirklich, nächstes Mal besser Code-Tags nehmen?

Beta-User

Das war jetzt jedenfalls recht einfach ins Wiki zu übernehmen, auch den smiley hat die Forensoftware als Quelltext aktzeptiert/interpretiert.

Ob das die richtige Richtung ist, kann ich nicht wirklich sagen, meine Sorge dabei sind die vielen Details, sowas veraltet schon mal gerne recht schnell (aber nicht mehr so schnell wie in den Anfangstagen der Doku zu MQTT2_DEVICE).

Und dass einem das eigene Geschreibsel dann unverständlich vorkommt, ist normal; ggf. magst du selbst dann nochmal drübersehen? (Erfahrungsgemäß trauen sich andere nicht einfach so, und schon gleich nicht in neuen Artikeln und "Baustellen").
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,
ja die Warnung das hier seit 120 Tagen nichts mehr passiert ist, ignoriere ich jetzt mal. ;) Wie im Wikitext erwähnt ist Zigbee2Tasmota noch sehr stark in der Entwicklung und in den 120 Tagen hat sich viel verändert. Zigbee2Tasmota ist Stand 04.01.2021 bei Version 9.2 angekommen und ich möchte gerne einige Aktualisierungen vornehmen. Dazu habe ich mich diesmal selbst fürs Wiki angemeldet, ich hoffe aber trotzdem auf Unterstützung durch die Community und vor allen Dingen, wie beim letzten Mal auf die Hilfe von Beta-User. Dafür schon Mal danke.
Zum Einstieg möchte ich 2 Textanpassungen vornehmen. In der Einführung steht unter andem folgender Satz
ZitatAußerdem sollte erwähnt werden, das sich das Projekt noch in einem frühen Stadium befindet und die Anzahl der unterstützten Geräte geringer ist als bei z.Bsp. zigbee2mqtt.
dazu möchte ich Folgendes hinzufügen
Zitatsowie das der Befehlssyntax noch ständig erweitert bzw. leicht verändert wird. Es ist sicher auch eine gute Idee sich bei neuen Versionen auf der Tasmota Seite https://tasmota.github.io/docs/ das Changelog anzusehen
Die zweite Textstelle betrifft die Hilfe beim händischen Anlegen von Devices, der dort erwähnte Befehl ZbStatus2 funktioniert so nicht mehr. Hier würde ich ganz am Schluß des Absatzes
ZitatDa hier aber keine Rückmeldung, insbesondere über die Schaltbefehle zu sehen ist, sollte die Zigbee2Tasmota Konsole zu Kontrollzwecken trotzdem geöffnet sein.
folgenden Text hinzufügen
ZitatIn neueren Versionen funktioniert der Befehl ZBStatus2 nicht mehr ohne die Angabe einer Short adress. Hier kann in neueren Versionen (9.20) als Alternative ZbList verwendet werden. Die eleganteste Lösung bietet  aber (bei neueren Tasmota Versionen, getestet ab 9.20 )das Webinterface, welche auf der Startseite eine Übersicht der angelernten Geräte inkluive der Short adress anzeigt. Diese kann dann wie weiter oben erläutert benutzt werden.

Beta-User

...das mit den 120 Tagen ist völlig ok :) .

Das mit der Aktualisierung/Changelog finde ich gut, ggf. sollte man auch einen deutlichen Hinweis platzieren, dass die attrTemplate auch für die jeweils aktuellste Fassung gedacht sind (und dann neue setList-Topics ggf. auch in die attrTemplate einpflegen).

Grundsätzlich würde ich Rückverweise vermeiden auf irgendwas, was irgendwann mal ging, und auch nicht lange Unterschiede erklären. Vorne den (möglichst aktuellsten) Stand, für den es gilt, attrTemplate ggf. auch auf diesen Stand bringen, fertig. Wo (noch) "alter" content steht ggf. separat vermerken, damit da keiner drüber stolpert. Meine Vermutung wäre, dass es die kommende Zeit noch ein paar kleinere Änderungen auf der Tasmota-Seite geben wird, aber das dann auch zeitnah abgeschlossen sein wird.

Fyi: ich hatte die Sonoff-Bridge auch testweise am Laufen, aber da z.B. festgestellt, dass bei jedem neuen Anlernvorgang für ein Device auch eine neue "shortid" erzeugt wurde. Das ist unschön, und falls das die Regel ist, sollte es auch irgendwo noch mit rein.
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

Danke für das Feedback!
Ich hatte eigentlich gedacht, den neueren Befehl ZbList nur zu ergänzen, aber ok, dann werde ich das ganze Konstrukt mal an die aktuelle Version 9.2 anpassen. Den Hinweis auf den alten Befehl würde ich aber doch gerne zumindest erwähnen wollen. Die Anregung die Templates anzupassen finde ich gut,habe aber im Moment kein Testsystem und würde mich dann im MQTT thread dazu wieder melden, außerdem habe ich mich vor Weihnachten mal mit Tasmota-IR beschäftigt und ich finde das Templates noch ausbaufähig.  :)
Fyi: Ich hatte ja das Gateway https://forum.fhem.de/index.php/topic,112502.0.html von Locutus im Rahmen der damaligen Template Erstellung genutzt und nutze es bis heute in meinem Produktivsystem noch mit der 8.3 Version ohne irgendwelche Probleme. Die Sonoff Bridge sollte dann wieder ins Testsystem,mal sehen was dann an Überraschungen passiert.
2 Fragen noch zum Wiki, so wie ich das sehe (hab gestern abend schon mal etwas probiert) kann ich auf 2 Arten editieren. Einmal mit dem Punkt Bearbeiten, ich nehme an um hauptsächlich den Text zu bearbeiten und zum zweiten Quelltext bearbeiten, womit man dann das Layout beeinflussen kann, Richtig? Außerdem sollte man sich bevor man Veränderungen abspeichert eine Vorschau anzeigen lassen, dazu habe ich nichts gefunden. Anmerkungen zu meinen Änderungen kann ich beim Abspeichern mit angeben ?
das wars erstmal
Gruß Thomas

Beta-User

Vermutlich ist der Schritt von 8.x nach 9.2 nicht sooo riesig, ich hatte mit 9.1 kurz getestet...

Das IR-Template ist gefühlt ein stub, und mAn. sollte man "meinen" alten Artikel zum IR-Gateway (und der eigencompiled firmware) mal aktualisieren (samt remotecontrol), aber ich habe das nicht mehr im Einsatz. Was an IR (und RF) schwierig ist, ist die relativ geringe Standardisierung, man muss eigentlich schon verstanden haben, wie man es einsetzen will und dann die Anpassungen vornehmen...

Quelltext ist "nicht-grafisch", "bearbeiten" bietet WYSWIG. Ich mache aus Gewohnheit Quelltext und da gibt es auch einen Vorschau-Button. Anmerkungen gehen ggf. auch (zumindest im Quelltext), aber da müßte ich auch suchen, wie es geht, vor dem Speichern kann (und sollte man mAn auch) man jedenfalls einen kurzen Kommentar eingeben, was man geändert hat.
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 und danke für die Hinweise,
da ich beim Schreiben gemerkt habe, das ich bei vielen Dingen mittlerweile unsicher bin, habe ich dann doch erstmal ein neues Testsystem aufgesetzt und darin einige Geräte angelernt. Die gute Nachricht: Im Grossen und Ganzen funktioniert das noch so wie im Wiki beschrieben und auch die Templates lassen sich ohne Probleme anwenden.
Aufgrund der Weiterentwicklung von Tasmota würde ich heute einige Dinge allerdings anders anfangen. Darum sind die Änderung am Text auch deutlich mehr geworden, als ursprünglich gedacht und ich habe ein PDF gemacht indem meine Änderungen in rot geschrieben sind, es wäre schön wenn der ein oder andere da mal reinschaut. Ich freue mich über jedes Feedback und hoffe das ist ok so wie ich es angefangen habe. Ausserdem stelle ich mir die Frage ob es Sinn macht ein oder zwei Bilder in der Art wie ich sie auch angehängt habe ins Wiki zu integrieren.
Gruß Thomas

Beta-User

 :) Nach meinem Eindruck brauchst du da nicht so vorsichtig oder zögerlich zu sein.

Zum einen ist es noch ausdrücklich als "Baustelle" gekennzeichnet, von daher kannst du das auch gerne als "persönliches Experimentierfeld" betrachten und das eine oder andere Austesten. Bilder/screenshots finde ich gut, vielen hilft das, wenn sie grafisch erfassen können, wo was zu finden ist, Text ist oft schwieriger zu verstehen.

Und Wiki ist nicht heilig, wenn "Unsinn" drin steht, findet sich in der Regel jemand, der einen entweder darauf hinweist oder direkt Korrekturen vornimmt... (manche Schreib- oder Grammatikfehler sieht man irgendwann selbst nicht mehr, und ich bin auch immer wieder dankbar, wenn ich dann sehe, dass da jemand lautlos hinter mir hergeräumt hat ::) .)
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,
war die letzten Tage etwas unpässlich  :( .Habe einige Sachen geändert und mich dagegen entschieden Bilder mit reinzunehmen.
@Beta-User: Der ZbInfo Befehl sollte nochmal in Zusammenhang mit dem Zigbbe2Tasmota Template betrachtet werden. Denn:
ZitatZbInfo
   <device> = display all information known about a device, equivalent to ZbStatus3 with a simpler JSON output
zeigt momentan keine Geräteliste in FHEM und ZbStatus2 bzw.3 benötigen zwingend als Argument eine Short Adress. Soll im MQTT Bereich einen neuen Thread aufmachen oder den alten reaktivieren ?
Gruß Thomas

Beta-User

Kein Ding, das eilt ja alles nicht...

Die Überarbeitungen sehen für mich soweit ok aus, und es spricht auch nichts dagegen, den "attrTemplate"-Thread weiterzuführen.
Unschön bzw. "Leichenfledderei" wird es erst, wenn der neue Aspekt mit dem nichts oder wenig zu tun hat, was da in dem "ruhenden Thread" thematisiert wurde. Diese Gefahr sehe ich hier nicht, es ist eher so, dass das gut ist, weil dann die Leute mitlesen, die das derzeit auch nutzen...
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