mqtt2.template: Contributing

[Blauhorn]

Guten Morgen,

als Ergebnis meiner Migration von MQTT nach MQTT2 https://forum.fhem.de/index.php/topic,103762.0.html
ist nun für die Sonoff-4CH mit Tasmota dieses template entstanden, das jeden Kanal in ein eigenes Geräte legt.

Code: [Auswählen]

# sonoff 4 channel device flashed with Tasmota.
name:A_04_tasmota_4channel_split
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:sonoff 4 channel device flashed with Tasmota. <br>NOTE: a second, third and fourth device will be created for each additional channel
set DEVICE attrTemplate A_01a_tasmota_basic_state_power1
par:CMNDTOPIC;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\b(tele|cmnd|stat)(/.*)?/LWT:, ? "${1}cmnd$3" : undef }
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
#create device for CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 stateFormat POWER2
attr DEVICE_CH2 comment Channel 2 for DEVICE
setreading DEVICE_CH2 associatedWith DEVICE
attr DEVICE_CH2 setList \
  off:noArg    CMNDTOPIC/POWER2 0\
  on:noArg     CMNDTOPIC/POWER2 1\
  toggle:noArg CMNDTOPIC/POWER2 2
attr DEVICE_CH2 setStateList on off toggle
#create device for CH3
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 stateFormat POWER3
attr DEVICE_CH3 comment Channel 3 for DEVICE
setreading DEVICE_CH3 associatedWith DEVICE
attr DEVICE_CH3 setList \
  off:noArg    CMNDTOPIC/POWER3 0\
  on:noArg     CMNDTOPIC/POWER3 1\
  toggle:noArg CMNDTOPIC/POWER3 2
attr DEVICE_CH3 setStateList on off toggle
#create device for CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 stateFormat POWER4
attr DEVICE_CH4 comment Channel 4 for DEVICE
setreading DEVICE_CH4 associatedWith DEVICE
attr DEVICE_CH4 setList \
  off:noArg    CMNDTOPIC/POWER4 0\
  on:noArg     CMNDTOPIC/POWER4 1\
  toggle:noArg CMNDTOPIC/POWER4 2
attr DEVICE_CH4 setStateList on off toggle
#set the model attr for all new devices
attr DEVICE model A_04_tasmota_4channel_split
attr DEVICE_CH2 model A_04_tasmota_4channel_split
attr DEVICE_CH3 model A_04_tasmota_4channel_split
attr DEVICE_CH4 model A_04_tasmota_4channel_split

Gruß vom Blauhorn

[Beta-User]

 
Du lernst ja fix...!

Thx, u.a. das habe ich eben (mit kleinen Modifikationen) eingecheckt. Danke auch für die Anregung, bei den "Kindern" auch immer das Modell zu setzen, das fehlt(e) bei dem einen oder anderen auch noch...

[rudolfkoenig]

Eventuell wäre es eine Idee, dazu ein neues, optionales "sort:" einzuführen (ebenfalls alphanummerisch, damit erst mal das bestehende System auf einfache Weise transferiert werden könnte)?

Ich habe order: (optional) implementiert.
Achtung: der Vergleich ist _nicht_ numerisch, sondern alphanumerisch!

Weiterhin erscheint ab sofort beim Auswahl eines attrTemplate Wertes die Beschreibung und die Liste der Befehle.

[Beta-User]

Ich habe order: (optional) implementiert.
Achtung: der Vergleich ist _nicht_ numerisch, sondern alphanumerisch!

Weiterhin erscheint ab sofort beim Auswahl eines attrTemplate Wertes die Beschreibung und die Liste der Befehle.

Habe eben eine aktualisierte Version von mqtt2.template ins svn geschoben, hatte zwar auf dem Testsystem keine große Auswahl an angezeigten Devices, aber das so gut aus .

Gefällt mir sehr gut mit den kürzeren Namen und dem Umstand, dass das sortieren jetzt im Hintergrund abläuft und auch nicht mehr im "model" hinterlegt ist (die sind auch alle geändert...). Wird zwar vermutlich ewig dauern, bis alle model-Angaben in der Statistik wieder passen, aber das können wir verschmerzen, oder?

Kann nicht garantieren, dass ich alles "erwischt" habe und nicht irgendwelche Querbezüge kaputt gegangen sind (interne Aufrufe auf andere templates). Wer was findet, bitte im "bugs"-Thread melden.

Wenn das hier keine größeren Probleme aufwerfen sollte, ziehe ich bei Gelegenheit "meine" beiden anderen files nach.

[Icinger]

Vielleicht wäre es eine Überlegung, die setlist der SonOff-Templates folgendermaßen zu ergänzen:

Code: [Auswählen]

  setOtaUrl:textField CMNDTOPIC/OtaUrl $EVTPART1\
  upgrade:noArg   CMNDTOPIC/upgrade 1\
Somit lässt sich die OTA-Url setzen und danach ein Firmware-Update für alle Geräte im Netz gleichzeitig anstoßen.

lg, Stefan

[Beta-User]

Thx, hab's mal beim "Basistemplate" dazugefügt, damit sollte es sich an (fast?) alle einkanaligen vererben.
Wenn es sich bewährt, schaue ich mir bei Gelegenheit noch die an, die fehlen.

@all: Seit gestern abend bzw. heute morgen werkelt bei mir testweise ein OpenMQTTGateway auf einem ESP32, siehe https://github.com/1technophile/OpenMQTTGateway/wiki, nachdem hier ein User Fragen im Zusammenhang mit 433HMz-Rolling Codes dazu hatte. Für 433MHz finde ich das vorläufig gar nicht sooo spannend, aber das kann scheinbar einige/alle (?) BT-Devices von Xiaomi und taugt evtl. auch als BT-Scanner.
Werde damit wohl meinen IR-ESP8266 (360°-GW, geflasht mit Tasmota) ersetzen (der ESP32 sollte alle drei Funktionen parallel können und sich noch z.B. mit einem BME280 ergänzen lassen, wer das will).
Wie dem auch sei, den Tag über hat das hier in der eher funkarmen Gegend ca. 25 BT-Devices "eingefangen" (bisher keinen Xiaomi, oh Wunder...). Wenn also jemand Lust hat, da mitzuüberlegen, wie man das @MQTT2-Device sinnvoll ausgestalten kann: feel free, entweder einen separaten Thread aufzumachen oder sich einzuklinken .

Ein schon ganz passables Template für die ESP-Brücke und einen speziellen RF-Anwendungsfall sind vorhanden, ansonsten scheint der Sketch intern auch nur "die üblichen Verdächtigen" zu nutzen, was libs angeht.

[oelkanne]

Guten Abend.
Ich versuche meine Jarolift Rolläden mit MQTT2 zu verwenden.
(Liefen bisher mit dem mosquitto broker)

