mqtt2.template: Contributing

Begonnen von Beta-User, 15 Dezember 2018, 11:45:40

Vorheriges Thema - Nächstes Thema

DasQ

#30
Ja eigentlich gehört Tasmota Pow (r2?) Template vorschlag ja auch hier reich
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Zitat von: DasQ am 15 Mai 2019, 16:07:14
Ja eigentlich gehört Tasmota Pow (r2?) Template vorschlag ja auch hier reich
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 :) .
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

DasQ

Zitat von: Beta-User am 14 Mai 2019, 07:32:12
Das relay in state schaltbar zu machen, hat den Vorteil, dass man on-for-timer etc. verwenden kann, macht es aber erforderlich, das devStateIcon mit Perl zusammenzubasteln. Außerdem sollte das online/offline-Symbol direkt zum WEB-IF führen, ohne dass extra die IP angezeigt wird; ich finde das eine elegante Lösung, die auch bei einigen anderen Devices so umgesetzt ist (die MiLight-Bridge, z.B.), ist aber natürlich Geschmackssache.


hab ich mir zu herzen genommen und noch den punkt klickbar gemacht schaus dir an. von mr aus ists ok
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

andies

Ich versuche gerade, eine Sonoff_B1 in MQTT2 einzubinden. Ich scheitere schon an elementaren Dingen. Zwar kann ich on-off einstellen, aber B1 hat auch Farbe und das geht nicht.

Bisher habe ich:
Internals:
   CFGFN     
   CID        DVES_86B762
   DEF        DVES_86B762
   DEVICETOPIC Sonoff_B1
   FUUID      5d1898ab-f33f-1115-3fa4-34d2a547e3cf09be
   IODev      Mosquitto
   LASTInputDev Mosquitto
   MSGCNT     80
   Mosquitto_MSGCNT 80
   Mosquitto_TIME 2019-06-30 14:53:50
   NAME       Sonoff_B1
   NR         19352
   STATE      off
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-06-30 14:50:07   CT              495
     2019-06-30 14:50:07   Channel_1       100
     2019-06-30 14:50:07   Channel_2       0
     2019-06-30 14:50:07   Channel_3       0
     2019-06-30 14:50:07   Channel_4       1
     2019-06-30 14:50:07   Channel_5       98
     2019-06-30 14:50:07   Color           FF000003FB
     2019-06-30 14:50:07   Dimmer          100
     2019-06-30 14:50:07   Fade            off
     2019-06-30 14:50:07   HSBColor        0,100,100
     2019-06-30 14:50:07   LedTable        off
     2019-06-30 14:50:07   LoadAvg         269
     2019-06-30 14:53:50   POWER1          off
     2019-06-30 14:32:12   SaveData        on
     2019-06-30 14:50:07   Scheme          0
     2019-06-30 14:32:12   SetOption26     on
     2019-06-30 14:50:07   Sleep           0
     2019-06-30 14:50:07   SleepMode       Dynamic
     2019-06-30 14:50:07   Speed           1
     2019-06-30 14:32:12   StateText1      off
     2019-06-30 14:32:12   StateText2      on
     2019-06-30 14:32:12   StateText3      toggle
     2019-06-30 14:32:12   StateText4      hold
     2019-06-30 14:50:07   Time            2019-06-30T14:50:06
     2019-06-30 14:50:07   Uptime          0T00:34:56
     2019-06-30 14:50:07   Vcc             3.374
     2019-06-30 14:50:07   Wifi_AP         1
     2019-06-30 14:50:07   Wifi_BSSId      F0:9F:C2:A7:4D:00
     2019-06-30 14:50:07   Wifi_Channel    1
     2019-06-30 14:50:07   Wifi_Downtime   0T00:00:04
     2019-06-30 14:50:07   Wifi_LinkCount  1
     2019-06-30 14:50:07   Wifi_RSSI       100
     2019-06-30 14:50:07   Wifi_SSId       WLAN-120954
     2019-06-30 14:53:49   state           set_off
Attributes:
   IODev      Mosquitto
   autocreate 0
   devStateIcon on:ios-on-green:off off:ios-off:on offline:ios_setoff_fill:
   group      Schalter
   model      A_01a_tasmota_basic_state_power1
   readingList tele/sonoff_b1/LWT:.* LWT
  tele/sonoff_b1/STATE:.* { json2nameValue($EVENT) }
  tele/sonoff_b1/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoff_b1/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoff_b1/RESULT:.* { json2nameValue($EVENT) }
   setList    off:noArg    cmnd/sonoff_b1/POWER1 0
  on:noArg     cmnd/sonoff_b1/POWER1 1
  toggle:noArg cmnd/sonoff_b1/POWER1 2
   setStateList on off toggle
   stateFormat POWER1

