Autor Thema: mqtt2.template: Contributing  (Gelesen 59563 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18703
Antw:mqtt2.template: Contributing
« Antwort #60 am: 20 November 2019, 07:03:18 »
Thx, ist eingecheckt.

Und: Willkommen im Forum @Zeppelin, starker Aufschlag ;D .


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

Server: HP-T620@Debian 11, 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

Offline Zeppelin

  • New Member
  • *
  • Beiträge: 4
Antw:mqtt2.template: Contributing
« Antwort #61 am: 23 November 2019, 10:44:07 »
Hallo Beta-User,

danke für das einchecken. Beim Test hat sich bei mir ergeben, dass ich einen Fehler erhalte, wenn die Zeile
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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18703
Antw:mqtt2.template: Contributing
« Antwort #62 am: 23 November 2019, 10:57:27 »
Es liegt am fehlenden "setter" in der setList. Ich bau's da noch ein, Danke für den Hinweis.
Server: HP-T620@Debian 11, 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

Offline Zeppelin

  • New Member
  • *
  • Beiträge: 4
Antw:mqtt2.template: Contributing
« Antwort #63 am: 23 November 2019, 12:12:27 »
Habe ich jetzt auch gesehen, da war ich etwas blind. Danke.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18703
Antw:mqtt2.template: Contributing
« Antwort #64 am: 25 November 2019, 13:41:31 »
(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
Server: HP-T620@Debian 11, 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

Offline Zeppelin

  • New Member
  • *
  • Beiträge: 4
Antw:mqtt2.template: Contributing
« Antwort #65 am: 29 November 2019, 20:28:00 »
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

Offline sledge

  • Sr. Member
  • ****
  • Beiträge: 549
  • Für den guten Zweck: www.rallye-for-a-cause.org
    • Abenteuer erleben und Menschen helfen!
Antw:mqtt2.template: Contributing
« Antwort #66 am: 30 November 2019, 18:55:42 »
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...

FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Offline Wuppi68

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2314
  • On the Highway to Shell
Antw:mqtt2.template: Contributing
« Antwort #67 am: 30 November 2019, 22:07:14 »
Habe auch noch eine Änderung ;-)

###########################################
# 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
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18703
Antw:mqtt2.template: Contributing
« Antwort #68 am: 01 Dezember 2019, 14:19:43 »
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...)
Server: HP-T620@Debian 11, 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

Offline Dersch

  • Sr. Member
  • ****
  • Beiträge: 534
Antw:mqtt2.template: Contributing
« Antwort #69 am: 19 Dezember 2019, 12:44:43 »
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


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18703
Antw:mqtt2.template: Contributing
« Antwort #70 am: 19 Dezember 2019, 12:53:43 »
...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!
Server: HP-T620@Debian 11, 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

Offline Dersch

  • Sr. Member
  • ****
  • Beiträge: 534
Antw:mqtt2.template: Contributing
« Antwort #71 am: 19 Dezember 2019, 13:52:06 »
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 :)

Offline Otto123

  • Tester
  • Hero Member
  • ****
  • Beiträge: 20952
  • schon mal restore trainiert?
    • Otto's Technik Blog
Antw:mqtt2.template: Contributing
« Antwort #72 am: 26 Dezember 2019, 19:26:39 »
Hi Beta-User,

im Beitrag #0 hat sich ein Fehler eingeschlichen:
Zitat
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? :
diff -u <original> <eure Kopie> > ~/mqtt2.template.<hinweis>.patch

Gruß Otto
Viele Grüße aus Leipzig
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18703
Antw:mqtt2.template: Contributing
« Antwort #73 am: 27 Dezember 2019, 11:42:35 »
Thx für die Hinweise, ist gefixt...
(Und auch das update zu devStateIcon aus dem anderen Post kommt bei nächster Gelegenheit  :) ).
Server: HP-T620@Debian 11, 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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18703
Antw:mqtt2.template: Contributing
« Antwort #74 am: 30 Dezember 2019, 16:58:34 »
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.
Server: HP-T620@Debian 11, 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

 

decade-submarginal