FHEM Forum

FHEM - Hausautomations-Systeme => MQTT => Thema gestartet von: moonsorrox am 13 Dezember 2018, 16:27:05

Titel: Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 13 Dezember 2018, 16:27:05
Für die Sonoff gibt es zwischenzeitlich auch ein paar templates, die man einfach mit "set <device> attrTemplate ..." anwenden kann.

Ich habe heute mal ein weiteres Gerät (Sonoff Basic) mit Hilfe der neuen Template Geschichte angelegt. Eigentlich hat da alles gut geklappt, was ich etwas erweitert habe ist die readingList, aber hier auch nur Info1-3.
Was ich jetzt aber gar nicht hinbekomme ist ein aktuelles devStaticon was ich bisher bei meinen anderen Geräten die schon auf MQTT2_Device umgerüstet sind bisher so war
ON:li_wht_on OFF:li_wht_off
Dadurch sehe ich auf meiner Weboberfläche nicht ob das Gerät "Ein" oder "Aus" geschaltet ist, wie kann ich das wieder hinbekommen.
Wenn ich im state schaue sehe ich ja on und off, aber auch so kommt kein Icon zustande
on:li_wht_on off:li_wht_off
Wie muss ich das jetzt schreiben..? Im Wiki ist dazu noch nichts zu finden.

Vllt. noch eine Ergänzung, dass erstellte attr stateFormat habe ich bisher nicht geändert, sollte ich das evtl. in meinen anderen MQTT2 Attributen steht dort nur Power drin
funktioniert leider nicht
Titel: Antw:Folgende frage zu MQTT und Sonoff/Tasmota
Beitrag von: Beta-User am 13 Dezember 2018, 16:59:07
Du hast "tasmota_basic" genutzt, oder?

Vorab: ich bin erst dabei, mich in diese Materie einzuarbeiten und hatte bisher "nur" andere Geräte. Wäre schön, wenn wir gemeinsam das so hinbekommen, dass man das noch einfacher nutzen kann...

Vom Gefühl her würde ich dann erst mal das "tasmota_1channel" versuchen, das sieht mir stringenter aus, dazu ggf. die readingList vom "tasmota_noprefix_pure_base".

Ansonsten:
Kannst du mal erst das Device "nackt" wieder anlegen lassen und einfach nur ein paar Schaltvorgänge, Werteabfragen usw. in der Weboberfläche des Tasmota durchführen (damit sich das MQTT2_DEVICE per autocreate füllt).
Dann ein list, anschließend nach Anwendung des templates wieder ein list, wobei ich vom Gefühl her annehmen würde, dass man am besten vorab das "tasmota_noprefix_pure_base" anwenden sollte (da steht eigentlich schon eine vernünftige readingList drin, danach ist dann autocreate für das Device deaktiviert).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 13 Dezember 2018, 17:04:42
OK ich muss das erst einmal sichern weil es um meine Wohnzimmer Beleuchtung geht, was ich noch gemerkt habe mein DOIF hat zum einschalten einen Fehler gezeigt, leider habe ich den schon gelöscht, weil ich annahm das der Fehler dadurch entstanden ist da ich dort noch noch ON und OFF drin hatte, welches ich durch on,off ersetzen muß.
Da sich ein Teil meiner Beleuchtung für eine kurze Zeit, wenn die Rollläden runter fahren einschalten  ;)
..und dann können wir los legen...!

und ja ich habe tasmota_basic verwendet
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 13 Dezember 2018, 17:14:58
Hier nochmal ein kurzer Vergleich von zwei Devices
1. Device - angelegt ohne template (list)
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_3AFF88
   DEF        DVES_3AFF88
   DEVICETOPIC AU_Garten
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     16
   NAME       AU_Garten
   NR         4819
   STATE      ON
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 16
   m2server_TIME 2018-12-13 17:05:52
   READINGS:
     2018-12-13 16:00:39   FallbackTopic   DVES_3AFF88
     2018-12-13 16:00:39   GroupTopic      sonoffs
     2018-12-13 16:00:39   Hostname        AU_Garten-8072
     2018-12-13 16:00:39   IPAddress       10.0.0.150
     2018-12-13 16:15:00   LWT             online
     2018-12-13 16:00:39   Module          Sonoff Basic
     2018-12-13 16:15:00   POWER           
     2018-12-13 17:05:52   POWER1          ON
     2018-12-13 16:00:39   RestartReason   Software/System restart
     2018-12-13 17:05:52   Time            2018-12-13T17:05:20
     2018-12-13 17:05:52   Uptime          0T01:05:17
     2018-12-13 17:05:52   Vcc             3.168
     2018-12-13 16:00:39   Version         6.3.0
     2018-12-13 16:00:39   WebServerMode   Admin
     2018-12-13 17:05:52   Wifi_AP         1
     2018-12-12 14:07:22   Wifi_APMac      9C:C7:A6:11:3E:A5
     2018-12-13 17:05:52   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-13 17:05:52   Wifi_Channel    11
     2018-12-13 17:05:52   Wifi_RSSI       70
     2018-12-13 17:05:52   Wifi_SSId       xxxxxxxxxxxxxxxxxxxxxxx
     2018-12-13 16:43:42   state           on
Attributes:
   IODev      m2server
   alias      Garten Lampen
   devStateIcon ON:li_wht_on OFF:li_wht_off
   eventMap   on:Ein off:Aus
   group      Aussen Beleuchtung Garten
   icon       light_uplight@blue
   readingList DVES_3AFF88:tele/AU_Garten/LWT:.* LWT
DVES_3AFF88:cmnd/AU_Garten/POWER:.* POWER
DVES_3AFF88:tele/AU_Garten/INFO1:.* { json2nameValue($EVENT) }
DVES_3AFF88:tele/AU_Garten/INFO2:.* { json2nameValue($EVENT) }
DVES_3AFF88:tele/AU_Garten/INFO3:.* { json2nameValue($EVENT) }
DVES_3AFF88:stat/AU_Garten/RESULT:.* { json2nameValue($EVENT) }
DVES_3AFF88:tele/AU_Garten/STATE:.* { json2nameValue($EVENT) }
DVES_3AFF88:tele/AU_Garten/UPTIME:.* { json2nameValue($EVENT) }
DVES_3AFF88:stat/AU_Garten/POWER1:.* POWER1
   room       Draußen,MQTT
   setList    on cmnd/AU_Garten/POWER1 ON
off cmnd/AU_Garten/POWER1 OFF
   sortby     02
   stateFormat POWER1
   userattr   room_map structexclude

2. Device - angelegt mit template (list)
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_3B5E50
   DEF        DVES_3B5E50
   DEVICETOPIC WZ_Schrank
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     27
   NAME       WZ_Schrank
   NR         4842
   STATE     
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 27
   m2server_TIME 2018-12-13 17:09:16
   READINGS:
     2018-12-13 15:34:43   Command         Unknown
     2018-12-13 15:59:03   FallbackTopic   DVES_3B5E50
     2018-12-13 15:59:03   GroupTopic      sonoffs
     2018-12-13 15:59:03   Hostname        WZ_Schrank-7760
     2018-12-13 15:59:03   IPAddress       10.0.0.152
     2018-12-13 16:14:59   LWT             online
     2018-12-13 15:59:03   Module          Sonoff Basic
     2018-12-13 17:09:16   POWER1          OFF
     2018-12-13 15:59:03   RestartReason   Software/System restart
     2018-12-13 17:09:16   Time            2018-12-13T17:08:45
     2018-12-13 17:09:16   Uptime          0T01:10:19
     2018-12-13 17:09:16   Vcc             3.238
     2018-12-13 15:59:03   Version         6.3.0
     2018-12-13 15:59:03   WebServerMode   Admin
     2018-12-13 17:09:16   Wifi_AP         1
     2018-12-13 17:09:16   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-13 17:09:16   Wifi_Channel    11
     2018-12-13 17:09:16   Wifi_RSSI       100
     2018-12-13 17:09:16   Wifi_SSId       xxxxxxxxxxxxxxxxxxx
     2018-12-13 16:51:05   state           off
Attributes:
   IODev      m2server
   alias      Wohnzimmer Schrank - Vitrine
   autocreate 0
   devStateIcon on:li_wht_on off:li_wht_off
   eventMap   on:Ein off:Aus
   group      Beleuchtung Wohnzimmer
   icon       light_cabinet@#FF6D00
   readingList tele/WZ_Schrank/LWT:.* LWT
  tele/WZ_Schrank/STATE:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/SENSOR:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO.:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO1:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO2:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO3:.* { json2nameValue($EVENT) }
  stat/WZ_Schrank/RESULT:.* { json2nameValue($EVENT) }
  stat/AU_Garten/POWER1:.* POWER1
   room       Wohnzimmer
   setList    off:noArg    cmnd/WZ_Schrank/POWER1 0
  on:noArg     cmnd/WZ_Schrank/POWER1 1
  toggle:noArg cmnd/WZ_Schrank/POWER1 2
   sortby     06
   stateFormat {lc ReadingsVal("$name","POWER","") }
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 13 Dezember 2018, 17:22:26
So als erstes habe ich jetzt einmal das von dir vorgeschlagene "tasmota_1channel" template genommen und es funktioniert auch wieder mein "devStateicon"
Aber.....
evtl. sollte ich doch mal da ganze Device leer machen um zu sehen wie es sich dann verhält

hier noch das list
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_3B5E50
   DEF        DVES_3B5E50
   DEVICETOPIC WZ_Schrank
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     35
   NAME       WZ_Schrank
   NR         4842
   STATE      on
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 35
   m2server_TIME 2018-12-13 17:26:27
   READINGS:
     2018-12-13 15:34:43   Command         Unknown
     2018-12-13 15:59:03   FallbackTopic   DVES_3B5E50
     2018-12-13 15:59:03   GroupTopic      sonoffs
     2018-12-13 15:59:03   Hostname        WZ_Schrank-7760
     2018-12-13 15:59:03   IPAddress       10.0.0.152
     2018-12-13 16:14:59   LWT             online
     2018-12-13 15:59:03   Module          Sonoff Basic
     2018-12-13 17:26:27   POWER1          ON
     2018-12-13 15:59:03   RestartReason   Software/System restart
     2018-12-13 17:24:17   Time            2018-12-13T17:23:45
     2018-12-13 17:24:17   Uptime          0T01:25:19
     2018-12-13 17:24:17   Vcc             3.253
     2018-12-13 15:59:03   Version         6.3.0
     2018-12-13 15:59:03   WebServerMode   Admin
     2018-12-13 17:24:17   Wifi_AP         1
     2018-12-13 17:24:17   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-13 17:24:17   Wifi_Channel    11
     2018-12-13 17:24:17   Wifi_RSSI       100
     2018-12-13 17:24:17   Wifi_SSId       xxxxxxxxxxxxxxxxxxxxxxxxxxx
     2018-12-13 17:26:27   state           on
Attributes:
   IODev      m2server
   alias      Wohnzimmer Schrank - Vitrine
   autocreate 0
   devStateIcon on:li_wht_on off:li_wht_off
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   group      Beleuchtung Wohnzimmer
   icon       light_cabinet@#FF6D00
   readingList tele/WZ_Schrank/LWT:.* LWT
  tele/WZ_Schrank/STATE:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/SENSOR:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO.:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO1:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO2:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO3:.* { json2nameValue($EVENT) }
  stat/WZ_Schrank/RESULT:.* { json2nameValue($EVENT) }
  stat/AU_Garten/POWER1:.* POWER1
   room       Wohnzimmer
   setList    off:noArg    cmnd/WZ_Schrank/POWER1 0
  on:noArg     cmnd/WZ_Schrank/POWER1 1
  toggle:noArg cmnd/WZ_Schrank/POWER1 2
   sortby     06
   stateFormat {lc ReadingsVal("$name","POWER1","")}


EDIT;// nur so nebenbei
ich habe noch ein komplettes 4-kanal Tasmota Gerät welches mein MQTT2 Server angelegt hat, weil ich heute meinen mosquitto gelöscht habe und er damit das MQTT2 Device gefunden hat.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 13 Dezember 2018, 17:27:48
Sieht mir nach einem Fehler in tasmota_basic aus, dass da im stateFormat die "1" fehlt.

stateFormat {ReadingsVal($name, "POWER1", "off")}
Kannst das nochmal leeren (am einfachsten über das pure-basic-Dingens) und dann wieder den 1Ch anwenden...

Werde vermutlich den 1-Channel einfach auf den ."-basic" umleiten und da wieder den "pure-basic" voranschalten. Dann sollte man eigentlich ein sinnvolles Gesamtdevice erhalten?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 13 Dezember 2018, 17:32:35
Ja die "1" hatte ich händisch dazu geschrieben  ;)

Hier jetzt mal ein komplett gelöschtes  und dann mit "tasmota_1channel" angelegtes Device
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_3B5E50
   DEF        DVES_3B5E50
   DEVICETOPIC WZ_Schrank
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     36
   NAME       WZ_Schrank
   NR         4842
   STATE     
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 36
   m2server_TIME 2018-12-13 17:29:17
   OLDREADINGS:
   READINGS:
Attributes:
   IODev      m2server
   alias      Wohnzimmer Schrank - Vitrine
   autocreate 0
   devStateIcon on:li_wht_on off:li_wht_off
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   group      Beleuchtung Wohnzimmer
   icon       light_cabinet@#FF6D00
   readingList tele/WZ_Schrank/LWT:.* LWT
  tele/WZ_Schrank/STATE:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/SENSOR:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO.:.* { json2nameValue($EVENT) }
  stat/WZ_Schrank/RESULT:.* { json2nameValue($EVENT) }
   room       Wohnzimmer
   setList    off:noArg    cmnd/WZ_Schrank/POWER1 0
  on:noArg     cmnd/WZ_Schrank/POWER1 1
  toggle:noArg cmnd/WZ_Schrank/POWER1 2
   sortby     06
   stateFormat {lc ReadingsVal("$name","POWER1","")}

nach einigen Ein/Aus schalten nur zwei readings
POWER1 OFF
state off

aber es füllt sich langsam
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 13 Dezember 2018, 17:40:32
OK was ich jetzt wieder anlegen muss sind die INFO Geschichten 1-3, weil ich eine readingsgroup habe wo ich z.B. die IP des Gerätes anzeige und auch dort dann drauf klicken kann um direkt über die IP auf das Gerät komme. Dann habe ich die Tasmota Version drin die fehlt mir ebenfalls in der RG

Ich muss nochmal auf der Github seite schauen was die Infos 1-3 genau anzeigen..!
Finde ich grad gar nicht, habe dort nur die ganzen Befehler gefunden, aber ich war der Meinung das es irgendwo erklärt ist.

Einen kleinen Schönheitsfehler aber auf hohem Niveau, ich habe bisher überall Ein statt on und Aus statt off, dass kann ich im Moment nicht erreichen webCmd meckert rum und in der eventMap habe ich bisher keine Lösung gefunden.
In der setList habe ich das mal probiert "off:Aus", da entsteht ein Dropdown Feld das ist nicht so schön, evtl. gibt es eine andere Lösung dafür.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 14 Dezember 2018, 07:30:35
So, Danke für den Hinweis, die "1" habe ich eingecheckt.

Für INFO reicht m.E. eine Zeile: "INFO." oder "INFO[1-3]", wäre noch interessant zu wissen, ob man das (und die anderen readingList-Standards) per default setzten sollte (Diskussion folgt ggf. an anderer Stelle).

Zum Rest: bisher keine Idee, außer der, ggf. aus einer gefundenen Lösung ein kleines template zu machen, das dann nur diesen Teil so setzt, wie du das haben willst :) .
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: tpm88 am 14 Dezember 2018, 16:09:42
Sieht mir nach einem Fehler in tasmota_basic aus, dass da im stateFormat die "1" fehlt.

stateFormat {ReadingsVal($name, "POWER1", "off")}

Meiner Meinung nach ganz im Gegenteil. Mit den Templates von heute ( egal ob A_01_tasmota_basic oder A_01a_tasmota_1channel) erhalte ich mit folgenden Devices keine korrekte Anzeige.

Sonoff S20
Sonoff Basic
Sonoff Touch

Damit der State korrekt angezeigt wird, muß ich die "1" beim stateFormat löschen.

Hier zum Vergleich ein list eines S20 (heute mit autocreate neu angelegt und template A_01_tasmota_basic gesetzt).

fhem> list MQTT2_DVES_8021F4
Internals:
   CID        DVES_8021F4
   DEF        DVES_8021F4
   DEVICETOPIC MQTT2_DVES_8021F4
   IODev      my_MQTT2
   LASTInputDev my_MQTT2
   MSGCNT     15
   NAME       MQTT2_DVES_8021F4
   NR         236
   STATE      off
   TYPE       MQTT2_DEVICE
   my_MQTT2_MSGCNT 15
   my_MQTT2_TIME 2018-12-14 15:56:32
   READINGS:
     2018-12-14 15:46:20   INFO1_FallbackTopic DVES_8021F4
     2018-12-14 15:46:20   INFO1_GroupTopic sonoffs
     2018-12-14 15:46:20   INFO1_Module    Sonoff S2X
     2018-12-14 15:46:20   INFO1_Version   6.3.0
     2018-12-14 15:46:20   INFO2_Hostname  sonoff_s20_01
     2018-12-14 15:46:20   INFO2_IPAddress 192.168.8.91
     2018-12-14 15:46:20   INFO2_WebServerMode Admin
     2018-12-14 15:46:20   INFO3_RestartReason Power on
     2018-12-14 15:47:03   LWT             Online
     2018-12-14 15:53:52   POWER           OFF
     2018-12-14 15:53:52   RESULT_POWER    OFF
     2018-12-14 15:56:32   STATE_POWER     OFF
     2018-12-14 15:56:32   STATE_Time      2018-12-14T15:56:33
     2018-12-14 15:56:32   STATE_Uptime    0T00:10:19
     2018-12-14 15:56:32   STATE_Vcc       3.179
     2018-12-14 15:56:32   STATE_Wifi_AP   1
     2018-12-14 15:56:32   STATE_Wifi_BSSId 5C:49:79:7C:93:A7
     2018-12-14 15:56:32   STATE_Wifi_Channel 13
     2018-12-14 15:56:32   STATE_Wifi_RSSI 96
     2018-12-14 15:56:32   STATE_Wifi_SSId TobiVision
     2018-12-14 15:53:52   state           off
Attributes:
   IODev      my_MQTT2
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   readingList DVES_8021F4:stat/sonoff/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }
DVES_8021F4:stat/sonoff/POWER:.* POWER
DVES_8021F4:tele/sonoff/LWT:.* LWT
DVES_8021F4:cmnd/sonoff/POWER:.* POWER
DVES_8021F4:tele/sonoff/STATE:.* { json2nameValue($EVENT, 'STATE_') }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoff/POWER1 0
  on:noArg     cmnd/sonoff/POWER1 1
  toggle:noArg cmnd/sonoff/POWER1 2
   stateFormat {lc ReadingsVal("$name","POWER","") }

Die "1" beim stateFormat habe ich anschliessend entfernt.

Das Tasmota 1channel Device war diesbezüglich schon länger fehlerhaft - hatte ich Rudi auch schon einmal geschrieben.

Danke für die viele Arbeit mit den Templates...

Gruss
Tobias
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: carlos am 14 Dezember 2018, 16:15:24
Siehe doku:
SetOption26    0 / off    (default) Keep using POWER without postfix for single power devices

Gruß
Carlos
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 14 Dezember 2018, 16:19:26
Ich habe in meinen S20 geschaut, der S20 ist wohl ein Sonderfall, da er nur mit "POWER" schaltet währenddessen der Basic mit POWER1 arbeitet, es braucht da für den S20 ein eigenes template... Denke ich  :-\

Falls jemand eine Lösung zu dem "Ein,Aus" Thema hat bitte hier mal posten
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: tpm88 am 14 Dezember 2018, 17:21:07
Nach meinen Erfahrungen können sowohl Basic als auch S2x mit POWER1 geschaltet werden (publish), geben aber beide als Reading über den Schaltzustand POWER (ohne "1") zurück.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 14 Dezember 2018, 17:26:13
Ich melde mich jetzt nochmal, aber zu meinem Sonoff 4-Kanalschalter.
So wie ich gestern geschrieben habe hat er mir das Teil ja selber angelegt, heute nun habe ich ihm mal das "neue" template "A_04a_tasmota_noprefix_sonoff_4ch" erstellen lassen.
Erst einmal hat er mir das angelegt das ist ja OK.
jetzt das Problem der Schalter heißt ja in der Sonoff Weboberfläche topic = %topic% (sonoff) "4-Kanal_Sonoff"
bei bei Client steht dieses drin "client (DVES_890FBF)"

Jetzt kommen die Dinge die mir das template erstellt hat
die readinglist:
tele/MQTT2_DVES_890FBF/LWT:.* LWT
  tele/MQTT2_DVES_890FBF/STATE:.* { json2nameValue($EVENT) }
  tele/MQTT2_DVES_890FBF/SENSOR:.* { json2nameValue($EVENT) }
  tele/MQTT2_DVES_890FBF/INFO.:.* { json2nameValue($EVENT) }
  stat/MQTT2_DVES_890FBF/RESULT:.* { json2nameValue($EVENT) }

die setlist:
p1:on,off cmnd/MQTT2_DVES_890FBF/POWER1 $EVTPART1
  p2:on,off  cmnd/MQTT2_DVES_890FBF/POWER2 $EVTPART1
  p3:on,off  cmnd/MQTT2_DVES_890FBF/POWER3 $EVTPART1
  p4:on,off  cmnd/MQTT2_DVES_890FBF/POWER4 $EVTPART1

stateFormat:
{
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))
  . " P3:". FW_makeImage(lc ReadingsVal($name, "POWER3", "off"))
  . " P4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off"))
  . "</div>"
  }

Folgende Anmerkung, wenn jetzt ein etwas unerfahrener User das so anlegt bekommt er das Teil nicht zum schalten, ich weiß aber durch die Sonoff die ich schon erstellt habe das der Pfad z.B.
p1:on,off cmnd/MQTT2_DVES_890FBF/POWER1 $EVTPART1
so nicht funktioniert, denn es muss heißen

p1:on,off cmnd/4-Kanal_Sonoff/POWER1 $EVTPART1
Das heißt ich muss jetzt das gerade erstellte "template" komplett umändern.
Ich denke das template muss anders gestaltet werden.. Was meint ihr..?


Zu guter Letzt hänge ich nochmal ein Screenshot zu dem 4-Kanal Schalter ran, dort ist das stateFormat der Schalter P1 - P4 on,off etwas unglücklich gestaltet, soll heißen unübersichtlich... ich habe aber noch keinen guten Einfall wie man das am besten machen kann, das man eine bessere Übersicht hat.
Ich habe soeben meinen Server gekillt der eingeschaltet war weil die Statusanzeige für P2 nicht den richtigen Stuatus "on" hatte und ich mal eben auf "off" gedrückt habe :-\.

Was ich damit sagen will auch hier müßte man etwas nacharbeiten, ebenso das devStateicon, aber wie gesagt es ist alles neu und so nacheinander bekommen wir das schon hin  ;)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 14 Dezember 2018, 19:46:18
noch ein weiterer Hinweis
Ich habe mir eine Readingsgroup erstellt in der alle MQTT2 Devices aufgelistet werden, dazu ein Screenshot.
Die ersten oberen beiden Devices wurden ohne "template" erstellt hier kommen alle von mir aufgelisteten Einträge/readings auch in der rg an.
Die unteren beiden Devices wurden mit dem "template" erstellt, hier kommt zum Teil gar nichts an siehe Screenshot die rg ist leer und die readings auch.
Was ankommt ist die Wifi_SSId für des WLAN.
Der untere ist auch ein Sonoff Basic, wie die beiden oberen.

Ich weiß das sich die readings erst nach einer kurzen Weile füllen, aber seit gestern erscheint mir etwas zu lange..!
Oder, kommen die noch..?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 14 Dezember 2018, 21:04:19
Vorab erst mal Danke für die zahlreichen Beiträge und Anregungen!

Wird etwas dauern, bis ich das (und die Anmerkungen+Rudis neuen Code aus den anderen Threads) verarbeitet haben werde.

a) es wird wieder zwei effektiv unterschiedliche Tasmota-templates geben, wäre schön, es wäre (für einen bisherigen Nicht-Tasmotaer) nachvollziehbar, nach welcher Regel was auszusuchen ist. Btw: Rudi hat Kommentare ermöglich! Könnte man die Typen/Firmware-Varianten... reinschreiben, für was ein template denn nun ist. => Wer das einigermaßen strukturiert liefern kann: her damit...

b) Macht es Sinn, eine Standard-readingList für alle Tasmota-Varianten mit auszuliefern? (Die vom 4-fach, oder?)

c) vermutlich braucht es für manche Readings eine Art "get ...". Könnte man gleich am Ende publishen, ich würde dann nur den Befehl benötigen...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 14 Dezember 2018, 22:31:15
Kurze Info:

das mit der Standard-readingList für alle Tasmotas habe ich eben eingecheckt, zusammen mit POWER/POWER1-Varianten.
Den von moonsorrox gemeldeten bug habe ich auch versucht zu fixen, bitte dazu um Rückmeldung.
Im Übrigen siehe hier: https://forum.fhem.de/index.php/topic,94060.msg872067.html#msg872067, auch den dortigen Hinweis zu "desc:".
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 14 Dezember 2018, 23:32:47
ja es ist sicher viel Arbeit für soetwas fast komplett neues, aber lass dir Zeit es funktioniert ja erst einmal. Das es nicht perfekt ist nach dieser kurzen Zeit ist ja klar und kein Problem, aber da arbeiten wir dran  ;)
Ich denke genug Mithelfer hast du ja...!  ;)

weitere Frage am Rande zum 4-Kanl Schalter, hast du mal gesehen was dort im STATE drin steht, bei meinen anderen Geräten steht dort maximal ein ON oder OFF oder auch off drin.
Ich kann das gerne mal ganz unten ran hängen, evtl. hilft es dir bei der Suche/Erstellung oder sonst irgend etwas

a)Rudi hat Kommentare ermöglich! Könnte man die Typen/Firmware-Varianten... reinschreiben, für was ein template denn nun ist. => Wer das einigermaßen strukturiert liefern kann: her damit...

b) Macht es Sinn, eine Standard-readingList für alle Tasmota-Varianten mit auszuliefern? (Die vom 4-fach, oder?)

c) vermutlich braucht es für manche Readings eine Art "get ...". Könnte man gleich am Ende publishen, ich würde dann nur den Befehl benötigen...

zu a) meinst du die Tasmota Firmware..? die lese ich ja z.B. schon in meiner readinggroup aus. Wenn du aber die Geräte meinst z.B. Basic, S20 usw. denke ich wird es schwieriger, weil es schon von fast jedem Gerät eine oder mehrere Versionen gibt die sich unterscheiden.
Dazu ein Beispiel ich hatte mir ein YouTube Video angeschaut und als ich meinen Basic bekam sah der vom Aufbau ganz anders aus und hatte eine andere Vers. Nr. da bist ewig am verändern, wenn den Chinesen was neues einfällt.

zu b) ich denke das ist evtl. das beste, denn einmal vllt auch im Wiki ein Beispiel dann weiß jeder wie er sie ergänzen kann, wobei die readinglist jetzt nicht das schwierige ist.

zu c) kann ich nichts sagen, weil ich grad nicht weiß was du meinst oder ich verstehe es nur nicht. :-\

O.T.
Meine 4 Shelly 1 sind auch schon unterwegs, dort in dem Thread habe ich auch schon mitgelesen, da tut sich auch einiges  ;)

Inhalt nur vom STATE des 4-fach Schalter:
<div>Drucker:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="617pt" viewBox="0 0 468 617" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)" stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> Dell Server:<svg class=" on" data-txt="on" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="537pt" viewBox="0 0 468 537" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,537) scale(0.181395,-0.181395)" stroke="none"> <path d="M957 2932 c-14 -16 -17 -43 -17 -174 0 -135 2 -157 18 -171 28 -25 72 -26 96 -1 13 13 16 43 16 173 0 140 -2 160 -18 174 -25 22 -75 21 -95 -1z"/> <path d="M1506 2928 c-13 -18 -16 -53 -16 -174 0 -138 2 -152 20 -169 24 -22 77 -22 99 0 13 12 17 44 19 151 4 147 1 174 -24 198 -24 24 -80 20 -98 -6z"/> <path d="M278 2834 c-29 -15 -44 -50 -34 -81 3 -11 73 -85 154 -166 127 -126 153 -147 180 -147 34 0 72 38 72 73 0 34 -312 341 -342 337 -2 -1 -15 -7 -30 -16z"/> <path d="M2235 2840 c-34 -14 -315 -305 -315 -327 0 -35 38 -73 72 -73 27 0 53 21 180 148 82 81 151 157 155 170 12 51 -44 100 -92 82z"/> <path d="M1039 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M2110 2123 c-49 -19 -64 -68 -34 -111 15 -22 19 -22 238 -22 211 0 224 1 241 20 23 25 24 76 1 98 -14 15 -44 17 -224 19 -114 1 -214 -1 -222 -4z"/> <path d="M16 2098 c-22 -31 -20 -71 5 -94 19 -17 39 -19 240 -19 236 0 241 1 254 55 4 18 0 34 -15 53 l-21 27 -224 0 c-220 0 -224 0 -239 -22z"/> <path d="M26 1559 c-32 -25 -35 -70 -6 -99 19 -19 33 -20 238 -20 207 0 220 1 237 20 26 29 24 79 -4 102 -21 16 -44 18 -231 18 -195 0 -209 -1 -234 -21z"/> <path d="M2080 1560 c-23 -23 -26 -68 -6 -96 13 -18 30 -19 233 -22 203 -3 221 -2 243 16 32 26 32 78 1 104 -21 16 -44 18 -237 18 -201 0 -215 -1 -234 -20z"/> <path d="M20 1010 c-29 -29 -26 -74 7 -100 26 -20 36 -21 240 -18 184 3 215 5 229 20 23 22 22 73 -1 98 -17 19 -30 20 -237 20 -205 0 -219 -1 -238 -20z"/> <path d="M2077 1012 c-22 -25 -21 -75 1 -95 16 -15 48 -17 238 -17 120 0 224 4 231 8 32 20 32 94 0 114 -7 4 -111 8 -233 8 -201 0 -222 -2 -237 -18z"/> <path d="M998 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M1023 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M1023 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M1101 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P3:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="617pt" viewBox="0 0 468 617" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)" stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P4:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg" width="468pt" height="617pt" viewBox="0 0 468 617" preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)" stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg></div>
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 15 Dezember 2018, 00:34:23
...das mit dem Zeit lassen ist relativ:
Zum einen will ich erst mal recht schnell einen Stand haben, der erst mal "brauchbar" ist => sowas wie dir passiert ist (welche Variante soll ich denn nehmen?!?) sollte - nach Lektüre der vorhandenen Info dazu - nicht sein. Und da es recht neu ist, wollen alle es a) einfach haben und b) möglichst sofort richtig...
Daher will ich den Schwung hier "mitnehmen" und schnell was brauchbares haben, und so wie ich den support durch Rudi hier erlebt habe, unterstelle ich mal: er (und andere) auch :) .

Dass das naturgemäß über die diversen Hardwarerevisionen und (v.a.) firmware-Varianten nicht einfach ist, ist einerseits klar, andererseits ist auch Theo & sein Team dahingehend "faul", dass die auch nicht ständig am Controllerinterface (hier: FHEM) rumbasteln wollen, sondern eher die firmware so hinbiegen, dass das über der Zeit möglichst keine Brüche generiert (=> Topicstruktur etc. bleibt möglichst unverändert)
Im Tasmota-Bereich dürfte daher der Anknüpfungspunkt eher eine/mehrere bestimmte (verbreitete) Firmware-Varianten sein, die im desc: auftauchen (=> lösbar und auch nicht ständig zu aktualisieren).

weitere Frage am Rande zum 4-Kanl Schalter, hast du mal gesehen was dort im STATE drin steht, bei meinen anderen Geräten steht dort maximal ein ON oder OFF oder auch off drin.
Nein, ich habe keinen einzigen Tasmota-geflashten ESP ;) . Und auch nur ganze 2 ESP8266 hier im Einsatz: Einen für Milight (Beleuchtung!) und einen mit einer selbergebastelten IR-firmware (die vielleicht demnächst ESPEasy@MQTT weicht). WLAN für Hausautomatisierungszwecke halte ich btw. für eine eher schlechte Lösung, die nur für Nebendevices gewählt werden sollte - dass ich hier grade ziemlich viel für Tasmota und Shelly mache, ist nicht ganz ironiefrei ;D .

Der Code wurde von jemandem anderen in dem Shelly-MQTT-Thread beigesteuert, Fragen also bitte da stellen (bzw. ggf. einen neuen aufmachen und den Autor bitten, das dort zu analysieren).

Zitat
zu b) ich denke das ist evtl. das beste, denn einmal vllt auch im Wiki ein Beispiel dann weiß jeder wie er sie ergänzen kann, wobei die readinglist jetzt nicht das schwierige ist.
zu c) kann ich nichts sagen, weil ich grad nicht weiß was du meinst oder ich verstehe es nur nicht. :-\
Bei c) geht es darum, dem ESP ein Kommando zu schicken, damit der seinerseits was an Infos liefert, was nicht regelmäßig kommt (bei der zigbee-Bridge z.B. alle Geräte mit weiteren Infos). Ist eigentlich ein set, allerdings gefollt von einem Dialogfeld mit der Anzeige des Ergebnisses. Das Problem bei der Sache scheint zu sein, dass dabei schon das Reading angegeben werden muß, unter dem die Info zurückgeliefert wird. Teilweise hängt es dann von der Rückmeldung bzw. der setList ab, wie das dargestellt wird. Ergo sind hier zu viele Automatismen nicht unbedingt hilfreich...
Bin aber selber erst am experimentieren und nicht sicher, ob ich a) alles selbst schon verstanden habe und b) das alles wirklich so funktioniert wie gedacht. Wenn, dann kommt es als erstes als Beispiel in die templates und dann hoffentlich zeitnah auch ins Wiki (wie gehabt, das letzte update bei den "Praxisbeispielen" hat m.E. leider zu lange gedauert, aber ich will das vorher auch "in echt" durchspielen...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 15 Dezember 2018, 13:24:33
also das mit par:DEVNAME sollte so OK sein, vorausgesetzt autocreate ist an so dass die readingList gefüllt wird. Das ist natürlich so universeller. Daran habe ich nicht gedacht. Mit leerer readingList funktioniert par:DEVNAME, so wie ich das verstehe, nicht. Oder liege ich da falsch?

Zur Info für nicht Tasmota-User:

Standardmäßig wird das Gerät in FHEM mit autocreate mit dem Namen MQTT2_<Tasmota-mqtt-client> angelegt. Tasmota verwendet dafür DVES_<letzte 6 Stellen der MAC-Adresse> wenn der client nicht gesetzt wird. Ich verwende in Tasmota normalerweise einen Namen wie sonoffBueroBriefkasten als client. FHEM legt das Gerät dann mit MQTT2_sonoffBueroBriefkasten an. Wenn ich das Gerät in FHEM fertig angelegt habe mache ich ein ren MQTT2_sonoffBueroBriefkasten sonoffBueroBriefkasten. Auch für DHCP wird der client benutzt und ich sehe so auch im DHCP-Server den Namen.

Bezüglich dem Topic (das kann man auch in Tasmota einstellen und konfigurieren) ist es so dass Tasmota hier sonoff als Voreinstellung hat. Dies muss immer abgeändert werden. Sonst haben alle Geräte das selbe topic, was natürlich Fatal ist wenn man nicht alle zusammen schalten will. Ich verwendet hier normalerweise die selbe Bezeichnung wie beim client also sonoffBueroBriefkasten.

Man kann hier MQTT-mäßig natürlich mit / feiner aufteilen. Da ich vorher ZWave hatte und da schon eine gewisse Logik im Namen hatte, mache ich da nix mit / sondern habe lieber alles einheitlich. Name des Gerätes, Topic, Benennung anderer Geräte.

Deswegen sieht das bei mir z. B. so aus

tele/sonoffBueroBriefkasten/STATE

und das Gerät heisst entsprechend sonoffBueroBriefkasten

Da ging das natürlich mit dem Device im template ;-) Für die die im anderen Forumthread nicht mitgelesen haben, das Ursprungstemplate war von mir.

Prinzipiell haben wir aktuell 2 Varianten die grundsätzlich mit und ohne Präfix möglich wären, was dann 4 Varianten wären.

Ist die Variante mit Präfix in den Readings jetzt ganz raus? Wenn das keiner nutzt wäre die Frage ob autocreate das auch ohne wieder generiert. Wer das dann wirklich mit nutzen möchte, kann das ja jederzeit machen. Mir fällt hier aber kein Grund ein wo das einen Vorteil bringt? Ihr wisst ja ich war da von vorn herein kein Freund von ;-)

Dann die 2 Varianten:
1. relay etc. auf mehrere FHEM-Geräte aufteilen
2. relay etc. alles in einem FHEM-Gerät

Mein Vorschlag wäre zumindest in den Templates generell nur ohne präfix zu fahren. Ist denke ich in der aktuellen Version schon so umgesetzt?

Für die Benennung:

A_09x_tasmota_pure_base
als basis ist gut und klar. War ja auch ursprünglich von mir ;-) Würde aber zuerst autocreate auf 0, dann readingList und zum Schluss deleteReading machen. Ist zwar eher theoretischer natur aber wir wollen ja nicht, dass nach setzen von readingList per autocreate noch was rein kommt.

Das mit den Mehrfachgeräten finde ich insgesamt schon etwas seltsam. Bei einem ZWave Bewegungssensor macht ja auch keiner X-Geräte für Temperatur, Bewegungserkennung etc. Ist das wirklich allgemein benutzt bei Tasmota da mehrere Geräte in FHEM draus zu machen? Oder einfach nur weil viele nicht wussten wie sie das in einem Gerät machen können? Ich weiss ich war da der Vorreiter mit dem Template und ich hatte das früher auch in mehreren Geräten gemacht...

Aber lohnt sich die Verwirrung in den Templates oder sollten wir uns nicht besser darauf konzentrieren für die wichtigsten Anwendungsfälle eine einfache und von der großen Mehrheit bevorzugte Variante bereit zu stellen? Die Frage hier was meint die große Mehrheit dazu? Wenn das Einzelaufteilen die Mehrheit darstellt. Sollte meine Variante mit einem Gerät wieder raus. Man könnte das ja dann stattdessen im Wiki als Beispiel für eigene Templates erklären. Aber so weiss doch keiner was er da jetzt wählen soll für ein Template, erst recht mit dem noprefix.

Für mich ist das logischer für meine Markisensteuerung 1 Gerät mit 2 Relay zu haben anstatt 2 wo ich mir dann schon bei der Benennung einen abbrechen muss mit einem Gerät als MarkiseRaus und einem als MarkiseRein. Aber bin ich da mehrheitsfähig?

Zum Thema Firmware ist mir keine Firmware von Tasmota bekannt wo der Aufbau unterschiedlich ist. Von daher muss aktuell in der desc kein Hinweis auf eine bestimmte Firmware stehen.

Bezüglich POWER1 bei einem Gerät mit nur einem Relay wird von Tasmota da normalerweise POWER verwendet ohne Zusatzzahl. Das selbe bei Switches und Buttons. Nur wenn mehr als einer im Gerät aktiv ist werden Zahlen benutzt. Allerdings scheint Tasmota da recht fehlertolerant zu sein und ein cmnd mit POWER1 bei einem Gerät nur mit POWER funktioniert auch. Generell ist Tasmota zumindest in der aktuellen Firmware (da habe ich es eben nochmal getestet) Groß/Kleinschreibung egal.

Das heisst cmnd/sonoffBueroBriefkasten/power1 OFF funktioniert genauso wie cmnd/sonoffBueroBriefkasten/Power Off

Hat das Gerät mehr als ein Relay kann für das erste Relay power1 oder power verwendet werden geht beides. das  2. Relay dann mit power2.

Ansonsten sind die aktuellen Template Versionen nicht ganz sauber.

Template A_01a wird nicht benötigt und funktioniert auch nicht. Bei einem 1 channel device wird in State etc. kein POWER1 sondern POWER zurückgegeben! Das heisst der Status wird so nicht aktualisiert.

Gerät A_01 sollte heißen:
desc: Applies to devices with one POWER reading like Sonoff Basic, S20, ...

Der Name vom A_01a Template wäre eigentlich super für A_01 da allgemein sonoff Basic ist da nur eine Variante unter sehr vielen bei Tasmota

Statt bei COMMAND/POWER1 Ziffern, sollten eigentlich die Texte verwendet werden 0 ist off, 1 ist on, 2 ist toggle. Gibt es da nicht vielleicht auch eine elegantere Variante, dass der Parameter gleich benutzt wird? Schließlich ist
off:noArg COMMAND/POWER1 off
doppelt off ;-) oder eventuell dass mit in setlist das nicht einzeln aufführen muss? wie z. B. beim 4 channel Gerät mit
p1:on,off  COMMAND/POWER1 $EVTPART1

Falls die zusammengefassten Tasmota Geräte gewünscht werden, kann ich auch die templates überarbeiten und hier nochmal bereitstellen.

Was mich an den Templates im Moment am meisten stört, ist dass ich noch keine Lösung habe um über die Icons zu schalten, sprich ein toggle abzusetzen. Ansonsten passt das für mich sehr gut. Bis auf p1, p2 etc in was sprechendes umbenennen und gegebenenfalls die Symbole z. B. auf sani_buffer_temp_down und sani_buffer_temp_up umzustellen, mache ich jetzt bei Neuinbetriebnahmen nichts mehr wesentliches und es geht ruck zuck.

Bitte entschuldigt den langen Post und ich will da auch keinem auf die Nerven gehen, mich würde auch sehr interessieren, wie andere ihre Tasmota konfigurieren. Eventuell wäre da sogar ein eigener Thread sehr interessant zum Austausch.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 15 Dezember 2018, 13:34:32
b) Macht es Sinn, eine Standard-readingList für alle Tasmota-Varianten mit auszuliefern? (Die vom 4-fach, oder?)
c) vermutlich braucht es für manche Readings eine Art "get ...". Könnte man gleich am Ende publishen, ich würde dann nur den Befehl benötigen...

b) die readingList von pure_base ist doch OK. Mehr braucht es nicht, oder habe ich was nicht richtig verstanden? Oder meinst du die setList? Die kann aber sehr unterschiedlich sein.
c) nein get's braucht es eigentlich nicht. Über STATE und SENSOR (sofern Sensoren angeschlossen sind) kommt eigentlich alles automatisch alle paar Minuten. Nur INFO1,2,3 kommt glaube ich nur beim restart des Tasmota-Gerätes, oder in sehr großen Zeitabständen. Aber auch wenn sich das Gerät neu mit dem mqtt-Server verbindet.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 15 Dezember 2018, 14:38:33
Ich hoffe, nichts wichtiges zu vergessen, sonst bitte melden:

b) die readingList von pure_base ist doch OK. Mehr braucht es nicht, oder habe ich was nicht richtig verstanden? Oder meinst du die setList? Die kann aber sehr unterschiedlich sein.
Sorry, die war gemeint und wird jetzt bei allen Tasmota-Varianten so eingesetzt. Damit müßte auch "noprefix" als default bei allen gesetzt sein
Zitat
c) nein get's braucht es eigentlich nicht. Über STATE und SENSOR (sofern Sensoren angeschlossen sind) kommt eigentlich alles automatisch alle paar Minuten. Nur INFO1,2,3 kommt glaube ich nur beim restart des Tasmota-Gerätes, oder in sehr großen Zeitabständen. Aber auch wenn sich das Gerät neu mit dem mqtt-Server verbindet.
Da wäre super, wenn man das IO-Device noch bestimmen würde und darüber ein set <IO-Device> publish <was es braucht, um die INFO- usw.-Readings direkt zu befüllen> abzusetzen. Dann hat der user direkt auch alle Readings angelegt, die er (z.B. in irgendwelchen ReadingsGrous) erwartet...

also das mit par:DEVNAME sollte so OK sein, vorausgesetzt autocreate ist an so dass die readingList gefüllt wird. Das ist natürlich so universeller. Daran habe ich nicht gedacht. Mit leerer readingList funktioniert par:DEVNAME, so wie ich das verstehe, nicht. Oder liege ich da falsch?
Wer meint, autocreate nicht nutzen zu wollen, weiß sich hoffentlich zu helfen. M.E. sollten die templates v.a. denen helfen, die eine Art "assisted configuration" wollen/benötigen.

Zitat
Prinzipiell haben wir aktuell 2 Varianten die grundsätzlich mit und ohne Präfix möglich wären, was dann 4 Varianten wären.

Ist die Variante mit Präfix in den Readings jetzt ganz raus? Wenn das keiner nutzt wäre die Frage ob autocreate das auch ohne wieder generiert. Wer das dann wirklich mit nutzen möchte, kann das ja jederzeit machen.
Wie gesagt, per default ist prefix ausgeschaltet und auch autocreate bringt das nicht zurück, selbst wenn man es einschaltet (war jedenfalls meine bisherige Erfahrung).
Zitat
Mir fällt hier aber kein Grund ein wo das einen Vorteil bringt? Ihr wisst ja ich war da von vorn herein kein Freund von ;-)
Es bringt dann einen Vorteil, wenn man ein "Einheitsdevice" bevorzugt, wie du das nachfolgend ja auch beschreibst. MAcht also an sich Sinn, aber eben nicht mehr, wenn die Topicstruktur so sauber vorbereitet ist wie bei Tasmota ;) .
Zitat
A_09x_tasmota_pure_base
als basis ist gut und klar. War ja auch ursprünglich von mir ;-) Würde aber zuerst autocreate auf 0, dann readingList und zum Schluss deleteReading machen. Ist zwar eher theoretischer natur aber wir wollen ja nicht, dass nach setzen von readingList per autocreate noch was rein kommt.
Schaue ich mir an, aber wir sprechen über minimale Zeiträume, oder?
Zitat
Das mit den Mehrfachgeräten finde ich insgesamt schon etwas seltsam. Bei einem ZWave Bewegungssensor macht ja auch keiner X-Geräte für Temperatur, Bewegungserkennung etc. Ist das wirklich allgemein benutzt bei Tasmota da mehrere Geräte in FHEM draus zu machen? Oder einfach nur weil viele nicht wussten wie sie das in einem Gerät machen können? Ich weiss ich war da der Vorreiter mit dem Template und ich hatte das früher auch in mehreren Geräten gemacht...
M.E. gibt es kein klares Votum für eine der beiden Varianten, beides hat m.E. seine Berechtigung:
Für Einheitsdevices spricht, dass in FHEMWEB alles beieinander  zu finden ist, was physisch zusammengehört. Dann benötigt man aber Umwege (z.B. ReadingsProxy), um sinnvolle Auszüge z.B. in einer Raumansicht darzustellen. Das kann man durch das Aufsplitten umgehen.

Aber z.B. einen Rolladenaktor sollte man nicht nach Kanälen auftrennen (daher im Parallelthread meine dringende Bitte an miggun, den 4-fach-Shelly AUCH als Einheitsdevice zu liefern (und die Empfehlung, dann nur 2x2 einzelne Kanäle für ROLLO zu nutzen).

Im Ergebnis meine ich: Man sollte klar rausarbeiten, dass beide Varianten möglich sind, dafür je firmwaretyp (shelly/tasmota/ESPEasy) je ein template "split" und "unified". Damit sollte sich gerade das Wissen vermitteln lassen, wie man das hinbekommen kann ;) .
Zitat
Zum Thema Firmware ist mir keine Firmware von Tasmota bekannt wo der Aufbau unterschiedlich ist. Von daher muss aktuell in der desc kein Hinweis auf eine bestimmte Firmware stehen.
Dann kommt es bei Gelegenheit wieder raus, sollte der Erhellung dienen, nicht der Verwirrung.

Zitat
Ansonsten sind die aktuellen Template Versionen nicht ganz sauber.

Template A_01a wird nicht benötigt und funktioniert auch nicht. Bei einem 1 channel device wird in State etc. kein POWER1 sondern POWER zurückgegeben! Das heisst der Status wird so nicht aktualisiert.

Gerät A_01 sollte heißen:desc: Applies to devices with one POWER reading like Sonoff Basic, S20, ...

Der Name vom A_01a Template wäre eigentlich super für A_01 da allgemein sonoff Basic ist da nur eine Variante unter sehr vielen bei Tasmota
Danke für den Hinweis. Die A_01 war nur im desc irreführend, oder? Das andere habe ich umbenannt, da das bei mehrkanaligen als template für den ersten Kanal dient - auch hier der Gedanke: am Beispiel lernen.
Zitat
Statt bei COMMAND/POWER1 Ziffern, sollten eigentlich die Texte verwendet werden 0 ist off, 1 ist on, 2 ist toggle. Gibt es da nicht vielleicht auch eine elegantere Variante, dass der Parameter gleich benutzt wird? Schließlich ist
off:noArg COMMAND/POWER1 off
doppelt off ;-) oder eventuell dass mit in setlist das nicht einzeln aufführen muss? wie z. B. beim 4 channel Gerät mit
p1:on,off  COMMAND/POWER1 $EVTPART1

Falls die zusammengefassten Tasmota Geräte gewünscht werden, kann ich auch die templates überarbeiten und hier nochmal bereitstellen.

Bitte ggf. den hier beachten: https://forum.fhem.de/index.php/topic,94495.0.html
(und gerne hier oder gesondert auch Rückmeldung zu den Hinweisen da geben, wenn Verbesserungsvorschläge bestehen).
Hmmm, also dazu folgendes:
Mein Wunsch an Rudi war, bei Schaltanweisungen ein "set_" voranzustellen und das dann jeweils auf state oder das passende Reading zu schreiben (bis die erfolgreiche Ausführung zurückgemeldet wird), hatte dazu auch einen patch vorgeschlagen.
Dazu muß man aber "state"-bezogene und "sonstige Reading-bezogene" Anweisungen unterscheiden können. Will hier bedeuten: on und off, die direkt als "set_on" bzw. "set_off" in den state geschrieben werden sollen, müssen einzelne (:noArg)-Zeilen bleiben, der Rest kann so mit $EVENT arbeiten wie von Dir vorgeschlagen.

Zitat
Was mich an den Templates im Moment am meisten stört, ist dass ich noch keine Lösung habe um über die Icons zu schalten, sprich ein toggle abzusetzen. Ansonsten passt das für mich sehr gut. Bis auf p1, p2 etc in was sprechendes umbenennen und gegebenenfalls die Symbole z. B. auf sani_buffer_temp_down und sani_buffer_temp_up umzustellen, mache ich jetzt bei Neuinbetriebnahmen nichts mehr wesentliches und es geht ruck zuck.
Für die Icon-Sache habe ich im Moment auch keine wirkliche Idee (mangels Device auch keine "Spieloption"), wirf vielleicht mal einen Blick auf diesen Post: https://forum.fhem.de/index.php/topic,86932.msg860636.html#msg860636, da ist evtl. ein Lösungsansatz zu finden.

Was die Umbenennung von "p1, p2" angeht: Macht es Sinn, erst mal die richtige (?) Reading-Benennung zu verwenden (p1=POWER1)? Dann wäre das insoweit konsistent (und ggf. sogar schaltbar?)

Ansonsten freue ich mich, wenn du weitere Templates für die jeweiligen Varianten beisteuern würdest, es kann ja eigentlich kein besseres Ergebnis geben wie: "mache ich jetzt bei Neuinbetriebnahmen nichts mehr wesentliches und es geht ruck zuck"

Zitat
Bitte entschuldigt den langen Post und ich will da auch keinem auf die Nerven gehen, mich würde auch sehr interessieren, wie andere ihre Tasmota konfigurieren. Eventuell wäre da sogar ein eigener Thread sehr interessant zum Austausch.
Ist schon ok mit der Länge, steckt ja auch einiges drin ;) .

Gerne dürft ihr weiterdiskutieren, was wie am besten@tasmota zu konfigurieren ist :) . Die allseits als sehr gut empfundenen Varianten sollten dann in die templates, oder? ;) 8) ::)

Schönes WE allseits!
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 15 Dezember 2018, 14:39:38
Template A_01a wird nicht benötigt und funktioniert auch nicht. Bei einem 1 channel device wird in State etc. kein POWER1 sondern POWER zurückgegeben! Das heisst der Status wird so nicht aktualisiert.
das habe ich auch schon bemerkt, da ich heute mal die Neue Version im Update geholt habe, soll heißen ich musste bei
stateFormat{lc ReadingsVal("$name","POWER","") }die "1" ergänzen bei POWER, weil er mir sonst kein devStateIcon anzeigt egal was ich dort eingebe.

Hast du evtl. zu dem devStateIcon eine Lösung..?
Ich z.B. nutze bei allen Sonoff Basic, da sie alle Lampen schalten dieses Icon der Glühlampe welches mir am besten gefällt ist aber ja Ansichtssache

So zeigt er mir die Glülampe an, vorausgesetzt es steht da POWER1:
on:li_wht_on:off off:li_wht_off:on
So zeigt er mir das andere svg Icon, aber auch hier muss POWER1 stehen
ON:li_wht_on:OFF OFF:li_wht_off:ON
ich denke hier wird sich noch einiges ändern lassen da die Geschmäcker da verschieden sind

Nur INFO1,2,3 kommt glaube ich nur beim restart des Tasmota-Gerätes, oder in sehr großen Zeitabständen. Aber auch wenn sich das Gerät neu mit dem mqtt-Server verbindet.
ja da hast du vollkommen Recht, dass wußte ich nicht, denn ich habe ums verrecken keine Infos rein bekommen  :-\
Aber nach dem Neustart des Gerätes waren sie alle da. Vielen Dank

Als Ergänzung hier mal die readings die jetzt alle rein kommen:
READINGS:
     2018-12-15 14:24:07   FallbackTopic   DVES_3B5E50
     2018-12-15 14:24:07   GroupTopic      sonoffs
     2018-12-15 14:24:07   Hostname        WZ_Schrank-7760
     2018-12-15 14:24:07   IPAddress       10.0.0.152
     2018-12-15 14:24:07   LWT             online
     2018-12-15 14:24:07   Module          Sonoff Basic
     2018-12-15 14:24:07   POWER           
     2018-12-15 14:45:38   POWER1          ON
     2018-12-15 14:24:07   RestartReason   Software/System restart
     2018-12-15 14:44:16   Time            2018-12-15T14:44:13
     2018-12-15 14:44:16   Uptime          0T00:20:13
     2018-12-15 14:44:16   Vcc             3.247
     2018-12-15 14:24:07   Version         6.3.0
     2018-12-15 14:24:07   WebServerMode   Admin
     2018-12-15 14:44:16   Wifi_AP         1
     2018-12-15 14:44:16   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-15 14:44:16   Wifi_Channel    11
     2018-12-15 14:44:16   Wifi_RSSI       100
     2018-12-15 14:44:16   Wifi_SSId       xxxxxxxxxxxxxxxxxxx
     2018-12-15 14:45:38   state           on

und das komplette list meines Sonoff Basic:
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_3B5E50
   DEF        DVES_3B5E50
   DEVICETOPIC WZ_Schrank
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     31
   NAME       WZ_Schrank
   NR         4843
   STATE      off
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 31
   m2server_TIME 2018-12-15 14:48:27
   READINGS:
     2018-12-15 14:24:07   FallbackTopic   DVES_3B5E50
     2018-12-15 14:24:07   GroupTopic      sonoffs
     2018-12-15 14:24:07   Hostname        WZ_Schrank-7760
     2018-12-15 14:24:07   IPAddress       10.0.0.152
     2018-12-15 14:24:07   LWT             online
     2018-12-15 14:24:07   Module          Sonoff Basic
     2018-12-15 14:24:07   POWER           
     2018-12-15 14:48:27   POWER1          OFF
     2018-12-15 14:24:07   RestartReason   Software/System restart
     2018-12-15 14:44:16   Time            2018-12-15T14:44:13
     2018-12-15 14:44:16   Uptime          0T00:20:13
     2018-12-15 14:44:16   Vcc             3.247
     2018-12-15 14:24:07   Version         6.3.0
     2018-12-15 14:24:07   WebServerMode   Admin
     2018-12-15 14:44:16   Wifi_AP         1
     2018-12-15 14:44:16   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-15 14:44:16   Wifi_Channel    11
     2018-12-15 14:44:16   Wifi_RSSI       100
     2018-12-15 14:44:16   Wifi_SSId       xxxxxxxxxxxxxxxxxxxxxxxx
     2018-12-15 14:48:27   state           off
Attributes:
   IODev      m2server
   alias      Wohnzimmer Schrank - Vitrine
   autocreate 0
   devStateIcon on:li_wht_on:off off:li_wht_off:on
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   group      Beleuchtung Wohnzimmer
   icon       light_cabinet@#FF6D00
   readingList tele/WZ_Schrank/LWT:.* LWT
  cmnd/WZ_Schrank/POWER:.* POWER
  stat/WZ_Schrank/POWER1:.* POWER1
  tele/WZ_Schrank/STATE:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/SENSOR:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO.:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO1:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO2:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO3:.* { json2nameValue($EVENT) }
  stat/WZ_Schrank/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT,Wohnzimmer
   setList    off:noArg    cmnd/WZ_Schrank/POWER1 0
  on:noArg     cmnd/WZ_Schrank/POWER1 1
  toggle:noArg cmnd/WZ_Schrank/POWER1 2
   sortby     06
   stateFormat {lc ReadingsVal("$name","POWER1","") }
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 15 Dezember 2018, 14:52:03
Hmm, also brauchen wir doch beide - dann stimmt der gerade eingecheckte desc zu der umbenannten 01x-Version wieder nicht, oder verstehe ich hier was miß?...

@moonsorrox: beide templates sind (im Ergebnis) praktisch gleich, nur eben im stateFormat unterschiedlich. Eines sollte ohne Modifikationen passen.

ja da hast du vollkommen Recht, dass wußte ich nicht, denn ich habe ums verrecken keine Infos rein bekommen  :-\
Aber nach dem Neustart des Gerätes waren sie alle da. Vielen Dank
Dann bitte die Info, was man absetzen muß, um den ESP zu "überreden", die Infos zu liefern ::) . (Siehe meinen vorherigen Post). Muß vermutlich kein reboot sein, notfalls aber eben auch das...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 15 Dezember 2018, 15:00:50
Hmm, also brauchen wir doch beide - dann stimmt der gerade eingecheckte desc zu der umbenannten 01x-Version wieder nicht, oder verstehe ich hier was miß?...
das habe ich noch nicht kapiert  :-\ weil ich auch gestern schon sagte das ich bei POWER die "1" brauche, oder wir haben beide von etwas anderem gesprochen  ;)

Also ich habe heute zum anlegen des Sonoff Basic den "A_01_tasmota_basic_noprefix" genutzt..!
Wenn du magst kann ich den nochmal komplett löschen und einmal beide Varianten anlegen lassen, also
1. A_01_tasmota_basic_noprefix und
2. A_01a_tasmota_1channel_noprefix
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 15 Dezember 2018, 15:22:10
Ok, jetzt ist  hoffentlich auch bei mir der Groschen vollends gefallen.
Für stateFormat also POWER1 bei allen Varianten, der Basic kann daher wirklich für alles als Basis herangezogen werden, auch bzgl. der readingList :D .
Nochmals aktualisierte Version im svn, so bekomme ich das auch geübt ::) .

Wenn das dann effektiv paßt, fliegen die jetzt auskommentierten Teile raus.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 15 Dezember 2018, 15:31:22
Zur Info...
ich habe Sonoff Basic, Sonoff 4CH, Sonoff Dual und Sonoff S20 zur Verfügung und zum testen, fehlt noch Sonoff Pow und Sonoff Touch 1-3 mehr kenne ich nicht  :-\ ;)
Die Touch gibt es jetzt auch in Black sehen sehr gut aus und davon hole ich mir die Tage den 3-Kanal

Ein Basic hat noch die Tasmota Version 5.12.0, weil ich nicht über OTA updaten kann und den erst später ausbauen muss um ihn über FTDI zu flaschen..!
Alle anderen  haben Tasmota Version 6.3.0
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 15 Dezember 2018, 16:46:54
Dann melde ich mich jetzt mal zum Sonoff Dual..!

Aber ich denke da bist du sicher noch nicht soweit um den anzupassen, oder sollte der fertig sein..?
Da ist noch einiges komplett anders... aber hier erst mal zur Information für dich, wenn du noch etwas brauchst sag bescheid

Den Dual habe ich jetzt mal per "template A02a_" eingerichtet und habe mich gewundert warum der in meiner readingsgroup nicht auftaucht.
Eine Info zum Gerät bei Tasmota muss ich ihn anlegen als Dual R2, den anderen der nur Dual heißt, der funktioniert bei mir nicht weil ich wohl einen der neueren Generation habe.

Dann hat er mir davon gleich zwei erstellt obwohl ich nur einen definiert habe, diesen hier "HWR_Dual" habe ich angelegt und den "HWR_Dual_CH2" hat er selber erstellt.
Bei einem hat er keine setlist angelegt bei dem anderen hat er eine setlist angelegt, die angelegte setlist sieht aber komplett anders aus als die der vorherigen Geräte und deshalb schaltet er wohl auch nicht
So sieht die setlist aus vom HWR_Dual_CH2:
off:noArg    COMMAND/POWER2 0
  on:noArg     COMMAND/POWER2 1
  toggle:noArg COMMAND/POWER2 2

readinglist wurde bei beiden Geräten angelegt angelegt.

Ich werde die jetzt nochmals löschen, denn mein MQTT Server sollte doch mit Autocreate die Geräte sobald sie gesehen werden erstellen. Denn ich hatte den Dual vorher ausser Betrieb, da ich ihn aber jetzt einsetzen möchte in meinem HWR wollte ich den mal in Betrieb nehmen.

Habe jetzt nochmal den unten von Hand angelegt
Er hat bei den ersten Angaben andere Readings die mit INFO1-3 beginnen, das denke ich braucht nicht sein da sie ja auch für den zweiten Kanal gelten. Oder die anderen Geräte müßten alle auch so benannt werden da wir sonst Unterschiede in den Readings haben.
Hier mal das list:
Internals:
   CFGFN     
   CID        DVES_98C414
   DEF        DVES_98C414
   DEVICETOPIC HWR_Dual
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     1
   NAME       HWR_Dual
   NR         5806
   STATE      off
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 1
   m2server_TIME 2018-12-15 16:38:56
   READINGS:
     2018-12-15 16:38:48   INFO1_FallbackTopic DVES_98C414
     2018-12-15 16:38:48   INFO1_GroupTopic sonoffs
     2018-12-15 16:38:48   INFO1_Module    Sonoff Dual R2
     2018-12-15 16:38:48   INFO1_Version   6.3.0
     2018-12-15 16:38:48   INFO2_Hostname  HWR_Dual-1044
     2018-12-15 16:38:48   INFO2_IPAddress 10.0.0.154
     2018-12-15 16:38:48   INFO2_WebServerMode Admin
     2018-12-15 16:38:48   INFO3_RestartReason Software/System restart
     2018-12-15 16:38:48   LWT             online
     2018-12-15 16:38:48   POWER           
     2018-12-15 16:38:48   POWER1          OFF
     2018-12-15 16:38:48   POWER2          OFF
     2018-12-15 16:38:48   RESULT_POWER1   OFF
     2018-12-15 16:38:48   RESULT_POWER2   OFF
     2018-12-15 16:38:56   STATE_POWER1    OFF
     2018-12-15 16:38:56   STATE_POWER2    OFF
     2018-12-15 16:38:56   STATE_Time      2018-12-15T16:38:56
     2018-12-15 16:38:56   STATE_Uptime    0T00:00:14
     2018-12-15 16:38:56   STATE_Vcc       3.134
     2018-12-15 16:38:56   STATE_Wifi_AP   2
     2018-12-15 16:38:56   STATE_Wifi_BSSId 9C:C7:A6:08:43:67
     2018-12-15 16:38:56   STATE_Wifi_Channel 8
     2018-12-15 16:38:56   STATE_Wifi_RSSI 100
     2018-12-15 16:38:56   STATE_Wifi_SSId xxxxxxxxxxxxxxx
Attributes:
   IODev      m2server
   comment    Channel 1 for HWR_Dual, see also HWR_Dual_CH2
   readingList DVES_98C414:tele/HWR_Dual/STATE:.* { json2nameValue($EVENT, 'STATE_') }
DVES_98C414:tele/HWR_Dual/LWT:.* LWT
DVES_98C414:cmnd/HWR_Dual/POWER:.* POWER
DVES_98C414:tele/HWR_Dual/INFO1:.* { json2nameValue($EVENT, 'INFO1_') }
DVES_98C414:tele/HWR_Dual/INFO2:.* { json2nameValue($EVENT, 'INFO2_') }
DVES_98C414:tele/HWR_Dual/INFO3:.* { json2nameValue($EVENT, 'INFO3_') }
DVES_98C414:stat/HWR_Dual/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }
DVES_98C414:stat/HWR_Dual/POWER1:.* POWER1
DVES_98C414:stat/HWR_Dual/RESULT:.* { json2nameValue($EVENT, 'RESULT_') }
DVES_98C414:stat/HWR_Dual/POWER2:.* POWER2
   room       MQTT
   stateFormat {lc ReadingsVal("$name","POWER1","") }

Übrigens ich habe beide gelöscht und nun habe ich nur den einen.

Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 15 Dezember 2018, 17:17:34
Dann melde ich mich jetzt mal zum Sonoff Dual..!

Aber ich denke da bist du sicher noch nicht soweit um den anzupassen, oder sollte der fertig sein..?
Hmmm, wie ich das sehe, könnte da das 4-ch-template (one device) an sich passen, müßte aber eben um die zwei Kanäle gekürzt werden.

Du hast das 2-ch-template verwendet, oder? Da ist es "normal", dass zwei Devices angelegt werden, steht auch so in der desc. Komisch ist aber, dass er COMMAND nicht übersetzt hat. Da sollte stattdessen "tele/HWR_Dual" stehen.

Ansonsten sehe ich im Moment nicht, dass der von der MQTT-Seite her speziell wäre.

Kann aber grade nicht intensiv drüber sehen, versuch dich ruhig selbst (nach der Anleitung in dem contribute-Thread).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 15 Dezember 2018, 17:22:41
Ja ich habe dieses verwednet "template A02a_"

Ehrlich gesagt finde ich das anlegen der zwei Kanäle wesentlich übersichtlicher und besser, es erscheinen beide Kanäle und das ist gut so als wenn man da alle in einem hat, das kann man besser Konfigurieren da ja sowieso alle für andere Geräte verwendet werden.
Das sollte man mal in die Runde fragen was da gewünscht ist..!

Ja das mit der setlist habe ich schon bereinigt bei mir und dann schaltet es auch  ;)

Die anderen readings versuche ich mal in meiner rg unterzubringen damit diese auf zwei unterschiedliche readings anspricht

Ich hänge mal den Screenshot meiner MQTT Geräte ran  ;)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: tpm88 am 15 Dezember 2018, 21:56:40
Ok, jetzt ist  hoffentlich auch bei mir der Groschen vollends gefallen.
Für stateFormat also POWER1 bei allen Varianten, der Basic kann daher wirklich für alles als Basis herangezogen werden, auch bzgl. der readingList :D .

Nochmal, POWER1 (mit "1") als Reading und für stateFormat ist NUR dann korrekt, wenn

SetOption26 1 gesetzt ist.

Default in der Tasmota Firmware (zumindest Release 6.3.0) ist aber SetOption26 0
Wie @carlos bereits oben in Antwort 10 schrieb:
SetOption26    0 / off    (default) Keep using POWER without postfix for single power devices

Das gilt sowohl für die S2x (also S20, S26) als auch den Basic.

@moonsorrox: Wie ist bei Dir SetOption26 bei deinen Basic/S2x gesetzt??

Das ist meiner Meinung nach die Verwirrung, ob im stateFormat die "1" benötigt wird, oder nicht. Bei mir mit SetOption26 = 0 (Default) DARF eben KEINE "1" im stateFormat sein!

In der setList hingegen ist POWER1 IMMER richtig (unabhängig von SetOption26).

Hier ein Auszug für einen Schaltvorgang aus dem verbose5 Log vom MQTT2-Server für SetOption26 = 0:
2018.12.15 21:35:30 4: my_MQTT2_192.168.8.89_2514 DVES_324190 PUBLISH stat/sonoff_basic_01/RESULT:{"POWER":"OFF"}
2018.12.15 21:35:30 4: my_MQTT2_192.168.8.89_2514 DVES_324190 PUBLISH stat/sonoff_basic_01/POWER:OFF
Reading: POWER (ohne "1")

Und jetzt wieder ein Schaltvorgang nach Setzen von  SetOption 26 = 1:
2018.12.15 21:38:24 4: my_MQTT2_192.168.8.89_2514 DVES_324190 PUBLISH stat/sonoff_basic_01/RESULT:{"SetOption26":"ON"}
2018.12.15 21:38:28 4: my_MQTT2_192.168.8.89_2514 DVES_324190 PINGREQ
2018.12.15 21:38:43 4: my_MQTT2_192.168.8.89_2514 DVES_324190 PUBLISH stat/sonoff_basic_01/RESULT:{"POWER1":"ON"}
2018.12.15 21:38:43 4: my_MQTT2_192.168.8.89_2514 DVES_324190 PUBLISH stat/sonoff_basic_01/POWER1:ON
Reading POWER1 (mit "1")

Gruß
Tobias
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 15 Dezember 2018, 22:02:20
Ok, jetzt ist  hoffentlich auch bei mir der Groschen vollends gefallen.
Für stateFormat also POWER1 bei allen Varianten, der Basic kann daher wirklich für alles als Basis herangezogen werden, auch bzgl. der readingList :D .
Nochmals aktualisierte Version im svn, so bekomme ich das auch geübt ::) .

Wenn das dann effektiv paßt, fliegen die jetzt auskommentierten Teile raus.

@moonsorrox

 habe hier 5 Basic mit 6.3.0 laufen und die liefern alle POWER in State, result, etc. Bist du sicher dass du das aktuelle template angewendet hast? Bei deinen Beispielen ist zum Teil die readinglist nicht gelöscht, so dass dort info1 etc noch einzeln auftaucht.

Bei Geräten mit mehr als einem relay  muss für stateformat power1, etc. Verwendet werden. Bei nur einem Kanal nur power. Du siehst das auch in der Konsole von tasmota.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 15 Dezember 2018, 22:25:20
Nochmal, POWER1 (mit "1") als Reading und für stateFormat ist NUR dann korrekt, wenn

SetOption26 1 gesetzt ist.

Default in der Tasmota Firmware (zumindest Release 6.3.0) ist aber SetOption26 0

Deutlicher und präziser geht es nicht mehr. Nur dass Power und power1 bei setlist immer beides geht.

zumindest seit einem Jahr und ab Version 5 von tasmota war das und der Standard noch nie anders.

Die Templates sind für die Standardkonfiguration da sind wir uns doch alle einig.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 15 Dezember 2018, 23:15:26
Im Ergebnis meine ich: Man sollte klar rausarbeiten, dass beide Varianten möglich sind, dafür je firmwaretyp (shelly/tasmota/ESPEasy) je ein template "split" und "unified".

Ja dann wäre mein Vorschlag bei allen Tasmota templates split oder unified in den template-Namen aufzunehmen dass das gleich klar ist.

Danke für den Hinweis. Die A_01 war nur im desc irreführend, oder?

Description ja, dazu der Template Name von dem 1channel ;-) weil es ist nicht nur basic sondern immer 1channel, wie sonoff Basic und Konsorten aber auch Wemos D1/Generic

Mein Wunsch an Rudi war, bei Schaltanweisungen ein "set_" voranzustellen und das dann jeweils auf state oder das passende Reading zu schreiben (bis die erfolgreiche Ausführung zurückgemeldet wird), hatte dazu auch einen patch vorgeschlagen.

Macht das Sinn? die Antwort kommt doch innerhalb von millisekunden in der Result-Nachricht. Ansonsten gibt es ein großeres Problem.
Hört sich für mich nach zu viel Aufwand an für ein praktisch nicht vorhandenes Problem. Wir reden hier von Tasmota mit WLAN nicht von ZWAVE ;-)

Was die Umbenennung von "p1, p2" angeht: Macht es Sinn, erst mal die richtige (?) Reading-Benennung zu verwenden (p1=POWER1)? Dann wäre das insoweit konsistent (und ggf. sogar schaltbar?)

Die Abkürzungen kamen eher daher, dass die Zeile bei 4 oder bei mehr Geräten mit 8 channels sehr lang wird. Wenn vorne und bei webcmd alles ausgeschrieben wird.

Für kombinierte Ansichten verwende ich eher Readinggroups um z. B. den LWT-Status in einer Ansicht über alle Geräte anzuzeigen oder von allen die Temperatur bzw. Bewegungsalarme. Da käme ich nie auf die Idee dafür extra Geräte in FHEM anzulegen.

Für mich sind Geräte erst mal die Hardware-Geräte, das zweite ist dann wie über FHEM Ansichten aufgebaut werden. Ich finde die Hardwareebene (echte Geräte) und die logische Ebene (Funktionalitäten) sollten (und können ja in FHEM auch perfekt) getrennt betrachtet werden.

Würde ich tatsächlich für jede Funktion ein extra Gerät erstellen wäre ich aktuell bei mindestens 200 statt nur 50 echten Geräten. Wahrscheinlich wären das sogar noch mehr. Nur für POWER wollen hier einige die Geräte splitten und damit auch die Readings vervielfachen, da ja STATE, RESULT, SENSOR etc. ja die Daten von allen Kanälen liefern. Komme mir jetzt keiner mit cmnd das allein reicht nicht um Fehler zu erkennen.

Für Markisensteuerung, Rollos etc. braucht man ja sowieso dummies bzw. zusätzliche Module um das umzusetzen, das Hardwaregerät allein reicht da nur selten. Also warum da inkonsequent POWER anders behandeln als einen Sensor? Nur weil der nicht direkt steuert? OK OK bin da vielleicht zu dogmatisch ... Noch einen schönen Abend und gute Nacht.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 16 Dezember 2018, 13:36:27
@moonsorrox: Wie ist bei Dir SetOption26 bei deinen Basic/S2x gesetzt??
ganz ehrlich ich weiß jetzt gar nicht wo das sein soll und gesetzt wird, ich habe diese Option noch nirgends gesehen.
Bitte einmal sagen wo ich diese Option setzen kann/soll

Hier mal zwei Auszüge aus der Konsole von 2 Sonoff Basic
12:43:03 MQT: tele/AU_Garten/STATE = {"Time":"2018-12-16T12:43:03","Uptime":"2T20:43:00","Vcc":3.157,"POWER1":"OFF","Wifi":{"AP":1,"SSId":"xxxxxxxxxxxxxxxxxxxxxxx","BSSId":"9C:C7:A6:11:3E:A5","Channel":11,"RSSI":78}}
12:48:03 MQT: tele/AU_Garten/STATE = {"Time":"2018-12-16T12:48:03","Uptime":"2T20:48:00","Vcc":3.156,"POWER1":"OFF","Wifi":{"AP":1,"SSId":"xxxxxxxxxxxxxxxxxxxxxxx","BSSId":"9C:C7:A6:11:3E:A5","Channel":11,"RSSI":76}}
12:53:03 MQT: tele/AU_Garten/STATE = {"Time":"2018-12-16T12:53:03","Uptime":"2T20:53:00","Vcc":3.170,"POWER1":"OFF","Wifi":{"AP":1,"SSId":"xxxxxxxxxxxxxxxxxxxxxxx","BSSId":"9C:C7:A6:11:3E:A5","Channel":11,"RSSI":78}}

und noch einer
12:41:11 MQT: tele/WZ_Schrank/STATE = {"Time":"2018-12-16T12:41:11","Uptime":"0T22:17:11","Vcc":3.246,"POWER1":"OFF","Wifi":{"AP":1,"SSId":"xxxxxxxxxxxxxxxxxxxxxxx","BSSId":"9C:C7:A6:11:3E:A5","Channel":11,"RSSI":100}}
12:46:11 MQT: tele/WZ_Schrank/STATE = {"Time":"2018-12-16T12:46:11","Uptime":"0T22:22:11","Vcc":3.245,"POWER1":"OFF","Wifi":{"AP":1,"SSId":"xxxxxxxxxxxxxxxxxxxxxxx","BSSId":"9C:C7:A6:11:3E:A5","Channel":11,"RSSI":100}}
12:51:11 MQT: tele/WZ_Schrank/STATE = {"Time":"2018-12-16T12:51:11","Uptime":"0T22:27:11","Vcc":3.256,"POWER1":"OFF","Wifi":{"AP":1,"SSId":"xxxxxxxxxxxxxxxxxxxxxxx","BSSId":"9C:C7:A6:11:3E:A5","Channel":11,"RSSI":100}}