Nach der commandref schreibe ich den MQTT-topic dahinter
color:rgb /cmnd/sonoff_b1/color
Mir ist nur nicht klar, wie ich vorab ein Farbauswahlfeld erzeugen kann, so dass die Farbe aus dem Farbauswahlfeld dann in das MQTT-topic kommt. Ob meine MQTT-Syntax richtig ist, konnte ich auch nicht prüfen.

Das Attribut "setStateList" regelt nach der englischen commandref nur, dass zwischen Ausführung und Feedback unterschieden wird; da könnte also Color hinzugefügt werden.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Hmm, also vorab: da das vermutlich eine etwas längere Sache wird, bitte entweder einen neuen Thread anfangen und hier ggf. verlinken, oder häng' dich an einen der Threads zu Tasmota, die sich (auch) mit RGB-Devices befassen.

Du mußt den $EVENT (oder nachbearbeitete Teile davon) versenden. Es gibt auch schon mind. ein Tasmota-RGB-Template; das könntest du evtl. mal testen, ob das nicht ootb geht, ansonsten bitte mal die entsprechenden Templates durchsehen (gibt auch ein oder 2 Shelly-templates in der File).

(Und laß Color aus der setStateList raus; da gehören nur Dinge rein, die mit on und off zu tun haben).
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

andies

läuft:

ttributes:
   IODev      Mosquitto
   autocreate 0
   devStateIcon on:ios-on-green:off off:ios-off:on offline:ios_setoff_fill:
   group      Schalter
   model      A_01a_tasmota_basic_state_power1
   readingList tele/sonoff_b1/LWT:.* LWT
  tele/sonoff_b1/STATE:.* { json2nameValue($EVENT) }
  tele/sonoff_b1/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoff_b1/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoff_b1/RESULT:.* { json2nameValue($EVENT) }
   setList    off:noArg    cmnd/sonoff_b1/POWER1 0
  on:noArg     cmnd/sonoff_b1/POWER1 1
  toggle:noArg cmnd/sonoff_b1/POWER1 2
  rgb:colorpicker,RGB cmnd/sonoff_b1/COLOR
   setStateList on off toggle
   stateFormat POWER1
   userReadings rgb {ReadingsVal($name,'Color','0')}
   webCmd     on:off:rgb



Gesendet von iPad mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zitat von: andies am 30 Juni 2019, 16:16:51
läuft:
Bin nicht sicher, ob da ein neues template Sinn macht. M.E. müßte A_05a_tasmota_rgb_led_controller auch zu diesem Device passen? Das bietet noch einen Dimmer. Geht das hier nicht?

Ansonsten: userReadings ohne Trigger kommen mir nicht mehr in die templates :) . Welchen Zweck verfolgt das Umpacken?
Wenn es sein muß, sollte die Langform von json2nameValue($EVENT,'',$JSONMAP) genutzt werden und ein passendes JSONMAP-Attribut, das Color nach rgb mappt ;) .
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

andies

OK, dann probiere ich das template mal aus. Bin nicht vor ort, aber auf FHEMWeb sieht das erstmal gut aus.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

mahowi

Ich habe mal den Bewegungsmelder von Osram (Lightify bzw. Smart+) und den Temperatur-/Luftfeuchte-Sensor ohne Luftdruck von Xiaomi ergänzt:

Index: mqtt2.template
===================================================================
--- mqtt2.template (Revision 20188)
+++ mqtt2.template (Arbeitskopie)
@@ -378,7 +378,26 @@
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE model L_14_aqara_cube

+# Osram Lightify, Smart+ Motion Sensor
+name:L_15_zigbee2mqtt_osram_motion_sensor
+desc: Osram motion sensor via zigbee2mqtt <br>Tested with: Osram Lightify Motion Sensor
+filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
+par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
+par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
+attr DEVICE stateFormat Motion: occupancy T: temperature
+attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
+deletereading -q DEVICE (?!associatedWith).*
+attr DEVICE model L_15_osram_motion_sensor

