Folgende Frage zu Sonoff/Tasmota und MQTT2_Device

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

Vorheriges Thema - Nächstes Thema

tpm88

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

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
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

osr

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

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

osr

Zitat von: tpm88 am 15 Dezember 2018, 21:56:40
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.

osr

Zitat von: Beta-User am 15 Dezember 2018, 14:38:33
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.

Zitat von: Beta-User am 15 Dezember 2018, 14:38:33
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

Zitat von: Beta-User am 15 Dezember 2018, 14:38:33
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 ;-)

Zitat von: Beta-User am 15 Dezember 2018, 14:38:33
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.

moonsorrox

#34
Zitat von: tpm88 am 15 Dezember 2018, 21:56:40
@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}}


Zitat von: osr am 15 Dezember 2018, 22:02:20
@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..!  :-\
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

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

TomLee

Zitatganz 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

moonsorrox

#36
Zitat von: TomLee am 16 Dezember 2018, 13:53:15
Einfach mal setOption26 in der Konsole auf dem Sonoff eingeben, um den aktuellen Status auszugeben.DOKU
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..!  :'(
Intel-NUC i5: FHEM-Server 6.1 :: Perl v5.18.2

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

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

osr

Zitat von: Beta-User am 16 Dezember 2018, 15:43:48
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?

rudolfkoenig

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

Beta-User

Zitat von: rudolfkoenig am 16 Dezember 2018, 23:30:18
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!

Zitat von: rudolfkoenig am 16 Dezember 2018, 23:30:18Eine 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.
Interpretiere ich das richtig: einfach ans Ende jedes Blocks den "name:" aus dem template in das Attribut schreiben?

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

Zitat von: osr am 16 Dezember 2018, 17:49:10
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.

Zitat von: osr am 16 Dezember 2018, 17:49:10
Zu allem anderen kann ich nur zustimmen. Wenn du eingechecked hast schaue ich gerne nochmal drüber.
Danke, ich melde mich dann hier.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

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

rudolfkoenig

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

Beta-User

#43
Zitat von: rudolfkoenig am 17 Dezember 2018, 09:51:16
Ja, aber dann haettest du [...]
Leuchtet ein; da müßte ich auch noch etwas rumexperimentieren...

Zitat von: Beta-User am 17 Dezember 2018, 07:56:30
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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files