@moonsorrox

 habe hier 5 Basic mit 6.3.0 laufen und die liefern alle POWER in State, result, etc. Bist du sicher dass du das aktuelle template angewendet hast? Bei deinen Beispielen ist zum Teil die readinglist nicht gelöscht, so dass dort info1 etc noch einzeln auftaucht.

Bei Geräten mit mehr als einem relay  muss für stateformat power1, etc. Verwendet werden. Bei nur einem Kanal nur power. Du siehst das auch in der Konsole von tasmota.

schau mal hier die lists von 3 Basic
Diesen habe ich schon länger im Einsatz und ohne template eingerichtet, aber durch autocreate
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_951CF3
   DEF        DVES_951CF3
   DEVICETOPIC AU_Landroid
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     265
   NAME       AU_Landroid
   NR         4805
   STATE      OFF
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 265
   m2server_TIME 2018-12-16 13:23:50
   READINGS:
     2018-12-13 16:01:40   FallbackTopic   DVES_951CF3
     2018-12-13 16:01:40   GroupTopic      sonoffs
     2018-12-13 16:01:40   Hostname        AU_Landroid-7411
     2018-12-13 16:01:40   IPAddress       10.0.0.151
     2018-12-15 17:33:13   LWT             online
     2018-12-13 16:01:40   Module          Sonoff Basic
     2018-12-12 15:48:42   OtaUrl          https://github.com/arendst/Sonoff-Tasmota/releases/download/v6.3.0/sonoff-DE.bin
     2018-12-16 13:23:50   POWER           OFF
     2018-12-13 16:01:40   RestartReason   Software/System restart
     2018-12-16 13:23:50   Time            2018.12.16 13:23:48
     2018-12-12 15:48:54   UPGRADE         Failed HTTP error: connection refused
     2018-12-12 15:48:42   Upgrade         Version 5.12.0 from https://github.com/arendst/Sonoff-Tasmota/releases/download/v6.3.0/sonoff-DE.bin
     2018-12-16 13:23:50   Uptime          2 21:20:15
     2018-12-16 13:23:50   Vcc             3.481
     2018-12-13 16:01:40   Version         5.12.0
     2018-12-13 16:01:40   WebServerMode   Admin
     2018-12-16 13:23:50   Wifi_AP         2
     2018-12-16 13:23:50   Wifi_APMac      9C:C7:A6:08:43:67
     2018-12-16 13:23:50   Wifi_RSSI       36
     2018-12-16 13:23:50   Wifi_SSId       xxxxxxxxxxxxxxxxxxxxxxx
     2018-12-13 16:01:40   config         
     2018-12-15 17:56:01   state           off
Attributes:
   IODev      m2server
   alias      Ladestation Landy - IP 10.0.0.151
   devStateIcon ON:message_socket_enabled@crimson OFF:message_socket_off@lightgreen
   eventMap   on:Ein off:Aus
   group      Rasenmäher - Landy
   icon       scene_robo_lawnmower@blue
   readingList DVES_951CF3:tele/AU_Landroid/LWT:.* LWT
DVES_951CF3:cmnd/AU_Landroid/POWER:.* POWER
DVES_951CF3:tele/AU_Landroid/INFO1:.* { json2nameValue($EVENT) }
DVES_951CF3:tele/AU_Landroid/INFO2:.* { json2nameValue($EVENT) }
DVES_951CF3:tele/AU_Landroid/INFO3:.* { json2nameValue($EVENT) }
DVES_951CF3:stat/AU_Landroid/RESULT:.* { json2nameValue($EVENT) }
DVES_951CF3:stat/AU_Landroid/POWER:.* POWER
DVES_951CF3:tele/AU_Landroid/STATE:.* { json2nameValue($EVENT) }
DVES_951CF3:tele/AU_Landroid/UPTIME:.* { json2nameValue($EVENT) }
DVES_951CF3:homeassistant/switch/AU_Landroid/config:.* config
DVES_951CF3:stat/AU_Landroid/UPGRADE:.* UPGRADE
   room       Draußen,MQTT
   setList    on cmnd/AU_Landroid/POWER ON
off cmnd/AU_Landroid/POWER OFF
   stateFormat POWER
   webCmd     Ein:Aus

dieser ebenfalls mit autocreate
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_3AFF88
   DEF        DVES_3AFF88
   DEVICETOPIC AU_Garten
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     261
   NAME       AU_Garten
   NR         4820
   STATE      OFF
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 261
   m2server_TIME 2018-12-16 13:18:10
   READINGS:
     2018-12-13 16:00:39   FallbackTopic   DVES_3AFF88
     2018-12-13 16:00:39   GroupTopic      sonoffs
     2018-12-13 16:00:39   Hostname        AU_Garten-8072
     2018-12-13 16:00:39   IPAddress       10.0.0.150
     2018-12-15 17:33:14   LWT             online
     2018-12-13 16:00:39   Module          Sonoff Basic
     2018-12-15 17:33:14   POWER           
     2018-12-16 13:18:10   POWER1          OFF
     2018-12-13 16:00:39   RestartReason   Software/System restart
     2018-12-16 13:18:10   Time            2018-12-16T13:18:05
     2018-12-16 13:18:10   Uptime          2T21:18:02
     2018-12-16 13:18:10   Vcc             3.171
     2018-12-13 16:00:39   Version         6.3.0
     2018-12-13 16:00:39   WebServerMode   Admin
     2018-12-16 13:18:10   Wifi_AP         1
     2018-12-12 14:07:22   Wifi_APMac      9C:C7:A6:11:3E:A5
     2018-12-16 13:18:10   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-16 13:18:10   Wifi_Channel    11
     2018-12-16 13:18:10   Wifi_RSSI       74
     2018-12-16 13:18:10   Wifi_SSId       xxxxxxxxxxxxxxxxxxxxxxx
     2018-12-16 00:45:00   state           off
Attributes:
   IODev      m2server
   alias      Garten Lampen
   devStateIcon ON:li_wht_on:OFF OFF:li_wht_off:ON
   eventMap   on:Ein off:Aus
   group      Aussen Beleuchtung Garten
   icon       light_uplight@blue
   readingList DVES_3AFF88:tele/AU_Garten/LWT:.* LWT
DVES_3AFF88:cmnd/AU_Garten/POWER:.* POWER
DVES_3AFF88:tele/AU_Garten/INFO1:.* { json2nameValue($EVENT) }
DVES_3AFF88:tele/AU_Garten/INFO2:.* { json2nameValue($EVENT) }
DVES_3AFF88:tele/AU_Garten/INFO3:.* { json2nameValue($EVENT) }
DVES_3AFF88:stat/AU_Garten/RESULT:.* { json2nameValue($EVENT) }
DVES_3AFF88:tele/AU_Garten/STATE:.* { json2nameValue($EVENT) }
DVES_3AFF88:tele/AU_Garten/UPTIME:.* { json2nameValue($EVENT) }
DVES_3AFF88:stat/AU_Garten/POWER1:.* POWER1
   room       Draußen,MQTT
   setList    off:noArg    cmnd/AU_Garten/POWER1 0
on:noArg     cmnd/AU_Garten/POWER1 1
toggle:noArg cmnd/AU_Garten/POWER1 2
   sortby     02
   stateFormat POWER1
   userattr   room_map structexclude

diesen hier habe ich vor 2 Tagen auf MQTT2 mit template "A_01_tasmota_basic_noprefix" erstellt
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_3B5E50
   DEF        DVES_3B5E50
   DEVICETOPIC WZ_Schrank
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     273
   NAME       WZ_Schrank
   NR         4843
   STATE      off
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 273
   m2server_TIME 2018-12-16 13:16:19
   READINGS:
     2018-12-15 14:24:07   FallbackTopic   DVES_3B5E50
     2018-12-15 14:24:07   GroupTopic      sonoffs
     2018-12-15 14:24:07   Hostname        WZ_Schrank-7760
     2018-12-15 14:24:07   IPAddress       10.0.0.152
     2018-12-15 17:33:12   LWT             online
     2018-12-15 14:24:07   Module          Sonoff Basic
     2018-12-15 17:33:12   POWER           
     2018-12-16 13:16:19   POWER1          OFF
     2018-12-15 14:24:07   RestartReason   Software/System restart
     2018-12-16 13:16:19   Time            2018-12-16T13:16:14
     2018-12-16 13:16:19   Uptime          0T22:52:14
     2018-12-16 13:16:19   Vcc             3.239
     2018-12-15 14:24:07   Version         6.3.0
     2018-12-15 14:24:07   WebServerMode   Admin
     2018-12-16 13:16:19   Wifi_AP         1
     2018-12-16 13:16:19   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2018-12-16 13:16:19   Wifi_Channel    11
     2018-12-16 13:16:19   Wifi_RSSI       100
     2018-12-16 13:16:19   Wifi_SSId       xxxxxxxxxxxxxxxxxxxxxxx
     2018-12-16 01:56:11   state           off
Attributes:
   IODev      m2server
   alias      Wohnzimmer Schrank - Vitrine
   autocreate 0
   devStateIcon on:li_wht_on:off off:li_wht_off:on
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   group      Beleuchtung Wohnzimmer
   icon       light_cabinet@#FF6D00
   readingList tele/WZ_Schrank/LWT:.* LWT
  cmnd/WZ_Schrank/POWER:.* POWER
  stat/WZ_Schrank/POWER1:.* POWER1
  tele/WZ_Schrank/STATE:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/SENSOR:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO.:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO1:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO2:.* { json2nameValue($EVENT) }
  tele/WZ_Schrank/INFO3:.* { json2nameValue($EVENT) }
  stat/WZ_Schrank/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT,Wohnzimmer
   setList    off:noArg    cmnd/WZ_Schrank/POWER1 0
  on:noArg     cmnd/WZ_Schrank/POWER1 1
  toggle:noArg cmnd/WZ_Schrank/POWER1 2
   sortby     06
   stateFormat {lc ReadingsVal("$name","POWER1","") }

zu sehen ist also einmal POWER und einmal POWER1, aber wie gesagt diese Konfigurationen sind durch autocreate erstellt oder template.

So wie es aussieht gibt es da wohl Unterschiede.. Ich muss das mal mit dieser setOption 26 klären, da ich da nie etwas eingestellt habe bzw. von gesehen habe  :-\
Meine anderen Sonoff lasse ich jetzt mal außer Acht sind ja sowieso mehr Kanal Devices...

Mein S20 schaltet auch mit POWER...

EDIT;// ich werde jetzt mal meine beiden Basic mit POWER1 händisch auf POWER umstellen, da das wohl die default Einstellung ist, warum das bei mir unterschiedlich ist bleibt zu ergründen..!  :-\
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 16 Dezember 2018, 13:53:15
Zitat
ganz ehrlich ich weiß jetzt gar nicht wo das sein soll und gesetzt wird, ich habe diese Option noch nirgends gesehen.
Bitte einmal sagen wo ich diese Option setzen kann/soll

Einfach mal setOption26 in der Konsole auf dem Sonoff eingeben, um den aktuellen Status auszugeben.DOKU (https://github.com/arendst/Sonoff-Tasmota/wiki/Commands)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 16 Dezember 2018, 14:05:10
Einfach mal setOption26 in der Konsole auf dem Sonoff eingeben, um den aktuellen Status auszugeben.DOKU (https://github.com/arendst/Sonoff-Tasmota/wiki/Commands)
jou im der Doku hatte ich es schon gefunden...!! aber wo wird das eingestellt, evtl. beim flashen der Sonoff welches ich mit Atom gemacht habe..? Da habe ich natürlich schon ewig nichts gemacht seit ich die Sonoff seiner Zeit erstellt habe.

Da ich bisher die Updates immer über die Sonoff OTA gemacht habe.
Einer meiner Basic lässt sich nicht über OTA Updaten von der 5.x.xer Version auf die 6.x.x den muss ich mal ausbauen und dann im Atom nochmals schauen wenn es da gemacht wurde von mir, aber eher unbewusst ohne es zu wissen

EDIT://
Ich habe die Geräte die POWER1 haben mit "SetOption26 0" auf der Konsole geändert  ;)
Jetzt erst habe ich begriffen  :-\ (schande über mein Haupt) das es überhaupt nicht an den templates liegt, das es schon beim flashen der Sonoffs entstanden ist...!
Da gab es mal ein Atom Update, kann sein das es dabei wohl mal umgestellt wurde, denn ich habe diese Option nie gesehen geschweige denn geändert..!  :'(
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 16 Dezember 2018, 15:43:48
Beruhigt euch :) .

Also doch 2 templates für den Basic (Für Power mit Nummer ohne Index, da entsprechend der Voreinstellung!), wobei die "a" Variante ("POWER1" für state) dann die Basis für die Multis bildet (und ich daher sowieso die interne Logik drehe, was aus was entsteht).... Sorry, wenn die ganze Verwirrung nur durch den Tpyo in der desc entstanden sein sollte, das war einer aus "copy-paste", der Rest hatte eigentlich (fast) gepaßt.

Den Vorschlag finde ich, im Namen klar zu machen, ob es "unified" oder "split" ist. Und es wird - sofern ich die getestet erhalte - auch jeweils beide Varianten im Angebot geben. Wie der Einzelne jeweils seine Hardware ansprechen will, bleibt jedem selbst überlassen, unsere Aufgabe ist es nur, klar zu machen, was zu welchem Ergebnis führt. Von der Logik her würde ich aber immer erst die "unified"-Variante (ohne "a") anbieten, und erst danach die "split". Dann muß nämlich keiner irgendwas löschen, wenn er erst das erste austestet. Einverstanden?
Dafür braut es m.E. das noprefix im Namen eigentlich nicht, weil das bei tasmota so oder so ein sinnvoller Standard ist und daher den technisch nicht Interessierten eher verwirrt, wenn dazu überhaupt was dasteht.

Zu "set_": Da sind zwei Dinge drin. Zum einen stört es mich, dass set-Befehle immer den "state" schreiben, selbst wenn es einen anderen als den "Hauptkanal" betrifft. Zum anderen finde ich es schon bei HM gut, wenn ich optisch erkennen kann, wenn es mal ein Problem gibt. Und der "Mehr-"Aufwand (nach Abarbeitung des "eigentlichen" Problems) war minimalst (die geänderte set-fn häge ich nochmal an, dann seht ihr, dass das nicht viel anders ist...).

Zum Aufhübschen der Multis: man kann auch mehrzeilige Anzeigen basteln, da gab es ein Beispiel in dem Milight-Thread...

Ansonsten scheint es so zu sein, dass Variablen durch einen internen set ... attrTemplate-Aufruf verloren gehen, da muß ich also eh nochmal was umstellen, aber das Bild insgesamt ist jetzt doch ziemlich klar, oder?

Es wird  etwas dauern, bis ich dann wieder einen konsolidierten Stand einchecke, vermutlich nicht vor morgen Abend.

Schönen Sonntag noch,

Beta-User
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 16 Dezember 2018, 17:49:10
Beruhigt euch :)
Also wir sind glaube ich alle etwas im Vorweihnachtsstreß und vielleicht etwas aufgeregt, dass die Templatelösung so super wird...

Abgesehen davon hört sich Deine Lösung mit dem set nach der Maximallösung an. Das ist natürlich super wenn wir sowas bekommen.

Zu allem anderen kann ich nur zustimmen. Wenn du eingechecked hast schaue ich gerne nochmal drüber.

Bezüglich dem Problem mit den Parametern INFO etc. Habe ich nichts gefunden. Die einzige Lösung wäre per publish einen restart des Tasmota-Gerätes auszulösen. Ich persönlich hätte damit kein Problem, dauert ja eh nur 1 oder 2 Sekunden und das Gerät reagiert wieder. Sonstige Nebenwirkungen sehe ich da eigentlich auch keine. Kann gerne mal den cmnd-Befehl posten bei Bedarf.

Andere Meinungen dazu?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 16 Dezember 2018, 23:30:18
Zitat
Zum einen stört es mich, dass set-Befehle immer den "state" schreiben, selbst wenn es einen anderen als den "Hauptkanal" betrifft. Zum anderen finde ich es schon bei HM gut, wenn ich optisch erkennen kann, wenn es mal ein Problem gibt.
Da ich wiederum mit der automatischen Erkennung der "richtigen" Befehle ein Problem habe, habe ich es anders geloest: es gibt ein setStateList Attribut, wo man die Liste der Befehle spezifiziert, die state mit dem Praefix set_ setzen. Fuer diese Befehle wird stateFormat ignoriert. Die anderen Befehle setzen ein <Befehl> Reading, mit dem Wort "set" und allen Befehls-Parametern als Wert.
Falls dieses Attribut nicht gesetzt ist, bleibt alles beim Alten.

Weiterhin habe ich "toggle" (klick auf dem Status-Icon) auch fuer ON/OFF (d.h. Grossgeschrieben) implementiert. Achtung: ON/OFF wird nur dann im STATE richtig ausgewertet, falls die Befehle auch ON/OFF lauten, sonst wird mir das zu kompliziert.
Fuer ON/OFF habe ich vor kurzem ein alias (opensvg/iconalias.txt) gesetzt, jetzt folgte in fhemSVG/iconalias.txt fuer set_ON/set_OFF/set_on/set_off mit light_exclamation.svg

Eine bitte: koennt ihr im template auch das model Attribut setzen, damit weiss man beim Support, was der Melder urspruenglich gesetzt hat, und die Statistik-Auswertung auf https://fhem.de/stats/statistics.html kann sinnvolle Werte anzeigen.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 17 Dezember 2018, 07:56:30
Weiterhin habe ich "toggle" (klick auf dem Status-Icon) auch fuer ON/OFF (d.h. Grossgeschrieben) implementiert. Achtung: ON/OFF wird nur dann im STATE richtig ausgewertet, falls die Befehle auch ON/OFF lauten, sonst wird mir das zu kompliziert.
Fuer ON/OFF habe ich vor kurzem ein alias (opensvg/iconalias.txt) gesetzt, jetzt folgte in fhemSVG/iconalias.txt fuer set_ON/set_OFF/set_on/set_off mit light_exclamation.svg
Cool!

Eine bitte: koennt ihr im template auch das model Attribut setzen, damit weiss man beim Support, was der Melder urspruenglich gesetzt hat, und die Statistik-Auswertung auf https://fhem.de/stats/statistics.html (https://fhem.de/stats/statistics.html) kann sinnvolle Werte anzeigen.
Interpretiere ich das richtig: einfach ans Ende jedes Blocks den "name:" aus dem template in das Attribut schreiben?

Da ich wiederum mit der automatischen Erkennung der "richtigen" Befehle ein Problem habe, habe ich es anders geloest: es gibt ein setStateList Attribut, wo man die Liste der Befehle spezifiziert, die state mit dem Praefix set_ setzen. Fuer diese Befehle wird stateFormat ignoriert. Die anderen Befehle setzen ein <Befehl> Reading, mit dem Wort "set" und allen Befehls-Parametern als Wert.
Wie immer: Kaum macht es der Profi, wird es was... :)
Frage dazu: Bei den Geräten, die direkt "on" etc. verstehen, ließe sich die setList dann noch auf state:on,off,toggle verkürzen (mit $EVTPART1). Da stünde direkt drin, dass state gesetzt werden soll...
Ob die tasmotas den Text verstehen, weiß ich nicht so recht, hatte aber irgendwo im Hinterkopf, dass das sogar da geht.

Bezüglich dem Problem mit den Parametern INFO etc. Habe ich nichts gefunden. Die einzige Lösung wäre per publish einen restart des Tasmota-Gerätes auszulösen. Ich persönlich hätte damit kein Problem, dauert ja eh nur 1 oder 2 Sekunden und das Gerät reagiert wieder. Sonstige Nebenwirkungen sehe ich da eigentlich auch keine. Kann gerne mal den cmnd-Befehl posten bei Bedarf.

Andere Meinungen dazu?
Hmmmm, je länger ich über diese Dinge nachdenke, desto weniger gefällt es mir, "in die reale Welt" per template einzugreifen. Ist m.E. einfach ein strukturell falsches Vorgehen.
Wenn ich mir für eine Weiterentwicklung was wünschen dürfte, wäre ein Hinweistext nach der Anwendung des template, was der Anwender dann ggf. noch tun sollte, wobei die Luxusvariante die wäre, den Befehl dann auf Weisung des Anwenders auch auszuführen (mit Abbruchmöglichkeit!).
Bis dahin würde ich eher den Hinweis in die desc: einbauen, dass der ESP hinterher neu gestartet werden sollte.

Zu allem anderen kann ich nur zustimmen. Wenn du eingechecked hast schaue ich gerne nochmal drüber.
Danke, ich melde mich dann hier.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 17 Dezember 2018, 09:51:16
Zitat
Bei den Geräten, die direkt "on" etc. verstehen, ließe sich die setList dann noch auf state:on,off,toggle verkürzen (mit $EVTPART1). Da stünde direkt drin, dass state gesetzt werden soll...
Ja, aber dann haettest du nur ein Befehl (state), mit einer Auswahlliste (on,off,toggle). Bin nicht sicher, ob FHEMWEB dafuer Bilder generiert, toggle beim Klick auf dem Bild wuerde sicher nicht funktionieren, und on/off explizit per webCmd anzubieten (z.Zt. wird das automatisch generiert) waere auch kompliziert.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 17 Dezember 2018, 09:53:54
Zitat
Interpretiere ich das richtig: einfach ans Ende jedes Blocks den "name:" aus dem template in das Attribut schreiben?
Ja. Bin noch nicht ganz sicher, ob man den Tamplatenamen, oder das eigentliche Geraet dahinter verwenden sollte, fuer beide Varianten gibt es Argumente.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 17 Dezember 2018, 12:17:28
Ja, aber dann haettest du [...]
Leuchtet ein; da müßte ich auch noch etwas rumexperimentieren...

Danke, ich melde mich dann hier.
So, also vorab mal eine völlig ungetestete Überarbeitung des Tasmota-Abschitts, für den Fall, dass jemand schon mal was testen mag:
###########################################
# TASMOTA
# The regexp must handle
# - tele/sonoff/LWT: => cmnd/sonoff/
# - DVES_XXXXXX:/SmartHome/Esszimmer/Stehlampe/tele/LWT: => /SmartHome/Esszimmer/Stehlampe/cmnd/
name:A_01a_tasmota_basic_state_power1
filter:TYPE=MQTT2_DEVICE
desc:Applies to Sonoff Basic, S20 using POWER1-topic for relay state <br>Use this in case "SetOption26 1" was used as described in tasmota documentation <br>NOTE: This template is intended to configure also channel one of multi-channel tasmota devices
par:COMMAND;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\btele(/.*)?/LWT:, ? "${1}cmnd$2" : undef }
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
attr DEVICE stateFormat {lc ReadingsVal("$name","POWER1","") }
attr DEVICE eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
attr DEVICE setList \
  off:noArg    COMMAND/POWER1 0\
  on:noArg     COMMAND/POWER1 1\
  toggle:noArg COMMAND/POWER1 2\
  mqttRetry   COMMAND/MqttRetry
#Forum topic 90145 msg 872776
attr DEVICE readingList \
  tele/DEVNAME/LWT:.* LWT\
  tele/DEVNAME/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVNAME/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVNAME/INFO.:.* { json2nameValue($EVENT) }\
  stat/DEVNAME/RESULT:.* { json2nameValue($EVENT) }
deleteReading DEVICE .*
set IO_DEV publish COMMAND/Status
attr DEVICE autocreate 0
attr DEVICE model A_01a_tasmota_basic_state_power1
# sonoff 1 channel device flashed with Tasmota.
name:A_01_tasmota_basic_state_power
filter:TYPE=MQTT2_DEVICE
desc:Applies to Sonoff 1 Channel devices using POWER-topic for relay state <br>Use this in case "SetOption26 1" was used as described in tasmota documentation
set DEVICE attrTemplate A_01a_tasmota_basic_state_power1
attr DEVICE stateFormat {lc ReadingsVal("$name","POWER","") }
attr DEVICE model A_01_tasmota_basic_state_power

# tasmota device with one relay, one motion sensor via switch
name:A_01b_tasmota_1ch+motion+SI7021
desc:tasmota device with one relay, one motion sensor via switch and one SI7021 combined temperature and humidity sensor. <br>Configures a single device including all readings
filter:TYPE=MQTT2_DEVICE
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 \
  off:noArg    cmnd/DEVNAME/POWER1 0\
  on:noArg     cmnd/DEVNAME/POWER1 1\
  toggle:noArg cmnd/DEVNAME/POWER1 2
attr DEVICE stateFormat {\
  my $state = lc ReadingsVal($name, "POWER2", "off");\
  my $devStateIcon = 'building_security@green';\
  if ($state eq "on") {\
    $devStateIcon = 'building_security@red';\
  }\
  "<div>" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
    . FW_makeImage($devStateIcon) . sprintf(\
    "&nbsp;&nbsp;[Temp: %.1f°C / Feucht: %.0f%%]",\
    ReadingsVal($name,"SI7021_Temperature",0),\
    ReadingsVal($name,"SI7021_Humidity",0)\
    ) . "</div>"\
  }
attr DEVICE model A_01b_tasmota_1ch+motion+SI7021

# tasmota 2ch as one FHEM device.
name:A_02_tasmota_sonoff_2ch_unified
filter:TYPE=MQTT2_DEVICE
desc:Configures a single device including all readings <br>NOTE: untested!
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 \
  POWER1:on,off cmnd/DEVNAME/POWER1 $EVTPART1\
  POWER2:on,off  cmnd/DEVNAME/POWER2 $EVTPART1
attr DEVICE webCmd POWER1 on:POWER1 off:POWER2 on:POWER2 off
attr DEVICE stateFormat {\
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))\
  . "</div>"\
  }
attr DEVICE model A_02_tasmota_sonoff_2ch_unified

# sonoff 2 channel device flashed with Tasmota.
name:A_02a_tasmota_2channel_split
filter:TYPE=MQTT2_DEVICE
desc:sonoff 2 channel device flashed with Tasmota. <br>NOTE: a second device will be created for the second channel
set DEVICE attrTemplate A_01a_tasmota_basic_state_power1
par:COMMAND;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\btele(/.*)?/LWT:, ? "${1}cmnd$2" : undef }
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 stateFormat {lc ReadingsVal("$name","POWER2","")}
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg    COMMAND/POWER2 0\
  on:noArg     COMMAND/POWER2 1\
  toggle:noArg COMMAND/POWER2 2
attr DEVICE model A_02a_tasmota_2channel_split


# tasmota 4ch as one FHEM device.
name:A_04_tasmota_sonoff_4ch_unified
filter:TYPE=MQTT2_DEVICE
desc:Configures a single device including all readings
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 cmnd/DEVNAME/POWER1 $EVTPART1\
  p2:on,off  cmnd/DEVNAME/POWER2 $EVTPART1\
  p3:on,off  cmnd/DEVNAME/POWER3 $EVTPART1\
  p4:on,off  cmnd/DEVNAME/POWER4 $EVTPART1
attr DEVICE webCmd p1 on:p1 off:p2 on:p2 off:p3 on:p3 off:p4 on:p4 off
attr DEVICE stateFormat {\
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))\
  . " P3:". FW_makeImage(lc ReadingsVal($name, "POWER3", "off"))\
  . " P4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off"))\
  . "</div>"\
  }
attr DEVICE model A_04_tasmota_sonoff_4ch_unified

# tasmota 4ch as one FHEM device.
name:A_04_tasmota_sonoff_4ch_unified_test
desc:Configures a single device including all readings <br>uses multiline for webCmd <br>NOTE: untested!
filter:TYPE=MQTT2_DEVICE
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 \
  POWER1:on,off cmnd/DEVNAME/POWER1 $EVTPART1\
  POWER2:on,off  cmnd/DEVNAME/POWER2 $EVTPART1\
  POWER3:on,off  cmnd/DEVNAME/POWER3 $EVTPART1\
  POWER4:on,off  cmnd/DEVNAME/POWER4 $EVTPART1
attr DEVICE webCmd POWER1:POWER2:POWER3:POWER4
attr DEVICE stateFormat {\
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))\
  . " P3:". FW_makeImage(lc ReadingsVal($name, "POWER3", "off"))\
  . " P4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off"))\
  . "</div>"\
  }
webCmdLabel Kanal 1:Kanal 2\
   Kanal 3:Kanal 4
attr DEVICE model A_04b_tasmota_sonoff_4ch_unified_test
Habe jetzt die template-Namen als "model" verwendet, erschien mir am Ende sinnvoller als konkrete Hardware; ist ja häufiger so, dass die templates auf mehrere Varianten bzw. ganz unterschiedliche Hersteller passen.

Ansonsten:
- Habe jetzt mal versucht, für multi-Geräte was mehrzeiliges zu basteln (A_04_tasmota_sonoff_4ch_unified_test). Würde mich überraschen, wenn das auf Anhieb funtioniert. Vielleicht mag mal jemand weiterspielen, Ideen: webCmdLabel entfernen (kommen dann Lampen mit dem Zustand?)
- 2ch-Tasmota-unified aus 4-ch-unified abgeleitet
- mqttRetry in die setList aufgenommen (sollte evtl. nach hinten und mit einer sinnvollen Vorauswahl belabelt werden?)

Viel Spaß erst mal damit, wenn das soweit paßt, checke ich das (bzw. die bereits passenden Teile) dann ein.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 17 Dezember 2018, 14:02:15
Zur Info:

Den A_01a_tasmota_basic_state_power1 habe ich eben nochmal geändert, das konnte so wie ursprünglich zusammenkopiert nicht klappen...

Ganz neu habe ich den Versuch aufgenommen, die Statusinfos abzufragen. Kann sein, dass da noch eine Zahl dahinter Sinn macht (https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#management), Testen wäre nett.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: noansi am 17 Dezember 2018, 15:54:42
Hallo Rudolf,

Zitat
Fuer ON/OFF habe ich vor kurzem ein alias (opensvg/iconalias.txt) gesetzt, jetzt folgte in fhemSVG/iconalias.txt fuer set_ON/set_OFF/set_on/set_off mit light_exclamation.svg
da Du schon mal www\images\fhemSVG\iconalias.txt anpackst, es fehlen auch noch:
set_toggle        light_toggle.svg
set_on_for_timer  light_on-for-timer.svg
set_off_for_timer light_off-for-timer.svg
set_dimup         light_dim_up.svg
set_dimdown       light_dim_down.svg
Dann wird auch dazu die passende SVG Grafik angezeigt, z.B. bei HM-devices.

Gruß, Ansgar.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 17 Dezember 2018, 16:32:02
Habe iconalias.txt modifiziert, wie bestellt.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 17 Dezember 2018, 17:27:56
Weiterhin habe ich "toggle" (klick auf dem Status-Icon) auch fuer ON/OFF (d.h. Grossgeschrieben) implementiert. Achtung: ON/OFF wird nur dann im STATE richtig ausgewertet, falls die Befehle auch ON/OFF lauten, sonst wird mir das zu kompliziert.
Fuer ON/OFF habe ich vor kurzem ein alias (opensvg/iconalias.txt) gesetzt, jetzt folgte in fhemSVG/iconalias.txt fuer set_ON/set_OFF/set_on/set_off mit light_exclamation.svg
Ist das evtl. eine unerwünschte Nebenwirkung: https://forum.fhem.de/index.php/topic,94586.0.html
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: noansi am 17 Dezember 2018, 19:41:30
Hallo Rudolf,

Zitat
Habe iconalias.txt modifiziert, wie bestellt.

Danke!

Gruß, Ansgar.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 17 Dezember 2018, 22:31:07
So, eben habe ich die vorhin angekündigten templates eingecheckt, nachdem ich die mehrkanaligen zumindest mal auf ein "fake"-Tasmota angewendet habe und die da ohne Probleme durchgelaufen sind.

Ihr meldet euch, wenn was nicht paßt...

Interessieren würde mich vor allem, ob jetzt die Statusmeldungen gleich  da sind (ohne reboot).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 18 Dezember 2018, 17:54:18
So, eben habe ich die vorhin angekündigten templates eingecheckt, nachdem ich die mehrkanaligen zumindest mal auf ein "fake"-Tasmota angewendet habe und die da ohne Probleme durchgelaufen sind.
Interessieren würde mich vor allem, ob jetzt die Statusmeldungen gleich  da sind (ohne reboot).

Meinst du den COMMAND/Status ? Der bewirkt nicht das gewünschte. Es ging hier um die INFO1, INFO2, ... die kommen nur nach einem restart.

Deswegen würde das gewünschte Resultat nur ein

COMMAND/restart 1

auslösen. Dann startet ein Tasmota-Gerät neu und sendet alle Parameter.

Bitte füge das pure_base auch wieder hinzu. Das war sehr praktisch um allen Geräten mal den Grundzustand überzubraten. Die komplette Konfiguration will man ja normalerweise nach dem Einrichten eines Gerätes nicht mehr verändern. Der Command/restart wäre da auch ganz praktisch gleich mit dazu.

Ansonsten ersetze sonoff in der Regel durch Tasmota oder bei den template-Namen nur 1ch, 4ch etc. sonoff hat da im Template einfach nichts zu suchen. Von den voreingestellten Tasmota-Geräten  in der Tasmota Firmware ist nur ein kleiner Teil wirklich von Sonoff. POWER etc. ist aber unabhängig davon. Auch z. B. ein Gosun funktioniert mit dem Template und das ist alles andere als ein sonoff-Gerät.

Ansonsten macht sich das so langsam ganz gut.

Das test ist mir etwas zu viel geklicke. Für mich wäre für die mehrkanaligen einfach ein klicken auf das Statusicon zum umschalten ausreichend. Dann bräuchte ich die webcmd gar nicht. Muss mir das die nächsten Tage mal genauer ansehen...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 18 Dezember 2018, 18:59:24
Schade, dass das mit dem COMMAND/status so nicht geklappt hat. Hattest du mal versucht, den Befehl mit einer Zahl dahinter abzusetzen (würde dann am ehesten auf 1 tippen; das geht direkt am Server-Device)?
Ganz neu habe ich den Versuch aufgenommen, die Statusinfos abzufragen. Kann sein, dass da noch eine Zahl dahinter Sinn macht (https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#management (https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#management)), Testen wäre nett.
Wie gesagt: ein Reboot finde ich eigentlich nicht optimal da ggf. in manchen Situationen unerwünscht, und es gibt lt. Doku ausdrücklich diverse Informationslevel, die man abrufen kann (ich bin also noch nicht überzeugt, dass es nur mit dem Reboot geht ;) ).

Was genau wünschst du dir für pure_base?
Das "alte" machte ja nur die kurze Reading-Liste, keine Schaltbefehle (hat aber auch nichts gelöscht). Sowas?
Ansonsten war mein Gedanke, dass das "basic" (mit state=POWER) bzw. die Variante mit state=POWER1 eigentlich eine Art Grundzustand sind (also anders gesagt, immer ein Relay zum Schalten da ist, das auch gleich konfiguriert werden kann). Wenn diese Annahme falsch ist, bau' ich ein eigenes temoplate gerne wieder ein, für jetzt habe ich den "basic" erst mal im Namen wieder verkürzt, das irritiert vielleicht sonst. Grundsätzlich wäre sonst meine Denke, dass man die Anzahl der Varianten einigermaßen überschaubar halten sollte. Aber eine Art "cleanup-template" ginge natürlich auch (auch mit deleteattr!).
Aber am Ende geschieht, was ihr euch wünscht, ich will das nur hinterfragt haben, damit nicht morgen einer kommt und behauptet, das pure_basic (oder sonst was) bräuchte man doch eigentlich nicht...

Sonoff kommt raus, das hatte mich auch schon irritiert, Danke für den Stups.

Bezgl. des 4-Kanaligen "test": Das mit dem Klicken ist nachvollziehbar, zumal ich den Zeilenumbruch auch noch falsch gesetzt hatte. Vielleicht würde eine eventMap Sinn machen (mit / als Trenner wären darin auch Leerzeichen möglich). Wenn du eine Idee hast: her damit...

Bin jetzt erst mal unterwegs, und checke eben noch den jetzigen Zwischenstand ein (da ist auch eine Verbesserung für die Milight-Sache drin, auch noch nicht fertig, aber immerhin etwas funktionaler).

Gruß und Danke für die Rückmeldung und das Testen!
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 18 Dezember 2018, 22:10:17
Schade, dass das mit dem COMMAND/status so nicht geklappt hat. Hattest du mal versucht, den Befehl mit einer Zahl dahinter abzusetzen (würde dann am ehesten auf 1 tippen; das geht direkt am Server-Device)? Wie gesagt: ein Reboot finde ich eigentlich nicht optimal da ggf. in manchen Situationen unerwünscht, und es gibt lt. Doku ausdrücklich diverse Informationslevel, die man abrufen kann (ich bin also noch nicht überzeugt, dass es nur mit dem Reboot geht ;) ).

Ja habe das gerade eben mal mit 1 etc. versucht. Ist aber so dass state wirklich etwas anderes ist.  Find ein Reboot ist da wohl das kleinste übel, sofern keiner was besseres auftreibt.

Was genau wünschst du dir für pure_base?
Das "alte" machte ja nur die kurze Reading-Liste, keine Schaltbefehle (hat aber auch nichts gelöscht). Sowas?

Ja genau. Nur mit autocreate 0 und deleteReading. Habe viele Geräte ohne POWER nur mit Sensoren. Zudem etliche mit Bewegungsmeldern und Temperatursensor. Der Bewegungssensor meldet auch über Power zurück, darf aber natürlich auf keinen Fall geschalten werden. So ein pure base dass man bei Änderungen oder Neuinbetriebnahmen gefahrlos mal über alles machen kann ist schon schön. Hatte das mit pure_base schon mal so gemacht. Also set sonoff.* AttrTemplate pure_base
Ansonsten war mein Gedanke, dass das "basic" (mit state=POWER) bzw. die Variante mit state=POWER1 eigentlich eine Art Grundzustand sind (also anders gesagt, immer ein Relay zum Schalten da ist, das auch gleich konfiguriert werden kann). Wenn diese Annahme falsch ist, bau' ich ein eigenes temoplate gerne wieder ein, für jetzt habe ich den "basic" erst mal im Namen wieder verkürzt, das irritiert vielleicht sonst. Grundsätzlich wäre sonst meine Denke, dass man die Anzahl der Varianten einigermaßen überschaubar halten sollte. Aber eine Art "cleanup-template" ginge natürlich auch (auch mit deleteattr!).
Aber am Ende geschieht, was ihr euch wünscht, ich will das nur hinterfragt haben, damit nicht morgen einer kommt und behauptet, das pure_basic (oder sonst was) bräuchte man doch eigentlich nicht...