+name:L_16_zigbee2mqtt_TempHumSensor
+desc: Temp/hum sensor via zigbee2mqtt <br>Tested with: Xiaomi MiJia WSDCGQ01LM Temperature Humidity Sensor
+filter:TYPE=MQTT2_DEVICE:FILTER=CID=zigbee.*
+par:BASE_TOPIC;base topic as set in configuration.yaml of the zigbee2mqtt bridge in the topics;{ AttrVal("DEVICE","readingList","") =~ m,([^/]+)[/].*:, ? $1 : undef }
+par:DEV_ID;name of the device in the zigbee2mqtt bridge;{ AttrVal("DEVICE","readingList","") =~ m,[^/]+[/]([^/]+).*:, ? $1 : undef }
+attr DEVICE stateFormat T: temperature H: humidity
+attr DEVICE readingList BASE_TOPIC/DEV_ID:.* { json2nameValue($EVENT) }
+deletereading -q DEVICE (?!associatedWith).*
+attr DEVICE model L_16_TempHumSensor

###########################################
# TASMOTA
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Beta-User

Thx, hab's eben eingecheckt, allerdings etwas anders einsortiert (sind eigentlich nahe Verwandte von bestehenden Devices) und benannt (die Namen sind eher funktions-/reading-Typ-bezogen, und eher nicht herstellerspezifisch).
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

mahowi

Ich wollte nicht alles neu nummerieren.  ;)

Ist die Nummerierung eigentlich notwendig? Ohne wäre es einfacher, Devices mittendrin hinzuzufügen.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Beta-User

"Notwendig" nicht, aber die Sortierung, wie man es bei "?" angezeigt bekommt, richtet sich nicht nach "order of appearance" in der file, sondern alphanummerisch nach den Namen.
Es ist daher für die user mMn. einfacher, wenn Dinge, die ähnlich sind, auch nahe beieinander auftauchen (es gab dazu mal einen Thread (-teil), in dem ich das versucht hatte, vorab mal zur Diskussion zu stellen, auch, was die Einordnung der ersten templates in ein späteres, viel größeres Gesamtbild anging, ich weiß nur nicht mehr wo... Mit der Filter-Option, die Rudi dann dankenswerterweise später irgendwann mal eingebaut hat, ist das mit der Übersichtlichkeit aber sowieso etwas entschärft).

Das mit "dazwischen" geht ja, man muß dann halt mit den "Indexbuchstaben" etwas tricksen, dass das am Ende paßt ;) .
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

rudolfkoenig

Zitat"Notwendig" nicht, aber die Sortierung, wie man es bei "?" angezeigt bekommt, richtet sich nicht nach "order of appearance" in der file, sondern alphanummerisch nach den Namen.
Das kann (auf Wunsch) aber leicht geaendert werden.
Ich denke auch ueber eine bessere Hilfe nach (neben attrTemplate ?), bisher noch ohne Ergebnis :)

Beta-User

Moin Rudi,

(die Antwort gehört eigentlich nach https://forum.fhem.de/index.php/topic,93370.0.html, aber da kann ich nicht antworten...? Oder gibt es einen allg. Thread zu dem Thema, damit auch andere (potentiell) "Betroffene" was dazu sagen könnten?)

Bzgl. des Sortierens: Danke für's Angebot. Auf "order of appearance" umzustellen, fände ich spontan nicht zielführend, weil dann "externe" templates nicht mehr "richtig" einsortiert würden (Bsp. ebusd.template, zukünftig evtl. Sprachsteuerungs-add-ins usw.).
Andererseits wäre es vermutlich für die Anwender "angenehmer", wenn nicht erst der Kenner für die Sortierung in den Namen gecoded wäre.

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)? Also erst alles anzeigen, was ausdrücklich sortiert werden soll, dann die ohne "sort" (dann gerne nach "order of appearance"? Dann könnte man auch die Namen wieder vereinfachen, was aber Nacharbeitsbedarf bei der Doku nach sich zieht).
Hätte allerdings den (großen?) Vorteil, dass man es nachträglich noch ändern könnte, ohne dass die User das wissen müßten, und notfalls halt immer längere Subindizes verwenden könnte, wenn irgendwas neues um's Eck kommt.

Zur Hilfe fällt mir spontan leider nichchts ein, wenn ja, melde ich mich. Einfach nur ein "help" "help <devspec>" einzuführen, das dann ggf. nur den Hinweistext zum aktuellen/den ausgewählten templates anzeigt bzw. einen allgemeinen Hilfetext zu attrTemplate, wenn kein model gesetzt ist, hilft vermutlich nicht wirklich?
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

KölnSolar

Nur die Ankündigung, dass die Entwicklung eines neuen templates für Ecovacs Deebot Saugroboter, die mqtt sprechen, hier stattfindet .

Als Bezeichnung hab ich mir B_01_deebot_bridge vorgestellt. Diskussion kann im Entwicklungsthread geführt werden.

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt