mqtt2.template: Contributing

[Beta-User]

Thx, ist eingecheckt.

Und: Willkommen im Forum @Zeppelin, starker Aufschlag .


on-for-timer bei Tasmota habe ich bei der Gelegenheit auf SetExtensions zurückgestellt und den betreffenden Kommentar erweitert...

[Zeppelin]

Hallo Beta-User,

danke für das einchecken. Beim Test hat sich bei mir ergeben, dass ich einen Fehler erhalte, wenn die Zeile

Code Auswählen Erweitern

set DEVICE x_mqttcom announce

aktiv ist.
Sobald ich diese auskommentiere funktioniert alles. Ich habe die Zeile von den anderen Tamplates nur übernommen. Eventuell liegt es auch an meiner Installation.
Wäre super, wenn sich das ein andere auch noch mal anschauen könnte.

[Beta-User]

Es liegt am fehlenden "setter" in der setList. Ich bau's da noch ein, Danke für den Hinweis.

[Zeppelin]

Habe ich jetzt auch gesehen, da war ich etwas blind. Danke.

[Beta-User]

(Ist zwar hier OT, aber um sicherzugehen, dass @Zeppelin das sieht; das shellydimmer-template hat Klärungsbedarf verursacht, was pct/brightness angeht):
https://forum.fhem.de/index.php/topic,94494.msg996478.html#msg996478

[Zeppelin]

Hallo Beta-User,

mit der Brightness bin ich bis jetzt beim Shelly-Dimmer auch noch nicht zu Frieden. Diese bleibt leider immer auf den letzten gedimmten Wert stehen, wenn man den Dimmer ausschaltet. Normalerweise geht man davon aus, dass Dimmer aus auch brightness/pct 0 bedeutet. Pct ist aus meiner Sicht hier auch die bessere Einheit, da ja wie bereits erwähnt der Wert von 0 bis 100 geht.
Das Mapping habe ich getestet und es funktioniert.

Gruß
Zeppelin

[sledge]

Bezüglich pct / brightness just my 2 cents:

Das machen viele Lampenhersteller unterschiedlich - wenn eine Normierung dessn innerhalb FHEM angestrebt wird, geht das vermmutlich in eine ähnliche Richtung wie seinerzeit beim Battery (+ Derivate) Reading... Meines Wissens ist diese Normierung auch auf halbem Wege stecken geblieben.

Ich habe hir Lampen, die anstelle von "ct" zum Beispiel "cct" als Reading und Setter haben, dito mit pct und brightness. Bei den Yeelights zB heißt das entsprechende Reading "bright", geht von 0-100 und bleibt beim "off" der Lampe ebenfalls unverändert.

Daher die Frage: Muss / soll sowas in den templates geändert werden oder wie wollen wir das künftig handhaben? Generell fände ich eine übergreifend stimmige Nomeklatur mit entsprechender Definition sehr sinnvoll...

[Wuppi68]

Habe auch noch eine Änderung

Code Auswählen Erweitern

###########################################
# zigbee2mqtt
# The zigbee2mqtt bridge device (entire hex id of devices as bridgeRegexp)
name:zigbee2mqtt_bridge
desc:The zigbee2mqtt bridge device
filter:TYPE=MQTT2_DEVICE
order:L_01
par:BASE_TOPIC;base topic set in configuration.yaml of the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[\b]?([^/:]+)[/].*:, ? $1 : undef }
attr DEVICE bridgeRegexp\
BASE_TOPIC/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"
attr DEVICE getList\
  devicelist:noArg log BASE_TOPIC/bridge/config/devices\
  networkmap_raw:noArg raw BASE_TOPIC/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz BASE_TOPIC/bridge/networkmap graphviz
attr DEVICE readingList\
  BASE_TOPIC/bridge/state:.* state\
  BASE_TOPIC/bridge/config/devices:.* {}\
  BASE_TOPIC/bridge/config/log_level:.* log_level\
  BASE_TOPIC/bridge/config/permit_join:.* permit_join\
  BASE_TOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  BASE_TOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
  BASE_TOPIC/bridge/log:.* log\
  BASE_TOPIC/bridge/networkmap:.* {}\
  BASE_TOPIC/bridge/networkmap/graphviz:.* graphviz\
  BASE_TOPIC/bridge/networkmap/raw:.* raw\
  BASE_TOPIC/bridge/config:.* { json2nameValue($EVENT) }
attr DEVICE setList\
  log_level:debug,info,warn,error BASE_TOPIC/bridge/config/log_level $EVTPART1\
  permit_join:true,false BASE_TOPIC/bridge/config/permit_join $EVTPART1\
  remove:textField BASE_TOPIC/bridge/config/remove $EVTPART1\
  y_device_setting:textField BASE_TOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
  x_bind:textField BASE_TOPIC/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField BASE_TOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField BASE_TOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField BASE_TOPIC/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField BASE_TOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField BASE_TOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField BASE_TOPIC/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField BASE_TOPIC/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField BASE_TOPIC/bridge/config/elapsed $EVTPART1\
  z_last_seen:disable,ISO_8601,epoch,ISO_8601_local BASE_TOPIC/bridge/config/last_seen $EVTPART1\
  z_ban:textField BASE_TOPIC/bridge/config/ban $EVTPART1\
  z_rename:textField BASE_TOPIC/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg BASE_TOPIC/bridge/config/reset