Sonoff kommt raus, das hatte mich auch schon irritiert, Danke für den Stups.

Bezgl. des 4-Kanaligen "test": Das mit dem Klicken ist nachvollziehbar, zumal ich den Zeilenumbruch auch noch falsch gesetzt hatte. Vielleicht würde eine eventMap Sinn machen (mit / als Trenner wären darin auch Leerzeichen möglich). Wenn du eine Idee hast: her damit...

Bin jetzt erst mal unterwegs, und checke eben noch den jetzigen Zwischenstand ein (da ist auch eine Verbesserung für die Milight-Sache drin, auch noch nicht fertig, aber immerhin etwas funktionaler).

Gruß und Danke für die Rückmeldung und das Testen!
[/quote]
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 19 Dezember 2018, 07:45:04
Hm, ok, Problem halbwegs verstanden, allerdings habe ich den Eindruck, dass der Wunsch v.a. auch daher kommt, dass das mit den Prefixen hier nicht erwünscht ist? Wenn das so wäre, wäre doch eigentlich folgendes zu überlegen:

- Nur Readings löschen, die einen Präfix haben (.*_.*)
- autocreate + die readingList lassen, aber beim Aufräumen so kürzen, dass die Readings ohne Präfix gefüllt werden (die Luxuslösung wäre "autoreate 2" zu setzen - gedacht als Anweisung,  json2nameValue() bei autocreate ohne Präfix zu verwenden; müßte aber (mind. letztendlich) Rudi implementieren).

Es wird also so oder so was kommen. Für den Fall, dass meine Vermutung zutrifft, dass eigentlich die Präfixe hier das Thema sind: Zuarbeit für eine passende Regex, um das ", '[^_]+[_]'" aus der readingList rauszuwerfen, wäre willkommen ;) .

Was Reboot angeht: Habe Hemmungen, das ohne Hinweis in ein template zu packen. Wäre es eine Idee, das als separates template anzulegen, und wenn ja, soll dann gleich noch die Voreinstellung mit den 10 Sekunden timeout auf z.B. 120 Sekunden geändert werden? (weiß grade nicht, welche setOption dass das war, aber die häufigen Pings führen uU. zu Problemen...).

Gruß, Beta-User
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 19 Dezember 2018, 11:10:34
Ungetestet, Rückmeldungen erbeten :) .
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 19 Dezember 2018, 11:13:31
Da war im Ersetzen-Teil ein Fehler drin, ihr wart zu schnell mit dem download, sorry
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 19 Dezember 2018, 21:36:25
Gibt's schon Rückmeldungen?

Ansonsten wäre es nett, wenn mir jemand eine raw-Definition eines unbearbeiteten Tasmota-Geräts (aus einer halbwegs aktuellen Fassung der MQTT2-Module) hier einstellen könnte. Dann kann ich das zwar nicht schalten, aber immerhin checken, ob die Ergebnisse plausibel sind...

[OT]
Beim Zuschauen bei dieser Diskussion hier: https://forum.fhem.de/index.php/topic,94640.0.html hatte ich den starken Eindruck, dass es für HTTPMOD auch eine klasse Sache wäre, wenn man hier attrTemplate nutzen könnte. Eine template-File hätte ich schon (mit zwei templates für die Preise einer Tankstelle bzw. die Umkreissuche), nur leider fehlt mir eine Idee für einen Patchvorschlag für HTTPMOD).

Wenn mir da jemand einen Tip hätte oder das übernehmen wollte?
[/OT]
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 19 Dezember 2018, 22:01:55
Zitat
leider fehlt mir eine Idee für einen Patchvorschlag für HTTPMOD
Den HTTPMOD Autor ueberzeugen SetExtensions zu verwenden, damit kommt attrTemplate auch mit.
Ansonsten aus SetExtensions abschreiben, im wesentlichen ruft man AttrTemplate_Set auf, wenn man selbst mit dem Befehl nichts anfangen kann.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 20 Dezember 2018, 11:52:02
So,

nachdem keiner gemeckert hatte, sind die templates eingecheckt.

Den HTTPMOD Autor ueberzeugen SetExtensions zu verwenden, damit kommt attrTemplate auch mit.
Ansonsten aus SetExtensions abschreiben, im wesentlichen ruft man AttrTemplate_Set auf, wenn man selbst mit dem Befehl nichts anfangen kann.
Danke für die Rückmeldung, ich habe stefanstrobel mal direkt angeschrieben. HTTPMOD bietet per default keine sets an, das übersteigt damit jedenfalls auf die Schnelle meine Perl-Fähigkeiten, und setExtensions sind m.E. nicht der optimale Weg (da HTTPMOD vermutlich häufig reine Lese-Geräte sind).

Gruß, Beta-User
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 20 Dezember 2018, 12:35:39
Hallo,

hab mir die Tage vorgenommen auf MQTT2 umzustellen.
Hab das so verstanden das ich erstmal über den MQTT2_CLIENT meine bisherigen MQTT_DEVICE in MQTT2_DEVICE ändere, dann MQTT lösche und durch MQTT2_Server ersetze und schlußendlich in IODev der neuen MQTT2_DEVICE den neuen MQTT2_Server eintrage.

Ist die vorgehensweise so korrekt ?


Mein erstes MQTT2_Device ist ein Sonoff_S20.

Hier ist mir aufgefallen wenn ich attrTemplate ($Id: mqtt2.template 17999 2018-12-18 18:02:57Z Beta-User $) nutze das egal ob mit A_01_tasmota_basic oder A_01a_tasmota_basic_state_power1 definiert immer POWER1 verwendet wird, außer in stateformat. Das tut der Funktion zwar nichts, schalten tut der Basic/Sonoff_S20 ja mit beidem.
In der Beschreibung (attr Template ?) steht allerdings das mit A_01_tasmota_basic POWER verwendet werden soll.

Zitat
Applies to Sonoff 1 Channel devices using POWER-topic for relay state

Internals:
   CID        myMQTT2CLIENT
   DEF        myMQTT2CLIENT
   DEVICETOPIC 1st_Sonoffs200
   IODev      myMQTT2_CLIENT
   LASTInputDev myMQTT2_CLIENT
   MSGCNT     126
   NAME       1st_Sonoffs200
   NR         513
   STATE      off
   TYPE       MQTT2_DEVICE
   myMQTT2_CLIENT_MSGCNT 126
   myMQTT2_CLIENT_TIME 2018-12-20 12:27:34
   OLDREADINGS:
   READINGS:
     2018-12-20 12:27:33   POWER           OFF
     2018-12-20 11:59:02   SetOption1      OFF
     2018-12-20 12:27:33   Time            2018-12-20T12:27:33
     2018-12-20 12:27:33   Uptime          1T13:16:13
     2018-12-20 12:27:33   Vcc             3.170
     2018-12-20 12:27:33   Wifi_AP         1
     2018-12-20 12:27:33   Wifi_BSSId      BC:05:43:CA:4F:AC
     2018-12-20 12:27:33   Wifi_Channel    13
     2018-12-20 12:27:33   Wifi_RSSI       100
     2018-12-20 12:27:33   Wifi_SSId       FBF
Attributes:
   IODev      myMQTT2_CLIENT
   autocreate 0
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   model      A_01_tasmota_basic
   readingList tele/sonoffs20/LWT:.* LWT
  tele/sonoffs20/STATE:.* { json2nameValue($EVENT) }
  tele/sonoffs20/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoffs20/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoffs20/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoffs20/POWER1 0
  on:noArg     cmnd/sonoffs20/POWER1 1
  toggle:noArg cmnd/sonoffs20/POWER1 2
  mqttRetry   cmnd/sonoffs20/MqttRetry
   stateFormat {lc ReadingsVal("$name","POWER","") }

Internals:
   CID        myMQTT2CLIENT
   DEF        myMQTT2CLIENT
   DEVICETOPIC 1st_Sonoffs200
   IODev      myMQTT2_CLIENT
   LASTInputDev myMQTT2_CLIENT
   MSGCNT     126
   NAME       1st_Sonoffs200
   NR         513
   STATE     
   TYPE       MQTT2_DEVICE
   myMQTT2_CLIENT_MSGCNT 126
   myMQTT2_CLIENT_TIME 2018-12-20 12:27:34
   OLDREADINGS:
   READINGS:
Attributes:
   IODev      myMQTT2_CLIENT
   autocreate 0
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   model      A_01a_tasmota_basic_state_power1
   readingList tele/sonoffs20/LWT:.* LWT
  tele/sonoffs20/STATE:.* { json2nameValue($EVENT) }
  tele/sonoffs20/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoffs20/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoffs20/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoffs20/POWER1 0
  on:noArg     cmnd/sonoffs20/POWER1 1
  toggle:noArg cmnd/sonoffs20/POWER1 2
  mqttRetry   cmnd/sonoffs20/MqttRetry
   stateFormat {lc ReadingsVal("$name","POWER1","") }

Ist mir nur so aufgefallen bei meinem ersten MQTT2_DEVICE, vielleicht versteh ich es auch bloss falsch.

Gruß

Thomas
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 20 Dezember 2018, 12:43:32
Moin,

die Vorgehensweise für die Umstellung sollte so passen wie beschrieben.

Das mit der Beschreibung (desc:) ist so zu lesen, dass für relay state POWER verwendet wird (bzw. POWER1). Ansonsten sind die wirklich gleich, sie schalten beide über POWER1 (was ja an sich korrekt zu sein scheint). Oder besteht da Handlungsbedarf, dass auch die setList anders sein sollte?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 20 Dezember 2018, 13:08:36
Zitat
... das für relay state POWER verwendet wird...

na ja, und deswegen auch in der setlist einfach das es ein "Bild" ist. Handlungsbedarf ? nö ☺
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 20 Dezember 2018, 18:49:34
Das mit der Beschreibung (desc:) ist so zu lesen, dass für relay state POWER verwendet wird (bzw. POWER1). Ansonsten sind die wirklich gleich, sie schalten beide über POWER1 (was ja an sich korrekt zu sein scheint). Oder besteht da Handlungsbedarf, dass auch die setList anders sein sollte?

Man könnte das setlist dann mit Power machen so dass das logischer wäre. Für Tasmota geht beides für den ersten Kanal. Also Schönheit gegen Einheitlichkeit ;-)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 20 Dezember 2018, 19:23:44
also zu tasmota sensors only sollte die desc: lauten

desc:Applies to all tasmota devices without relays

relays nicht switches

deleteReading DEVICE .*_.*

ist Mist. Gerade das Problem dass wir eigentlich lösen wollten kriegen wir damit nicht in den Griff. Statt dessen müsste man die Readings umschreiben ohne Prefix. Das halte ich aber für fehleranfällig. Da es ja auch Readings gibt mit _. Das könnte bei bestehenden Geräten wo das Präfixing schon aus war dazu führen dass aus SI7021_Humidity nur Humidity wird und neu dann auch wieder SI7021_Humidity hinzugefügt wird.

Also ich würde es beim normalen deleteReading lassen und wirklich den restart hinzufügen. Man könnte das ja im desc mit Klarstellen also 2. Zeile:

when applying the template the tasmota device is rebooted to get all readings

Oder so ähnlich... würde nur halt nicht nur schreiben "device will reboot" sondern auch warum

mqttretry bringt wohl nicht das gewünschte Ergebnis also besser nicht dran rumschrauben.

Noch eine andere Frage:
Wie kann ich denn diese Textansicht erzeugen mit den ganzen Readings wie es hier alle machen um sie hier zu posten? Einfach nur Copy und Paste aus der Oberfläche geht da ja nicht.

@Beta-User wenn du mich privat kontaktierst kann ich dir gerne einen Wemos D1 mit USB-Netzteil kostenlos zusenden. Fertig mit Tasmota geflashed. Dann kannst du damit die Templates auch problemlos in echt testen. Von mir aus kann ich auch noch 1,5 € für einen Temperatursensor drauflegen ;-)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 20 Dezember 2018, 20:13:45
Zitat
Wie kann ich denn diese Textansicht erzeugen mit den ganzen Readings wie es hier alle machen um sie hier zu posten? Einfach nur Copy und Paste aus der Oberfläche geht da ja nicht.
Vermutlich tippen die Herrschaften irgendwo "list device". Was aber fuer die Weiterverwendung gar nicht optimal ist, besser waere "list -r device", bzw unten in der Detailansicht: "Raw definition"
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 20 Dezember 2018, 20:31:28
Vermutlich tippen die Herrschaften irgendwo "list device". Was aber fuer die Weiterverwendung gar nicht optimal ist, besser waere "list -r device", bzw unten in der Detailansicht: "Raw definition"


Vermutlich liegt das daran das Beta-User noch nicht angemerkt hat, das sowas hier (https://forum.fhem.de/index.php/topic,71806.msg633579.html#msg633579) mit angepinnt werden sollte.

Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 20 Dezember 2018, 21:01:59
Vermutlich liegt das daran das Beta-User noch nicht angemerkt hat, das sowas hier (https://forum.fhem.de/index.php/topic,71806.msg633579.html#msg633579) mit angepinnt werden sollte.
Das wäre für Anfänger, die für diesen Bereich treffende Variante mit dem nur noch fetten Hinweis, dass bitte ein list geliefert werden soll, wäre die hier: https://forum.fhem.de/index.php/topic,94495.msg872201.html#msg872201

Und dazu hatte ich bereits zwei Hinweise verteilt, dass ich diesen gerne angepinnt hätte.

@Rudi: Spricht was dagegen und wenn nein, wärst du so freundlich?

also zu tasmota sensors only sollte die desc: lauten
Thx, wird korrigiert.

Zitat
deleteReading DEVICE .*_.*

ist [...]
Also ich würde es beim normalen deleteReading lassen und wirklich den restart hinzufügen. Man könnte das ja im desc mit Klarstellen also 2. Zeile:
Hab's geändert, wobei das von dir zitierte Reading m.E. nicht gekürzt wird, sondern ebenfalls gelöscht, und dann bei autocreate 1 auch wiederkommen sollte. Aber egal, ihr entscheidet...
Gekürzt werden sollte nur die Präfix-Einstellung in der readingList. Da sich dazu bisher keiner beschwert hat, gehe ich mal davon aus, dass das funktioniert? (ich hatte dazu nur eine alte RAW-Definition aus dem Wiki ;) , daher kam die Bitte, mal ein list von einem aktuellen autocreate-erstellten Device zu posten).
Den Hinweis auf den Reboot habe ich aufgenommen und den Titel erweitert, dann kann man es auch nicht übersehen.
 
Zitat
mqttretry bringt wohl nicht das gewünschte Ergebnis also besser nicht dran rumschrauben.
Danke für den Hinweis, habe das nur aus der Doku genommen und fand das als Idee praktisch, da wir in einem anderen Thread schon das Problem mit den vielen Anfragen im 10-Sek-Takt hatten; wenn's aber nicht wirkt und dann nur der reboot bleibt, wird das template ganz verworfen, oder?
(Anm.: Eigentlich wäre es gut, es stände irgendwo (im Wiki?) eine Zusammenfassung, welche Einstellungen an den Tasmota-Devices (direkt) vorgenommen werden sollten. Zwischendurch hatte ich die Idee, eine Art Zentraldevice (ähnlich wie das template, aber direkt zu bedienen für alle Tasmotas) zu bauen, aber irgendwas darf der geneige User auch selber einstellen...).

Zitat
@Beta-User wenn du mich privat kontaktierst kann ich dir gerne einen Wemos D1 mit USB-Netzteil kostenlos zusenden. Fertig mit Tasmota geflashed. Dann kannst du damit die Templates auch problemlos in echt testen. Von mir aus kann ich auch noch 1,5 € für einen Temperatursensor drauflegen ;-)
Thx für's Angebot! Mach' dir nicht die Mühe...
[kurz OT]
Einen (oder ein paar Wemos D1 habe ich hier auch noch "ungenutzt" hier rumfliegen, aber eigentlich wollte ich mich nicht mehr als notwendig mit diesen Biestern befassen. M.E. sind das schlecht designte IC's und WLAN ist für HA auch Mist => ich habe effektiv nur einen ESP tatsächlich am laufen (diese Milight-Bridge; die ist um Längen besser als das (bescheuerte!) Original. Ein zweiter macht - eher als Testsystem - etwas IR (die Dioden sind zu schwach, da ist eine firmware drauf, an der ich sogar selber nach kleinen Änderungen compiliert habe ;) ). Ich plane auch nicht wesentlich mehr und werde mich wenn, dann mit ESPEasy (@MQTT) befassen, um das Teil darauf umzustellen. Nichts gegen Tasmota, aber ESPEasy scheint den IR-Empfangsteil besser zu beherrschen.

Und Temperatursensoren habe ich ca. 15 DS18B20 im Einsatz und nochmal 15 rumliegen, dazu mehrere BMxx80, PT100(?) mit MAXirgendwas, und einen IR-basierten - es herrscht also kein Mangel....

Die 1wire hängen bei mir aber an einer MySensors-RS485-Installation, wie auch ein BME280; wenn ich Funk brauche (demnächst wieder), dann wird das auch MySensors, das ich btw. ausschließlich mit seriellen GW's betreibe; grade hängen (teilweise zu Testzwecken) alleine 5 MySensors-GW's an meinem Server ;D .

Will sagen: Das Material ist nicht das Problem, die Flasherei an sich auch nicht, es fehlt der Wille, sich in Ruhe hinzusetzen und sich auch noch Tasmota praktisch reinzuziehen...
[/OT]
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 20 Dezember 2018, 21:45:03
Zitat
@Rudi: Spricht was dagegen und wenn nein, wärst du so freundlich?
Habs gemacht.
Kannst du bitte noch eine kurze Einleitung/Abgrenzung (MQTT2 vs. MQTT) reinschreiben, sonst ist der Anfaenger verwirrt.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 20 Dezember 2018, 22:02:31
Habs gemacht.
Kannst du bitte noch eine kurze Einleitung/Abgrenzung (MQTT2 vs. MQTT) reinschreiben, sonst ist der Anfaenger verwirrt.
Danke und Danke für den Hinweis.

Hab's ergänzt und auch auf den Wiki-Beitrag verlinkt, der das Zusammenspiel der Module kurz erklärt. Hat evtl. auch den Effekt, dass man das auch leichter wiederfindet, wenn man mal jemand den Unterschied erklären soll :) . Gab's ja zuletzt immer wieder Beiträge, wo die Unterscheidung dem TE nicht so klar war.

Feedback zu dem Artikel gerne im Wiki-Bereich: https://forum.fhem.de/index.php/topic,93343.0.html
Der ist auch erst mal "auf die Schnelle" entstanden und nicht unbedingt ausgereift...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: DasQ am 20 Dezember 2018, 22:03:30
[OT]
aber eigentlich wollte ich mich nicht mehr als notwendig mit diesen Biestern befassen. M.E. sind das schlecht designte IC's und WLAN ist für HA auch Mist

na na na, die dinger sind doch putzig. musst ihn nur ordentlich zureden, dann tun die auch was se sollen.
[/OT]

p.s. deine IR schaltung würd mich mal intressieren. meiner hier rockt auf fast 5m das ganze wohnzimmer ir gedöns
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 20 Dezember 2018, 22:36:11
[immer noch OT]Putzig, ja... Ich habe mich nur zuerst mit diesen dusseligen 01-er-Versionen rumgeplagt, als ich noch nicht wußte, wie man Microcontroller schreibt. Da war das miese Design was timing usw. angeht noch nicht durch software ausgebügelt, und ich habe mich ausgerechnet mit dem timing-kritischen IR-Quatsch versucht, da reinzukommen. Nicht lustig, nein gar nicht...
Da war anschließend MySensors (@nRF24+seriellem GW) ein Kinderspiel dagegen.

Das ist das "normale" IR-360°-GW, allerdings mit der SW wie hier beschrieben: https://wiki.fhem.de/wiki/IR-MQTT-Gateway. Da sind nur testweise nach vorne zwei 6200-er drauf (engerer Winkel, größere Leistung). Ich will nur eigentlich über die gegenüberliegende weiße Wand zurück, das sind dann 8m... Stelle ich mich 2m davor, geht's auch, aber dann brauche ich eigentlich auch kein IR :( .
Vermutlich muß ich das doch mit MySensors lösen (das war meine erste Lösung, die auch noch sendetechnisch mit den alten Dioden genauso leidlich funktioniert, da hat aber die von mir verwendete IR-Lib einen Hau und kommt nach dem Empfangen nicht mehr auf Senden zurück (oder anders rum...). Aber da hängen die Dioden hinter einem Transistor und bekommen die vollen 5V ab (Schaltung wie in der ursprünglichen IRlib für Arduino).
Ist halt Spielzeug ;) . Die Ecke hat keine hohe Prio.

Ergo: Ich kann den Dingern schon gut zureden, wenn ich will; wenn's sein muß, kommt auch was raus. Ändert aber nichts an meiner Einstellung zu WLAN+HA im Allgemeinen und den ESP's im Speziellen :P . Der direkte Weg (ohne WLAN) ist nicht nur sicherer, er macht m.E. auch mehr Spaß 8) .
[/OT]
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 21 Dezember 2018, 12:52:48
(Anm.: Eigentlich wäre es gut, es stände irgendwo (im Wiki?) eine Zusammenfassung, welche Einstellungen an den Tasmota-Devices (direkt) vorgenommen werden sollten.

Ich dachte wir waren uns hier einig, dass mit den templates nur unveränderte Tasmota-Firmware unterstützt wird? Also ohne irgendwelche nicht Standard Anpassungen?

So sind die templates ja aktuell auch ausgelegt.

[kurz OT]
Ich kam zufällig auf die sonoff und dann anschließend auf die Wemos D1. Relay, Sensoren etc. angelötet, Tasmota in einer Version mit voreingestelltem WLAN geflashed, Weboberfläche aufgerufen und Sensoren etc. gewählt. Läuft! Vorher hatte ich über 100 Z-Wave Geräte in einem etwas größeren Gebäude. Größtenteils ZWAVE+. Die Zuverlässigkeit war nicht gegeben. Irgenwann ging z. B. ein Fibaro Bewegungsmelder einfach nicht mehr... Oder aus irgendeinem Grund schlug ein Schaltbefehl fehl. Bei der Menge an Geräten wollte ich nicht jedem Gerät hinterher rennen. Insbesondere für die Fußbodenheizungssteuerung.

WLAN-Abdeckung ist über unify-Geräte top gegeben und 2.4 ist nur für die Haussteuerung. 5 für alles was Bandbreite braucht. Sicherheit würde ich aktuell für besser gegeben halten bei WPA2 als bei ZWAVE+ (insbesondere da viele Geräte das ja auch nur zum Teil oder gar nicht verschlüsselt implementiert haben und mit aktivierter Verschlüsselung reduziert sich die Stabilität nochmal) Klar ich brauche jetzt aktuell immer Netz. Aber das ist kein großes Problem da ich die Sensoren eh in die Dosen packe wo früher die Temperaturregler für die Fußbodenheizung drin waren ;-)

Also auf die Zuverlässigkeit (aktuell leider nur mit mosquitto, wegen den Problemen mit MQTT2_Server) lasse ich da auf die Geräte mit Tasmota-Firmware nichts kommen. Für die Steckdosen-Zwischenstecker gibt es ja mit Gosun auch eine genauso kompakte alternative wie die Fibaro-ZWAVE-Geräte. Nur die Popp Z-Weather Station wird wohl als einziges Gerät übrig bleiben. Die funktioniert und die nehme ich als Basis für die Steuerung der Markisen bei Wind.

MySensors kannte ich bisher nicht. Das werde ich mir wohl mal etwas genauer ansehen, hört sich recht interessant an. Würde gerne noch draußen ein paar Sensoren einbinden (Teich, ...) über die DS18... da würde sich das eventuell gut machen. Wobei ich das letztes Jahr für die Poolpumpensteuerung und einen DS draußen einfach über einen Wemos mit Relay, DS-Temperatursensor und wasserdichtem Gehäuse gelöst hatte. Aber eben immer mal wieder was neues ;-)
[/OT]
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 21 Dezember 2018, 13:04:11
Zitat
aktuell leider nur mit mosquitto, wegen den Problemen mit MQTT2_Server
Sind das die SSL Probleme?
Wenn ja: kannst du es bitte erneut testen? Vor ein paar Tagen habe ich ein Problem mit SSL+fhemFork gefixt.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 21 Dezember 2018, 13:35:42
Zur Info:

Habe die gestern angesprochenen Themen ins heutige update gepackt gehabt, zusammen mit einer setList etc. mit POWER für das eine template, damit da nicht nochmal einer drüber stolpert, warum das auseinanderfällt.

Ich dachte wir waren uns hier einig, dass mit den templates nur unveränderte Tasmota-Firmware unterstützt wird? Also ohne irgendwelche nicht Standard Anpassungen?

So sind die templates ja aktuell auch ausgelegt.
Bei dem Vorschlag ging es nicht um empfohlene Patches/anpassungen der firmware bei Tasmota, die Auswirkungen auf die MQTT-Seite (also die templates) hätten, sondern z.B. um die Frage, wie oft der Broker von einem Device angepingt wird (derzeit 10 Sekunden) und ähnliches. Sorry, wenn das nicht verständlich formuliert war. Ob es mehr gibt wie diesen Punkt, kann ich mangels eigener Erfahrung nicht sagen, vermute es aber fast.

Zitat
[kurz OT]
Ich kam zufällig auf die sonoff [...]
[/OT]
:) Vermutlich bringt da jeder halt auch seine "Leidensgeschichte" mit irgendwas mit, was er (negativ) kennt - und jedes Ding hat halt seine Kehrseite.
Hier lese ich halt immer wieder Posts von einfachen Menschen, die "mal eben schnell einsteigen wollen", und sich nicht groß über die Infrastruktur an sich groß Gedanken machen wollen oder können, sondern erst mal den Pi über WLAN an ihre Fritte hängen, und sich dann beim 26. Tasmota-Device wundern, warum in aller Welt denn wohl seltsame Effekte auftreten...

Dass man sowas bei vernünftiger Planung, der richtigen Hardware, genügend Kenntnis, wie was funktioniert und etwas Glück umgehen kann, ist schon klar :) . Ich bin aber eigentlich auch "nur User" und habe hier auch nicht die riesen Infrastruktur am laufen, sondern will "halt einfach" mein Häuschen etwas intelligenter haben ;) . Und da soll der Server möglichst autarkt von der restlichen IT-Infrastruktur vor sich hin blubbern und mit "seinen" Geräten kommunizieren können (jedenfalls, wenn überhaupt Strom da ist).

Dass in dem Zusammenhang Funk immer nur die zweitbeste Lösung ist, ist klar, und dass irgendwo eine Grenze bei vermeshten 868-er Geräten ist, ist eigentlich auch logisch (1%), dass das aber bei nur 100 Geräten schon der Fall sein soll, finde ich seltsam, da ist man ja schnell angelangt :o .

MySensors ist m.E. super, wenn es um einen der folgenden Punkte geht
- eigene Logik in die firmware einzubauen
- praktisch jedes Bauteil (v.a.Sensor-Hardware) ist nutzbar, für das es eine Arduino-lib gibt
- batteriebetrieben (mach das mal mit WLAN)
- kabelgebunden (RS485, iVm. einem CAN-Transceiver superstabil seit 2.3.1!)
- große Reichweite (mit LoRa-Transceivern RFM9x, selbst bisher aber nur angetestet, aber grundsätzlich funktional...)
Details im entsprechenden Forumsbereich, zum Einlesen gibts im Wiki den Starter-Guide...
Das eine oder andere kann man zwar auch mit anderen Lösungen erreichen, die Kombi an Auswahlmöglichkeiten ist aber ziemlich einmalig, ohne dass man sich in zu viel unterschiedliches Coding eindenken muß! (Da fällt mir ein, ich muß dringend mal Löten und flaschen, um das leidige OTA-Thema da zu Ende zu bringen ::) )

Da du aber Tasmota kennst und das stabil rennt, darfst du auch damit glücklich sein!

Man sieht sich!
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 21 Dezember 2018, 15:13:55
Heute ist als erstes ein Sonoff-Dual dran.

Das klappt auch mit A_02a_tasmota_2channel_split.
Das die Readings POWER1 und POWER2 in beiden Geräten stehen ist etwas irritierend anfänglich, stehen aber halt auch beide im STATE JSON. Könnt ich das jeweilige nicht benötigte löschen oder wird es nach einem restart wieder angelegt ? Habs jetzt noch nicht probiert.

Rein interessehalber hab ich ein A_02_tasmota_2ch_unified definiert, einfach um zu schauen wie das aussieht.
Schaut euch mal den STATE an:

defmod sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 MQTT2_DEVICE myMQTT2CLIENT
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 IODev myMQTT2_CLIENT
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 autocreate 0
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 model A_02_tasmota_2ch_unified
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 readingList tele/sonoffDual_schaltschrank_Vorderh/LWT:.* LWT\
  tele/sonoffDual_schaltschrank_Vorderh/STATE:.* { json2nameValue($EVENT) }\
  tele/sonoffDual_schaltschrank_Vorderh/SENSOR:.* { json2nameValue($EVENT) }\
  tele/sonoffDual_schaltschrank_Vorderh/INFO.:.* { json2nameValue($EVENT) }\
  stat/sonoffDual_schaltschrank_Vorderh/RESULT:.* { json2nameValue($EVENT) }
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 room MQTT2_DEVICE
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 setList POWER1:on,off cmnd/sonoffDual_schaltschrank_Vorderh/POWER1 $EVTPART1\
  POWER2:on,off  cmnd/sonoffDual_schaltschrank_Vorderh/POWER2 $EVTPART1
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 stateFormat {\
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))\
  . "</div>"\
  }
attr sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 webCmd POWER1 on:POWER1 off:POWER2 on:POWER2 off

setstate sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2 <div>P1:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P2:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg></div>

edit:
$Id: mqtt2.template 18015 2018-12-21 06:04:35Z Beta-User
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 21 Dezember 2018, 15:44:22
Zu den "doppelten" Readings: da die über dasselbe Topic reinkommen, kann man es m.E. nicht verhindern, dass das immer wieder kommt.

Das 2ch ist "nur" ein experimentelles abgeleitetes. Kann jemand sagen, ob man dazu weitere SW benötigt (Wo kommt das FW_makeImage her...)? Dann wäre auch das 4ch betroffen und der Effekt "schon immer" da.
Dann müßte entweder die desc entsprechend erweitert werden oder eine Lösung her, die das nicht erfordert (oder 2 Varianten).

Bevorzugen würde ich als "default" für stateFormat was, was keine Abhängigkeiten hat. Wenn das nicht so funktioniert wie derzeit im template, dann lieber sowas wie "Relay 1: POWER1, Relay 2: POWER2".

Aber wie immer: Ihr entscheidet, Tasmota ist nicht meine persönliche Baustelle ;) .
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 21 Dezember 2018, 16:16:16
Das mit den doppelten Readings ist mir gar nicht so wichtig, kann ja jeder die Topic anpassen wie er möchte. Wenn mir das auf Dauer nicht passt verzichte ich auf das ganze Gedöns im Topic STATE und nehme dafür die jeweilige POWER-Topic.

Mein Anliegen war mehr darauf hinzuweisen das mit dem anlegen über attrTemplate A_02_tasmota_2ch_unified ein merkwürdiger STATE dargestellt wird, ein ganz normales List zeigt das vlt. besser wie zuvor die raw definition:

Internals:
   CID        myMQTT2CLIENT
   DEF        myMQTT2CLIENT
   DEVICETOPIC sonoffDual_schaltschrank_Vorderhaus_ch1t
   IODev      myMQTT2_CLIENT
   LASTInputDev myMQTT2_CLIENT
   MSGCNT     52
   NAME       sonoffDual_schaltschrank_Vorderhaus_ch1t
   NR         513
   STATE      <div>P1:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P2:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg></div>
   TYPE       MQTT2_DEVICE
   myMQTT2_CLIENT_MSGCNT 52
   myMQTT2_CLIENT_TIME 2018-12-21 15:54:27
   OLDREADINGS:
   READINGS:
Attributes:
   IODev      myMQTT2_CLIENT
   autocreate 0
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   model      A_02_tasmota_2ch_unified
   readingList tele/sonoffDual_schaltschrank_Vorderh/LWT:.* LWT
  tele/sonoffDual_schaltschrank_Vorderh/STATE:.* { json2nameValue($EVENT) }
  tele/sonoffDual_schaltschrank_Vorderh/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoffDual_schaltschrank_Vorderh/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoffDual_schaltschrank_Vorderh/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    POWER1:on,off cmnd/sonoffDual_schaltschrank_Vorderh/POWER1 $EVTPART1
  POWER2:on,off  cmnd/sonoffDual_schaltschrank_Vorderh/POWER2 $EVTPART1
   stateFormat {
  "<div>P1:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))
  . "</div>"
  }
   webCmd     POWER1 on:POWER1 off:POWER2 on:POWER2 off
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 21 Dezember 2018, 16:24:08
Zitat
Zu den "doppelten" Readings: da die über dasselbe Topic reinkommen, kann man es m.E. nicht verhindern, dass das immer wieder kommt.
Mit dem attribute "jsonMap POWER2:0" sollte das gehen.
Das ist jetzt keine Aufforderung zu "mach mal", nur eine Erklaerung.

Zitat
Wo kommt das FW_makeImage her...
FW_makeImage kommt aus FHEMWEB.pm, und wird hier dazu benutzt, den Status mehrerer Schalter in FHEMWEB anzuzeigen.
Der Aufruf im stateFormat fuehrt zu Fehler, wenn jemand FHEM ohne FHEMWEB betreibt.
Weiterhin macht er die Anzeige per list unbrauchbar (siehe Beitrag vom TomLee), genauso wie die Statusauswertung via Value(), und Schalten per Klick auf das Bild ist auch nicht moeglich.

Die fuer dieses Problem vorgesehene Loesung geht ueber das devStateIcon Attribut. Da das mW nur vom FHEMWEB ausgewertet wird, ist der Aufruf von FW_makeImage in devStateIcon auch weniger problematisch. Allerdings ist das Schalten ueber Klick auf das Icon auch mit devStateIcon eine "echte Herausforderung".

Habe ich schon gesagt, dass ich nicht ohne Grund die Split- gegenueber die Kombi-Loesung bevorzuge?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 21 Dezember 2018, 16:55:02
Mit dem attribute "jsonMap POWER2:0" sollte das gehen.
Das ist jetzt keine Aufforderung zu "mach mal", nur eine Erklaerung.
Dann, liebe Tasmota-User: macht mal... (wobei ich glaube, dass der Teil nicht schwer ist, also just do it ;) )

Zitat
FW_makeImage kommt aus FHEMWEB.pm, und wird hier dazu benutzt, den Status mehrerer Schalter in FHEMWEB anzuzeigen.
Der Aufruf im stateFormat fuehrt zu Fehler, wenn jemand FHEM ohne FHEMWEB betreibt.
Weiterhin macht er die Anzeige per list unbrauchbar (siehe Beitrag vom TomLee), genauso wie die Statusauswertung via Value(), und Schalten per Klick auf das Bild ist auch nicht moeglich.

Die fuer dieses Problem vorgesehene Loesung geht ueber das devStateIcon Attribut. Da das mW nur vom FHEMWEB ausgewertet wird, ist der Aufruf von FW_makeImage in devStateIcon auch weniger problematisch. Allerdings ist das Schalten ueber Klick auf das Icon auch mit devStateIcon eine "echte Herausforderung".
Ergo: soll ich für die unified-templates erst mal nur eine einfache Form des stateFormat bereitstellen ??? ?
Dass Value() für den Fall kaputt ist, ist m.E. verschmerzbar, weil jemand, der mehrkanalige Geräte betreibt, wissen sollte, dass er readingsVal() nutzen sollte, wenn er was "richtig" abfragen will.
Zitat
Habe ich schon gesagt, dass ich nicht ohne Grund die Split- gegenueber die Kombi-Loesung bevorzuge?
Das war jedenfalls mir - wie vieles andere ;D - neu :) .

Ich kann das gerne wieder in den templates umdrehen, was jetzt die zuerst angezeigte Variante angeht. Soll ich?

Meine eigene Gedankenführung ging eher in die Richtung, die mehrkanaligen tendenziell immer als "unified" anzulegen und dann aber nur den ersten Kanal für state zu verwenden - der Rest wäre dann als ReadingsProxy anzulegen gewesen... Zum Hintergrund: Ich komme von MySensors her, da ist das mit der Mehrkanaligkeit "einfacher", weil man die Kanäle sowieso nur über ReadingsProxy (o. ReadingsGroup) separat zu greifen bekommt (glaube ich jedenfalls). (Mir ist schon einigermaßen klar, dass das Füllen der Readingswerte direkt im Modul effizienter sein wird als was abgeleitetes.)

Der eigentliche Schmerz liegt nach meinem Empfinden bei den "split"-Lösungen darin, dass - neben den (scheinbar vermeidbaren) "zu vielen" Readings - verloren geht, zu welchem _physischen Gerät_ eigentlich was gehört. Spätestens, wenn man irgendwo ein rename drüber anwendet, sind die Beziehungen weg. Vorübergehend hatte ich mal die Idee, einfach ein "parentDevice"-Reading zu schreiben (bei den weiteren Kanälen); aber spätestens mit einem rename wäre das auch überholt, oder?

Vielleicht siehst du eine Möglichkeit, ein "probably associated with" abzuleiten, dass man darüber wiederfindet, was physisch zusammengehört? (Anmerkung: das wäre evtl. auch was für "bridged"-Devices (wenn das nicht schon da sein sollte, ungeprüft).)

Oder bin ich mit meinen Überlegungen auf dem Holzweg?

(Ergänzend: alias verwende ich praktisch nicht, sondern in der Regel ein rename. Soweit ersichtlich gibt es auch keine "offiziellen" oder halboffiziellen Empfehlungen, den einen oder anderen Weg zu bevorzugen, oder?)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 21 Dezember 2018, 21:49:21
Mit dem update von heute:



