Autor Thema: Folgende Frage zu Sonoff/Tasmota und MQTT2_Device  (Gelesen 18601 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10870
  • eigentlich eher "user" wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #90 am: 23 Dezember 2018, 12:10:07 »
Jein: SetExtensions (on-for-timer, etc) ist noch nicht Grossbuchstaben-Faehig, ist aber auf der TODO Liste.
Hmmm, da (jedefalls afaik) das aber vom Device ja nicht zurückgemeldet wird, dürfte das keine praktische Auswirkung haben, oder? Habe es daher mal in dem test-4ch rausgenommen.
Wenn es für den Rest raus soll/kann, bitte um ein Signal.

Neu: falls man das associatedWith Reading setzt
Thx :) . Das setreading kommt dann in der nächsten Iteration von mqtt2.template für alle mehrkanaligen incl. Shelly.

Vielleicht überlege ich mir sowas in die Richtung auch für MYSENSORS_DEVICE, um einzelne Kanäle/Readings als eigenes Device direkt zu befüllen, das klingt insgesamt nach einer schlanken und eleganten Lösung :) . Der Mechanismus an sich ist ja nicht MQTT2-spezifisch, oder?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #91 am: 23 Dezember 2018, 15:12:55 »
- Auch wenn es klare Präferenzen gibt, würde ich für die mehrkanaligen auch unified-templates anbieten. Mind. in bestimmten Situationen (wie der ROLLO-Verwendung) braucht man keine separaten Devices pro Kanal. Dann wird es vermutlich wieder Leute geben, die sowas vermissen... Kann aber gerne einen Hinweis aufnehmen, dass man lieber die split-Variante nehmen sollte.
Die Reihenfolge (split/unified) drehe ich bei Gelegenheit.

Naja gerade für Rollos ist das doch egal. Da braucht man ja eh noch was zusätzliches um hoch runter etc. von den Relays zu entkopplen. Wie z. B. das rollo-Modul. Das wäre jetzt kein Grund für mich unified templates anzubieten. Wenn rename etc. durch die neuen Anpassungen kein Problem mehr sind, könnte man das schon als Standard verwenden (wenn auch nicht ich ;-) )

Was ich mir überlegt habe um das ganze sauber zu trennen, ein Gerät anzulegen mit allen Readings und setList für die Steuerung aller vorhandenen Kanäle (0, 1, 2, 4 und 8 Kanäle), aber keine weiteren Elemente für die Oberfläche außer vielleicht restart. Perfekt wäre hier wenn FHEM/MQTT2_SERVER die setList entsprechend der POWER, POWER1, ... im STATE selber aufbaut (per  autocreate?). Dann müsste man hier gar nichts tun!  Ein Gerät liefert im STATE nur die tatsächlich vorhandenen Kanäle mit.

Dann die Oberfläche/Steuerung in ein extra Gerät, egal ob man das dann getrennt für die POWER oder Sensor-Daten haben will oder nicht. Das muss dann ja kein MQTT2_DEVICE mehr sein, Also generell die Oberfläche zur Steuerung zu trennen. Dann wäre das einheitlich und sauber abstrahiert. Das hat mich schon bei ZWAVE immer genervt. Das betrifft ja nicht nur MQTT. Aktuell könnte man das über das Basisgerät als MQTT2_DEVICE machen und die anderen Kanäle als DOIF. Dann gibt es auch das Problem mit den mehrfachen readings nicht, ohne sich dabei irgendwie zu verrenken. Warum muss für die weiteren Kanäle überhaupt ein weiteres MQTT2_DEVICE angelegt werden?

Gibt es aktuell andere Möglichkeiten wenn man einen Button drückt in der Oberlfäche ein Event auszulösen? Außer DOIF?

