Folgende Frage zu Sonoff/Tasmota und MQTT2_Device

Begonnen von moonsorrox, 13 Dezember 2018, 16:27:05

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: rudolfkoenig am 22 Dezember 2018, 19:04:21
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.

Zitat von: rudolfkoenig am 22 Dezember 2018, 20:46:10
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-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

osr

Zitat von: Beta-User am 22 Dezember 2018, 15:17:27
- 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.

Zitat von: Beta-User am 22 Dezember 2018, 15:17:27
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.

osr

Der Befehl zum neu starten heißt restart nicht reboot. Bitte in Template ändern.

Beta-User

Zitat von: osr am 23 Dezember 2018, 15:55:44
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-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

osr

Zitat von: Beta-User am 23 Dezember 2018, 16:45:02
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.

rudolfkoenig

ZitatHmmm, 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.

ZitatPerfekt 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.

ZitatWarum 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.

ZitatGibt 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.

osr

Zitat von: rudolfkoenig am 23 Dezember 2018, 18:44:50
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.

Zitat von: rudolfkoenig am 23 Dezember 2018, 18:44:50
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 ;-)

moonsorrox

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 i5: FHEM-Server 6.1 :: 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

osr

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.

Beta-User

Zitat von: osr am 24 Dezember 2018, 14:04:24
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:
Zitat von: osr am 23 Dezember 2018, 18:29:53
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.

ZitatsetStateList sollte auch überall benutzt werden.
Also sollte in die Basistemplates das folgende rein, oder?
attr DEVICE setStateList on off toggle
Zitatim 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-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

osr

Zitat von: Beta-User am 24 Dezember 2018, 14:26:35
Du sprichst bereits von Version 18047 von heute Mittag, oder?
ja aus dem repository

Zitat von: Beta-User am 24 Dezember 2018, 14:26:35
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?

Beta-User

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-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

osr

Zitat von: Beta-User 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?
....

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

rudolfkoenig

ZitatHabe 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?

Beta-User

Zitat von: rudolfkoenig am 26 Dezember 2018, 11:59:42
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-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