Dafür habe ich ein frisches FHEM aufgesetzt und wollte es entsprechend Anleitung betreiben. (Mit ioDEV 
MQTT2_FHEM_Server, sonst wie in der Anleitung https://github.com/madmartin/Jarolift_MQTT/wiki/Usage-with-FHEM-&-MQTT)

Mein Problem: das attribut publishSet gibt es nicht für das ioDEV.

Wie gehe ich richtigerweise vor?

[Beta-User]

Falscher Thread. Der hier ist für fertige Templates...

OT-Tipp: Wenn du irgendwo einen ESP8266 rumliegen hast, mach da mal ein Tasmota drauf und wende das basic-Template darauf an. Dann hast du schon mal ein Beispiel, wie eine setList aufzubauen ist. Das erfüllt die Funktion, die die publishSet-Attribute aus MQTT_DEVICE hatten. Vermutlich wäre sowas sinnvoll:

Code: [Auswählen]

attr DEVICE setList \
   close:noArg cmd/jarolift/shutter/1 DOWN\
   open:noArg cmd/jarolift/shutter/1 UP\[....]open/close sind als Befehle gewählt, damit es zu anderen Templates paßt (hier: tasmota_2ch_shutter_invert_0), aber im Prinzip beliebig...

Weitere Diskussion - sofern noch erforderlich - bitte in gesondertem Thread in diesem Forumsbereich, ich sehe das dann in der Regel schon, sonst in dem "Anregungen"-Thread kurz dahin verlinken.

[aperoap]

Hallo Zusammen,
betreibe seit paar Wochen auch zigbee Komponente bei mir. Bis vor eine Woche habe ich MQTT(mosquitto) und zigbee2mqtt von Koenkk mit cc3251 als Controller und ein cc3251 Router betrieben. Seit eine Woche bin ich auf mqtt2 Server umgestigen un mosquitto gelöscht.
Soweit läuft alles und kann betrieben werden. Die integrierten Templates sind hervorragend.

Problem:

-Der Router wurde erkannt und als mqtt2 device angelegt.
 meldet sich minütlich bei Controller und setzt folgende readings.

Code: [Auswählen]

Readings
associatedWith MQTT2_zigbee_0x00Xxxxxxxxx 2019-11-09 08:18:50
led_state true 2019-11-09 08:35:50
linkquality 0 2019-11-09 08:35:50
state true 2019-11-09 08:35:50
ich habe leider kein template gefunden (online / offline) Anzeige wie mqtt.

Hat vielleicht jemand schon was in der Richtung gemacht?

[Beta-User]

Falscher Thread. Der hier ist für fertige Templates...

Warum wird das überlesen? Kann ich da was machen, dass das nicht übersehen wird?

Aber der Vorschlag ist gut .
Bitte in dem anderen Thread (Bugs, Fragen...) ein vollständiges list einstellen und Infos liefern, was du wie (in etwa) angezeigt bekommen willst bzw. wie die Werte dazu sind (state true/false mit einem grünen und roten Punkt wäre kein Problem). Vermutlich würde es Sinn machen, in dem Fall auch die Verbindungsqualität irgendwie zu visualisieren (farbig?).
Kann man die LED via MQTT ein- und ausschalten? (bitte das passende Kommando mitteilen, dann kann man auch dazu einen setter basteln...).

[dieter114]

War das eine positive Rückmeldung zu dem vertemplateten Vorschlag in meiner Antwort? Da waren in meiner Wahrnehmung noch ein paar Fragen offen...

Dann: Soll das den vorhandenen POW ersetzen oder zusätzlich ins file?

Wenn ich dazu klare Antworten erhalte, mach ich das selbstredend direkt mit rein .

Hallo Beta-User,
ich sehe immer noch kein (für mich) nutzbares Template für den Tasmota POW2.
Ich habe diverse Tasmotas in meine Systeme eingebunden
aber mit den (neueren) POW2 gibt es Probleme.
Wenn ich das Template POW nehme, wird eigentlich viel Ausgelesen und Angezeigt.
Ein einfaches "On" oder "Off" schaltet zwar den Pow, aber der Status wird nicht nachgezogen.
Bin nur zu blöd das Ding zu integrieren - oder gibt es hier doch noch ein Problem?

Gruß Wolfdieter

[Beta-User]

(Für die Statistik: Falscher Thread #3...)

Der Hinweis, dass der state nicht paßt, hätte besser in den verlinkten Thread gepaßt und betrifft mMn. auch den "normalen" POW. Meine persönliche Tendenz wäre, in die generelle Tasmota-Struktur einzugreifen und die erweiterte json2nameValue()-Variante zu nutzen und POWER1 darüber via JSONMAP nach state zu schreiben. Ist aber uU. nicht (für die anderen Tasmota-templates) nebenwirkungsfrei, muß ich mir ansehen und ggf. in dem allg. Tasmota-Thread mal nachhaken, wie da die Temperatur dazu ist.

Für einen schnellen Fix kannst du einen userReadings-Eintrag machen, der auf POWER1 triggert und das Ergebnis nach state schreibt. In etwa so:

Code: [Auswählen]

attr DEVICE userReadings state:POWER1:.* { ReadingsVal($name,"POWER1","") }Habe jetzt aber nicht nachgesehen, ob man z.B. auch $EVTPART1 nutzen kann, wenn, ist das  der direktere Weg.
Weitere Diskussion dazu bitte in dem passenden Thread: https://forum.fhem.de/index.php/topic,100484.0.html

[rudolfkoenig]

Habe jetzt aber nicht nachgesehen, ob man z.B. auch $EVTPART1 nutzen kann, wenn, ist das  der direktere Weg.

userReadings kennt kein EVTPART*, weil es im readingsEndUpdate berechnet wird, wenn eine (zusammengehoerige) Menge von Events fuer die notifies vorbereitet werden.
Beispielweise alles, was in einem JSON kommt, wird mit userReadings nur einmal "bearbeitet".
Eine moegliche Alternative ist "attr DEVICE stateFormat POWER1".

[Beta-User]

Danke für die Klarstellung betr. $EVTPARTx.

stateFormat ist hier schon gesetzt, beeinflußt aber nur STATE. Ob es Sinn macht, statt ReadingsVal->state auf IntenalVal->STATE umzubiegen, war auch eine Überlegung. Dabei hab ich aber die Befürchtung, dass das an einer Stelle ist, die gerne auch mal vom Benutzer geändert wird (grade bei dem POW), und dann funktioniert das wieder nicht.

Im Moment denke ich, es ist das einfachste, das globale Tasmota-template dahingehend zu ändern, dass json2nameValue in der vollen Form (für Result) genutzt wird und dann (erst mal nur für den POW) das jsonMap POWER1:state zu verwenden; dazu muß wohl auch im POW-template stateFormat (kommend aus dem globalen template) gleich wieder gelöscht werden...
Auch wenn es unschön ist, Attribute evtl. unnötig zu löschen, ist das m.E. jedenfalls für den Einstieg in eine eventuelle Umstellung ein gangbarer Weg; auch das allg. template ignoriert ja grade evtl. andere Vorgaben des Users.

[Zeppelin]

Hallo zusammen,

hätte einen ersten Vorschlag für den ShellyDimmer:

Code: [Auswählen]

--- mqtt2.template      2019-11-19 23:02:57.134372779 +0100
+++ mqtt2.template.new  2019-11-19 23:01:39.041573002 +0100
@@ -1499,6 +1499,34 @@
 setreading DEVICE_CH4 associatedWith DEVICE,DEVICE_CH2,DEVICE_CH3
 attr DEVICE_CH4 setStateList on off
 
+#shellydimmer
+# contributed by zeppelin
+name:shellydimmer
+filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
+desc:shellydimmer <br>Tested with 20191119-085746/master@e3a747f5
+order:A_18
+par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
+par:ICON;ICON as set, defaults to light_control;{ AttrVal("DEVICE","icon","light_control") }
+attr DEVICE icon ICON
+attr DEVICE setList\
+  off:noArg shellies/DEVNAME/light/0/command off\
+  on:noArg shellies/DEVNAME/light/0/command on\
+  pct:slider,0,1,100 shellies/DEVNAME/light/0/set {"turn": "on","brightness": $EVTPART1}
+deletereading -q DEVICE status_.*
+attr DEVICE readingList \
+  shellies/DEVNAME/light/0/status:.* {json2nameValue($EVENT)}\
+  shellies/DEVNAME/temperature:.* temperature\
+  shellies/DEVNAME/temperature_f:.* temperature_f\
+  shellies/DEVNAME/overtemperature:.* overtemperature\
+  shellies/DEVNAME/overload:.* overload\
+  shellies/DEVNAME/loaderror:.* loaderror\
+  shellies/announce:.* { $EVENT =~ m,..id...DEVNAME...mac.*, ? json2nameValue($EVENT) : undef }
+attr DEVICE webCmd pct:on:off
+attr DEVICE devStateIcon {my $lderr = ReadingsVal($name,"loaderror","true") eq "true"?"10px-kreis-rot":"10px-kreis-gruen";; my $light = ReadingsVal($name,"ison","false") eq "true"?"on":"off";; my $cons = ReadingsVal($name,"light_0_power","unknown");; FW_makeImage($lderr)."<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Leistung: $cons</div>"}
+set DEVICE x_mqttcom announce
+attr DEVICE model shellydimmer
+
+
 ###############
 #ebusd
 #