Das ließe sich auch so über die templates anlegen. Also Basisgerät + Elemente für  verschiedene Gerätekonfigurationen. Die Elemente dann als DOIF (oder was anderes was für sowas gedacht ist?). Dann wäre das Basisgerät immer gleich und die Oberfläche könnte als unified oder gesplittet (oder eben nur in der gesplitteten Version) angeboten werden. Für eine Steuerung würde das Basisgerät immer reichen, weil Readings kann ich auslesen und set funktioniert auch. halt wieder über p1 on etc. Da es nicht in der Oberfläche erscheint, wäre die volle Auschreibung auch kein Problem.

Habe mal auf Basis von A_04b_tasmota_4ch_unified_test ein wenig rumgebastelt. Wäre das als Basis für ein überarbeitetes unified-template passend?
defmod tasmota_test MQTT2_DEVICE DVES_9B01BD
attr tasmota_test IODev MQTT2_FHEM_Server
attr tasmota_test autocreate 0
attr tasmota_test readingList tele/sonoffkitchen/LWT:.* LWT\
  tele/sonoffkitchen/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/sonoffkitchen/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/sonoffkitchen/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/sonoffkitchen/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr tasmota_test room MQTT2_DEVICE
attr tasmota_test setList POWER1:on,off,toggle cmnd/sonoffkitchen/POWER1 $EVTPART1\
  POWER2:on,off,toggle cmnd/sonoffkitchen/POWER2 $EVTPART1\
  POWER3:on,off,toggle cmnd/sonoffkitchen/POWER3 $EVTPART1\
  POWER4:on,off,toggle cmnd/sonoffkitchen/POWER4 $EVTPART1
attr tasmota_test setStateList on off toggle
attr tasmota_test stateFormat P1: POWER1 P2: POWER2 P3: POWER3 P4: POWER4
attr tasmota_test webCmd POWER1 toggle:POWER2 toggle:POWER3 toggle:POWER4 toggle

Ja ich denke das ist universell und sollte dann für jeden funktionieren.

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #92 am: 23 Dezember 2018, 15:55:44 »
Der Befehl zum neu starten heißt restart nicht reboot. Bitte in Template ändern.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10870
  • eigentlich eher "user" wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #93 am: 23 Dezember 2018, 16:45:02 »
Der Befehl zum neu starten heißt restart nicht reboot. Bitte in Template ändern.
Done.

Zum "Oberflächen"-Thema mag ich nichts sagen, aber dafür ein ultrakompliziertes extra-Device (egal mit welchem weiteren Modul) zu bauen, ist definitiv nicht mein Ding (und nein, wir vertiefen hier nicht die pros und cons bestimmter Module!).

Das unified-Test in der abgewandelten Form ist bereits eingecheckt und nutzt auch das "set" für die einzelnen Kanäle. (Was mir nicht klar ist: warum nicht set_on etc.? Dafür gibt's sogar Icons... Ist aber im Prinzip unwichtig, wichtiger war, dass nicht alles über state läuft. DANKE!).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #94 am: 23 Dezember 2018, 18:29:53 »
Zum "Oberflächen"-Thema mag ich nichts sagen, aber dafür ein ultrakompliziertes extra-Device (egal mit welchem weiteren Modul) zu bauen, ist definitiv nicht mein Ding (und nein, wir vertiefen hier nicht die pros und cons bestimmter Module!).
Ok bringen wir die Standardtemplates zu einem guten Stand und gut ist.

Würde aber in dem Zusammenhang allgemein für die öffentlichen Templates (unified mit 2 und mehr Kanäle und mit Bewegungsmelder) die Textvariante der Icon-Variante vorziehen, da allgemeingültig und keine Probleme wenn kein FHEMWeb. Also wie bei 4channel unified test. Das ist einfacher und übersichtlicher.

setStateList sollte auch überall benutzt werden.

im Code ist aber jetzt wohl ein Fehler. Die Variante mit POWER fehlt. Dafür ist bei der Variante mit POWER1 die setList doppelt. Einmal mit POWER1 und einmal mit POWER. Vermute da fehlen ein paar Zeilen. Siehe Zeile 143 und 158.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22533
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #95 am: 23 Dezember 2018, 18:44:50 »
Zitat
Hmmm, da (jedefalls afaik) das aber vom Device ja nicht zurückgemeldet wird, dürfte das keine praktische Auswirkung haben, oder?
Doch, die Geraete koennen kein on-for-timer, etc ausfuehren.
Ich habe aber jetzt SetExtensions ON/OFF faehig gemacht.

Zitat
Perfekt wäre hier wenn FHEM/MQTT2_SERVER die setList entsprechend der POWER, POWER1, ... im STATE selber aufbaut (per autocreate?).
Verstehe ich nicht ganz und ich rate: wenn POWER2 eintrifft und noch kein stateFormat gesetzt ist, dann soll stateFormat automatisch gesetzt werden auf POWER1 POWER2. Wenn ja: das waere mir zu viel Magie und bin fuer eine Loesung mit Template.

Zitat
Warum muss für die weiteren Kanäle überhaupt ein weiteres MQTT2_DEVICE angelegt werden?
Damit man jeden Kanal darstellen und individuell steuern kann. Und da es ein MQTT2_DEVICE ist, liegt es nahe, es mit einem MQTT2_DEVICE zu machen, und nicht ueber ein dummy+notify Konstrukt.

Zitat
Gibt es aktuell andere Möglichkeiten wenn man einen Button drückt in der Oberlfäche ein Event auszulösen? Außer DOIF?
DOIF kenne ich nicht :). Natuerlich kann man sowas mit dummy und mehreren notifies bauen. Ist halt kompliziert, fehleranfaellig und mAn nicht logisch, aber wenn jemand das unbedingt so haben will: bitte. Aber bitte diese Loesung nicht als "Die Richtige" bewerben.

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #96 am: 23 Dezember 2018, 20:45:18 »
Verstehe ich nicht ganz und ich rate: wenn POWER2 eintrifft und noch kein stateFormat gesetzt ist, dann soll stateFormat automatisch gesetzt werden auf POWER1 POWER2. Wenn ja: das waere mir zu viel Magie und bin fuer eine Loesung mit Template.

Nein bloß nicht stateFormat anpassen. Ich dachte da an setList, ohne setList kann man die Kanäle ja nicht setzen. Ist aber nichts wichtiges, war nur so eine Idee. Die readingList wird ja auch automatisch gefüllt per autocreate.

Damit man jeden Kanal darstellen und individuell steuern kann. Und da es ein MQTT2_DEVICE ist, liegt es nahe, es mit einem MQTT2_DEVICE zu machen, und nicht ueber ein dummy+notify Konstrukt.
DOIF kenne ich nicht :). Natuerlich kann man sowas mit dummy und mehreren notifies bauen. Ist halt kompliziert, fehleranfaellig und mAn nicht logisch, aber wenn jemand das unbedingt so haben will: bitte. Aber bitte diese Loesung nicht als "Die Richtige" bewerben.

Seit es DOIF gibt verwende ich keine notifies mehr. notify ist für mich perl (oder FHEM?) Voodoo, das ist nix für einen altgedienten C++ Programmierer ;-)

Und ja mir ist klar dass ich mich zur Zeit etwas auf Abwegen befinde. Für mich sind aber jetzt erstmal alle MQTT-Dinge abgehakt. Werde noch helfen bei den Templates, dann ist von mir erstmal wieder Ruhe ;-)

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 3589
  • Online
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #97 am: 24 Dezember 2018, 11:55:59 »
Ich sehe es eigentlich genauso, wie @osr
Ich nutze aktuell auch nur noch DOIF, das ist relativ einfach zu gestalten mit etwas Einarbeitung...
Auch was setList betrifft bin ich da bei ihm, denn ohne die geht ja nichts... statFormat kann man dann ja selber anpassen bei Bedarf...
MQTT Device habe ich auch keines mehr, alles umgestellt auf MQTT2...

Kann aktuell erst mal nichts testen da über Weihnachten nicht zuhause, ansonsten bin ich gerne bereit die template Dinge auszuprobieren
Intel-NUC i3: FHEM-Server 5.9 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #98 am: 24 Dezember 2018, 14:04:24 »
aktuelle Version der Templates für tasmota sieht für mich soweit gut aus.

Habe noch etwas gefunden um stateFormat recht einfach schaltbar zu machen. Wird dann aber wohl auch wieder nur mit fhemweb laufen, da eine URL aufgerufen wird?

Code getestet:

{
"<div><a href=\"/fhem?cmd.dummy=set%20sonoffAussenKB%20p1%20toggle&XHR=1\">"
. FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))
. "</a> <a href=\"/fhem?cmd.dummy=set%20sonoffAussenKB%20p2%20toggle&XHR=1\">"
. FW_makeImage(lc ReadingsVal($name, "POWER2", "off")) . "</a></div>"
}

müsste dann so auch wieder mit plain text gehen (code nicht getestet):
{
"<div><a href=\"/fhem?cmd.dummy=set%20sonoffAussenKB%20p1%20toggle&XHR=1\">"
. ReadingsVal($name, "POWER1", "off")
. "</a> <a href=\"/fhem?cmd.dummy=set%20sonoffAussenKB%20p2%20toggle&XHR=1\">"
. ReadingsVal($name, "POWER2", "off") . "</a></div>"
}

sonoffAussenKB wäre dann im template wieder DEVICE

Damit habe ich eigentlich alle meine offenen Punkte gelöst. Nur das automatische Anlegen der setlist wäre noch spitze. Vielleicht schaue ich mir das im neuen Jahr mal an, aber Perl ist für mich sehr ungewohnt.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10870
  • eigentlich eher "user" wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #99 am: 24 Dezember 2018, 14:26:35 »
aktuelle Version der Templates für tasmota sieht für mich soweit gut aus.
Du sprichst bereits von Version 18047 von heute Mittag, oder?

Zu dem Code von 14:04: Wo kommt das cmd.dummy her? Das sieht mir danach aus, als würde man ein zusätzliches device benötigen, oder verstehe ich da was nicht?

Die nachfolgenden Anmerkungen bezogen sich auf die in 18047 enthaltenen Änderungen:
Würde aber in dem Zusammenhang allgemein für die öffentlichen Templates (unified mit 2 und mehr Kanäle und mit Bewegungsmelder) die Textvariante der Icon-Variante vorziehen, da allgemeingültig und keine Probleme wenn kein FHEMWeb. Also wie bei 4channel unified test. Das ist einfacher und übersichtlicher.
Müßte jetzt passen, die Icon-Variante habe ich aber drin gelassen und die Namen wieder mal angepaßt.

Zitat
setStateList sollte auch überall benutzt werden.
Also sollte in die Basistemplates das folgende rein, oder?
attr DEVICE setStateList on off toggle
Zitat
im Code ist aber jetzt wohl ein Fehler. Die Variante mit POWER fehlt. Dafür ist bei der Variante mit POWER1 die setList doppelt. Einmal mit POWER1 und einmal mit POWER. Vermute da fehlen ein paar Zeilen. Siehe Zeile 143 und 158.
Thx, da hat sich unbeabsichtigt was verschoben...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #100 am: 24 Dezember 2018, 14:48:05 »
Du sprichst bereits von Version 18047 von heute Mittag, oder?
ja aus dem repository

Zu dem Code von 14:04: Wo kommt das cmd.dummy her? Das sieht mir danach aus, als würde man ein zusätzliches device benötigen, oder verstehe ich da was nicht?
da verstehst du glaube ich was falsch ;-). Über den Aufruf, zusammen mit XHR kann man einfach per URL Befehle an fhem übersenden. Das nutze ich schon ewig. Habe mir z. B. ein paar NFC Chips gemacht, da kann ich nur das Handy dranhalten und muss noch das Passwort bestätigen und der Schaltvorgang wird ausgelöst. Echt praktische Sache. So wie ich das von 2015 kenne ist das Standard (vermutlich fhemweb?).