Internals:
   CID        myMQTT2CLIENT
   DEF        myMQTT2CLIENT
   DEVICETOPIC sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2
   IODev      myMQTT2_CLIENT
   LASTInputDev myMQTT2_CLIENT
   MSGCNT     136
   NAME       sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2
   NR         514
   STATE      off
   TYPE       MQTT2_DEVICE
   myMQTT2_CLIENT_MSGCNT 136
   myMQTT2_CLIENT_TIME 2018-12-21 21:34:41
   JSONMAP:
     POWER2     0
   OLDREADINGS:
   READINGS:
     2018-12-21 21:29:32   FallbackTopic   DVES_E768B3
     2018-12-21 21:29:32   GroupTopic      sonoffs
     2018-12-21 21:29:32   Hostname        sonoffDual_schaltschrank_Vorder
     2018-12-21 21:29:32   IPAddress       192.168.188.63
     2018-12-21 21:29:32   LWT             online
     2018-12-21 21:29:32   Module          Sonoff Dual
     2018-12-21 21:34:41   POWER1          OFF
     2018-12-21 21:34:41   POWER2          ON
     2018-12-21 21:29:24   Restart         Restarting
     2018-12-21 21:29:32   RestartReason   Software/System restart
     2018-12-21 21:34:41   Time            2018-12-21T21:34:40
     2018-12-21 21:34:41   Uptime          0T00:05:13
     2018-12-21 21:34:41   Vcc             3.184
     2018-12-21 21:29:32   Version         5.14.0
     2018-12-21 21:29:32   WebServerMode   Admin
     2018-12-21 21:34:41   Wifi_AP         1
     2018-12-21 21:34:41   Wifi_APMac      08:96:D7:A6:3F:27
     2018-12-21 21:34:41   Wifi_RSSI       72
     2018-12-21 21:34:41   Wifi_SSId       FBF
Attributes:
   IODev      myMQTT2_CLIENT
   autocreate 0
   comment    Channel 1 for sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2, see also sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2_CH2
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   jsonMap    POWER2:0
   model      A_02a_tasmota_2channel_split
   readingList tele/sonoffDual_schaltschrank_Vorderh/LWT:.* LWT
  tele/sonoffDual_schaltschrank_Vorderh/STATE:.* { json2nameValue($EVENT) }
  tele/sonoffDual_schaltschrank_Vorderh/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoffDual_schaltschrank_Vorderh/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoffDual_schaltschrank_Vorderh/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoffDual_schaltschrank_Vorderh/POWER 0
  on:noArg     cmnd/sonoffDual_schaltschrank_Vorderh/POWER 1
  toggle:noArg cmnd/sonoffDual_schaltschrank_Vorderh/POWER 2
   stateFormat {lc ReadingsVal("$name","POWER1","") }
   webCmd     POWER1 on:POWER1 off:POWER2 on:POWER2 off

Das POWER2 Reading hatte ich vor der Aktualisierung (21:34:41) gelöscht.

jsonMap    POWER2:0 klappt nicht.

Wenn ich

Zitat
Mit dem attribute "jsonMap POWER2:0" sollte das gehen.

richtig verstanden habe.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 21 Dezember 2018, 23:36:55
Zitat
jsonMap    POWER2:0 klappt nicht.
Stimmt, dazu muss noch beim Aufruf von json2nameValue auch spezifiziert werden alsjson2nameValue($EVENT,'',$JSONMAP)wie auch hier: https://fhem.de/commandref_modular.html#jsonMap dokumentiert ist.

Bin selbst noch nicht ganz gluecklich mit dieser Loesung, evtl. waere ein global verwendbares event-rename besser.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 22 Dezember 2018, 01:32:26
Stimmt, dazu muss noch beim Aufruf von json2nameValue auch spezifiziert werden alsjson2nameValue($EVENT,'',$JSONMAP)wie auch hier: https://fhem.de/commandref_modular.html#jsonMap dokumentiert ist.

Bin selbst noch nicht ganz gluecklich mit dieser Loesung, evtl. waere ein global verwendbares event-rename besser.

So klappts.

Das Reading wird nicht mehr aktualisiert, auch nicht mehr angelegt nachdem es gelöscht wurde und auch nach einem shutdown restart taucht es nicht mehr auf.

Internals:
   CID        myMQTT2CLIENT
   DEF        myMQTT2CLIENT
   DEVICETOPIC sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2
   IODev      myMQTT2_CLIENT
   LASTInputDev myMQTT2_CLIENT
   MSGCNT     182
   NAME       sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2
   NR         514
   STATE      off
   TYPE       MQTT2_DEVICE
   myMQTT2_CLIENT_MSGCNT 182
   myMQTT2_CLIENT_TIME 2018-12-22 01:19:46
   JSONMAP:
     POWER2     0
   OLDREADINGS:
   READINGS:
     2018-12-21 21:29:32   FallbackTopic   DVES_E768B3
     2018-12-21 21:29:32   GroupTopic      sonoffs
     2018-12-21 21:29:32   Hostname        sonoffDual_schaltschrank_Vorder
     2018-12-21 21:29:32   IPAddress       192.168.188.63
     2018-12-21 21:29:32   LWT             online
     2018-12-21 21:29:32   Module          Sonoff Dual
     2018-12-22 01:19:46   POWER1          OFF
     2018-12-22 01:14:46   POWER2          OFF
     2018-12-21 21:29:24   Restart         Restarting
     2018-12-21 21:29:32   RestartReason   Software/System restart
     2018-12-22 01:19:46   Time            2018-12-22T01:19:45
     2018-12-22 01:19:46   Uptime          0T03:50:18
     2018-12-22 01:19:46   Vcc             3.187
     2018-12-21 21:29:32   Version         5.14.0
     2018-12-21 21:29:32   WebServerMode   Admin
     2018-12-22 01:19:46   Wifi_AP         1
     2018-12-22 01:19:46   Wifi_APMac      08:96:D7:A6:3F:27
     2018-12-22 01:19:46   Wifi_RSSI       74
     2018-12-22 01:19:46   Wifi_SSId       FBF
Attributes:
   IODev      myMQTT2_CLIENT
   autocreate 0
   comment    Channel 1 for sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2, see also sonoffDual_schaltschrank_Vorderhaus_ch1t_CH2_CH2
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   jsonMap    POWER2:0
   model      A_02a_tasmota_2channel_split
   readingList tele/sonoffDual_schaltschrank_Vorderh/LWT:.* LWT
  tele/sonoffDual_schaltschrank_Vorderh/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/sonoffDual_schaltschrank_Vorderh/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoffDual_schaltschrank_Vorderh/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoffDual_schaltschrank_Vorderh/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoffDual_schaltschrank_Vorderh/POWER 0
  on:noArg     cmnd/sonoffDual_schaltschrank_Vorderh/POWER 1
  toggle:noArg cmnd/sonoffDual_schaltschrank_Vorderh/POWER 2
   stateFormat {lc ReadingsVal("$name","POWER1","") }
   webCmd     POWER1 on:POWER1 off:POWER2 on:POWER2 off
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 22 Dezember 2018, 13:54:19
FW_makeImage kommt aus FHEMWEB.pm, und wird hier dazu benutzt, den Status mehrerer Schalter in FHEMWEB anzuzeigen.
Der Aufruf im stateFormat fuehrt zu Fehler, wenn jemand FHEM ohne FHEMWEB betreibt.

Ich fand das FW_makeImage halt gut weil damit die Icons einheitlich sind. Früher hatte ich die on/off.png direkt benutzt aber in f18 sehen die anders aus und ich wollte das einheitlich.

Das Problem hier ist auch insbesondere weil die on/off als inline svg generiert werden und nicht extra. Das bläht den status enorm auf.

Ich fände es generell hier besser und vermutlich auch ressourcenschonender da weniger traffic wenn hierfür auch ein svg fest direkt verwendet würde. Der Browser könnte das dann wie bei einem png auch entsprechend cachen. So wie ja auch die anderen templates pngs einbinden. Allerdings weiss ih nicht ob das dann mit der Farbgebung trotzdem noch möglich ist, oder was dann damit vielleicht alles nicht mehr möglich wäre.

Weiterhin macht er die Anzeige per list unbrauchbar (siehe Beitrag vom TomLee), genauso wie die Statusauswertung via Value(), und Schalten per Klick auf das Bild ist auch nicht moeglich.

wie gesagt list ist ja eher das Problem wegen inline svg und nicht FW_mkImage an sich.

Die Statusauswertung ist da Ansichtssache. Bei einem einfachen Gerät mit, sagen wir mal 2 Relays und einem Kombisensor mit Temperatur und Feuchtigkeit, weiß ich einfach welches das Gerät ist und lese dann entsprechend Power1, Power2, SI7021_Humidity und SI7021_Temperature von dem Gerät in den entsprechenden doif aus. sonoffOGGast:SI7021_Temperature etc. Das ist für mich viel übersichtlicher als für jedes Reading ein eigenes Gerät anzulegen. Von den Problemen die da die Präfixgeschichte aufwirft wollen wir gar nicht erst reden.

Habe ich schon gesagt, dass ich nicht ohne Grund die Split- gegenueber die Kombi-Loesung bevorzuge?

Das ist mir bekannt ;) und ich bin sehr dankbar für FHEM, von daher, wenn die Voreinstellung und supportete Lösung allgemein separate Geräte sein soll, habe ich kein Problem damit.

Für mich ist es halt nicht die richtige Lösung. Ich weiss wo das Gerät sitzt vom Namen her und an den notwendigen Stellen greife ich mir das reading aus dem Gerät. Egal ob das jetzt POWER ist oder die aktuelle Leistung des Geräts, oder was für Sensordaten das Gerät so liefert. Früher hatte ich mehrere Geräte angelegt (bei MQTT bzw. bei ZWAVE ging das ja zum Teil gar nicht anders), jetzt mit MQTT2 bin ich glücklich dass ich das direkt über stateFormat machen kann. Ohne dann noch ein dummy anzulegen wo dann die gewünschte Ansicht zusammengebastelt werden musste.

Ich finde es nachvollziehbar wenn man nur einen Weg, als den Standardweg, auch in den Templates aufzeigt. Das führt zu weniger Verwirrung. Wie man gerade eben ja wieder sieht sind einige schon mit der Unterscheidung von MQTT und MQTT2 überfordert.

Für mich, dank eigener Templates und dem autocreate 0 bei MQTT2_DEVICE ist das so oder so eine super Lösung.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 22 Dezember 2018, 14:19:25
Sind das die SSL Probleme?
Wenn ja: kannst du es bitte erneut testen? Vor ein paar Tagen habe ich ein Problem mit SSL+fhemFork gefixt.

Eigentlich nicht dass ich wüsste. Mein Raspi mit FHEM hat kein SSL, hatte ich zeitweise, aber das machte die Sache gegenüber http deutlich langsamer. Jetzt darf der Raspi nur mit meinem gentoo Linux server kommunizieren und der nginx darauf legt das ssl drüber (proxy).

Das Problem war, dass das setzen (cmnd/.../POWER on) bei einigen Geräten kaum noch möglich war. Vermutlich wegen dem Problem dass MQTT2_Server der Meinung war, das Gerät wäre offline. Mit mosquitto und MQTT oder MQTT_Client tritt das Problem nicht auf.

Da mosquitto das Problem nicht hat, glaube ich nicht, dass der tcp/ip-Stack auf dem Tasmota-Gerät das Problem ist. Grundsätzlich waren auch alle Geräte betroffen also sowohl 4 channel sonoff als auch Geräte mit Wemos D1. Schwaches WLAN kann ich ausschließen. Die AccessPoints lassen nur mit einer bestimmten Signalstärke die Verbindung zu. So dass die Geräte immer mit einem guten Signal verbunden sind.

Wenn ich etwas Zeit habe, werde ich nochmal von MQTT2_Client auf Mqtt2_server umstellen um dann auch nochmal Fakten zu liefern und nicht nur Vermutungen. Eine 2. Installation mit nur 4 Tasmota-Geräten und MQTT2_Server läuft problemlos. Deswegen war ja meine Vermutung ob es irgendein Problem mit MQTT2_Server geben könnte bei vielen Verbindungen? Kann ja auch sein, dass mosquitto hier etwas nicht standardkonform abwickelt und so die Probleme umgeht.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 22 Dezember 2018, 14:31:37
Zitat
Ich fände es generell hier besser und vermutlich auch ressourcenschonender da weniger traffic wenn hierfür auch ein svg fest direkt verwendet würde.
Patches sind willkommen. Bitte auch daran denken, dass man SVGs im Status beliebig umfaerben kann (@red)

Zitat
wie gesagt list ist ja eher das Problem wegen inline svg und nicht FW_mkImage an sich.
Das Problem ist nicht das inline svg, sondern dass man hier Status (wie on/off) mit der Anzeige (vulgo Bild) verwechselt.
Ein Status von http://192.168.0.10/fhem/light_light.svg waere mAn auch nicht besser fuer die Auswertung (notify/DOIF) oder Logging. Von der telnet Anzeige ganz zu schweigen.
Bilder sollte man nicht mit stateFormat, sondern mit devStateIcon dazubauen, da das FHEMWEB spezifisch ist.

Zitat
Für mich ist es halt nicht die richtige Lösung.
Ich habe mit Sonderwegen kein Problem, solange man diese nicht anderen empfiehlt, die dann wg. weiteren Problemen damit zu mir kommen, und ich die Sache ausbaden muss. Deswegen verweise ich bei dieser Kombiloesung erstmal darauf, dass _ich_ das nicht so loesen wuerde.

Zitat
Deswegen war ja meine Vermutung ob es irgendein Problem mit MQTT2_Server geben könnte bei vielen Verbindungen?
Die Benachrichtigung in FHEM geht ueber select, und ein Prozess darf unter Linux per Voreinstellung 1024 filedescriptoren oeffnen (siehe limit), man kann es aber erhoehen.

Zitat
Kann ja auch sein, dass mosquitto hier etwas nicht standardkonform abwickelt und so die Probleme umgeht.
Wenn ja, dann wuerde es mich interessieren, wie.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 22 Dezember 2018, 14:35:53
Vermutlich tippen die Herrschaften irgendwo "list device". Was aber fuer die Weiterverwendung gar nicht optimal ist, besser waere "list -r device", bzw unten in der Detailansicht: "Raw definition"

OK das mit Raw definition hatte ich gesehen, aber da das abwich von der Ansicht die hier meistens gepostet wird (list device), dachte ich das wäre nicht das richtige ;-)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 22 Dezember 2018, 15:06:42
Das Problem ist nicht das inline svg, sondern dass man hier Status (wie on/off) mit der Anzeige (vulgo Bild) verwechselt.
Ein Status von http://192.168.0.10/fhem/light_light.svg waere mAn auch nicht besser fuer die Auswertung (notify/DOIF) oder Logging. Von der telnet Anzeige ganz zu schweigen.
Bilder sollte man nicht mit stateFormat, sondern mit devStateIcon dazubauen, da das FHEMWEB spezifisch ist.

OK ich dachte bisher stateFromat ist gedacht für Kombianzeigen um z. B. auch Temperaturen etc. aufzunehmen, damit ist aber im STATE nie mehr nur on/off. Das Problem ist ja grundsätzlich bei allen Geräten die nicht nur ein- und ausschalten. Wie ist denn hier die offizielle Meinung wie man mit Kombigeräten mit 1 oder 2 Relays, Temperaturen, Bewegungserkennung, Helligkeit umgehen soll? Ich hatte dafür schon bei ZWAVE stateFormat benutzt und für ein ReadingVal entsprechend Gerät+Reading in den doif verwendet.

devStateIcon hatte ich bisher so verstanden, kann nur einen Zustand anzeigen. Also keine Lösungsmöglichkeit für Kanal 2 etc.

Ich habe mit Sonderwegen kein Problem, solange man diese nicht anderen empfiehlt, die dann wg. weiteren Problemen damit zu mir kommen, und ich die Sache ausbaden muss. Deswegen verweise ich bei dieser Kombiloesung erstmal darauf, dass _ich_ das nicht so loesen wuerde.
Ich verstehe das vollkommen. Deswegen ja auch meine Frage ob wir uns in den offiziellen Templates auf die Mehrgerätelösung konzentrieren sollten um unnötigen support-Aufwand zu vermeiden.

Die Benachrichtigung in FHEM geht ueber select, und ein Prozess darf unter Linux per Voreinstellung 1024 filedescriptoren oeffnen (siehe limit), man kann es aber erhoehen.
Wenn ja, dann wuerde es mich interessieren, wie.
Davon sollte ich mit meinen 40 Geräten aber noch weit weg sein. Das wie und warum ist wohl die Frage. Fakt ist mit mosquitto ist die Anzahl kein Problem. Wie wird dass denn in MQTT2_Server benutzt? Braucht es pro Gerät eine Verbindung oder pro Eintrag in der readingList?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 22 Dezember 2018, 15:17:27
Zu den Tasmota-templates:

- Sehe ich das richtig, dass die lowercase-Konvertierung für das stateFormat zwischenzeitlich nicht mehr erforderlich ist? (bei den Milights habe ich die eventMap auch rausgeworfen => kein Problem). Und was ist mit eventMap?

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

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
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 22 Dezember 2018, 19:04:21
Zitat
Wie wird dass denn in MQTT2_Server benutzt? Braucht es pro Gerät eine Verbindung oder pro Eintrag in der readingList? 
Eine Netzwerkverbindung entspricht einem Filedescriptor.
Fuer mehr Details siehe list .* FD oder { `ls -l /proc/$$/fd` }

Zitat
Sehe ich das richtig, dass die lowercase-Konvertierung für das stateFormat zwischenzeitlich nicht mehr erforderlich ist?
Jein: SetExtensions (on-for-timer, etc) ist noch nicht Grossbuchstaben-Faehig, ist aber auf der TODO Liste.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 22 Dezember 2018, 20:46:10
Zitat
Vielleicht siehst du eine Möglichkeit, ein "probably associated with" abzuleiten, dass man darüber wiederfindet, was physisch zusammengehört? (Anmerkung: das wäre evtl. auch was für "bridged"-Devices (wenn das nicht schon da sein sollte, ungeprüft).)

Neu: falls man das associatedWith Reading setzt (Wert: Komma oder Leerzeichen getrennte FHEM-Devicenamen), dann:
- pflegt ein rename dieses Reading
- FHEMWEB zeigt im "Probably associated with" Abschnitt diese Geraete auch an.
- list -R / "Probably associated with" im "Raw definition" zeigt diese Geraete auch.
- bei wegen bridgeRegexp automatisch angelegten MQTT2_DEVICE Instanzen wird dieses Reading gesetzt auf die bridge Instanz
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User 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?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr 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.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 23 Dezember 2018, 15:55:44
Der Befehl zum neu starten heißt restart nicht reboot. Bitte in Template ändern.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User 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!).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr 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.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig 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.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr 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 ;-)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox 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
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr 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.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User 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...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr 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?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag 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?
# 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 :) !
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr 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...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig 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?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User 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"...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 26 Dezember 2018, 21:59:46
Ja, und viele (Benutzer von telnet, FileLog/DbLog, iOS/Android Apps) werden euch verfluchen :)

Aber doch hoffentlich nicht an Weihnachten ;-)

Seit f18 funktioniert die Weboberfläche unter Android im Browser eigentlich sehr gut. Sehe da für mich keine Veranlassung mehr für eine App (insbesondere über https).

Habe den stateFormat-Eintrag einfach mal ins devStateIcon gepackt und siehe da funktioniert ohne Änderung. Dazu noch webCmd : und gut ist!

Allerdings wie kann ich jetzt das STATE bei Sensoren wo nichts geschalten wird einfach wieder los werden?

Gibt es eine Möglichkeit in der Weboberfläche das devSateIcon wie das stateFormat beim Editieren in einem Fenster anzuzeigen?

Und noch was, gibt es eine Möglichkeit in der Weboberfläche in der "Befehlszeile" den Cursor zu nutzen um den vorherigen Befehl nochmal zu bekommen? Oder einen anderen Trick?

Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 26 Dezember 2018, 22:32:33
Habe das devStateIcon eingecheckt. Bitte nachsehen, ob ich das mit dem ":" richtig verstanden habe.

Wäre nett, wenn wir das A_01b_tasmota_1ch+motion+SI7021 auch noch überarbeitet bekämen; da da aber auch noch der Motion-Channel irgendwie zu berücksichtigen wäre, ist das m.E. nichts für eine Trockenübung... Hier wäre es nach meinem vorläufigen Eindruck evtl. ganz gut, beides zu pflegen, also eine Textvariante für stateFormat und ein devStateIcon?

Ein deleteattr wollte ich dem sensors-only nicht ohne Rückfrage spendieren. Sowas sollte man schon dem user überlassen, oder? Oder habe ich das falsch verstanden?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 27 Dezember 2018, 11:18:00
Zitat
Gibt es eine Möglichkeit in der Weboberfläche das devSateIcon wie das stateFormat beim Editieren in einem Fenster anzuzeigen?
Ja, mit widgetOverride, Typ waere textField-long. Ich habe aber jetzt auch die Voreinstellung geaendert.

Zitat
gibt es eine Möglichkeit in der Weboberfläche in der "Befehlszeile" den Cursor zu nutzen um den vorherigen Befehl nochmal zu bekommen?
Bei mir wird nach Tippen im Browser eine gefilterte Historie angezeigt.
Zum "ernsthaften" Arbeiten verwende ich telnet, mit socat, hier ist mein tcsh alias:socat TCP:!:1\:!:2 readline,history=/Users/rudi/.telnet_historyDa gibt es die Historie mit Pfeilen, und Kommandozeilen-Editieren ist auch einfacher.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 27 Dezember 2018, 11:39:21
Habe das devStateIcon eingecheckt. Bitte nachsehen, ob ich das mit dem ":" richtig verstanden habe.

ja webCmd ist richtig.

A_01a_tasmota_basic_state_power1:
Bitte nimm dass mqttRetry COMMAND/MqttRetry noch raus. Da es ohnehin nicht das macht was wir wollten, lassen wir besser die Finger davon.

A_01_tasmota_basic:
<br>Use this in case "SetOption26 1" was used as described in tasmota documentation
sollte hier raus, da dies der Standard ist und ist ja hier auch falsch. Sollte nur bei A_01a_tasmota_basic_state_power1 rein

A_01x_tasmota_sensors_only, braucht es eigentlich nicht.  Würde des eher umbenennen und abändern in
A_01x_tasmota_clear_readings_reset_readingsList_and_reboot
desc: replaces the readingList with defaults, clears the readingList and reboots to get all readings
par:COMMAND;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\btele(/.*)?/LWT:, ? "${1}cmnd$2" : undef }
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
attr DEVICE readingList \
  tele/DEVNAME/LWT:.* LWT\
  tele/DEVNAME/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVNAME/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVNAME/INFO.:.* { json2nameValue($EVENT) }\
  stat/DEVNAME/RESULT:.* { json2nameValue($EVENT) }
deletereading DEVICE .*
set IO_DEV publish COMMAND/Restart 1
attr DEVICE autocreate 0

Hier der abgeänderte Code für motion+SI:
# tasmota device with one relay, one motion sensor via switch
name:A_01b_tasmota_1ch+motion+SI7021
desc:tasmota device with one relay, one motion sensor via switch and one SI7021 combined temperature and humidity sensor. <br>Configures a single device including all readings
filter:TYPE=MQTT2_DEVICE
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 \
  off:noArg    cmnd/DEVNAME/POWER1 0\
  on:noArg     cmnd/DEVNAME/POWER1 1\
  toggle:noArg cmnd/DEVNAME/POWER1 2
attr DEVICE stateFormat {\
  ReadingsVal($name, "POWER1", "off") . " "\
  ReadingsVal($name, "POWER2", "off") . " "\
  . sprintf("%.1f°C ",ReadingsVal($name,"SI7021_Temperature",0))\
  . sprintf("%.0f%%",ReadingsVal($name,"SI7021_Humidity",0))\
  }
attr DEVICE devStateIcon {\
  my $state = lc ReadingsVal($name, "POWER2", "off");\
  my $devStateIcon = 'building_security@green';\
  if ($state eq "on") {\
    $devStateIcon = 'building_security@red';\
  }\
  "<div>" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))\
    . FW_makeImage($devStateIcon) . sprintf(\
    "&nbsp;&nbsp;[Temp: %.1f°C / Feucht: %.0f%%]",\
    ReadingsVal($name,"SI7021_Temperature",0),\
    ReadingsVal($name,"SI7021_Humidity",0)\
    ) . "</div>"\
  }
attr DEVICE model A_01b_tasmota_1ch+motion+SI7021

und noch ein letztes. Ich würde bei A_04b_tasmota_4ch_unified_icon auch den stateFormat von unified_text übernehmen, dann kommt das als status in einigen Ansichten die kein devIcon benutzen.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 28 Dezember 2018, 15:36:12
Großes Danke an osr.

Die Änderungen sind seit eben im svn.

Dazu gesellt sich seit neuestem auch ein template-File für eine Test-Version von HTTPMOD (https://forum.fhem.de/index.php/topic,45176.msg877608.html#msg877608).
Wer da was beitragen kann/will: bitte dort melden :) ...

Gruß, Beta-User
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 31 Dezember 2018, 12:59:30
Kann das sein das sich in den Templates für Tasmota_basic ein Fehler eingeschlichen hat?
Da steht aktuell:
attr DEVICE setList \
  off:noArg    COMMAND/POWER 0\
  on:noArg     COMMAND/POWER 1\
  toggle:noArg COMMAND/POWER 2
Denke das sollte so sein:
attr DEVICE setList \
  off:noArg    cmnd/DEVNAME/POWER1 0\
  on:noArg     cmnd/DEVNAME/POWER1 1\
  toggle:noArg cmnd/DEVNAME/POWER1 2

Bei mir jedenfalls hat das Template in der aktuelle Fassung nicht funktioniert.

Gruß, Ingo

Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: binford6000 am 31 Dezember 2018, 15:58:40
Kann das sein das sich in den Templates für Tasmota_basic ein Fehler eingeschlichen hat?
Da steht aktuell:
attr DEVICE setList \
  off:noArg    COMMAND/POWER 0\
  on:noArg     COMMAND/POWER 1\
  toggle:noArg COMMAND/POWER 2
Denke das sollte so sein:
attr DEVICE setList \
  off:noArg    cmnd/DEVNAME/POWER1 0\
  on:noArg     cmnd/DEVNAME/POWER1 1\
  toggle:noArg cmnd/DEVNAME/POWER1 2

Bei mir jedenfalls hat das Template in der aktuelle Fassung nicht funktioniert.

Gruß, Ingo

Jepp, dem ist so  :(
VG Sebastian
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 31 Dezember 2018, 16:34:59
Korrektur ist im svn, Danke für den Hinweis.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 31 Dezember 2018, 16:40:47
Ja, mit widgetOverride, Typ waere textField-long. Ich habe aber jetzt auch die Voreinstellung geaendert.

Irgendwas geht dabei schief. Bisher ging das bei mir auch nach einem Update nicht. Habe mal in global bei userAttr devStateIcon rausgenommen und devStateIcon:textField-long drin gelassen.

Dann wird ein Fenster zum editieren angezeigt. Allerdings kommt dann immer eine Fehlermeldung sobald ein Zeilenumbruch vorhanden ist. Meldung ist dann dass es irgendeinen regexp-Problem gibt. Der selbe code im devStateIcon ohne Zeilenumbruch funktioniert aber.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 01 Januar 2019, 15:42:26
Zitat
Meldung ist dann dass es irgendeinen regexp-Problem gibt.
Danke fuer den Hinweis, mehrzeilige devStateIcon Attribute haben nicht funktioniert.Habs gefixt und eingecheckt.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 03 Januar 2019, 13:53:28
ich habe das hier jetzt nicht weiter verfolgt und mußte nun feststellen das sich mein 4-fach Sonoff nicht mehr über mein FTUI schalten läßt.
Ich weiß jetzt nicht zu welchem Zeitpunkt ich das template dafür genommen hatte.

Meine Definition in FTUI sieht aktuell so aus:
<div class="card">
<div data-type="switch" data-device="BU_Sonoff_1" data-get-on="on" data-get-off="off" data-icon="fs-it_printer" data-states='["on","off"]' data-background-icons='["red-box","green-box"]' data-off-color="lightgreen" data-on-color="#DC143C"></div>
<div>Netzwerk Drucker</div>
</div>

Da es aber die einzelnen Kanäle BU_Sonoff_1, BU_Sonoff_2, BU_Sonoff_3, BU_Sonoff_4 mit dem template nicht mehr gibt weiß ich nicht wie ich die jetzt ansteuern kann.
Muss ich diese Kanäle jetzt von Hand eintragen oder sollte ich ein Update machen mit neuen template Eigenschaften..?
Mir fehlt da grad aktuell das Verständnis..! :-\

Mein list vom 4 Kanal Sonoff sieht momentan so aus:
Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_890FBF
   DEF        DVES_890FBF
   DEVICETOPIC BU_4CH
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     3
   NAME       BU_4CH
   NR         4788
   STATE      <div>Drucker:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P2:<svg class=" on" data-txt="on" version="1.0" xmlns="http://www.w3.org/2000/svg"  width="468pt" height="537pt" viewBox="0 0 468 537"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,537) scale(0.181395,-0.181395)"  stroke="none"> <path d="M957 2932 c-14 -16 -17 -43 -17 -174 0 -135 2 -157 18 -171 28 -25 72 -26 96 -1 13 13 16 43 16 173 0 140 -2 160 -18 174 -25 22 -75 21 -95 -1z"/> <path d="M1506 2928 c-13 -18 -16 -53 -16 -174 0 -138 2 -152 20 -169 24 -22 77 -22 99 0 13 12 17 44 19 151 4 147 1 174 -24 198 -24 24 -80 20 -98 -6z"/> <path d="M278 2834 c-29 -15 -44 -50 -34 -81 3 -11 73 -85 154 -166 127 -126 153 -147 180 -147 34 0 72 38 72 73 0 34 -312 341 -342 337 -2 -1 -15 -7 -30 -16z"/> <path d="M2235 2840 c-34 -14 -315 -305 -315 -327 0 -35 38 -73 72 -73 27 0 53 21 180 148 82 81 151 157 155 170 12 51 -44 100 -92 82z"/> <path d="M1039 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M2110 2123 c-49 -19 -64 -68 -34 -111 15 -22 19 -22 238 -22 211 0 224 1 241 20 23 25 24 76 1 98 -14 15 -44 17 -224 19 -114 1 -214 -1 -222 -4z"/> <path d="M16 2098 c-22 -31 -20 -71 5 -94 19 -17 39 -19 240 -19 236 0 241 1 254 55 4 18 0 34 -15 53 l-21 27 -224 0 c-220 0 -224 0 -239 -22z"/> <path d="M26 1559 c-32 -25 -35 -70 -6 -99 19 -19 33 -20 238 -20 207 0 220 1 237 20 26 29 24 79 -4 102 -21 16 -44 18 -231 18 -195 0 -209 -1 -234 -21z"/> <path d="M2080 1560 c-23 -23 -26 -68 -6 -96 13 -18 30 -19 233 -22 203 -3 221 -2 243 16 32 26 32 78 1 104 -21 16 -44 18 -237 18 -201 0 -215 -1 -234 -20z"/> <path d="M20 1010 c-29 -29 -26 -74 7 -100 26 -20 36 -21 240 -18 184 3 215 5 229 20 23 22 22 73 -1 98 -17 19 -30 20 -237 20 -205 0 -219 -1 -238 -20z"/> <path d="M2077 1012 c-22 -25 -21 -75 1 -95 16 -15 48 -17 238 -17 120 0 224 4 231 8 32 20 32 94 0 114 -7 4 -111 8 -233 8 -201 0 -222 -2 -237 -18z"/> <path d="M998 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M1023 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M1023 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M1101 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P3:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg> P4:<svg class=" off" data-txt="off" version="1.0" xmlns="http://www.w3.org/2000/svg"  width="468pt" height="617pt" viewBox="0 0 468 617"  preserveAspectRatio="xMidYMid meet"> <metadata> Created by potrace 1.8, written by Peter Selinger 2001-2007 </metadata> <g transform="translate(0,617) scale(0.221801,-0.221801)"  stroke="none"> <path d="M756 2765 c-9 -25 -7 -128 3 -144 5 -8 16 -11 25 -8 24 10 19 160 -5 165 -9 2 -19 -4 -23 -13z"/> <path d="M1310 2695 c0 -77 2 -86 18 -83 14 3 17 15 17 83 0 68 -3 80 -17 83 -16 3 -18 -6 -18 -83z"/> <path d="M1806 2581 c-47 -47 -67 -74 -63 -85 4 -9 10 -16 14 -16 17 0 155 148 149 159 -14 21 -32 10 -100 -58z"/> <path d="M220 2622 c0 -23 125 -147 139 -138 21 13 11 32 -52 94 -64 64 -87 75 -87 44z"/> <path d="M809 2257 c-70 -20 -136 -63 -174 -115 -65 -87 -65 -91 -65 -643 0 -479 1 -500 21 -553 25 -67 87 -134 160 -173 l54 -28 250 0 c235 0 253 1 296 21 63 29 125 94 158 163 l26 56 0 520 0 520 -28 56 c-32 66 -99 132 -165 162 -43 20 -65 22 -267 24 -153 2 -234 -2 -266 -10z m486 -146 c48 -22 69 -44 90 -94 13 -31 15 -107 15 -517 0 -526 0 -523 -59 -573 -48 -40 -90 -47 -299 -47 -205 0 -226 4 -280 54 -51 46 -50 40 -53 567 l-3 495 23 40 c24 43 64 72 115 85 17 4 117 7 221 8 164 0 195 -2 230 -18z"/> <path d="M13 2065 c-11 -29 12 -36 118 -33 96 3 104 4 104 23 0 19 -8 20 -108 23 -91 2 -108 0 -114 -13z"/> <path d="M1877 2066 c-11 -27 17 -36 113 -36 100 0 127 8 117 34 -5 13 -25 16 -116 16 -83 0 -110 -3 -114 -14z"/> <path d="M10 1510 c0 -19 6 -20 116 -20 105 0 115 2 112 18 -3 15 -18 17 -116 20 -107 3 -112 2 -112 -18z"/> <path d="M1876 1522 c-2 -4 -1 -14 3 -20 5 -9 38 -12 117 -10 89 2 109 6 109 18 0 12 -20 16 -112 18 -61 1 -114 -1 -117 -6z"/> <path d="M21 981 c-8 -5 -11 -16 -8 -25 5 -13 24 -16 112 -16 88 0 107 3 112 16 10 26 -16 34 -112 34 -50 0 -96 -4 -104 -9z"/> <path d="M1882 978 c-8 -8 -9 -15 -1 -25 8 -9 40 -13 108 -13 101 0 128 8 118 34 -5 13 -24 16 -110 16 -66 0 -107 -4 -115 -12z"/> <path d="M768 693 c-36 -41 -30 -95 11 -108 60 -19 520 -91 539 -84 53 20 66 99 19 119 -28 12 -482 90 -524 90 -16 0 -37 -8 -45 -17z"/> <path d="M793 530 c-41 -17 -58 -85 -28 -110 15 -12 492 -100 543 -100 33 0 62 34 62 74 0 18 -6 38 -13 44 -6 6 -120 29 -252 51 -132 23 -251 43 -265 46 -14 2 -35 0 -47 -5z"/> <path d="M793 360 c-46 -18 -59 -90 -20 -114 21 -13 478 -96 531 -96 14 0 35 9 46 20 26 26 27 85 2 99 -10 5 -126 28 -258 51 -131 22 -248 42 -259 44 -11 2 -30 0 -42 -4z"/> <path d="M871 154 c-26 -33 -27 -55 -3 -82 13 -16 51 -26 176 -47 158 -27 159 -27 185 -7 31 22 41 81 18 101 -16 13 -271 61 -323 61 -23 0 -39 -8 -53 -26z"/> </g> </svg></div>
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 3
   m2server_TIME 2019-01-03 13:32:45
   READINGS:
     2019-01-01 12:57:29   FallbackTopic   DVES_890FBF
     2019-01-01 12:57:29   GroupTopic      sonoffs
     2019-01-01 12:57:29   Hostname        4Kanal-Sonoff-4031
     2019-01-01 12:57:29   IPAddress       10.0.0.155
     2019-01-03 13:24:48   LWT             Online
     2019-01-03 13:32:45   LoadAvg         19
     2019-01-01 12:57:29   Module          Sonoff 4CH
     2018-12-15 14:07:57   POWER           
     2019-01-03 13:32:45   POWER1          OFF
     2019-01-03 13:32:45   POWER2          ON
     2019-01-03 13:32:45   POWER3          OFF
     2019-01-03 13:32:45   POWER4          OFF
     2019-01-01 12:57:29   RestartReason   Power on
     2018-12-15 14:10:33   STATE_POWER1    OFF
     2018-12-15 14:10:33   STATE_POWER2    ON
     2018-12-15 14:10:33   STATE_POWER3    OFF
     2018-12-15 14:10:33   STATE_POWER4    OFF
     2018-12-15 14:10:33   STATE_Time      2018-12-15T14:10:33
     2018-12-15 14:10:33   STATE_Uptime    2T23:47:17
     2018-12-15 14:10:33   STATE_Vcc       3.176
     2018-12-15 14:10:33   STATE_Wifi_AP   1
     2018-12-15 14:10:33   STATE_Wifi_BSSId 9C:C7:A6:11:3E:A5
     2018-12-15 14:10:33   STATE_Wifi_Channel 11
     2018-12-15 14:10:33   STATE_Wifi_RSSI 30
     2018-12-15 14:10:33   STATE_Wifi_SSId xxxxxxxxxxxx
     2019-01-03 13:32:45   Sleep           50
     2019-01-03 13:32:45   SleepMode       Dynamic
     2019-01-03 13:32:45   Time            2019-01-03T13:32:28
     2019-01-03 13:32:45   Uptime          2T00:35:21
     2019-01-03 13:32:45   Vcc             3.477
     2019-01-01 12:57:29   Version         6.4.0(sonoff)
     2019-01-01 12:57:29   WebServerMode   Admin
     2019-01-03 13:32:45   Wifi_AP         1
     2019-01-03 13:32:45   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2019-01-03 13:32:45   Wifi_Channel    11
     2019-01-03 13:32:45   Wifi_RSSI       28
     2019-01-03 13:32:45   Wifi_SSId       xxxxxxxxxxxx
     2019-01-03 13:19:19   state           Drucker
