Folgende Frage zu Sonoff/Tasmota und MQTT2_Device

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

Vorheriges Thema - Nächstes Thema

Beta-User

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

TomLee

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

rudolfkoenig

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

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

Beta-User

Zitat von: rudolfkoenig am 21 Dezember 2018, 16:24:08
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.
ZitatHabe 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?)
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

TomLee

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

ZitatMit dem attribute "jsonMap POWER2:0" sollte das gehen.

richtig verstanden habe.

rudolfkoenig

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

TomLee

Zitat von: rudolfkoenig am 21 Dezember 2018, 23:36:55
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

osr

#82
Zitat von: rudolfkoenig am 21 Dezember 2018, 16:24:08
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.

Zitat von: rudolfkoenig am 21 Dezember 2018, 16:24:08
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.

Zitat von: rudolfkoenig am 21 Dezember 2018, 16:24:08
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.

osr

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

rudolfkoenig

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

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

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

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

ZitatKann ja auch sein, dass mosquitto hier etwas nicht standardkonform abwickelt und so die Probleme umgeht.
Wenn ja, dann wuerde es mich interessieren, wie.

osr

Zitat von: rudolfkoenig am 20 Dezember 2018, 20:13:45
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 ;-)

osr

Zitat von: rudolfkoenig am 22 Dezember 2018, 14:31:37
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.

Zitat von: rudolfkoenig am 22 Dezember 2018, 14:31:37
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.

Zitat von: rudolfkoenig am 22 Dezember 2018, 14:31:37
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?

Beta-User

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

ZitatWie 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` }

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

rudolfkoenig

ZitatVielleicht 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