Habe nochmal eine verbesserte Version, damit muss das Gerät nicht angegeben werden sondern kommt per $name. Das escapen mit %20 von Leerzeichen ist zudem wohl nicht notwendig:
{
"<div><a href=\"/fhem?cmd.dummy=set ".$name." p1 toggle&XHR=1\">Schopf:"
. FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))
. "</a> <a href=\"/fhem?cmd.dummy=set ".$name." p2 toggle&XHR=1\">Weg:"
. FW_makeImage(lc ReadingsVal($name, "POWER2", "off")) . "</a></div>"
}
Damit habe ich dann das webCmd auch bei mir entfernt. Wäre höchstens die Frage ob da jeder drauf kommt dass man da draufklicken kann und es ok ist webCmd wegzulassen?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10870
  • eigentlich eher "user" wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #101 am: 24 Dezember 2018, 15:09:30 »
Ah, Danke für die Erläuterung. Die allgemeingültige Variante (statt Schopf und Weg) sähe dann so aus, oder?
# tasmota 4ch as one FHEM device.
name:A_04b_tasmota_4ch_unified_icon
filter:TYPE=MQTT2_DEVICE
desc:Configures a single device including all readings <br>NOTE: Clicking on icons will issue a corresponding toggle command
set DEVICE attrTemplate A_01a_tasmota_basic_state_power1
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
attr DEVICE setList \
  p1:on,off,toggle cmnd/DEVNAME/POWER1 $EVTPART1\
  p2:on,off,toggle cmnd/DEVNAME/POWER2 $EVTPART1\
  p3:on,off,toggle cmnd/DEVNAME/POWER3 $EVTPART1\
  p4:on,off,toggle cmnd/DEVNAME/POWER4 $EVTPART1
attr DEVICE stateFormat {\
    "<div><a href=\"/fhem?cmd.dummy=set ".$name." p1 toggle&XHR=1\">POWER1:"\
    . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
    . "</a> <a href=\"/fhem?cmd.dummy=set ".$name." p2 toggle&XHR=1\">POWER2:"\
    . FW_makeImage(lc ReadingsVal($name, "POWER2", "off")) . "</a></div>"\
    . "</a> <a href=\"/fhem?cmd.dummy=set ".$name." p3 toggle&XHR=1\">POWER3:"\
    . FW_makeImage(lc ReadingsVal($name, "POWER3", "off")) . "</a></div>"\
    . "</a> <a href=\"/fhem?cmd.dummy=set ".$name." p4 toggle&XHR=1\">POWER4:"\
    . FW_makeImage(lc ReadingsVal($name, "POWER4", "off")) . "</a></div>"\
    }
attr DEVICE model A_04b_tasmota_4ch_unified_icon
Checke ich dann demnächst so ein, wenn keine Korrektur mehr kommt.

Danke für den Input :) !
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline osr

  • Jr. Member
  • **
  • Beiträge: 72
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #102 am: 24 Dezember 2018, 21:51:48 »
Ah, Danke für die Erläuterung. Die allgemeingültige Variante (statt Schopf und Weg) sähe dann so aus, oder?
....

Ja genau. Am besten dann auch für das Kombigerät mit Bewegungsmelder und Temperatur Sensor SI...

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22533
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #103 am: 26 Dezember 2018, 11:59:42 »
Zitat
Habe noch etwas gefunden um stateFormat recht einfach schaltbar zu machen. Wird dann aber wohl auch wieder nur mit fhemweb laufen, da eine URL aufgerufen wird?
Ja, und viele (Benutzer von telnet, FileLog/DbLog, iOS/Android Apps) werden euch verfluchen :)

Was spricht gegen devStateIcon mit einem perl Ausdruck, im commandref unter "Second form:" dokumentiert?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 10870
  • eigentlich eher "user" wie "developer"
Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
« Antwort #104 am: 26 Dezember 2018, 12:43:17 »
Was spricht gegen devStateIcon mit einem perl Ausdruck, im commandref unter "Second form:" dokumentiert?
Kurzform für FHEMWEB-Nutzer, um die Flucher aus den genannten Fraktionen zu besänftigen:
Derselbe code im devStateIcon statt im stateFormat wäre ok?

Dann "parke ich das gerne um"...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

 

decade-submarginal