mqtt2.template: Contributing

[rudolfkoenig]

doch die Readings bezüglich result aktualisieren sich nicht.
Erst wenn das Device erneut in der WEB-Oberfläche geöffnet wird.

Vielleicht liegt es daran, dass das JavaScript-Programm im Browser nur vorhandene Elemente (vulgo Readings-Zeilen) aktualisiert, aber keine neuen dazubaut.

[hydrotec]

... nur vorhandene Elemente (vulgo Readings-Zeilen) aktualisiert, aber keine neuen dazubaut.

Die Readings sind schon vorhanden gewesen.

Jetzt hab ich mir gedacht, ok, versuchst es mal mit dem Edge.
Funktioniert wie es soll, Readings werden sofort aktuallisiert.
Wieder zurück zum Firefox, kontrolliert ob NoScript mir dazwischenfunkt, aber die Seite ist freigegeben.
Und was soll ich sagen, es werden die Readings sofort aktuallisiert. 
Keine Ahnung mit was das zusammengewirkt hat das es vorher nicht funktioniert hatte.

Entschuldigung wenn ich hier Pferde scheu gemacht habe. 
Für mich ist das Thema erledigt.

Dankeschön für die Unterstützung.

Schönen Sonntag noch
Gruß, Karsten

[barneybaer]

Hallo, hier wieder ein Patch für den "blind drive motor TS0601_cover" bei welchem die Stop-Funktion eingefügt wird.

Code: [Auswählen]

--- mqtt2.template 2021-08-17 20:02:31.333269762 +0200
+++ mqtt2.template_neu 2021-08-31 23:28:39.000000000 +0200
@@ -544,13 +544,14 @@
 par:ICON;ICON as set, defaults to fts_shutter_100;{ AttrVal("DEVICE","icon","fts_shutter_100") }
 attr DEVICE icon ICON
 attr DEVICE devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
-attr DEVICE webCmd open:close:pct:speed
+attr DEVICE webCmd open:close:stop:pct:speed
 attr DEVICE devicetopic BASE_TOPIC/DEV_ID
 attr DEVICE jsonMap position:pct motor_speed:speed
 attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
 attr DEVICE setList \
   open:noArg $\DEVICETOPIC/set {"state":"OPEN"}\
   close:noArg $\DEVICETOPIC/set {"state":"CLOSE"}\
+  stop:noArg $\DEVICETOPIC/set {"state":"STOP"}\
   pct:slider,0,1,100 $\DEVICETOPIC/set {"position":"$EVTPART1"}\
   speed:colorpicker,BRI,0,1,255 $\DEVICETOPIC/set {"options": {"motor_speed":"$EVTPART1"}}
 attr DEVICE stateFormat pct


[Beta-User]

Danke für den Patch, ist schon ein paar Tage im svn verarbeitet (neben ein paar anderen "Kleinigkeiten").

Allgemeiner Hinweis: Generell ist für sowas der mqtt2.template: bugs, Fragen, Anregungen -Thread gedacht, hier soll eigentlich nicht groß diskutiert werden (was vorliegend auch keinen großen Sinn hätte).

[MiKn]

Hallo,
ich habe ein paar "Moes 3 Channel Schalter" und das zigbee2mqtt_3channel_split Template benutzt. Um es korrekt nutzen zu können musste ich etwas ergänzen, welches ich mir beim 2 Kanal schalter abgeguckt habe. Bei Bedarf bitte gerne im Git anpassen. Danke

Code: [Auswählen]

For zigbee2mqtt 3 channel device like Silvercrest Steckerleiste »Zigbee Smart Home«.
NOTE: Two additional devices will be created for further channels.
NOTE: Untested updated version

attr DEVICE icon ICON
attr DEVICE eventMap { dev=>{ON=>'on',OFF=>'off'} }
attr DEVICE devicetopic BASE_TOPIC/DEV_ID
attr DEVICE readingList $\DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr DEVICE jsonMap state:availability state_l1:state state_l2:0 state_l3:0
attr DEVICE setList \
  on:noArg $\DEVICETOPIC/1/set {"state_l1":"ON"}\
  off:noArg $\DEVICETOPIC/1/set {"state_l1":"OFF"}\
  toggle:noArg $\DEVICETOPIC/1/set {"state_l1":"TOGGLE"}
attr DEVICE setStateList on off toggle
deletereading -q DEVICE (?!associatedWith|IODev).*
set DEVICE attrTemplate set_associatedWith \CHANNELS=3 \MAKECOPIES=1
attr DEVICE_CH2 setList \
  on:noArg $\DEVICETOPIC/2/set {"state_l2":"ON"}\
  off:noArg $\DEVICETOPIC/2/set {"state_l2":"OFF"}\
  toggle:noArg $\DEVICETOPIC/2/set {"state_l2":"TOGGLE"}
attr DEVICE_CH2 jsonMap state_l2:state state_l1:0 state_l3:0 state:0 consumption:0 linkquality:0 power:0 temperature:0
attr DEVICE_CH3 setList \
  on:noArg $\DEVICETOPIC/3/set {"state_l3":"ON"}\
  off:noArg $\DEVICETOPIC/3/set {"state_l3":"OFF"}\
  toggle:noArg $\DEVICETOPIC/3/set {"state_l3":"TOGGLE"}