Attributes:
   IODev      m2server
   alias      Büro 4-Kanal-Schalter
   autocreate 0
   readingList DVES_890FBF:tele/4Kanal-Sonoff/LWT:.* LWT
  DVES_890FBF:tele/4Kanal-Sonoff/STATE:.* { json2nameValue($EVENT) }
  DVES_890FBF:tele/4Kanal-Sonoff/SENSOR:.* { json2nameValue($EVENT) }
  DVES_890FBF:tele/4Kanal-Sonoff/INFO.:.* { json2nameValue($EVENT) }
  DVES_890FBF:tele/4Kanal-Sonoff/INFO1.:.* { json2nameValue($EVENT) }
  DVES_890FBF:tele/4Kanal-Sonoff/INFO2.:.* { json2nameValue($EVENT) }
  DVES_890FBF:tele/4Kanal-Sonoff/INFO3.:.* { json2nameValue($EVENT) }
  DVES_890FBF:stat/4Kanal-Sonoff/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT,OG - Flur
   setList    Drucker:on,off cmnd/4Kanal-Sonoff/POWER1 $EVTPART1
  p2:on,off  cmnd/4Kanal-Sonoff/POWER2 $EVTPART1
  p3:on,off  cmnd/4Kanal-Sonoff/POWER3 $EVTPART1
  p4:on,off  cmnd/4Kanal-Sonoff/POWER4 $EVTPART1
   stateFormat {
  "<div>Drucker:" . FW_makeImage(lc ReadingsVal($name, "POWER1", "off"))
  . " P2:" . FW_makeImage(lc ReadingsVal($name, "POWER2", "off"))
  . " P3:". FW_makeImage(lc ReadingsVal($name, "POWER3", "off"))
  . " P4:" . FW_makeImage(lc ReadingsVal($name, "POWER4", "off"))
  . "</div>"
  }
   webCmd     Drucker on:Drucker off:p2 on:p2 off:p3 on:p3 off:p4 on:p4 off
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 03 Januar 2019, 14:15:12
Gestern habe ich nochmal die tasmota-templates durchgesehen und dann auf einen einheitlichen Standard (nur noch mit "cmnd/DEVNAME/") gebracht. Da ging irgendwie manches durcheinander, hoffe, das paßt jetzt so.


@moonsorrox: wie war das denn vorher definiert? Vermutlich hattest du jeden Kanal als eigenes Device, oder?

Ich kenne jetzt FTUI nicht, aber tippen würde ich darauf, dass du zum einen data-device anpassen mußt (BU_4CH) und dann data-get-on auf "Drucker on" ändern (und data-get-off ebenfalls sinngemäß).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 03 Januar 2019, 14:55:54
Gestern habe ich nochmal die tasmota-templates durchgesehen und dann auf einen einheitlichen Standard (nur noch mit "cmnd/DEVNAME/") gebracht. Da ging irgendwie manches durcheinander, hoffe, das paßt jetzt so.


@moonsorrox: wie war das denn vorher definiert? Vermutlich hattest du jeden Kanal als eigenes Device, oder?
ja, genau, ich habe ja einen Kanal oben stellvertetend gezeigt.

Dieses ist eine komplette FTUI Anzeige, bedeutet ein Icon welches ich schalte und über die Farbe des Icons bekomme ich die Rückmeldung ob ein oder aus.
Das schalten habe ich ja noch hinbekommen - hierbei ist aber auch genau eben das Device abzubilden so wie du schon richtig geschrieben hast in data-get-on und data-get-off, aber was ich absolut nicht hinbekomme ist der Status abgebildet mit data-states, da habe ich schon alles mögliche eingetragen, aber ich bekomme es nicht hin.

Für den 1. Kanal
Aktuell arbeite ich noch mit data-get="POWER1" aber auch das funktioniert nicht ich kann einschalten aber nicht mehr aus und das Icon ändert sich zwar aber eben nicht richtig.
Gut wenn du FTUI nicht kennst, dann muss ich weiter probieren, oder ich stelle es manuell wieder um auf die einzelnen Kanäle.
Hier der aktuelle Code aus FTUI für den 1. Kanal
<div class="card">
<div data-type="switch" data-device="BU_4CH" data-get="POWER1" data-get-on="Drucker on" data-get-off="Drucker off" data-icon="fs-it_printer" data-states='["ON","OFF"]' data-background-icons='["red-box","green-box"]' data-off-color="lightgreen" data-on-color="#DC143C"></div>
<div>Netzwerk Drucker</div>
</div>

Evtl. hat das ja hier schon jemand mit dem 4Kanal Sonoff erstellt, dann wäre ich über einen Tipp dankbar...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 03 Januar 2019, 15:13:21
Hmm,

also bei FTUI kann ich nicht wirklich weiterhelfen, aber eigentlich sieht mir das nicht nach was kompliziertem aus.
Aber wieso wird "data-get-on" verwendet zum Schalten? Logischer wäre für mich "data-set-on". Die "get"-Variante klingt für meine unbedaften Ohren eher nach der Rückmeldung (und da POWER1 eigentlich schon was vernünftiges liefern sollte, wäre das m.E. ausreichend und nicht weiter aufzudröseln).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 03 Januar 2019, 17:47:42
Aber wieso wird "data-get-on" verwendet zum Schalten? Logischer wäre für mich "data-set-on". Die "get"-Variante klingt für meine unbedaften Ohren eher nach der Rückmeldung (und da POWER1 eigentlich schon was vernünftiges liefern sollte, wäre das m.E. ausreichend und nicht weiter aufzudröseln).
ja da hast du vollkommen Recht, da habe ich ein list zum falschen Zeitpunkt gemacht...! Das heißt dies ist durch meine vergeblichen Versuche passiert.

Also ich habe jetzt das template nochmal genutzt und komplett neu erstellt nun sehen die readinList, setList usw. auch alle anders aus.
Ich kann jetzt mit schalten, aber der Status des Icons in FTUI macht es nicht mehr....
Scheint ein Problem des 4 Kanal Sonoff zu sein, denn meine anderen Icons zeigen alles richtig an passend zum Status.
Evtl. muss ich mal warten ob diesen 4 Kanalschalter jemand nutzt und auch in FTUI die entsprechenden Icons angezeigt bekommt.

Ich bekomme es jedenfalls nicht gebacken  :-\  werde mal im FTUI hier im Forum fragen ob das jemand einsetzt
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 04 Januar 2019, 21:24:00
Ich habe jetzt hier nicht alles gelesen, aber es ergibt sich eine Frage:
Meine Steckdose habe ich per Hand eingeschaltet.
Trotzdedm zeigt "setstate Steckdose_2 2019-01-04 14:43:13 state off"
aber: "setstate Steckdose_2 2019-01-04 18:09:02 RESULT_POWER ON
          setstate Steckdose_2 2019-01-04 21:14:45 STATE_LoadAvg 19
          setstate Steckdose_2 2019-01-04 21:14:45 STATE_POWER ON"

Warum wird nicht überall on oder ON angezeigt? state solte doch on sein, wenn ich per Hand einschalte?


defmod Steckdose_2 MQTT2_DEVICE DVES_6ADBE6
attr Steckdose_2 IODev MQTT2_Server
attr Steckdose_2 devStateIcon .*on:hue_filled_outlet@lime .*off:hue_filled_outlet@LightSkyBlue
attr Steckdose_2 readingList DVES_6ADBE6:tele/sonoff1/LWT:.* LWT\
DVES_6ADBE6:cmnd/sonoff1/POWER:.* POWER\
DVES_6ADBE6:tele/sonoff1/INFO1:.* { json2nameValue($EVENT, 'INFO1_', $JSONMAP) }\
DVES_6ADBE6:tele/sonoff1/INFO2:.* { json2nameValue($EVENT, 'INFO2_', $JSONMAP) }\
DVES_6ADBE6:tele/sonoff1/INFO3:.* { json2nameValue($EVENT, 'INFO3_', $JSONMAP) }\
DVES_6ADBE6:stat/sonoff1/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }\
DVES_6ADBE6:stat/sonoff1/POWER:.* POWER\
DVES_6ADBE6:tele/sonoff1/STATE:.* { json2nameValue($EVENT, 'STATE_', $JSONMAP) }\
DVES_6ADBE6:tele/sonoff1/UPTIME:.* { json2nameValue($EVENT, 'UPTIME_', $JSONMAP) }
attr Steckdose_2 room MQTT2_DEVICE
attr Steckdose_2 setList on cmnd/sonoff1/POWER on\
off cmnd/sonoff1/POWER off\
reboot cmnd/sonoff1/Restart 1
attr Steckdose_2 webCmd on:off:reboot

setstate Steckdose_2 off
setstate Steckdose_2 2019-01-03 20:43:57 INFO1_FallbackTopic cmnd/DVES_6ADBE6_fb/
setstate Steckdose_2 2019-01-03 20:43:57 INFO1_GroupTopic sonoffs
setstate Steckdose_2 2019-01-03 20:43:57 INFO1_Module Sonoff S2X
setstate Steckdose_2 2019-01-03 20:43:57 INFO1_Version 6.4.1(sonoff)
setstate Steckdose_2 2019-01-03 20:43:57 INFO2_Hostname sonoff1-7142
setstate Steckdose_2 2019-01-03 20:43:57 INFO2_WebServerMode Admin
setstate Steckdose_2 2019-01-03 20:43:57 INFO3_RestartReason Power on
setstate Steckdose_2 2019-01-04 21:14:37 LWT Online
setstate Steckdose_2 2019-01-04 21:14:37 POWER
setstate Steckdose_2 2019-01-04 18:09:02 RESULT_POWER ON
setstate Steckdose_2 2019-01-04 21:14:45 STATE_LoadAvg 19
setstate Steckdose_2 2019-01-04 21:14:45 STATE_POWER ON
setstate Steckdose_2 2019-01-04 21:14:45 STATE_Sleep 50
setstate Steckdose_2 2019-01-04 21:14:45 STATE_SleepMode Dynamic
setstate Steckdose_2 2019-01-04 21:14:45 STATE_Time 2019-01-04T21:14:45
setstate Steckdose_2 2019-01-04 21:14:45 STATE_Uptime 1T00:30:54
setstate Steckdose_2 2019-01-04 21:14:45 STATE_Vcc 3.532
setstate Steckdose_2 2019-01-04 21:02:00 UPTIME_Time 2019-01-04T21:02:00
setstate Steckdose_2 2019-01-04 21:02:00 UPTIME_Uptime 1T00:18:09
setstate Steckdose_2 2019-01-04 14:43:13 state off


WIFI infos entfernt.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 08:02:57
@Invers:
Du nutzt (noch) nicht das template für den "einkanaligen" mit state=Power, daher sind alle Readings mit dem Prefix versehen.

Vielleicht versuchst du erst mal das mit dem template?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 09:08:45
Ich weiss nicht, die Steckdosen wurden ja automatisch angelegt. Aber ich versuche es mal. Danke.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 09:18:11
...das schließt sich nicht aus, genauer gesagt sind die templates eine "Erfindung", um einem ua. mit Tasmota das Leben zu erleichtern ;) . Details siehe hier: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Tasmota
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 10:15:41
OK, vielleicht habe ich mich geirrt, da ich ziemlich viel herumprobiert hatte.
Ich habe nun eine andere Steckdose mal gelöscht und neu anlegen lassen. Anschliessend habe ich Template A_01a_tasmota_basic_state_power1 zugewiesen.
Sieht dann so aus (WiFi entfernt):

defmod MQTT2_DVES_9C6846 MQTT2_DEVICE DVES_9C6846
attr MQTT2_DVES_9C6846 IODev MQTT2_Server
attr MQTT2_DVES_9C6846 autocreate 0
attr MQTT2_DVES_9C6846 eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
attr MQTT2_DVES_9C6846 model A_01a_tasmota_basic_state_power1
attr MQTT2_DVES_9C6846 readingList tele/sonoff3/LWT:.* LWT\
  tele/sonoff3/STATE:.* { json2nameValue($EVENT) }\
  tele/sonoff3/SENSOR:.* { json2nameValue($EVENT) }\
  tele/sonoff3/INFO.:.* { json2nameValue($EVENT) }\
  stat/sonoff3/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9C6846 room MQTT2_DEVICE
attr MQTT2_DVES_9C6846 setList off:noArg    cmnd/sonoff3/POWER1 0\
  on:noArg     cmnd/sonoff3/POWER1 1\
  toggle:noArg cmnd/sonoff3/POWER1 2
attr MQTT2_DVES_9C6846 setStateList on off toggle
attr MQTT2_DVES_9C6846 stateFormat POWER1

setstate MQTT2_DVES_9C6846 POWER1
setstate MQTT2_DVES_9C6846 2019-01-05 09:46:54 LoadAvg 19
setstate MQTT2_DVES_9C6846 2019-01-05 09:46:54 POWER OFF
setstate MQTT2_DVES_9C6846 2019-01-05 09:46:54 Sleep 50
setstate MQTT2_DVES_9C6846 2019-01-05 09:46:54 SleepMode Dynamic
setstate MQTT2_DVES_9C6846 2019-01-05 09:46:54 Time 2019-01-05T09:46:53
setstate MQTT2_DVES_9C6846 2019-01-05 09:46:54 Uptime 0T00:35:27
setstate MQTT2_DVES_9C6846 2019-01-05 09:46:54 Vcc 3.519
setstate MQTT2_DVES_9C6846 2019-01-05 09:45:48 state set_off


Ich habe keine Anpassungen vorgenommen.
Folgendes ist mir nun aufgefallen:
Firefox wird "DeviceOverview MQTT2_DVES_9C6846 POWER1 on off" angezeigt. POWER1, on und off können geklickt werden.
Klick auf POWER1 schaltet nur an, sonst nichts. On und off funktionieren, wie gewohnt. Leider  blitzt dazwischen das Lampen-Icon nur kurz auf und nimmt den Platz für diese kurze Zeit von POWER1 ein.
Bei den Readings steht POWER auf on. Aktualisiere ich aber den Browser, steht das Reading auf ON. Nach der nächsten Aktualisierung durch MQTT2 steht da wieder on (klein geschrieben).
Bei STATE steht POWER1. Das ändert sich bis jetzt niemals.
Bei state steht set_on oder set_off, aber nur, wenn ich über die Oberfläche schalte, nicht, wenn ich an der Steckdose die Taste drücke. Dann bleibt state unverändert.

Ist das alles so gewollt? Ich beschäftige mich noch nicht lange mit MQTT2 und hab da erst einmal wenig Ahnung.
Ich würde allerdings gefühlsmäßig erwarten, dass bei state on oder off steht. Muss ich nun wirklich statt state in allen DOIFs und so weiter POWER abfragen? Und das dann in Gross- oder/und Kleinschreibung?
Eventmonitor zeigt POWER: off oder POWER: on. Also Kleinschreibung.

Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 10:58:50
Du solltest das andere template (A_01_tasmota_basic) nehmen.
Ees gibt zwei Basic-templates, die sich darin unterscheiden, was im state angezeigt wird und wie die Schaltbefehle sind. Das mit state_POWER1 ist für die, die das umkonfiguriert haben.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 11:15:28
OK, versuche ich. Ich war der Empfehlung attrTemplate ? gefolgt. Danke dir.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 11:20:49
Ich war der Empfehlung attrTemplate ? gefolgt. Danke dir.
Verstehe ich nicht ganz; da steht doch auch beim basic:
Zitat
Applies to Sonoff 1 Channel devices using POWER-topic for relay state
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 11:37:20
Aber beim Anderen steht:
A_01a_tasmota_basic_state_power1
Applies to Sonoff Basic, S20 using POWER1-topic for relay state

Und ich habe ja S20 und S26. Da dachte ich, das wäre richtig, zumal der mit A_01_tasmota_basic in der FHEM-Oberfläche nicht geschaltet hatte und auch jetzt nicht schaltet.
Ich habe nun das Template A_01_tasmota_basic genommen. Die Steckdose schaltet aber nicht per FHEM-Oberfläche, wobei das Icon aber korrekt angezeigt wird. Werte kommen von der Dose.
Das Problem mit Gross/ Kleinschreibung besteht weiterhin.


defmod MQTT2_DVES_9C6846 MQTT2_DEVICE DVES_9C6846
attr MQTT2_DVES_9C6846 IODev MQTT2_Server
attr MQTT2_DVES_9C6846 autocreate 0
attr MQTT2_DVES_9C6846 eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
attr MQTT2_DVES_9C6846 model A_01a_tasmota_basic_state_power1
attr MQTT2_DVES_9C6846 readingList tele/sonoff3/LWT:.* LWT\
  tele/sonoff3/STATE:.* { json2nameValue($EVENT) }\
  tele/sonoff3/SENSOR:.* { json2nameValue($EVENT) }\
  tele/sonoff3/INFO.:.* { json2nameValue($EVENT) }\
  stat/sonoff3/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9C6846 room MQTT2_DEVICE
attr MQTT2_DVES_9C6846 setList off:noArg    cmnd/DEVNAME/POWER1 0\
  on:noArg     cmnd/DEVNAME/POWER1 1\
  toggle:noArg cmnd/DEVNAME/POWER1 2
attr MQTT2_DVES_9C6846 setStateList on off toggle
attr MQTT2_DVES_9C6846 stateFormat POWER1

setstate MQTT2_DVES_9C6846 set_off
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 FallbackTopic cmnd/DVES_9C6846_fb/
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 GroupTopic sonoffs
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 Hostname sonoff3-2118
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 IPAddress 192.168.178.37
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 LWT Online
setstate MQTT2_DVES_9C6846 2019-01-05 11:35:04 LoadAvg 19
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 Module Sonoff S2X
setstate MQTT2_DVES_9C6846 2019-01-05 11:35:04 POWER OFF
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 RestartReason Power on
setstate MQTT2_DVES_9C6846 2019-01-05 11:35:04 Sleep 50
setstate MQTT2_DVES_9C6846 2019-01-05 11:35:04 SleepMode Dynamic
setstate MQTT2_DVES_9C6846 2019-01-05 11:35:04 Time 2019-01-05T11:35:03
setstate MQTT2_DVES_9C6846 2019-01-05 11:35:04 Uptime 0T00:05:14
setstate MQTT2_DVES_9C6846 2019-01-05 11:35:04 Vcc 3.523
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 Version 6.4.1(sonoff)
setstate MQTT2_DVES_9C6846 2019-01-05 11:29:55 WebServerMode Admin
setstate MQTT2_DVES_9C6846 2019-01-05 11:35:15 state set_off


Hab ich noch etwas übersehen? Hast du noch ne Idee?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 11:53:14
Arghh, da ist mir im basic eine Zeile verloren gegangen:

Das hier sollte in Zeile 164 stehen:
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }Ich check's gleich ein...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 12:02:10
Ja , sorry, hatte ich diesmal vergessen bei readingList den Namen zu ändern und gerade noch ebend selber bemerkt. Nun schaltet sie wieder.
Alle Probnleme sind nun wieder mit denen des anderen Templates identisch.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 12:12:40
Hmm, lösche mal

attr MQTT2_DVES_9C6846 setStateList on off toggleDas ist für das "Zwischenschalten" von set_on verantwortlich (ich finde das mit dem Zwischenstatus gut, weil dann erst der rückgemeldete Status da steht und nicht das Wunschergebnis).

Für Groß- und Kleinschreibung ist die eventMap zuständig. Wenn du Großschreibung brauchst (?), dann evtl. auch probeweise mal löschen, FHEM sollte auch in der Darstellung zwischenzeitlich trotzdem klarkommen.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: sinus61 am 05 Januar 2019, 12:26:30
Ich bekomme es jedenfalls nicht gebacken  :-\  werde mal im FTUI hier im Forum fragen ob das jemand einsetzt

Die Lösung zum Status von POWER1 sieht ja so aus:
data-states='["(.*on|ON)","(.*off|OFF)"]'

Aber warum wechselt der Status auf Fhem Seite nach einiger Zeit auf Großbuchstaben? Praktisch zur Auswertung ist das ja nicht.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 14:08:39
@Beta-User
Habe ich gelöscht. Jetzt kann ich schalten. Alle anderen Probleme bleiben aber bestehen.
Gross-Kleinschreibung sollte eigentlich nur einheitlich sein.
Weil bei allen Steckdosen und Lampen bei state on oder off steht, finde ich es halt seltsam, dass es her nicht so ist.
nun,, nach Löschung des Attributes steht da aber on oder off bei state, so ist es in Ordnung. Nun bleibt aber state on oder off, auch dann, wenn ich am Knopf der Dose schalte. Und das ist für mich das eigentliche Problem. Ist das denn so richtig?
Wäre es nicht logischer (wie es ja sonst auch ist), wenn in und off auch wechseln würden, wenn man an der Dose schaltet? Darum meine Frage, ob ich nun statt state (wie sonst überall) nun POWER auswerten muss.
Bei DeviceOverview steht bei mir immer noch POWER1 on off. Ich bekomme auch kein devStateIcon mehr.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 14:15:45
Habe ich gelöscht.
Welches der Attribute? Ich hatte zwei genannt...
Ich würde unterstellen, dass das eigentliche Problem immer noch ist, dass stateFormat auf POWER1 steht - und genau das wird nicht akutalisiert, weil das Reading POWER heißt.
Ich kann aber nur doppelt vermuten, den a) habe ich keinen sonoff-Tasmota daliegen und b) kenne ich das aktuelle list nicht (am besten raw, dann sieht man auch die setreadings)...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 14:25:10
Sorry, hatte
attr MQTT2_DVES_9C6846 setStateList on off toggle
gelöscht.

List sieht aktuell so aus:

Internals:
   CID        DVES_9C6846
   DEF        DVES_9C6846
   DEVICETOPIC MQTT2_DVES_9C6846
   IODev      MQTT2_Server
   LASTInputDev MQTT2_Server
   MQTT2_Server_MSGCNT 82
   MQTT2_Server_TIME 2019-01-05 14:17:23
   MSGCNT     82
   NAME       MQTT2_DVES_9C6846
   NR         2323
   STATE      POWER1
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-01-05 13:47:15   FallbackTopic   cmnd/DVES_9C6846_fb/
     2019-01-05 13:47:15   GroupTopic      sonoffs
     2019-01-05 13:47:15   Hostname        sonoff3-2118
     2019-01-05 13:47:15   IPAddress       192.168.178.37
     2019-01-05 13:47:14   LWT             Online
     2019-01-05 14:17:23   LoadAvg         19
     2019-01-05 13:47:15   Module          Sonoff S2X
     2019-01-05 14:17:23   POWER           ON
     2019-01-05 13:47:15   RestartReason   Power on
     2019-01-05 14:17:23   Sleep           50
     2019-01-05 14:17:23   SleepMode       Dynamic
     2019-01-05 14:17:23   Time            2019-01-05T14:17:23
     2019-01-05 14:17:23   Uptime          0T00:30:14
     2019-01-05 14:17:23   Vcc             3.522
     2019-01-05 13:47:15   Version         6.4.1(sonoff)
     2019-01-05 13:47:15   WebServerMode   Admin
     2019-01-05 14:11:13   state           on
Attributes:
   IODev      MQTT2_Server
   autocreate 0
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   model      A_01a_tasmota_basic_state_power1
   readingList tele/sonoff3/LWT:.* LWT
  tele/sonoff3/STATE:.* { json2nameValue($EVENT) }
  tele/sonoff3/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoff3/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoff3/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoff3/POWER1 0
  on:noArg     cmnd/sonoff3/POWER1 1
  toggle:noArg cmnd/sonoff3/POWER1 2
   stateFormat POWER1
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 14:32:07
stateFormat ändern wie bereits vermutet. Dann könntest du das andere m.E. sogar wieder rein nehmen...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 14:51:48
Ich habe noch einmal alles weggeworfen und neu anlegen lassen/angelegt.

sieht nun nach autoCreate so aus:
Internals:
   CID        DVES_9C6846
   DEF        DVES_9C6846
   DEVICETOPIC MQTT2_DVES_9C6846
   IODev      MQTT2_Server
   LASTInputDev MQTT2_Server
   MQTT2_Server_MSGCNT 6
   MQTT2_Server_TIME 2019-01-05 14:33:35
   MSGCNT     6
   NAME       MQTT2_DVES_9C6846
   NR         540
   STATE      ???
   TYPE       MQTT2_DEVICE
   READINGS:
     2019-01-05 14:31:31   LWT             Online
     2019-01-05 14:33:35   POWER           ON
     2019-01-05 14:33:35   RESULT_POWER    ON
     2019-01-05 14:32:30   STATE_LoadAvg   19
     2019-01-05 14:32:30   STATE_POWER     ON
     2019-01-05 14:32:30   STATE_Sleep     50
     2019-01-05 14:32:30   STATE_SleepMode Dynamic
     2019-01-05 14:32:30   STATE_Time      2019-01-05T14:32:30
     2019-01-05 14:32:30   STATE_Uptime    0T00:45:21
     2019-01-05 14:32:30   STATE_Vcc       3.538
Attributes:
   IODev      MQTT2_Server
   readingList DVES_9C6846:tele/sonoff3/LWT:.* LWT
DVES_9C6846:cmnd/sonoff3/POWER:.* POWER
DVES_9C6846:tele/sonoff3/STATE:.* { json2nameValue($EVENT, 'STATE_', $JSONMAP) }
DVES_9C6846:stat/sonoff3/RESULT:.* { json2nameValue($EVENT, 'RESULT_', $JSONMAP) }
DVES_9C6846:stat/sonoff3/POWER:.* POWER
   room       MQTT2_DEVICE

Nach dem Anwenden des Templates und der Änderung von setList sieht es dann so aus:

Internals:
   CID        DVES_9C6846
   DEF        DVES_9C6846
   DEVICETOPIC MQTT2_DVES_9C6846
   IODev      MQTT2_Server
   LASTInputDev MQTT2_Server
   MQTT2_Server_MSGCNT 14
   MQTT2_Server_TIME 2019-01-05 14:39:26
   MSGCNT     14
   NAME       MQTT2_DVES_9C6846
   NR         540
   STATE      ON
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2019-01-05 14:37:30   LoadAvg         19
     2019-01-05 14:39:26   POWER           ON
     2019-01-05 14:37:30   Sleep           50
     2019-01-05 14:37:30   SleepMode       Dynamic
     2019-01-05 14:37:30   Time            2019-01-05T14:37:30
     2019-01-05 14:37:30   Uptime          0T00:50:21
     2019-01-05 14:37:30   Vcc             3.538
     2019-01-05 14:39:26   state           set_on
Attributes:
   IODev      MQTT2_Server
   autocreate 0
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   model      A_01_tasmota_basic
   readingList tele/sonoff3/LWT:.* LWT
  tele/sonoff3/STATE:.* { json2nameValue($EVENT) }
  tele/sonoff3/SENSOR:.* { json2nameValue($EVENT) }
  tele/sonoff3/INFO.:.* { json2nameValue($EVENT) }
  stat/sonoff3/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
   setList    off:noArg    cmnd/sonoff3/POWER 0
  on:noArg     cmnd/sonoff3/POWER 1
  toggle:noArg cmnd/sonoff3/POWER 2
   setStateList on off toggle
   stateFormat POWER


nun ist das Icon da und ich kann auch schalten.
Die Schreibweise von POWER On on OFF off ignoriere ich einfach.
Bleibt nur noch die Frage, ob es so gewollt ist, dass sich state nicht verändert, wenn man am Taster der Dose schaltet.
Beim Schalten per set - Befehl wird state geändert.

stateFormat  ändern kann ich probieren. Aber was soll das ändern? Dann steht da halt nur off, statt set_off, oder sehe ich da was nicht richtig?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 15:59:16
Hmmm,

das mit dem Schalter kann ich ohne Hardware nicht nachvollziehen.

Lösche mal das autocreate-Attribut und schalte dann. Gibt es irgendein neues Reading (Browser-refresh machen)? Wird irgendwas vorhandenes aktualisiert?

Im Zweifel mußt du mal mitlesen, was beim Schalten über den Schalter an Verkehr in MQTT stattfindet, das sieht mir nicht nach einem Problem des templates aus, sondern eher danach, dass der ESP irgendwas nicht liefert...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 16:33:23
Das ist sicher kein Problem des Templates. Ich hatte ja dieses Problem bereits, bevor du sagtest, ich soll ein Template nutzen. Also bestand das Problem schon nach dem Autocreate.
Änderungen konnte ich nicht bemerken.

Womit soll ich den Verkehr denn loggen? Mosquitto habe ich deinstalliert. Vielleicht die Konsole der Steckdose?

Steckdose Konsole:

manuell
16:35:50 MQT: stat/sonoff3/RESULT = {"POWER":"ON"}
16:35:50 MQT: stat/sonoff3/POWER = ON
16:35:53 MQT: stat/sonoff3/RESULT = {"POWER":"OFF"}
16:35:53 MQT: stat/sonoff3/POWER = OFF

per Set
16:36:42 MQT: stat/sonoff3/RESULT = {"POWER":"ON"}
16:36:42 MQT: stat/sonoff3/POWER = ON
16:36:43 MQT: stat/sonoff3/RESULT = {"POWER":"OFF"}
16:36:43 MQT: stat/sonoff3/POWER = OFF


und noch verbose5 Server und Device

2019.01.05 16:44:15 5: PINGREQ:
2019.01.05 16:44:15 4: MQTT2_Server_192.168.178.33_49189 DVES_6ADBE6 PINGREQ
2019.01.05 16:44:17 5: PINGREQ:
2019.01.05 16:44:17 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 16:44:18 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"ON"}
2019.01.05 16:44:18 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 16:44:18 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 16:44:18 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 16:44:18 5: PUBLISH: (0)(18)stat/sonoff3/POWERON
2019.01.05 16:44:18 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/POWER:ON
2019.01.05 16:44:18 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:ON
2019.01.05 16:44:18 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 16:49:32
Also:
1. Ist autocreate wieder aktiv am Device? Wenn nein: Bitte wieder einschalten (=Attribut löschen).
2. Mitlesen kann man z.B. so: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#MQTT2_SERVER_nutzen
oder mosquitto_sub an einer Konsole nutzen (man muß dazu nicht auch die mosquitto-server-Komponente installieren, es reicht das Paket mosquitto-clients).

Uns interessiert eigentlich _nur_ das, was über MQTT kommt. Alles, was im Web-IF oder auf der seriellen Konsole rauskommt kann allenfalls eine Art Indikator dafür dienen, ob auf dem Teil irgendwas ganz schief läuft (aber es schaltet ja...).

Wenn du Vorschläge hast, wie man den verlinkten Wiki-Artikel verbessern kann, insbesondere im Tasmota-Abschnitt: Her damit....
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 17:04:22
Ich weiss nicht, ob der Mittschnitt so ausreichend ist. Falls nicht, kann ich nachliefern.

attr MQTT2_Server rawEvents DVES_9C6846

an aus an aus am Taster

019.01.05 17:00:28 5: PINGREQ:
2019.01.05 17:00:28 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 17:00:29 5: PINGREQ:
2019.01.05 17:00:29 4: MQTT2_Server_192.168.178.33_49189 DVES_6ADBE6 PINGREQ
2019.01.05 17:00:32 5: PINGREQ:
2019.01.05 17:00:32 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PINGREQ
2019.01.05 17:00:36 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"OFF"}
2019.01.05 17:00:36 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:00:36 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:00:37 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:00:37 5: PUBLISH: (0)(18)stat/sonoff3/POWEROFF
2019.01.05 17:00:37 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/POWER:OFF
2019.01.05 17:00:37 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:OFF
2019.01.05 17:00:37 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:00:38 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"ON"}
2019.01.05 17:00:38 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:00:38 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:00:38 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:00:38 5: PUBLISH: (0)(18)stat/sonoff3/POWERON
2019.01.05 17:00:38 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/POWER:ON
2019.01.05 17:00:38 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:ON
2019.01.05 17:00:38 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:00:38 5: PINGREQ:
2019.01.05 17:00:38 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 17:00:39 5: PINGREQ:
2019.01.05 17:00:39 4: MQTT2_Server_192.168.178.33_49189 DVES_6ADBE6 PINGREQ
2019.01.05 17:00:40 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"OFF"}
2019.01.05 17:00:40 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:00:40 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:00:40 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:00:40 5: PUBLISH: (0)(18)stat/sonoff3/POWEROFF
2019.01.05 17:00:40 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/POWER:OFF
2019.01.05 17:00:40 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:OFF
2019.01.05 17:00:40 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:00:41 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"ON"}
2019.01.05 17:00:41 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:00:41 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:00:41 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:00:41 5: PUBLISH: (0)(18)stat/sonoff3/POWERON
2019.01.05 17:00:41 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH stat/sonoff3/POWER:ON
2019.01.05 17:00:41 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:ON
2019.01.05 17:00:41 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:00:42 5: PUBLISH: (0)(18)tele/sonoff3/STATE{"Time":"2019-01-05T17:00:41","Uptime":"0T01:10:20","Vcc":3.538,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":29,"POWER":"ON","Wifi":{"AP":1,"SSId":"HachMichHart","BSSId":"08:96:D7:16:26:89","Channel":11,"RSSI":100}}
2019.01.05 17:00:42 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PUBLISH tele/sonoff3/STATE:{"Time":"2019-01-05T17:00:41","Uptime":"0T01:10:20","Vcc":3.538,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":29,"POWER":"ON","Wifi":{"AP":1,"SSId":"HachMichHart","BSSId":"08:96:D7:16:26:89","Channel":11,"RSSI":100}}
2019.01.05 17:00:42 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:tele/sonoff3/STATE:{"Time":"2019-01-05T17:00:41","Uptime":"0T01:10:20","Vcc":3.538,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":29,"POWER":"ON","Wifi":{"AP":1,"SSId":"HachMichHart","BSSId":"08:96:D7:16:26:89","Channel":11,"RSSI":100}}
2019.01.05 17:00:42 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 tele/sonoff3/STATE => { json2nameValue($EVENT) }
2019.01.05 17:00:42 5: PINGREQ:
2019.01.05 17:00:42 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PINGREQ


an aus an aus per set

2019.01.05 17:01:35 1: Logfile gelöscht
2019.01.05 17:01:39 5: PINGREQ:
2019.01.05 17:01:39 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 17:01:39 5: PINGREQ:
2019.01.05 17:01:39 4: MQTT2_Server_192.168.178.33_49189 DVES_6ADBE6 PINGREQ
2019.01.05 17:01:42 5: PINGREQ:
2019.01.05 17:01:42 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PINGREQ
2019.01.05 17:01:43 5: MQTT2_Server: PUBLISH cmnd/DEVNAME/POWER 1
2019.01.05 17:01:44 5: PUBLISH: (0)(18)tele/sonoff1/STATE{"Time":"2019-01-05T17:01:44","Uptime":"0T11:16:32","Vcc":3.543,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"ON","Wifi":{"AP":1,"SSId":"HachMichHart","BSSId":"08:96:D7:16:26:89","Channel":11,"RSSI":90}}
2019.01.05 17:01:44 4: MQTT2_Server_192.168.178.33_49189 DVES_6ADBE6 PUBLISH tele/sonoff1/STATE:{"Time":"2019-01-05T17:01:44","Uptime":"0T11:16:32","Vcc":3.543,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"ON","Wifi":{"AP":1,"SSId":"HachMichHart","BSSId":"08:96:D7:16:26:89","Channel":11,"RSSI":90}}
2019.01.05 17:01:44 5: MQTT2_Server: dispatch autocreate:DVES_6ADBE6:tele/sonoff1/STATE:{"Time":"2019-01-05T17:01:44","Uptime":"0T11:16:32","Vcc":3.543,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"ON","Wifi":{"AP":1,"SSId":"HachMichHart","BSSId":"08:96:D7:16:26:89","Channel":11,"RSSI":90}}
2019.01.05 17:01:45 5: MQTT2_Server: PUBLISH cmnd/DEVNAME/POWER 0
2019.01.05 17:01:46 5: MQTT2_Server: PUBLISH cmnd/DEVNAME/POWER 1
2019.01.05 17:01:48 5: MQTT2_Server: PUBLISH cmnd/DEVNAME/POWER 0
2019.01.05 17:01:49 5: PINGREQ:
2019.01.05 17:01:49 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 17:01:49 5: PINGREQ:
2019.01.05 17:01:49 4: MQTT2_Server_192.168.178.33_49189 DVES_6ADBE6 PINGREQ
2019.01.05 17:01:52 5: PINGREQ:
2019.01.05 17:01:52 4: MQTT2_Server_192.168.178.37_49157 DVES_9C6846 PINGREQ
2019.01.05 17:01:59 5: PINGREQ:
2019.01.05 17:01:59 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ


WLAN-Daten geändert!!! Falls da Fehler drinnen sind, ignorieren.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 17:15:34
Ansonsten sollte doch eigentlich das reading POWER auch beim Drücken des Tasters aktualisiert worden sein, oder verstehe ich den Traffic nicht?
Aber was ganz anderes: wo kommt denn jetzt wieder "DEVNAME" her?!?
Hast du das template aus dem svn genommen oder das fehlerhafte wieder angewendet? Oder FHEM ohne save neu gestartet?
Es macht keinen großen Sinn, ständig woanders aufzusetzen und alle Variablen wieder zu ändern. Dann ist es frustrierende Raterei.

Dann wäre noch interessant, welche Tasmota-Version das ist: https://forum.fhem.de/index.php/topic,95360.0.htmlScheint aber noch nicht die ganz letzte zu sein, das Reading POWER kommt ja rein.


Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 17:45:19
Ja, ich stehe heute wohl etwas neben mir. Ich hatte das Device neu angelegt, weil ich selber noch rumprobiert hatte und habe dabei vergessen, erneut die Änderung vorzunehmen. Bitte entschuldige. Asche auf mein Haupt.
Hier der richtige Mitschnitt.



aus an aus an per Knopf und dann aus an aus an per set
2019.01.05 17:38:10 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"OFF"}
2019.01.05 17:38:10 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:38:10 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:38:10 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:38:10 5: PUBLISH: (0)(18)stat/sonoff3/POWEROFF
2019.01.05 17:38:10 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/POWER:OFF
2019.01.05 17:38:10 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:OFF
2019.01.05 17:38:10 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:38:10 5: PINGREQ:
2019.01.05 17:38:10 4: MQTT2_Server_192.168.178.33_49202 DVES_6ADBE6 PINGREQ
2019.01.05 17:38:11 5: PINGREQ:
2019.01.05 17:38:11 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 17:38:12 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"ON"}
2019.01.05 17:38:12 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:38:12 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:38:12 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:38:12 5: PUBLISH: (0)(18)stat/sonoff3/POWERON
2019.01.05 17:38:12 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/POWER:ON
2019.01.05 17:38:12 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:ON
2019.01.05 17:38:12 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:38:13 5: PINGREQ:
2019.01.05 17:38:13 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PINGREQ
2019.01.05 17:38:14 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"OFF"}
2019.01.05 17:38:14 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:38:14 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:38:14 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:38:15 5: PUBLISH: (0)(18)stat/sonoff3/POWEROFF
2019.01.05 17:38:15 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/POWER:OFF
2019.01.05 17:38:15 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:OFF
2019.01.05 17:38:15 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:38:17 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"ON"}
2019.01.05 17:38:17 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:38:17 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:38:17 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:38:17 5: PUBLISH: (0)(18)stat/sonoff3/POWERON
2019.01.05 17:38:17 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/POWER:ON
2019.01.05 17:38:17 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:ON
2019.01.05 17:38:17 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:38:21 5: PINGREQ:
2019.01.05 17:38:21 4: MQTT2_Server_192.168.178.33_49202 DVES_6ADBE6 PINGREQ
2019.01.05 17:38:21 5: PINGREQ:
2019.01.05 17:38:21 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 17:38:24 5: PINGREQ:
2019.01.05 17:38:24 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PINGREQ
2019.01.05 17:38:30 5: PINGREQ:
2019.01.05 17:38:30 4: MQTT2_Server_192.168.178.33_49202 DVES_6ADBE6 PINGREQ
2019.01.05 17:38:31 5: PINGREQ:
2019.01.05 17:38:31 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 17:38:34 5: PINGREQ:
2019.01.05 17:38:34 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PINGREQ
2019.01.05 17:38:40 5: PINGREQ:
2019.01.05 17:38:40 4: MQTT2_Server_192.168.178.33_49202 DVES_6ADBE6 PINGREQ
2019.01.05 17:38:41 5: PINGREQ:
2019.01.05 17:38:41 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ
2019.01.05 17:38:44 5: PINGREQ:
2019.01.05 17:38:44 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PINGREQ
2019.01.05 17:38:45 5: MQTT2_Server: PUBLISH cmnd/sonoff3/POWER 0
2019.01.05 17:38:45 5: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 => cmnd/sonoff3/POWER:0
2019.01.05 17:38:45 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"OFF"}
2019.01.05 17:38:45 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:38:45 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:38:45 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:38:45 5: PUBLISH: (0)(18)stat/sonoff3/POWEROFF
2019.01.05 17:38:45 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/POWER:OFF
2019.01.05 17:38:45 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:OFF
2019.01.05 17:38:45 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:38:46 5: MQTT2_Server: PUBLISH cmnd/sonoff3/POWER 1
2019.01.05 17:38:46 5: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 => cmnd/sonoff3/POWER:1
2019.01.05 17:38:47 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"ON"}
2019.01.05 17:38:47 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:38:47 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:38:47 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:38:47 5: PUBLISH: (0)(18)stat/sonoff3/POWERON
2019.01.05 17:38:47 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/POWER:ON
2019.01.05 17:38:47 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:ON
2019.01.05 17:38:47 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:38:48 5: MQTT2_Server: PUBLISH cmnd/sonoff3/POWER 0
2019.01.05 17:38:48 5: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 => cmnd/sonoff3/POWER:0
2019.01.05 17:38:48 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"OFF"}
2019.01.05 17:38:48 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:38:48 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"OFF"}
2019.01.05 17:38:48 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:38:48 5: PUBLISH: (0)(18)stat/sonoff3/POWEROFF
2019.01.05 17:38:48 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/POWER:OFF
2019.01.05 17:38:48 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:OFF
2019.01.05 17:38:48 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:38:49 5: MQTT2_Server: PUBLISH cmnd/sonoff3/POWER 1
2019.01.05 17:38:49 5: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 => cmnd/sonoff3/POWER:1
2019.01.05 17:38:49 5: PUBLISH: (0)(19)stat/sonoff3/RESULT{"POWER":"ON"}
2019.01.05 17:38:49 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:38:49 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/RESULT:{"POWER":"ON"}
2019.01.05 17:38:49 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/RESULT => { json2nameValue($EVENT) }
2019.01.05 17:38:49 5: PUBLISH: (0)(18)stat/sonoff3/POWERON
2019.01.05 17:38:49 4: MQTT2_Server_192.168.178.37_49153 DVES_9C6846 PUBLISH stat/sonoff3/POWER:ON
2019.01.05 17:38:49 5: MQTT2_Server: dispatch autocreate:DVES_9C6846:stat/sonoff3/POWER:ON
2019.01.05 17:38:49 4: MQTT2_DEVICE_Parse: MQTT2_DVES_9C6846 stat/sonoff3/POWER => POWER
2019.01.05 17:38:50 5: PINGREQ:
2019.01.05 17:38:50 4: MQTT2_Server_192.168.178.33_49202 DVES_6ADBE6 PINGREQ
2019.01.05 17:38:51 5: PINGREQ:
2019.01.05 17:38:51 4: MQTT2_Server_192.168.178.27_49185 DVES_24C4E2 PINGREQ