attr DEVICE setStateList on off
attr DEVICE model zigbee2mqtt_bridge
# Based on https://forum.fhem.de/index.php/topic,94060.msg872371.html#msg872371

der SETter für LastSeen

[Beta-User]

Leute, ihr seid praktisch alle hier OT, aber:

- LastSeen ist geändert
- bei den Shellys habe ich (hoffentlich bei allen relevanten+korrekt) JSONMAP eingebaut, dass der 0-100-Wertebereich als Reading pct läuft.
(Sofern ich das nicht zwischendurch vergesse), gedenke ich, das bei mqtt2-attrTemplate weiter so zu halten, so dass es jedenfalls in diesem Modul durchgängig bleibt; für andere Module muß das der jeweilige Autor entscheiden, wie bei battery.* wird/kann es da Gründe für und gegen die "Einheitlichkeit" geben....

Was das "0"-Stellen angeht, halte ich das nicht für zweifelsfrei, bei off auch "0" anzuzeigen: Zum einen wird das device vermutlich den letzten Dimm-Wert annehmen, wenn man on schaltet (also ist der Wert weiter interessant), und zum anderen kann man das beim devStateIcon noch "verwursten" bzw. hat darüber eine Visualisierung.
MMn. also "no action required"... (Aber bitte: Das ist meine persönliche Meinung, wenn sich eine Mehrheit dafür findet und jemand, der Code/patches liefert...: Ich bin nur der, der es einpflegt. Letztlich entscheiden darf es die community).

(Und bitte weitere Diskussion zu pct etc. in dem Shelly-Thread, den Link und die Sachstandsddarstellung habe ich ja nicht ganz ohne Hintergedanken da reingenommen...)

[Dersch]

Ich hätte den Vorschlag das als Template mit aufzunehmen.

https://github.com/weetmuts/wmbusmeters

Gerne teste ich ausgiebig, richte die Tage das für einen orts entfernten iperl Wasserzähler ein. Das JSON wird dann in mein MQTT zuhause gespült.

Grüße Dirk

[Beta-User]

...ich muß wohl meinen Einleitungstext nochmal ergänzen...

Gemeint ist: hier in diesem Thread soll es um fertige Template-Vorschläge gehen, die ich (mehr oder weniger) "einfach so" übernehmen kann.

Das mit dem WMBUSMETER mache ich gerne, es ist aber eher eine Anregung und gehört daher in den anderen (bugs, Fragen usw.) Thread....

Vorgehen im Allgemeinen:
- RAW-Definition von dem, was du hast in einen komplett neuen Thread im MQTT-Bereich packen (das sieht auf den ersten Blick so aus, als müßte man da irgendwie Daten nachbearbeiten, für einfache Devices kann man das direkt im "Fragen"-Thread machen);
- Da (wenn vorhanden) noch etwas mehr Hintergrundinfo verlinken, insbesondere zur MQTT-Topic (und ggf. JSON/Payload-) Struktur
- Einen Link in "Fragen"-Thread dahin legen, sollte ich das nicht nach einer gewissen Zeit sowieso gesehen haben...

Danke!

[Dersch]

Ah ok, dann war ich zu vorschnell. Ich kann mich am Wochenende mal mit der Template Erstellung einlesen. Dann sollte das Beispiel auch schon laufen zum testen. Vielleicht ist es ja gar nicht so schwer wie ich grade danke

[Otto123]

Hi Beta-User,

im Beitrag #0 hat sich ein Fehler eingeschlichen:

Vorschläge möglichst als diff
Ist alles fertig, könnt ihr eine Kopie dr vorhandenen mqtt2.template-Datei anlegen, und euer template in die bisherge einfügen. Ein diff -u <original> <eure Kopie> ~/mqtt2.template.<hinweis>.patch ausführen, dann liegt im home-Verzeichnis eures users die neue Datei, die ihr nach Durchsicht dann hier anfügen könnt.

abgesehen vom "der ... bisherige" ist die Befehlszeile unvollständig - oder? :

Code Auswählen Erweitern

diff -u <original> <eure Kopie> > ~/mqtt2.template.<hinweis>.patch

Gruß Otto

[Beta-User]

Thx für die Hinweise, ist gefixt...
(Und auch das update zu devStateIcon aus dem anderen Post kommt bei nächster Gelegenheit  ).

[Beta-User]

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 [...] das jsonMap POWER1:state zu verwenden [...]

Zur Info, damit eventuelle Mitleser aus diesem Thread hier das auch mitbekommen:

Es gibt hier eine Fassung mit (fast) kompletter jsonMap-Nutzung @Tasmota und der Bitte um Test und Rückmeldung dort.