attr DEVICE_CH2 jsonMap state_l3:state state_l1:0 state_l2:0 state:0 consumption:0 linkquality:0 power:0 temperature:0
set DEVICE,DEVICE_CH2,DEVICE_CH3 attrTemplate speechcontrol_type_switch
attr DEVICE,DEVICE_CH2,DEVICE_CH3 model zigbee2mqtt_3channel_split
setreading DEVICE,DEVICE_CH2,DEVICE_CH3 attrTemplateVersion 20211030
ändern in:
  on:noArg $\DEVICETOPIC/l2/set {"state_l2":"ON"}\
  off:noArg $\DEVICETOPIC/l2/set {"state_l2":"OFF"}\
  toggle:noArg $\DEVICETOPIC/l2/set {"state_l2":"TOGGLE"}
.....
  on:noArg $\DEVICETOPIC/l3/set {"state_l3":"ON"}\
  off:noArg $\DEVICETOPIC/l3/set {"state_l3":"OFF"}\
  toggle:noArg $\DEVICETOPIC/l3/set {"state_l3":"TOGGLE"}
[/code]

Das "l" fehlte bei state_l2 und l3.

[Beta-User]

Danke für den Hinweis, hab's gefixt (frage mich aber, warum das bei dem ersten Kanal anders ist).

Kleine Anmerkung: für sowas gibt es eigentlich den "bugs, ..."-Thread (siehe link im eresten Beitrag hier).

[Otto123]

Wenn sich Software komplett ändert...
Wie handhaben wir das dann?
Template aufblasen mit Versionserkennung?
Davon ausgehen: ab "heute" ist alles neu - die Templates für alte Versionen sind ja längst angewendet - und die alten Templates neumachen?
Ich habe das Gefühl das trifft uns stückweise bei tasmota, bei shelly sind es neue Geräte, ok dann neue Templates - aber...

Ganz konkret habe ich das bei valetudo, die haben eine völlig neue MQTT Struktur gemacht.
Mach ich jetzt das dritte valetudo Template oder das Alte neu? Die mqtt2.template Datei im SVN hat jetzt schon 5000+ Zeilen 

Gliedern wir die mqtt2.template thematisch weiter in Dateien?

[Beta-User]

Meine bisherige "Leitlinie" war:
Das aktuell verfügbare Haupt-Template sollte zum "stable"-Stand der firmware passen, und FHEM selbst muss auch auf dem aktuellen Stand sein (Rudi hat ja immer mal wieder ein neues feature möglich gemacht ).

In einigen Fällen ist dann das "alte" template noch eine Weile verfügbar gewesen, bis es dann irgendwann entsorgt wurde (müßte  checken, ob das Sinn macht, mal wieder aufzuräumen).

Komplizierte Unterscheidungen würde ich nicht machen, andererseits: mit "option" kann man ggf. übergangsweise auch arbeiten - was halt am wenigsten Aufwand macht...

Wegen der Zeilenzahl: ...einerseits ja sehr erfreulich, weil "einiges geboten" ist, andererseits "frißt" es (etwas) Speicher. Rudi hatte mich deswegen erst mal beruhigt, als ich diesbezüglich auch Bedenken geäußert hatte.

Aufsplitten in mehrere Files wäre denkbar, allerdings sollten es dann schon "signifikante Brocken" sein, und ob das die Übersichtlichkeit erhöht? (Ich "klaue" gern bei mir selbst, und dann ist es einfacher, die Einheitsfile zu durchsuchen).

Wegen valetudo: Die alte Implementierung war doch sowieso mehr oder weniger "kaputt", da sollten wir schlicht "nur noch neu" fahren (weil auch aus User-Sicht ein firmware-update dringend zu empfehlen ist, oder?).

[Reinhard.M]

Hallo Beta-User,
nach viel probieren und langem Suchen habe ich gerade festgestellt, dass die Template Files nur geladen werden wenn in der Datei das UNIX Zeilenende (LF) verwendet wird. Mit dem Windows (CR/LF) oder Mac (CR) Zeilenende werden die entsprechenden Dateien nicht geladen. Falls das kein Fehler ist wäre es sehr hilfreich wenn du es im ersten Post des Threads und im Wiki als Voraussetzung für die Erstellung von eigenen Template Files festhalten könntest.

Gruß Reinhard

[rudolfkoenig]

Mit dem Windows (CR/LF) oder Mac (CR) Zeilenende werden die entsprechenden Dateien nicht geladen.

Geladen werden sie, aber vmtl. nicht so verarbeitet, wie gewuenscht.

Nur aus Interesse: Wie kommt man zu "Mac"-Zeilenenden?

[Beta-User]

Falls das kein Fehler ist wäre es sehr hilfreich wenn du es im ersten Post des Threads und im Wiki als Voraussetzung für die Erstellung von eigenen Template Files festhalten könntest.

Danke für den Hinweis, hab's reingeknödelt...