jump to the top

Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 Januar 2019, 17:51:52
Ich glaube, wir sollten das heute lassen und warten, bis du wieder fitter bist. Soweit ich das aus dem log ablese, wird MQTT-seitig was gesendet und dann auch POWER aktualisiert, wenn du am Gerät ein- und ausschaltest.
Geh dann nochmal diesen Teil des Threads durch, das müßte lösbar sein.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 05 Januar 2019, 18:04:14
Ja, vertagen wir uns.

Aber zu Sicherheit noch die Klarstellung:
POWER wird immer aktualisiert, habe ich auch immer gesagt. Nur "state" nicht.
"state" wird nicht aktualisert, wenn man per Taster schaltet.
"state" wird immer aktualisert, wenn man per set schaltet.

Natürlich kann ich das Problem umgehen, wenn ich POWER in meinen Routingen abfrage.
Aber wozu ist dann  "state" noch nützlich? devStateIcon ist dann auch nicht richtig nutzbar, denke ich.

Vielen Dank für die Geduld und schönes WE.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 05 Januar 2019, 19:14:53
Aber wozu ist dann  "state" noch nützlich? devStateIcon ist dann auch nicht richtig nutzbar, denke ich.
das ist ja genau das was ich auch immer geschrieben habe, du bekommst kein devStateIcon mehr hin, dass mußt du dann anders lösen.

Ich habe da dann bei einem Basic herum konfiguriert und irgendwo hier im Thread steht auch etwas von mir.
Ich habe gerade gestern erst mit dem 4-Kanal Schalter erhebliche Probleme gehabt weil sich dort die States immer von Kleinschreibung auf Großschreibung ändern. Mein Dank geht da an den User "sinus61" der mir geholfen hat.  :D

Bei Bedarf kann ich dir lists schicken von meinen Geräten damit du siehst wie das mit dem devStateIcon gemacht wurde.
Ich habe Basics, Dual, S20 und den 4-Kanalschalter alle mit Tasmota am laufen. Shelly1 habe ich schon 4 Stück aber noch nicht im Einsatz und ich bekomme die Tage noch Sonoff Touch 2 und 3
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 05 Januar 2019, 19:35:18
Zitat
das ist ja genau das was ich auch immer geschrieben habe, du bekommst kein devStateIcon mehr hin, dass mußt du dann anders lösen.
Siehe https://forum.fhem.de/index.php/topic,95360.msg882041.html#msg882041
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: osr am 06 Januar 2019, 20:39:30
generell noch was.

Bei Tasmota lässt sich der on, off, toggle und hold Text konfigurieren. Standardmäßig ist das alles in Großbuchstaben. Bei set/cmnd Befehlen unterscheidet tasmota nicht zwischen Groß/Kleinschreibung. Es geht also nur um das zurückmelden.

Man könnte hier einfach SetText1 off, SetText2 on, SetText3 toggle und SetText4 hold per cmnd setzen und ein Tasmota Gerät meldet so zurück wie es FHEM intern überall erwartet. Keine eventmap mehr und keine Probleme mit ON/on etc.

Ich verwende das seit circa einem halben Jahr so und es macht die Sache viel einfacher und einheitlicher. Ob man sowas in die Templates einbauen sollte? Nur mal so als Denkanstoß.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 07 Januar 2019, 00:37:59
Man könnte hier einfach SetText1 off, SetText2 on, SetText3 toggle und SetText4 hold per cmnd setzen und ein Tasmota Gerät meldet so zurück wie es FHEM intern überall erwartet. Keine eventmap mehr und keine Probleme mit ON/on etc.

Ich verwende das seit circa einem halben Jahr so und es macht die Sache viel einfacher und einheitlicher. Ob man sowas in die Templates einbauen sollte? Nur mal so als Denkanstoß.
mich interessiert das habe da aktuell gar keine Vorstellung
Könntest du das mal an einem Beispiel hier zeigen, da kann ich das evtl. mal bei mir probieren oder einsetzen.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 07 Januar 2019, 07:01:07
generell noch was.

Bei Tasmota lässt sich der on, off, toggle und hold Text konfigurieren. Standardmäßig ist das alles in Großbuchstaben. Bei set/cmnd Befehlen unterscheidet tasmota nicht zwischen Groß/Kleinschreibung. Es geht also nur um das zurückmelden.

Man könnte hier einfach SetText1 off, SetText2 on, SetText3 toggle und SetText4 hold per cmnd setzen und ein Tasmota Gerät meldet so zurück wie es FHEM intern überall erwartet. Keine eventmap mehr und keine Probleme mit ON/on etc.

Ich verwende das seit circa einem halben Jahr so und es macht die Sache viel einfacher und einheitlicher. Ob man sowas in die Templates einbauen sollte? Nur mal so als Denkanstoß.
Ohne jetzt näher über irgendwelche Nebenwirkungen nachgedacht zu haben, kommt mir das "richtige" Einstellen der Sendeoptionen am einzelnen Client wie "die" Lösung vor.

Vom Ansatz her ist das ja eine Einmal-Aktion, oder? Man müßte also nur die passenden publish-Anweisungen in ein template packen und über das passende IO an den ESP schicken?
Wenn ja: Dann wäre es m.E. das einfachste, 2-3 "Grund-" templates zu machen, die - sendeseitig nach dem Vorbild von A_01x_tasmota_prefix_clearing_and_reboot - entweder (je als einzelnes template)
a) alles auf "FHEM-Standard" setzen (Kleinschreibung und Verwendung von POWER1 für alle Geräte)
b) alles auf "Tasmota-Default" zurücksetzen (Großschreibung)
c) die einkanaligen auf POWER statt POWER1 zurücksetzen.
(ggf. und das Device dann hinterher wirklich rebooten, für den Fall, dass das notwendig ist, um die Änderungen wirksam werden zu lassen).

Im Ergebnis würde ich dann alle vorhandenen templates so umbauen, das immer erst a) durchläuft, eventMap usw. kann dann weg. Damit wären diese Geräte dann vollständig FHEM-konform, oder?

Wer dann Geräte hat, für die er die "alten" Tasmota-Defaults benötigt, schreibt dann nur noch b) (bzw. c), das intern b) aufruft) drüber. Kann dann zwar sein, dass diese Variante nicht zu so schönen Devices führt, die dann ggf. noch nachbearbeitet werden müssen (devStateIcon etc.?), aber dazu kann man entweder weitere Funktionalität bereitstellen oder im Wiki erläutern, was zu tun ist.

Meinungen?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 07 Januar 2019, 15:19:54
Das währe meiner Meinung nach eine sehr gute Lösung. Die mqtt Befehle hab ich auch gerade in Tasmota Wiki gefunden.
StateText1      Show current Off state text
StateText1   <text>   Set Off state text (10 chars max)
StateText2      Show current On state text
StateText2   <text>   Set On state text (10 chars max)
StateText3      Show current Toggle state text
StateText3   <text>   Set Toggle state text (10 chars max)
Dann hätten wir ein Standard der immer funktionieren sollte. Momentan ist das verhalten ja jedes mal anders, je nach Version der Vorlage.
Danke übrigens für die Arbeit mit den Templates. Vereinfacht das normalerweise schon erheblich für mich als halbwissenden  :).

Gruß,
Ingo
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 08 Januar 2019, 11:04:15
Also, dann mal eine Trockenübung zum Testen (wenn das mit dem Backlog nicht funktioniert bzw. ein Reboot erforderlich wird, bitte ggf. die passenden Zeilen aktivieren und die erste auskommentieren bzw. für das 2. template dann entsprechend ändern):

name:A_01z_tasmota_set_lowercase_texts_and_state1
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will change ON, OFF etc. sent from tasmota side to lowercase. <br>When applying the template the tasmota device is rebooted to get all readings
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/Backlog StateText1 off; StateText2 on; StateText3 toggle; SetOption26 1
#set IO_DEV publish cmnd/DEVNAME/StateText1 off#set IO_DEV publish cmnd/DEVNAME/StateText2 on
#set IO_DEV publish cmnd/DEVNAME/StateText3 toggle
#set IO_DEV publish cmnd/DEVNAME/SetOption26 1
#set IO_DEV publish cmnd/DEVNAME/Restart 1

name:A_01z_tasmota_set_uppercase_texts_and_state1
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will change on, off etc. sent from tasmota side to uppercase. NOTE: this  template only exists for compability reasons to older MQTT implementations; not recommended for other user groups
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/Backlog StateText1 OFF; StateText2 ON; StateText3 TOGGLE; SetOption26 1

name:A_01z_tasmota_set_power1_state_to_power
filter:TYPE=MQTT2_DEVICE
desc:Applies to single relay tasmota devices <br>NOTE: this  template only exists for compability reasons to other HA solutions; not recommended for usage in FHEM context
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/SetOption26 0

Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Omega am 08 Januar 2019, 11:43:30
Ich meine irgendwo gelesen zu haben, dass für ein dauerhaftes Umstellen auf Kleinbuchstaben zuerst ein "savedata 1" und abschließend ein "savedata 0" benötigt wird.
Der Vollständigkeit halber setzte ich auch immer gleich "StateText4 hold" ein, um konsistent zu sein.

LG
Holger
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 08 Januar 2019, 11:58:59
Ich meine irgendwo gelesen zu haben, dass für ein dauerhaftes Umstellen auf Kleinbuchstaben zuerst ein "savedata 1" und abschließend ein "savedata 0" benötigt wird.
Der Vollständigkeit halber setzte ich auch immer gleich "StateText4 hold" ein, um konsistent zu sein.
Danke für den Hinweis.
Da ich bekennendermaßen keine Tasmota-Geräte habe, kann ich sowas immer schlecht selbst testen und will - möglichst - auch nicht andere User zum Tester machen.

Könntest du den template-Vorschlag entsprechend erweitern und dann ein getestetes Ergebnis hier posten?

Das kann ich dann gerne wieder versuchen, in die allgemeine Systematik einzubauen.

Und aus dem hier (https://forum.fhem.de/index.php/topic,94494.msg882630.html#msg882630) würde mich noch interessieren, ob sowas (ggf. verbessert) funktioniert:
attr DEVICE eventMap { dev=>{'^IPAddress(.?): (\d+)\.(\d+)\.(\d+)\.(\d+)$'=>'<html><a href=http://$1.$2.$3.$4/>IPAddress</a></html>', } }
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Omega am 08 Januar 2019, 12:46:50
Zitat
Könntest du den template-Vorschlag entsprechend erweitern und dann ein getestetes Ergebnis hier posten?

Ist mir leider momentan nicht möglich. Musste mein System nach dem letzten Update wg. Problemen bei Homematic auf einen älteren Stand zurücksetzen und "kämpfe" da noch mit den Nachwirkungen.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 09 Januar 2019, 14:19:42

Ich meine irgendwo gelesen zu haben, dass für ein dauerhaftes Umstellen auf Kleinbuchstaben zuerst ein "savedata 1" und abschließend ein "savedata 0" benötigt wird.
Der Vollständigkeit halber setzte ich auch immer gleich "StateText4 hold" ein, um konsistent zu sein.

LG
Holger

SaveData ist per default eingeschaltet. Sollte eigentlich kein Problem sein wenn das nicht explizit umgestellt wurde.

SaveData   1 / on   (default) Save parameter changes every second

Ich habe das bei meinem Sonoff Basic Testgerät umgestellt (auf on off POWER1) die setList angepasst und dann die eventmap und stateFormat Attibute gelöscht.
Fuktioniert prima und vereinfacht das doch ganz erheblich.

Grüße,
Ingo
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 09 Januar 2019, 14:43:24
Danke euch für die Rückmeldungen!

Das mit dem Rückgriff auf das Backup bei @omega tut mir leid

Versuch, das soweit zusammenzufassen:
name:A_01z_tasmota_set_lowercase_texts_and_state1
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will change ON, OFF etc. sent from tasmota side to lowercase. <br>After applying the template you might consider to delete or change stateFormat, eventMap and/or userReadings attribute values
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/Backlog StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SetOption26 1; SaveData 1

name:A_01z_tasmota_set_uppercase_texts_and_state1
filter:TYPE=MQTT2_DEVICE
desc:Applies to all tasmota devices <br>NOTE: This template will change on, off etc. sent from tasmota side to uppercase. NOTE: this  template only exists for compability reasons to older MQTT implementations; not recommended for other user groups
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/Backlog StateText1 OFF; StateText2 ON; StateText3 TOGGLE; StateText4 HOLD; SetOption26 1
attr DEVICE userReadings state:POWER1:.* { lc(ReadingsVal("DEVICE","POWER1","")) }

name:A_01z_tasmota_set_power1_state_to_power
filter:TYPE=MQTT2_DEVICE
desc:Applies to single relay tasmota devices <br>NOTE: this  template only exists for compability reasons to other HA solutions; not recommended for usage in FHEM context
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:IO_DEV;Currently used IO;{ AttrVal("DEVICE","IODev","")}
set IO_DEV publish cmnd/DEVNAME/SetOption26 0
attr DEVICE userReadings state:POWER:.* { lc(ReadingsVal("DEVICE","POWER","")) }

name:A_01z_tasmota_test_IPAdress_to_http
filter:TYPE=MQTT2_DEVICE
desc:Applies to single relay tasmota devices <br>NOTE: this  template changes existing eventMap attribute
attr DEVICE eventMap { dev=>{'^IPAddress.?: (\d+)\.(\d+)\.(\d+)\.(\d+)$'=>'<html><a href=http://$1.$2.$3.$4/>IPAddress</a></html>', } }

Anmerkung zu SaveData:
Das scheint ja auch nur eine Einmalaktion zu sein und unschädlich, wenn man es auf default (1) setzt. Ist also jetzt v.a. "sicherheitshalber" drin, falls es jemand ausgeschaltet haben sollte, aber in der Regel eigentlich nicht nötig.

@IngoF:
Darf ich Dich bitten, auch die anderen Templates alle mal zu testen?
Ohne eine abgesicherte Rückmeldung zu den ersten drei würde ich ungern auf der Basis einen grundlegenderen Umbau vornehmen. Man sollte das auf den Devices wenigstens definiert wieder rückgängig machen können, für den Fall, dass es doch irgendwo Auswirkungen hat, die man nicht haben will...

@all:
Wenn niemand rechtzeigit widerspricht, gehe ich davon aus, dass die Änderung auf Kleinschriebung der Tasmota-Messages als neuem Default allseits begrüßt wird!
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 11 Januar 2019, 20:29:38
@all:
Wenn niemand rechtzeigit widerspricht, gehe ich davon aus, dass die Änderung auf Kleinschriebung der Tasmota-Messages als neuem Default allseits begrüßt wird!
Nanu?
Gar keine Rückmeldung? Heißt das: Einchecken?!?
(Wenn ich nichts höre, mach ich das voraussichtlich morgen, laß aber den IPAdress-Teil weg).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 11 Januar 2019, 21:00:45
So jetzt bin ich endlich zu testen gekommen.
Ich habe meinen Sonoff Basic komplett zurückgesetzt. Die drei Templates zum anpassen der MQTT Parameter funktionieren einwandfrei.
Danach habe ich dann das A01 und A01a Template angewendet.
Das attibut eventMap habe ich dann gelöscht. userReadings müssen auf jeden Fall drin bleiben damit der Status direkt vom Gerät ausgewertet wird. Schalten direkt am Sonoff oder wenn das Gerät nicht erreichbar ist wird zuverlässig zurückgemeldet.
Die Anpassung der Tasmota-Messages würde ich auf jeden Fall begrüßen.

Für was das vierte Template nötig ist erschließt sich mir leider nicht.

Gruß, Ingo
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 11 Januar 2019, 21:34:21
Für was das vierte Template nötig ist erschließt sich mir leider nicht.
Das ist ein Wunsch aus dem link unten: Es soll die IP klickbar machen... (ich finde da auch c&p ausreichend, aber wenn es gewünscht wird ;) ). Ich kann's nur nicht testen oder verbessern, da muß was vom Gerät kommen, und mosquitto_pub mit JSON ist nicht so meine Spezialität...
Und aus dem hier (https://forum.fhem.de/index.php/topic,94494.msg882630.html#msg882630) würde mich noch interessieren,
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 11 Januar 2019, 22:00:21
Ich habe jetzt noch den Sonoff Dual getestet. Dabei ist mir aufgefallen das beim Anwenden des A02 Template zwei Geräte erzeugt werden aber beim zweiten Kanal steht in der setList wieder DEVNAME statt dem Gerätenamen drin. Schalten geht dann natürlich nicht.
Beim umbenennen eines Gerätes wird das userReadings Attribut nicht mit angepasst. Muss das manuell gemacht werden oder gibts da eine andere Lösung.

Gruß,
Ingo
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 12 Januar 2019, 06:16:53
So, Änderungen sind eingecheckt. Da es insgesamt etwas größere Umbauten waren, wäre ich für nochmaliges kritisches Durchsehen aller Tasmota-Sachen dankbar (bzw. eigentlich die user, die die templates dann später verwenden...)
Damit wäre lowercase der neue Standard, die ESP's werden entsprechend konfiguriert. Zwar erschließt sich mir nicht, warum man die userReadings neben stateFormat noch braucht, aber ihr könnt das besser beurteilen.

Ich habe jetzt noch den Sonoff Dual getestet. Dabei ist mir aufgefallen das beim Anwenden des A02 Template zwei Geräte erzeugt werden aber beim zweiten Kanal steht in der setList wieder DEVNAME statt dem Gerätenamen drin. Schalten geht dann natürlich nicht.
Beim umbenennen eines Gerätes wird das userReadings Attribut nicht mit angepasst. Muss das manuell gemacht werden oder gibts da eine andere Lösung.
Das Dual sollte jetzt auch im zweiten Kanal gehen, die Attribute sind insgesamt auf den Standard "$name" gestellt (das war noch gemischt). Damit sollte das auch Umbenennungen überleben.

Dann gab es auch an ein paar anderen Stellen (die 4-kanaligen) noch die Schreibweise $NAME. Das ist jetzt da auch geändert, wenn es Probleme machen sollte, bitte melden...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 12 Januar 2019, 10:09:56
Schläfst du auch mal irgendwann ;)
Zwar erschließt sich mir nicht, warum man die userReadings neben stateFormat noch braucht, aber ihr könnt das besser beurteilen.
Wenn ich die die userReadings und stateFormat lösche und dann direkt am Gerät schalte ändert dich zwar das reading "Power1" aber aber "state" nicht. Sehe also nicht den aktuellen Zustand.
Wenn ich nur stateFormat lösche dann sieht erst mal alles normal aus. Wenn das Gerät aber nicht antwortet dann ändert sich das Lampen Symbol trotzdem obwohl das Gerät nicht schaltet. Mit stateFormat ist dann in diesem Fall die Lampe mit Ausrufezeichen zu sehen.
Wenn ich userReadings lösche und stateFormat nicht das steht im "state" "set_on" oder "set_off".

Nachdem ich jetzt die neuen Templates getestet habe ist mir aufgefallen das bei den vorherringen Tests stateFormat=POWER1 nicht gesetzt war. Wenn das nämlich gesetzt ist kann man sich tatsächlich userReadings, und setStateList sparen und alle funktioniert wir erwartet außer das die Lampe mit Ausrufezeichen bei nicht erfolgreichen Schalten nicht angezeigt wird. Macht also durchaus Sinn die drin zu lassen.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 12 Januar 2019, 17:49:22
Nachdem ich jetzt die neuen Templates getestet habe ist mir aufgefallen das bei den vorherringen Tests stateFormat=POWER1 nicht gesetzt war. Wenn das nämlich gesetzt ist kann man sich tatsächlich userReadings, und setStateList sparen und alle funktioniert wir erwartet außer das die Lampe mit Ausrufezeichen bei nicht erfolgreichen Schalten nicht angezeigt wird. Macht also durchaus Sinn die drin zu lassen.
Hmmm, also im Kern spricht vieles eher für Löschen wenn ich das richtig verstehe.
Den von dir bemängelten Übergangszustand sollte man mit einem passenden setStateList abfangen können.

Kannst du mal für die "einkanaligen" folgendes testen (bei ansonsten gelöschten Attributen)?
attr DEVICE setStateList on off(für die mehrkanaligen habe ich grade keine weiterführende Idee, aber vermutlich würde dasselbe als "fake" auch gehen).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 12 Januar 2019, 21:54:18
Hast recht. Mit
attr DEVICE setStateList on offpasst das. Status wird immer korrekt angezeigt. Wenn der Sonoff nicht reagiert bleibt das Icon auf Ausrufezeichen. Passt übrigens auch auf den Sonoff Dual.
So ist mein Sonoff jetzt konfiguriert ist.
defmod SonoffBasic MQTT2_DEVICE DVES_A8497A
attr SonoffBasic DbLogExclude .*
attr SonoffBasic IODev MQTT2_FHEM_Server
attr SonoffBasic autocreate 0
attr SonoffBasic model A_01a_tasmota_basic_state_power1
attr SonoffBasic readingList tele/sonofftest/LWT:.* LWT\
  tele/sonofftest/STATE:.* { json2nameValue($EVENT) }\
  tele/sonofftest/SENSOR:.* { json2nameValue($EVENT) }\
  tele/sonofftest/INFO.:.* { json2nameValue($EVENT) }\
  stat/sonofftest/RESULT:.* { json2nameValue($EVENT) }
attr SonoffBasic room MQTT2_DEVICE
attr SonoffBasic setList off:noArg    cmnd/sonofftest/POWER1 0\
  on:noArg     cmnd/sonofftest/POWER1 1\
  toggle:noArg cmnd/sonofftest/POWER1 2
attr SonoffBasic setStateList on off
attr SonoffBasic stateFormat POWER1
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: tpm88 am 14 Januar 2019, 18:32:06
Hallo Beta-User,

ich denke, bei Tasmota in der RegEx zur Bestimmung des DEVNAME für die Ersetzung fehlt noch etwas. Das funktioniert für einfache Topics (wie z.B. sonoff oder sonoff_s20_01) nicht aber bei mehrstufigen Topics wie z.B. sonoff/s20/01.

Im Template steht folgende Beschreibung:
# The regexp must handle
# - tele/sonoff/LWT: => cmnd/sonoff/
# - DVES_XXXXXX:/SmartHome/Esszimmer/Stehlampe/tele/LWT: => /SmartHome/Esszimmer/Stehlampe/cmnd/

Korrekt müsste die zweite Bedingung bei der Ersetzung für die regexp doch so heißen:

DVES_XXXXXX:tele/SmartHome/Esszimmer/Stehlampe/LWT: => cmnd/SmartHome/Esszimmer/Stehlampe
Ich habe das mal mittels https://regex101.com (https://regex101.com) überprüft:

Die regexp im Template m,tele/([^/]*)/, liefert für DEVNAME beim Teststring DVES_375AB5:tele/sonoff/S20/02/LWT auch nur sonoff und nicht sonoff/S20/02 zurück.

Allerdings habe ich (noch) keine Idee, wie die regexp richtig lauten müsste. Oder habe ich generell etwas falsch verstanden??

Gruß
Tobias
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 14 Januar 2019, 21:35:42
Hallo Tobias,
Danke für Deine Frage; jetzt ich bin mir auch nicht so richtig sicher, ob die Beschreibung und die Regex jeweils so passen...
Die Beschreibung stammt noch aus der ersten Fassung; da war noch ein
par:COMMAND;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\btele(/.*)?/LWT:, ? "${1}cmnd$2" : undef }drin und sowas in der Art:
attr DEVICE setList \
off:noArg    COMMAND/POWER1 0\
on:noArg     COMMAND/POWER1 1\
toggle:noArg COMMAND/POWER1 2\
mqttRetry   COMMAND/MqttRetry
Würde das auf Deine Pfade soweit passen? Dann müßte ich das wieder herstellen; scheinbar haben bisher alle anderen ihre Pfade nicht angepaßt gehabt... :-\
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: tpm88 am 14 Januar 2019, 21:55:40
Nein, ohne noch einmal den ganzen Thread gelesen zu haben, wurde doch die Berücksichtigung von Tasmota prefixes verworfen.

So komplex muß es also gar nicht sein.

Ganz trivial sollte das für die Aufgabenstellung in der Beschreibung eigentlich auch genügen:

m,tele/(.*)/LWT:,
Dann werden sowohl einstufige Topics (z.B. sonoff) als auch mehrstufige (z.B. SmartHome/Esszimmer/Stehlampe) korrekt als DEVNAME zurückgegeben. 

Diese RegEx prüft natürlich nicht die Syntax der Topics, würde aber bei syntaktisch korrekten Ausgangstopics die richtigen Ersetzungen liefern.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 14 Januar 2019, 22:12:51
Hmm,

das mit den Prefixes ist m.E. eine andere Baustelle;

aber dein Vorschlag klingt eigentlich auch ganz einleuchtend, jedenfalls, wenn der Topic-Pfad so statisch ist, wie er zu sein scheint. Muß mal in Ruhe drübersehen :) .
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 15 Januar 2019, 19:22:04
Dann müßte ich das wieder herstellen; scheinbar haben bisher alle anderen ihre Pfade nicht angepaßt gehabt... :-\

Ich habe meine Pfade schon angepasst... halt auf die Standardeinstellung von Tasmota (%prefix%/%topic%/). Das ist der default nach "Konfiguration zurücksetzen".
Hatte das bei der Umstellung auf MQTT2 gemacht damit die Templates funktionieren  ;). Hatte vorher auch meine Geräte mit /smarthome/wohnzimmer/%topic%/%prefix% eingerichtet was ich eigentlich auch logischer fand.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 15 Januar 2019, 19:35:53
Ich habe meine Pfade schon angepasst... halt auf die Standardeinstellung von Tasmota (%prefix%/%topic%/). Das ist der default nach "Konfiguration zurücksetzen".
Hatte das bei der Umstellung auf MQTT2 gemacht damit die Templates funktionieren  ;) . Hatte vorher auch meine Geräte mit /smarthome/wohnzimmer/%topic%/%prefix% eingerichtet was ich eigentlich auch logischer fand.
:o ;D 8)

Na ja, jeder hat da seine eigenen Vorstellungen, kommt halt scheinbar drauf an, auf was man den Schwerpunkt legt.
Auf diese Variante hätte dann wieder die jetzt vorgeschlagene Regex nicht gepaßt, da muß %prefix% demnach vorne bleiben...
Wie dem auch sei, eine Variante, die nicht mit den Defaults kann, wird es jedenfalls nicht, allenfalls eine erweiterte, die sich nicht an "Verlängerungen" stört ::) ::) ::) .
Und wer es unbedingt haben will, muß halt doch händisch nachbessern 8) .

@Rudi:
Kann es eigentlich sein, dass das Eingabefeld nicht funktioniert, das jeweils erscheint, wenn die Regex nicht hinhaut? Ich hatte das neulich mal, den Effekt dann aber bis grade verdrängt....

Und noch was: Wegen des homekit-Themas von nebenan: Es könnte durchaus Sinn machen, sowas wie einen postProcessingHint für ergänzende Konfigurationsoptionen da reinzubauen. Dann hätte man all sowas "an einem Ort", ohne dass die entsprechenden Module jeweils geladen sein müßten.
Der "Hit" wären An- und Abwähl-Optionen...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 15 Januar 2019, 19:45:36
Zitat
Kann es eigentlich sein, dass das Eingabefeld nicht funktioniert, das jeweils erscheint, wenn die Regex nicht hinhaut?
Es kann alles sein, ich brauche aber Beispiele.
Es gibt kein Dialog, wenn alle Parameter gesetzt sind. Ob Inhalt des Parameters im Sinne des Erfinders ist,wird aber nicht geprueft.


Zitat
Wegen des homekit-Themas von nebenan
Wenn ich damit gemeint bin: da brauche ich deutlich mehr Kontext.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 16 Januar 2019, 08:21:25
Es kann alles sein, ich brauche aber Beispiele.
Es gibt kein Dialog, wenn alle Parameter gesetzt sind. Ob Inhalt des Parameters im Sinne des Erfinders ist,wird aber nicht geprueft.
Korrekt, aber wenn irgendwas schief läuft, also ein Parameter - aus welchen Gründen auch immer - nicht automatisch bestimmt werden kann, kommt ein Dialogfeld. In das kann man zwar was eintragen, aber ganz egal, was man da eingibt, es hat keine Auswirkungen.

Beispiel: Man manipuliere die readingList eines tasmota, z.B. so (tulu statt tele):

defmod tasmota_test3 MQTT2_DEVICE DVES_9B01BD
attr tasmota_test3 IODev MQTT2_FHEM_Server
attr tasmota_test3 readingList DVES_9B01BD:tulu/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tulu/sonoffkitchen/INFO:.* { json2nameValue($EVENT) }
attr tasmota_test3 room MQTT2_DEVICE
und versuche dann, darauf eines der Tasmota-templates anzuwenden.
Ergebnis: Es passiert nichts, selbst wenn man da "das richtige" (sonoffkitchen) oder irgendwas anderes einträgt.

Erwartung wäre: der eingegebene Text ersetzt den Parameter.

Zitat
Wenn ich damit gemeint bin: da brauche ich deutlich mehr Kontext.
Ok, es geht um die Thematik, die hier (https://forum.fhem.de/index.php/topic,94060.msg888776.html#msg888776) und in den paar Beiträgen davor angerissen wird:
Nutzt jemand z.B. homekit, macht es Sinn, gleich die passende Parametrierung vorzunehmen (siriName, genericDeviceType, und eigentlich muß das Gerät dann noch in den Raum Homekit). Entsprechendes gilt für AutoShuttersControl, vermutlich auch andere Sprachsteuerungen etc...
Mal sind es mehrere Attribute, die gesetzt werden müssen (mit sinnvollem individuellem Inhalt, z.B. für siriName), mal ist es nur ein klar definiertes Attribut (ASC). Allen ist gemeinsam: sie können nur gesetzt werden, wenn das betr. Modul überhaupt geladen ist (könnte man ggf, auch prüfen, aber irgendwann ist auch gut...)

Vielleicht wird es klarer mit folgendem Fantasie-template:
# shelly2 using original firmware in roller mode.
name:A_11b_shelly2_roller
filter:TYPE=MQTT2_DEVICE
desc:shelly2 using original firmware. <br>NOTE: shelly2 roller operated, change settings first!
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment shelly2 roller operated
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command open\
  close:noArg shellies/DEVNAME/roller/0/command close\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pct:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1\
  DoRecalibration:noArg shellies/DEVNAME/roller/0/command rc
attr DEVICE readingList shellies/DEVNAME/roller/0/pos:.* pct\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/roller/0:.* state\
  shellies/DEVNAME/input/1:.* input1\
  shellies/DEVNAME/input/0:.* input0
attr DEVICE devStateIcon 0:fts_shutter_100 100:fts_shutter_10 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100 set_.*:fts_shutter_updown
attr DEVICE stateFormat pct
deleteReading DEVICE .*
attr DEVICE setStateList open close stop

option01:SIRINAME;When using homekit enter desired siriname and click OK, otherwise CANCEL;
attr DEVICE siriName SIRINAME
attr DEVICE genericDeviceType blind
par:ROOM_ATTRIBUTE;Extend room attribute with Homekit;{ my $rooms = AttrVal("DEVICE","room","none"); $rooms =~ m,none, ? "Homekit" : $rooms =~ m,Homekit, ? $rooms : $rooms.",Homekit" }
attr DEVICE room ROOM_ATTRIBUTE
option01end

option02:;Set AutoShuttersControl attribute?
attr DEVICE ASC 2
option02end

finalhint:Thank you for using mqtt2Template. Now have fun using your device and don't forget to save changes.

attr DEVICE model A_11b_shelly2_roller
Das könnte man entweder Option für Option durchgehen, oder einmal ein Dialogfeld anzeigen, das für jede Optionsgruppe ein "Kreuzchenfeld" vorneweg hat, das das jeweils aktiviert. (Ich habe aber keine Ahnung, wie man das mit erforderlichem Userinput machen würde; hier ggf. nachgelagerte Abfragen...?).

Aber das ist der totale Luxus, über den wir hier sprechen...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 16 Januar 2019, 20:10:01
Mir ist da noch was aufgefallen. Durch
attr DEVICE setStateList on offseht ja im  Reading state "set_on" oder halt "set_off". Das kommt dann auch so bei der Homebridge an wie man im Log sieht. Die kann damit nichts anfangen und man sieht auf dem IPhone leider nicht den aktuellen Status des Geräts. Auch direktes schalten bekommt man so leider nicht mit. Ist es den möglich das Reading state mit dem vom Gerät gemeldeten Status zu befüllen (POWER1)? StateFormat hilft hier ja nicht weiter :-\.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 16 Januar 2019, 21:01:55
Hmmm, eigentlich sollte das nur so lange so sein, bis auch Vollzug vom Gerät zurückgemeldet wird....
Ist also eigentlich nicht schlecht, wenn das sichtbar ist. Wenn du das Ausschalten wolltest, schreibe mal testweise Unsinn rein (reboot oder so).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 16 Januar 2019, 21:59:32
wenn ich bei setStateList irgendwas reinschreibe bekomme ich zwei neue Readings wenn ich mit FHEM schalte.
setstate SonoffBasic 2019-01-16 21:51:26 off set
setstate SonoffBasic 2019-01-16 21:51:27 on set
setstate SonoffBasic 2019-01-16 21:50:53 state set_on
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 17 Januar 2019, 07:32:42
Hmmm,

bei intensiverem Nachdenken scheint es so zu sein, dass sich Homekit da direkt state greift und nicht irgendwas, was danach passiert. Als Spielmaterial kommt m.E. noch ein userReadings in Frage:
attr DEVICE userReadings state:POWER1:.* { lc(ReadingsVal($name,"POWER1","")) }
(lc ist vermutlich nicht mehr erforderlich; insgesamt gefällt mir das gar nicht im template, userReadings sollte man m.E. wirklich vollständig in User-Hand lassen)
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: tpm88 am 18 Januar 2019, 08:18:52
Die Beschreibung stammt noch aus der ersten Fassung; da war noch ein
par:COMMAND;Command topic prefix, without trailing /;{ AttrVal("DEVICE","readingList","") =~ m,([^:]*)\btele(/.*)?/LWT:, ? "${1}cmnd$2" : undef }drin und sowas in der Art:
...

Hallo Beta-User,

nachdem ich https://github.com/arendst/Sonoff-Tasmota/wiki/MQTT-Features (https://github.com/arendst/Sonoff-Tasmota/wiki/MQTT-Features) noch einmal gründlich durchgesehen habe, ziehe ich meinen Vorschlag aus #168 zurück. Mehrstufige Topics werden also nicht via %topic% sondern mit Hilfe von FullTopic gebildet. Da man dort komplett frei ist bei der Bildung der Topics, sehe ich überhaupt keine sinnvolle Möglichkeit, das im Attribut Template vernünftig abzubilden. Das sind ja auch nur _Beispiele_ für mehrstufige Topics:

Zitat: Using the tokens the following example topics can be made:

    FullTopic %prefix%/%topic%/ being the legacy situation up to version 5.0.5
    FullTopic tasmota/%topic%/%prefix%/
    FullTopic tasmota/bedroom/%topic%/%prefix%/
    FullTopic penthouse/bedroom1/bathroom2/%topic%/%prefix%/

Insbesondere kann %prefix% am Ende stehen, muß aber nicht...

Insofern denke ich, sollte das Template nur den Auslieferungszustand von Tasmota mit einem einfachen einstufigen Topic %topic% abbilden.

Gruß
Tobias
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 18 Januar 2019, 09:28:09
Zitat
Insbesondere kann %prefix% am Ende stehen, muß aber nicht...
In diese Falle bin ich auch am Anfang geraten, und ich habe mal ein Regexp gebaut, was beide Faelle abgedeckt hat (irgendwo hier im Forum dokumentiert). Allerdings bin ich nicht sicher, dass es _alle_ Faelle abdeckt, und bin dafuer, keine Zeit und Energie fuer Sonderloesungen zu vergeuden, und nur die Tasmota Voreinstellung zu unterstuetzen. Hoffentlich kommen die nicht auf die Idee, daran was zu drehen.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 18 Januar 2019, 09:34:01
@tpm88
Danke für's recherchieren. Dann lasse ich das erst mal so, wie es jetzt ist. (@Rudi: die generellere ist vermutlich in den ersten Fassungen im svn zu finden, das könnte man durchaus wieder vorholen, denn ich mir nicht sicher, ob es nicht Sinn machen würde, das etwas weiter zu fassen, als es derzeit ist. Andererseits: Wer intensiver in der MQTT-Welt unterwegs ist und daher die Vorgaben ändert, wird auch kaum größere Probleme haben, die templates als Vorlagen zu nutzen.)

@Rudi
Dafür sollten sie aber durchlaufen, selbst wenn die Regex zu keinem match führt. War jedenfalls aber bei dem Testszenario hier nicht der Fall:
Korrekt, aber wenn irgendwas schief läuft, also ein Parameter - aus welchen Gründen auch immer - nicht automatisch bestimmt werden kann, kommt ein Dialogfeld. In das kann man zwar was eintragen, aber ganz egal, was man da eingibt, es hat keine Auswirkungen.

Beispiel: Man manipuliere die readingList eines tasmota, z.B. so (tulu statt tele):

defmod tasmota_test3 MQTT2_DEVICE DVES_9B01BD
attr tasmota_test3 IODev MQTT2_FHEM_Server
attr tasmota_test3 readingList DVES_9B01BD:tulu/sonoffkitchen/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tulu/sonoffkitchen/INFO:.* { json2nameValue($EVENT) }
attr tasmota_test3 room MQTT2_DEVICE
und versuche dann, darauf eines der Tasmota-templates anzuwenden.
Ergebnis: Es passiert nichts, selbst wenn man da "das richtige" (sonoffkitchen) oder irgendwas anderes einträgt.
Das sollte man m.E. fixen, oder habe ich was in der Handhabung nicht richtig verstanden?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: rudolfkoenig am 18 Januar 2019, 11:00:55
Zitat
Das sollte man m.E. fixen, oder habe ich was in der Handhabung nicht richtig verstanden?
Ich sehe kein Problem: wenn ich das ausprobiere, bekomme ich nach Anwenden des attrTemplates ein haufen "BLA", siehe Anhaenge, mit Vorher, Dialog, Nachher.
Falls das bei Dir anders ausschaut, dann bitte ich um Screenshots, oder genauere Beschreibung der Vorgaenge.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 18 Januar 2019, 12:28:12
Ahhhh, tatsächlich ein Anwenderproblem :( .

Dass man _nur_ die Variable ersetzten soll, hat sich mir nicht direkt erschlossen; ich hatte immer den ganzen Text mit dem Variableninhalt ersetzt und mich gewundert, wieso man das alles vorneweg angezeigt bekommt.

Thx, vielleicht sollte ich den Hinweis, wie es gemeint ist, im Wiki ergänzen, das machen dann bestimmt bei Gelegenheit auch andere nicht as designed... (das mit der cref ist auch nicht vergessen und kommt irgendwann noch).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 18 Januar 2019, 18:16:26
Hmmm,

bei intensiverem Nachdenken scheint es so zu sein, dass sich Homekit da direkt state greift und nicht irgendwas, was danach passiert. Als Spielmaterial kommt m.E. noch ein userReadings in Frage:
attr DEVICE userReadings state:POWER1:.* { lc(ReadingsVal($name,"POWER1","")) }
(lc ist vermutlich nicht mehr erforderlich; insgesamt gefällt mir das gar nicht im template, userReadings sollte man m.E. wirklich vollständig in User-Hand lassen)
Damit funktionierts. Das kommt dann auch so an der Homebrige an. So sieht das dann im Log aus:

  2019-01-18 17:50:19 caching: SonoffBasic-state: on
[1/18/2019, 5:50:19 PM] [FHEM]     caching: On: true (as boolean; from 'on')
  2019-01-18 17:50:20 caching: SonoffBasic-state: off
[1/18/2019, 5:50:20 PM] [FHEM]     caching: On: false (as boolean; from 'off')

Ohne userReadings und mit "setStateList on off"sieht das so aus:
 2019-01-18 17:55:24 caching: SonoffBasic-state: set_on
 2019-01-18 17:55:25 caching: SonoffBasic-state: set_off

Sollte sich aber nicht eigentlich das reading "state" von "set_on" nach "on" wechseln wenn der Sonoff Vollzug gemeldet hat? Oder hab ich das fasch verstanden? Über das Attribut
attr SonoffBasic stateFormat POWER1wird das ja zurückgemeldet und auch im FHEM angezeigt.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 19 Januar 2019, 14:36:07
Schön, dass das jetzt geklappt hat.

Dass state nicht verändert wird, ist keine Überraschung, das geht im Prinzip nur, wenn das Modul das direkt macht.
Das bringt mich aber zu folgender Überlegung: Hier könnte man evtl. auch bei der JSON-Extraktion irgendwie mit jsonMap eingreifen, und dann POWER1 in state (oder noch besser state:POWER1) umleiten. Müßtest du ggf. mal ausprobieren, ich fände das eleganter als das userReadings-Dingens, das sollte m.E. wirklich in Userhand verbleiben...

Wenn das nämlich klappt, wäre es eine generische Lösung, die ggf. mit kleinen Anpassungen für alle Tasmotas paßt, auch die mehrkanaligen. (Denke ich zumindest).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: IngoF am 23 Januar 2019, 20:31:22
Ich hab das jetzt folgendermaßen gelöst. Ich habe einfach in die readingList
Zitat
stat/sonofftest/POWER1:.* state
eingefügt und stateFomat gelöscht. setStateList muss drin bleiben um die Rückmeldung zu bekommen, ob der Sonoff schaltet.
Damit funktioniert auch die Aktualisierung über die Homebridge, egal wo geschaltet wird.

Gruß, Ingo
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 05 März 2019, 18:42:29
Ich habe jetzt nochmal eine Frage zu einem Sonoff Touch mit 3 Kanälen, welches Template kann ich dafür nutzen
Das Modul heißt unter Tasmota Einstellungen "Sonoff T1 3CH Modul" (30)

Den 2-Kanal Touch hatte ich mit dem template "A_02_tasmota_2channel_split" angelegt

Da es für den 3-Kanal kein template gibt habe ich die 3 Kanäle mal von Hand angelegt, aber irgendwie bekomme ich den nicht zum schalten mit Fhem.
Finde den Fehler nicht..!!
Wenn ich den Schalter von Hand schalte sehe ich auch wie die Readings sich ändern nur aus Fhem heraus geht es nicht.

Die Kanäle heißen:
BU_3Kanal_Sonoff_Touch
BU_3Kanal_Sonoff_Touch_CH2
BU_3Kanal_Sonoff_Touch_CH3

hier mal ein list von einem 1.Kanal:
Internals:
   CFGFN      ./FHEM/Obergeschoss.cfg
   CID        DVES_DC78C3
   DEF        DVES_DC78C3
   DEVICETOPIC BU_3Kanal_Sonoff_Touch
   FUUID      5c7e9978-f33f-a6c6-b55e-571eb6f28757159c
   IODevMissing 1
   IODevName  m2server
   LASTInputDev m2server
   MSGCNT     83
   NAME       BU_3Kanal_Sonoff_Touch
   NR         2777
   STATE      off
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 83
   m2server_TIME 2019-03-05 18:34:53
   OLDREADINGS:
   READINGS:
     2019-03-05 18:19:44   FallbackTopic   cmnd/DVES_DC78C3_fb/
     2019-03-05 18:19:44   GroupTopic      sonoffs
     2019-03-05 18:19:45   Hostname        3Kanal_Sonoff_Touch-6339
     2019-03-05 18:19:45   IPAddress       10.0.0.157
     2019-03-05 18:19:44   LWT             Online
     2019-03-05 18:34:53   LoadAvg         19
     2019-03-05 18:19:44   Module          Sonoff T1 3CH
     2019-03-05 18:34:53   POWER1          off
     2019-03-05 18:34:53   POWER2          off
     2019-03-05 18:34:53   POWER3          off
     2019-03-05 18:19:45   RestartReason   Software/System restart
     2019-03-05 18:18:33   SaveData        on
     2019-03-05 18:18:33   SetOption26     on
     2019-03-05 18:34:53   Sleep           50
     2019-03-05 18:34:53   SleepMode       Dynamic
     2019-03-05 18:18:32   StateText1      off
     2019-03-05 18:18:32   StateText2      on
     2019-03-05 18:18:33   StateText3      toggle
     2019-03-05 18:18:33   StateText4      hold
     2019-03-05 18:34:53   Time            2019-03-05T18:34:48
     2019-03-05 18:34:53   Uptime          0T00:15:14
     2019-03-05 18:34:53   Vcc             3.499
     2019-03-05 18:19:44   Version         6.4.1(sonoff)
     2019-03-05 18:19:45   WebServerMode   Admin
     2019-03-05 18:34:53   Wifi_AP         2
     2019-03-05 18:34:53   Wifi_BSSId      9C:C7:A6:08:43:67
     2019-03-05 18:34:53   Wifi_Channel    8
     2019-03-05 18:34:53   Wifi_RSSI       100
     2019-03-05 18:34:53   Wifi_SSId       xxxxxxxxxxxxxxxxxxxxxxxxxxx
     2019-03-05 18:25:24   state           off
Attributes:
   IODev      m2server
   alias      Touch - 1 -
   autocreate 0
   comment    Channel 1 for BU_3Kanal_Sonoff_Touch
   devStateIcon Ein:led_stripe_on@crimson:Aus Aus:light_led_stripe@lightgreen:Ein
   group      Licht Büro
   icon       taster@#F0E68C
   readingList tele/3Kanal_Sonoff_Touch/LWT:.* LWT
  tele/3Kanal_Sonoff_Touch/STATE:.* { json2nameValue($EVENT) }
  tele/3Kanal_Sonoff_Touch/SENSOR:.* { json2nameValue($EVENT) }
  tele/3Kanal_Sonoff_Touch/INFO.:.* { json2nameValue($EVENT) }
  tele/3Kanal_Sonoff_Touch/INFO1.:.* { json2nameValue($EVENT) }
  tele/3Kanal_Sonoff_Touch/INFO2.:.* { json2nameValue($EVENT) }
  tele/3Kanal_Sonoff_Touch/INFO3.:.* { json2nameValue($EVENT) }
  stat/3Kanal_Sonoff_Touch/RESULT:.* { json2nameValue($EVENT) }
   room       MQTT,OG - Flur
   setList    off:noArg    cmnd/3Kanal_Sonoff_Touch/POWER1 0
  on:noArg     cmnd/3Kanal_Sonoff_Touch/POWER1 1
  toggle:noArg cmnd/3Kanal_Sonoff_Touch/POWER1 2
   sortby     02
   stateFormat {lc ReadingsVal("$name","POWER1","")}
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 05 März 2019, 19:25:11
Werden die POWERn-Kanäle nicht hochgezählt? Müßte hier dann "3" sein.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 05 März 2019, 23:00:28
ja das ist schon klar, ich habe hier auch nur einen Kanal angehangen...
Die setlist der 3 Kanäle sieht so aus:
Kanal 1
attr BU_3Kanal_Sonoff_Touch
off:noArg    cmnd/3Kanal_Sonoff_Touch/POWER1 0
  on:noArg     cmnd/3Kanal_Sonoff_Touch/POWER1 1
  toggle:noArg cmnd/3Kanal_Sonoff_Touch/POWER1 2
Kanal 2
attr BU_3Kanal_Sonoff_Touch_CH2
off:noArg    cmnd/3Kanal_Sonoff_Touch/POWER2 0\
  on:noArg     cmnd/3Kanal_Sonoff_Touch/POWER2 1\
  toggle:noArg cmnd/3Kanal_Sonoff_Touch/POWER2 2
Kanal 3
attr BU_3Kanal_Sonoff_Touch_CH3
off:noArg    cmnd/3Kanal_Sonoff_Touch/POWER3 0
  on:noArg     cmnd/3Kanal_Sonoff_Touch/POWER3 1
  toggle:noArg cmnd/3Kanal_Sonoff_Touch/POWER3 2

stateFormat, jeweils
{lc ReadingsVal("$name","POWER1","")}
{lc ReadingsVal("$name","POWER2","")}
{lc ReadingsVal("$name","POWER3","")}

anders habe ich das bei meinen Tasmota ob nun der Dual oder auch der 4-Kanalschalter, nie gemacht.
Selbst den 2Kanal Touch habe ich im Einsatz und den konnte ich über template ja erstellen, aber irgendwie mag der 3 Kanal mich wohl nicht...

Weiß da grad nicht weiter was ich noch machen soll  :-\
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 06 März 2019, 01:09:12
Zitat
attr BU_3Kanal_Sonoff_Touch_CH2 
off:noArg    cmnd/3Kanal_Sonoff_Touch/POWER2 0\
  on:noArg     cmnd/3Kanal_Sonoff_Touch/POWER2 1\
  toggle:noArg cmnd/3Kanal_Sonoff_Touch/POWER2 2

Sind die Beispiele aus der Raw-Definition oder aus einem List kopiert ?

Aus einem List würd ich sagen Kanal 1 und 3 sollten schalten.
Aus der Raw-Defintion dürfte nur Kanal 2 schalten.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 06 März 2019, 10:26:44
Sind alle aus dem RAW... ist wohl von meinen unzähligen Versuchen ein Überbleibsel  :-\
Aber schalten tut keiner der drei...!
Werde nachher nochmal mit frischer Kraft ran gehen und schauen ob ich etwas übersehen habe
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 06 März 2019, 12:26:16
ich habe jetzt nochmal alle 3 setlist über das Attribut setlist neu erstellt und nun funktioniert es auch.
Ich habe mal geschaut die "\" sind jetzt in allen 3 setlist drin, aber auch vorher war es ja bei der 2. setlist drin und funktionierte auch nicht.
Keine Ahnung warum es nun geht....! war wohl zu spät gestern  :D ;)

@Beta-User evtl. sollte noch ein template für 3 kanalige Geräte erstellt werden, ich habe sie jetzt alle händisch angelegt, da kein template existiert. Ich weiß nicht ob es noch mehr 3 kanalige Geräte gibt..!!
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 06 März 2019, 12:42:32
Hmm, es wäre vermutlich zielführender, ein 4-chanel-split tamplate aufzunehmen.

Da wird dann zwar ein Kanal zu viel erstellt, aber den kann man dann einfach löschen. Die templates können m.E. sowieso nicht jeden Sonderfall abdecken (vielleicht fällt mir was ein, um da erst mal bestimmte Teile zu verstecken, die man nur in bestimmten Fällen benötigt...).

Magst du das zuliefern?

Übrigens: das lc-stateFormat dürfte nicht mehr erforderlich sein, wenn der tasmota umgestellt wurde auf "sende in Kleinschriebung" (was das template intern macht).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 06 März 2019, 15:38:37
Leider war meine Freude nur kurz, jetzt funktioniert es über die Fhem Tasten nicht mehr, keine Ahnung warum. :-\ :-\
Nach einem Neustart von Fhem geht es wieder

Wenn ich den Touch selber betätige schaltet es und wenn ich den über die Tasmota Weboberfläche (IP) schalte funktioniert es auch, dass devStateIcon ändert sich auch und das Reading POWER1, POWER2 und POWER3 ändert sich auch.
Werde mal weiter schauen warum es nun nicht mehr funktioniert...!  :-\

Das mit der Kleinschreibung habe ich gesehen die Readings sind immer "on" oder "off"

Ja natürlich könnte man ein 4-Kanal Split auch nehmen, dass wäre mir persönlich egal, da es glaube ich weiter keine 3-kanaligen Geräte gibt
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 06 März 2019, 19:12:52
Ich will gerade ein Template A_01_tasmota_basic nutzen, um eine Steckdose s20 zu installieren.
Das wurde mir hier mal so gesagt.
Das Template lässt sich aber nicht zuweisen. Es ist in der Liste enthalten (da steht immer noch, dass man für s20 das Template _01a_tasmota_basic_state_power1 genutzt werden soll), lässt sich aber nicht zuweisen, sondern Statt dessen erscheint dann kommentarlos bei Model das Template A_01a_tasmota_basic_state_power1.
Was kann ich da tun? Bin ich hier nicht auf dem neuesten Wissensstand?

Bin dankbar für einen Rat.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 06 März 2019, 22:59:20
hier mal ein list von meiner S20, evtl. hilft es dir...

Internals:
   CFGFN      ./FHEM/Sonoff.cfg
   CID        DVES_80F6D5
   DEF        DVES_80F6D5
   DEVICETOPIC OG_S20
   FUUID      5c4319e1-f33f-a6c6-a477-bf1d276834978125
   IODev      m2server
   LASTInputDev m2server
   MSGCNT     107
   NAME       OG_S20
   NR         4855
   STATE      off
   TYPE       MQTT2_DEVICE
   m2server_MSGCNT 107
   m2server_TIME 2019-03-06 22:54:34
   READINGS:
     2019-01-07 15:43:04   FallbackTopic   DVES_80F6D5
     2019-01-07 15:43:04   GroupTopic      sonoffs
     2019-01-07 15:43:04   Hostname        OG_S20-5845
     2019-01-07 15:43:04   IPAddress       10.0.0.153
     2019-03-06 22:49:28   LWT             Online
     2019-03-06 22:52:58   LoadAvg         19
     2019-01-07 15:43:04   Module          Sonoff S2X
     2018-12-19 15:45:03   OtaUrl          http://thehackbox.org/tasmota/release/sonoff-DE.bin
     2019-03-06 22:54:34   POWER           OFF
     2019-01-07 15:43:04   RestartReason   Power on
     2019-03-06 22:52:58   Sleep           50
     2019-03-06 22:52:58   SleepMode       Dynamic
     2019-03-06 22:52:58   Time            2019-03-06T22:52:51
     2018-12-19 15:45:03   Upgrade         Version 6.3.0 from http://thehackbox.org/tasmota/release/sonoff-DE.bin
     2019-03-06 22:52:58   Uptime          58T07:10:16
     2019-03-06 22:52:58   Vcc             3.457
     2019-01-07 15:43:04   Version         6.4.0(sonoff)
     2019-01-07 15:43:04   WebServerMode   Admin
     2019-03-06 22:52:58   Wifi_AP         1
     2019-03-06 22:52:58   Wifi_BSSId      9C:C7:A6:11:3E:A5
     2019-03-06 22:52:58   Wifi_Channel    11
     2019-03-06 22:52:58   Wifi_RSSI       28
     2019-03-06 22:52:58   Wifi_SSId       xxxxxxxxxxxx
     2019-03-06 22:54:34   state           off
Attributes:
   IODev      m2server
   autocreate 0
   devStateIcon on:message_socket_on2@crimson:off off:message_socket_off2@lightgreen:on
   eventMap   { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
   icon       message_socket@blue
   readingList tele/OG_S20/LWT:.* LWT
cmnd/OG_S20/POWER:.* POWER
stat/OG_S20/POWER:.* POWER
tele/OG_S20/SENSOR:.* { json2nameValue($EVENT) }
tele/OG_S20/INFO.:.* { json2nameValue($EVENT) }
tele/OG_S20/INFO1:.* { json2nameValue($EVENT) }
tele/OG_S20/INFO2:.* { json2nameValue($EVENT) }
stat/OG_S20/RESULT:.* { json2nameValue($EVENT) }
tele/OG_S20/STATE:.* { json2nameValue($EVENT) }
tele/OG_S20/UPTIME:.* { json2nameValue($EVENT) }
   room       MQTT,OG - Flur
   setList    off:noArg    cmnd/OG_S20/POWER 0
on:noArg     cmnd/OG_S20/POWER 1
toggle:noArg cmnd/OG_S20/POWER 2
  mqttRetry   cmnd/OG_S20/MqttRetry
   stateFormat {lc ReadingsVal("$name","POWER","") }

oder hier die RAW Definition
defmod OG_S20 MQTT2_DEVICE DVES_80F6D5
attr OG_S20 IODev m2server
attr OG_S20 autocreate 0
attr OG_S20 devStateIcon on:message_socket_on2@crimson:off off:message_socket_off2@lightgreen:on
attr OG_S20 eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }
attr OG_S20 icon message_socket@blue
attr OG_S20 readingList tele/OG_S20/LWT:.* LWT\
cmnd/OG_S20/POWER:.* POWER\
stat/OG_S20/POWER:.* POWER\
tele/OG_S20/SENSOR:.* { json2nameValue($EVENT) }\
tele/OG_S20/INFO.:.* { json2nameValue($EVENT) }\
tele/OG_S20/INFO.:.* { json2nameValue($EVENT) }\
tele/OG_S20/INFO1:.* { json2nameValue($EVENT) }\
tele/OG_S20/INFO2:.* { json2nameValue($EVENT) }\
stat/OG_S20/RESULT:.* { json2nameValue($EVENT) }\
tele/OG_S20/STATE:.* { json2nameValue($EVENT) }\
tele/OG_S20/UPTIME:.* { json2nameValue($EVENT) }
attr OG_S20 room MQTT,OG - Flur
attr OG_S20 setList off:noArg    cmnd/OG_S20/POWER 0\
on:noArg     cmnd/OG_S20/POWER 1\
toggle:noArg cmnd/OG_S20/POWER 2\
  mqttRetry   cmnd/OG_S20/MqttRetry
attr OG_S20 stateFormat {lc ReadingsVal("$name","POWER","") }
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 07 März 2019, 06:17:19
Ich will gerade ein Template A_01_tasmota_basic nutzen, um eine Steckdose s20 zu installieren.
Das wurde mir hier mal so gesagt.
Das Template lässt sich aber nicht zuweisen. Es ist in der Liste enthalten (da steht immer noch, dass man für s20 das Template _01a_tasmota_basic_state_power1 genutzt werden soll), lässt sich aber nicht zuweisen, sondern Statt dessen erscheint dann kommentarlos bei Model das Template A_01a_tasmota_basic_state_power1.
Was kann ich da tun? Bin ich hier nicht auf dem neuesten Wissensstand?

Bin dankbar für einen Rat.
Danke für den Hinweis zur Benennung, da muß ich ggf. noch mal nacharbeiten oder mind. einen Hinweis auf das folgende aufnehmen:

Das mit dem model ist ok, intern ruft das eine template das andere auf und stellt u.a. auch das Sendeformat auf lowercase um. Also sollte der Tasmota auch funktionieren wie erwartet.

@moonsorrox: Das list hilft daher nicht weiter; da sind einige Angaben drin, die nicht mehr erforderlich sind, wenn man den Sonoff selbst umkonfiguriert (was das template macht).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Invers am 07 März 2019, 10:14:55
Vielen Dank an euch für die Hilfe. Dann ist erst einmal alles klar. Da müsste dann der Hinweistext, wenn man das Fragezeichen wählt, angepasst werden.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 07 März 2019, 10:50:21
Vielen Dank an euch für die Hilfe. Dann ist erst einmal alles klar. Da müsste dann der Hinweistext, wenn man das Fragezeichen wählt, angepasst werden.
Darfst gerne einen Vorschlag machen...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: moonsorrox am 07 März 2019, 12:02:35
@moonsorrox: Das list hilft daher nicht weiter; da sind einige Angaben drin, die nicht mehr erforderlich sind, wenn man den Sonoff selbst umkonfiguriert (was das template macht).

Ja, bis auf das devStateIcon und das stateFormat welches ich brauche um mein Icon auch so anzuzeigen ist der Rest aus dem seinerzeit aktuellen Template erstellt worden
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 07 März 2019, 12:16:18
@moonsorrox:
Ok, da war aus dem list nicht ersichtlich, dass du da mal eine frühere Fassung des templates drübergehen hast lassen.

Die aktuelle Fassung sollte einiges erleichtern gg. dem Stand von vor einigen (wenigen) Monaten :) .
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: 87insane am 23 März 2019, 21:25:36
Hallo zusammen,

durch die Template Entwicklung mit Beta-User ist mir eine kleine aber feine Sache aufgefallen. Macht es nicht sinn, das Webinterface (wenn vorhanden und gewollt) mit in den Online Status zu legen?
In dem Template A_02b wäre das z.B. so. Hinzu ist dort die Variable IPAddress hinterlegt, welche das manuelle anpassen der IP des jeweiligen Gerätes unnötig macht, da sie hinterlegt ist.

Beispiel Schalter:
<a href="http://IPAddress" target="_blank">
LWT
</a>
1:POWER1
2:POWER2

Beispiel Rollo:
<a href="http://IPAddress" target="_blank">
LWT
</a>
state

Screenshot unten...(macht euch nicht ins Hemd, wegen meiner Paint-Künste :-P)


EDIT: Gemeint ist natürlich stateFormat
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TomLee am 23 März 2019, 21:55:38
Find ich naheliegend und eine gute Idee, ist ja seit kurzem (https://wiki.fhem.de/wiki/DevStateIcon) kein Thema mehr. Fehlt doch nur noch ein entsprechendes Icon  ;D

Gruß

Thomas
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: 87insane am 23 März 2019, 22:14:31
Du meinst was, was quasi besser online/offline und Webinterface darstellt? Puh - also da bin ich un-kreativ. Für Deko, frage ich mal bei meinem Management.

Antwort war: Sowas wie den kleinen kreis für online/offline vor dem alten Teletextbild und eine darauf klickende Windows/Linux Maus-Hand.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 24 März 2019, 07:43:05
Hmm,

die Wahl des Icon hat der Anwender in der Hand, die LWT-messages sollten sich ja konfigurieren lassen, so ist es halt so, dass der kleine grüne Punkt das "online"-Icon ist; aber wer sich da den Text für einen roten Mülleimer oder eine grüne Pumpe schicken läßt, wird eben das sehen...

Wenn mehr Leute die Umstellung auf den klickbaren LWT-icon gut fänden, können wir das gerne machen. Ich gebe allerdings zu bedenken, dass die template ja teilweise auch dazu da sind, unterschiedliche Varianten zu präsentieren, wie man dasselbe Problem lösen kann, so dass Einheitlichkeit nicht unbedingt das Ziel war...

Folgender Vorschlag:
- @87insane: Würdest du mir einen patch liefern, der die Änderungen alle (oder die meisten) enthält?
Bitte dabei aber
-- vorher prüfen, dass das template (in der jetzigen Fassung) im wesentlichen optisch nur den "Punkt" zusätzlich erhält, und dafür nur die Elemente entfallen, die in Text einen Link oder eine IP-Adresse enthalten;
-- eine Liste machen mit den Anweisungen in den templates, die ggf. ansprechende optische oder funktionale Alternativen enthalten (dann kann ich mir anschauen, ob ich den Teil jeweils als "Änderungstemplate" mit reinbastle, und der Anwender dann ggf. ein anderes einheitliches Aussehen für seine tasmotas herstellen kann?
(Sorry, ist eine größere Fleißaufgabe, darfst auch nein sagen ;) ...; dann darf gerne auch ein anderer Freiwilliger).
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 07 Mai 2019, 19:23:47
Kurzer update:
im svn ist seit eben eine Version, in der die Auswertung der Topic-Struktur verbessert wurde (hoffe ich zumindest ::) ); damit sollten auch "populäre" Änderung der Topic-Struktur mit MQTT2_SERVER zu sinnvollen setList- und readingList-Einträgen führen...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: 87insane am 07 Mai 2019, 20:59:28
Mehr Details?  :)
Zufällig auch wegen dem 1pm Reading?
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 08 Mai 2019, 08:58:55
Mehr Details?  :)
Zufällig auch wegen dem 1pm Reading?
Details:
https://svn.fhem.de/trac/changeset/19345/

Den shelly1pm habe ich nicht extra angefaßt, wer das devStateIcon zuerst liefert, bekommt einen smiley ;) . Du wolltest doch Perl lernen... :P
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: 87insane am 08 Mai 2019, 14:02:35
Da warst du aber fleißig!

Naja - Es stehen auch noch x andere (alte) Aufgaben von dir/mir auf meiner Liste. Wie gerne hätte ich einen 48h Tag ;)
Wie bereits gesagt, hatte ich mir die Zähne daran ausgebissen. Das ist mir mit aktuellem Wissensstand zu hoch.

Smilies verdienen sich sicher alle gerne :)
Wäre schon echt cool, wenn mehr Leute mal Ihren Senf dazu geben und ggf. das ein oder andere Template mit aufbauen... Ich persönlich finde, es sind zu wenig User, die hier mit machen. ABER ich möchte betonen, das nur die gemeint sind, die ihr wissen einfach für sich nutzen aber nichts hier teilen oder einbringen.

Wie auch immer... ich werde gerne weiter mithelfen und auch so viel ich kann mitmachen.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: DasQ am 09 Mai 2019, 09:20:32
Hmm,

die Wahl des Icon hat der Anwender in der Hand, die LWT-messages sollten sich ja konfigurieren lassen, so ist es halt so, dass der kleine grüne Punkt das "online"-Icon ist; aber wer sich da den Text für einen roten Mülleimer oder eine grüne Pumpe schicken läßt, wird eben das sehen...

Wenn mehr Leute die Umstellung auf den klickbaren LWT-icon gut fänden, können wir das gerne machen. Ich gebe allerdings zu bedenken, dass die template ja teilweise auch dazu da sind, unterschiedliche Varianten zu präsentieren, wie man dasselbe Problem lösen kann, so dass Einheitlichkeit nicht unbedingt das Ziel war...

am milighthub kannst des alles wieder rausnehmen, der hat weder lwt noch sonstwas ...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 09 Mai 2019, 09:58:59
am milighthub kannst des alles wieder rausnehmen, der hat weder lwt noch sonstwas ...
Hast du evtl. in dem anderen Thread überlesen: Kann er seit neuestem sehr wohl, https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.9.0-rc.5 (https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.9.0-rc.5) :P . Gerne nehme ich einen Vorschlag für ein Comment-Attribut entgegen, wie man das konfigurieren muß ;) .
Seit RC3 (?) ist auch das Group-Handling verbessert, kann sein, dass das schon dein Problem aus dem allgemeinen "template-Thread" löst (https://github.com/sidoh/esp8266_milight_hub/releases/tag/1.9.0-dev4).

Bitte aber allgemein: Anregungen und Fragen zu dem milight@mqtt2-Zeug bitte in dem Milight-Thread ("war:"). Sonst geht das zu sehr durcheinander und die MiLight-Nutzer (die vermutliuch mehrheitlich den anderen Thread verfolgen) bekommen es andererseits nicht mit, wenn es Verbesserungen gibt...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: DasQ am 09 Mai 2019, 12:33:37
noch nicht! is ja "nur" rc ;)

aber danke für den tip, mich nervt in meiner angeblich aktuellen 1.8.8. das er nicht rebooten will
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 09 Mai 2019, 12:49:55
noch nicht! is ja "nur" rc ;)
Wir sind hier bei open source ;D . Spätestens seit meinen ersten Geh-Versuchen zu LIRC gehe ich "in dieser Welt" per default davon aus, dass spätestens "beta" sowas heißt wie: Vergiß alles, was vorher war, das hier funktioniert... (Darauf bezieht sich übrigens auch mein Nickname "Beta-User" :P ; FHEM ist sowas wie eine perpetual beta...)

Da ist RCn mit n>3 schon sowas wie "Gold-Standard" 8) .

Im Ernst: Ich hatte mit den veröffentlichten Versionen selten ein ernsthaftes Problem; einmal war eventuell (nach einem Downgrade?) die Übernahme der MQTT-Einstellungen kaputt, da habe ich ein "erase" gemacht, dann war alles wieder gut.
 
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TWART016 am 29 April 2020, 17:43:48
Hallo,

ich habe ein paar Gosund Steckdosen (Tasmota), die ich per MQTT2 eingebunden habe.

Beim MQTT2_CLIENT Device bekomme ich von dem Gerät allerdings in der readingList diese Einträge:
MQTT2_CLIENT:stat/GosundSP111-2/RESULT:.* { json2nameValue($EVENT) }
MQTT2_CLIENT:stat/GosundSP111-2/POWER:.* POWER

Die anderen Readings werden korrekt in das dafür angelegte Device geschrieben
tele/GosundSP111-2/LWT:.* LWT
cmnd/GosundSP111-2/POWER:.* POWER
tele/GosundSP111-2/INFO1:.* { json2nameValue($EVENT) }
tele/GosundSP111-2/INFO2:.* { json2nameValue($EVENT) }
tele/GosundSP111-2/INFO3:.* { json2nameValue($EVENT) }
tele/GosundSP111-2/STATE:.* { json2nameValue($EVENT) }
tele/GosundSP111-2/SENSOR:.* { json2nameValue($EVENT) }

Bei mit GeneralBridge steht das im bridgeRegex (kommt vom attrTemplate MQTT2_CLIENT_general_bridge)
attr MQTT2_GeneralBridge bridgeRegexp (tele|cmnd)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"\
  valetudo[/]([^/]+)[/].*:.* "$1"\
  [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"\
  wallpanel[/]([^/]+)[/].*:.* "$1"\
  (wled)[/]([^/]+)[/].*:.* "$1_$2"\
  (go-eCharger)[/]([^/]+)[/].*:.* "go_eCharger_$2"\
  (owntracks)[/]([^/:]+)[/]([^/:]+).*:.* "$1_$2$3"

Da dort nur tele und cmd steht, ist klar dass stat nicht in das Gerät geschrieben wird.

Gibt es Gründe warum das im attrTemplate nicht mit stat steht?
(tele|cmnd|stat)[/]([^/]+)[/].*:.* "$2"
Wie sollte dann denn die MQTT Konfiguration bei Tasmota sein, dass dieses Modul automatisch die topics richtig erkennt? Grundsätzlich macht es ja Sinn, eine einheitliche Struktur zu habe z.B. Raum/Typ/...
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: Beta-User am 29 April 2020, 17:53:25
Gibt es Gründe warum das im attrTemplate nicht mit stat steht?
Offen gestanden ist es so, dass sich zu diesem attrTemplate bisher - soweit ich mich entsinnen kann NIEMAND irgendwann irgendwie geäußert hat, und ich hatte das damals eher "mit heißer Nadel" gestrickt, um überhaupt was zu haben. War ein "Abfallprodukt" aus meinen Tests mit dem ebus...
Mir kam das bei den letzten Durchsichten auch unvollständig vor, wobei ich dazu neigen würde, den cmnd-Zweig gar nicht erst aufzunehmen, sondern das mit einer ignoreRegexp am IO-Device "nach dev/0" zu himmeln: Das was via cmnd kommt sind Schaltanweisungen, und die sollten eigentlich nur in Richtung Hardware gehen... (die Ausführungsbestätigung bekommt man dann ja wieder).

Zitat
Wie sollte dann denn die MQTT Konfiguration bei Tasmota sein, dass dieses Modul automatisch die topics richtig erkennt? Grundsätzlich macht es ja Sinn, eine einheitliche Struktur zu habe z.B. Raum/Typ/...
Gebaut habe ich das damals so, dass es mit den "defaults" (bzw. einer sinnvollen Namensvergabe statt "sonoff" (?)) klarkam. Wenn du die Topicstruktur änderst, mußt du eben die bridgeRegexp auch entsprechend anpassen, dann sollte das "ohne weiteres" gehen. (Aber wie gesagt, die Rückmeldung zu diesem attrTemplate war bisher 0...).

Diskussion dazu bitte in dem passenden Thread, ich hatte damals nach allgemeiner Rückmeldung gefragt, soweit ich mich entsinne.
Titel: Antw:Folgende Frage zu Sonoff/Tasmota und MQTT2_Device
Beitrag von: TWART016 am 29 April 2020, 18:26:39
Wenn du die Topicstruktur änderst, mußt du eben die bridgeRegexp auch entsprechend anpassen, dann sollte das "ohne weiteres" gehen. (Aber wie gesagt, die Rückmeldung zu diesem attrTemplate war bisher 0...).
Du meinst so?
/SmartHome/Wohnung/stat/([^/]+)/.*:.* "$1"
Diskussion dazu bitte in dem passenden Thread, ich hatte damals nach allgemeiner Rückmeldung gefragt, soweit ich mich entsinne.
Welchen Thread meinst du, habe keinen Allgemeingültigen gefunden.