MQTT2+Shelly: erste Konfiguration und template-Entwicklung

Begonnen von miggun, 03 Dezember 2018, 21:05:34

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: miggun am 11 Dezember 2018, 19:59:40
Funktioniert.  :)
Auch hier ein Dankeschön für die Rückmeldung.

Kannst du die übrigen, noch fehlenden templates für deine Shellys auch noch entsprechend überarbeiten und dann (getestet ;) ) hier posten?

Wenn möglich auch ein "unified" 4-Kanal-template? (also alle Kanäle in einem Device, das ganze möglichst kompakt...)
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

miggun

#136
Getestet und funktioniert.

Shelly4Pro:
# shelly4pro using original firmware
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/0/power power1\
  shellies/DEVNAME/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVNAME/relay/1/command off\
  on:noArg shellies/DEVNAME/relay/1/command on
attr DEVICE getList shellies/DEVNAME/relay/1/power power2\
  shellies/DEVNAME/relay/1/energy energy2
attr DEVICE comment Channel 2 for DEVICE, see also DEVICE, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVNAME/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/DEVNAME/relay/2/command off\
  on:noArg shellies/DEVNAME/relay/2/command on
attr DEVICE getList shellies/DEVNAME/relay/2/power power3\
  shellies/DDEVNAME/relay/2/energy energy3
attr DEVICE comment Channel 3 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVNAME/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/DEVNAME/relay/3/command off\
  on:noArg shellies/DEVNAME/relay/3/command on
attr DEVICE getList shellies/DEVNAME/relay/3/power power4\
  shellies/DEVNAME/relay/3/energy energy4
attr DEVICE comment Channel 4 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH3


Shelly2:
# shelly2 using original firmware.
# NOTE: a second device will be created for the second channel
name:shelly2
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly2 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/power power
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVNAME/relay/1/command off\
  on:noArg shellies/DEVNAME/relay/1/command on
deleteattr DEVICE_CH2 getList


Shelly1:
# shelly1 using original firmware.
name:shelly1
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state


Ich würde ja für den Shelly4Pro gerne ein 5. und 6. Device anlegen. Muss nicht im Template sein. Aber da kommen wieder meine mangelnden Kenntnisse.
Shelly4Pro liefert power1-power4 und Energy1-energy4. Wie kann ich diese summieren?
Damit könnte ich/man ein Device power (Gesamt) und ein Device energy (Gesamt anlegen.
Raspberry Pi 3 B+
MapleCUN
Shelly1, Shelly2, Shelly4pro, FS20

Beta-User

Danke, ich verpatche das heute abend (da ist mir auch was in zigbee2mqtt doch nicht recht gelungen, patch dafür anbei...)

Was dein 5. Device angeht (wofür ist das 6.?): Einfach die Readings aller Kanäle einfangen und dann ein userreadings-Attribut mit anlegen, das die Infos für beide Angaben addiert. Beispiel für userreadings im template war in der shelly-Bulb.

Und nochmal: Es gibt Leute, die gerne _nur ein_ Device haben wollen, in dem alles drin ist (alle 4 Kanäle, Summen...). Vielleicht tobst du dich da nochmal aus (kannst ja mal versuchen, meinen 4-Kanal-Code für den Wemos-Tasmota zu adaptieren, ansonsten auf Basis des codes von hier:
Zitat von: osr am 10 Dezember 2018, 21:16:28
So habe mal 2 templates angelegt eines wo nur die readingList gesetzt wird und eines für einen sonoff 4 Kanal inklusive setList, webCmd und stateFormat damit man alle 4 Kanäle in einem Device nutzen kann.
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

miggun

Das mit einem Device für alle 4 Kanäle klingt auf jeden Fall sehr gut. Da werde ich mich mal dran geben. Muss aber hier noch ein paar Kabel verlegen, damit ich alles umrüsten kann.
Habe das mit dem addieren gelöst. Falls es einer nutzen will...
Shelly4Pro plus Gesamt-Power und Gesamt-Energy:
# shelly4pro using original firmware
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/0/power power1\
  shellies/DEVNAME/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVNAME/relay/1/command off\
  on:noArg shellies/DEVNAME/relay/1/command on
attr DEVICE getList shellies/DEVNAME/relay/1/power power2\
  shellies/DEVNAME/relay/1/energy energy2
attr DEVICE comment Channel 2 for DEVICE, see also DEVICE, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVNAME/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/DEVNAME/relay/2/command off\
  on:noArg shellies/DEVNAME/relay/2/command on
attr DEVICE getList shellies/DEVNAME/relay/2/power power3\
  shellies/DDEVNAME/relay/2/energy energy3
attr DEVICE comment Channel 3 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVNAME/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/DEVNAME/relay/3/command off\
  on:noArg shellies/DEVNAME/relay/3/command on
attr DEVICE getList shellies/DEVNAME/relay/3/power power4\
  shellies/DEVNAME/relay/3/energy energy4
attr DEVICE comment Channel 4 for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3, DEVICE_POWER and DEVICE_ENERGY
copy DEVICE DEVICE_POWER
attr DEVICE_POWER userReadings power { (ReadingsVal("DEVICE_POWER","power1",0)+ReadingsVal("DEVICE_POWER","power2",0)+ReadingsVal("DEVICE_POWER","power3",0)+ReadingsVal("DEVICE_POWER","power4",0));; }
attr DEVICE_POWER stateFormat power
attr DEVICE comment Power for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3, DEVICE_CH4 and DEVICE_ENERGY
copy DEVICE DEVICE_ENERGY
attr DEVICE_ENERGY userReadings energy { (ReadingsVal("DEVICE_ENERGY","energy1",0)+ReadingsVal("DEVICE_ENERGY","energy2",0)+ReadingsVal("DEVICE_ENERGY","energy3",0)+ReadingsVal("DEVICE_ENERGY","energy4",0));; }
attr DEVICE_ENERGY stateFormat energy
attr DEVICE comment Energy for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3, DEVICE_CH4 and DEVICE_POWER
Raspberry Pi 3 B+
MapleCUN
Shelly1, Shelly2, Shelly4pro, FS20

Beta-User

Das kannst du noch nicht abschließend getestet haben: userreadings kann man nur einmal anlegen, es müssen beide in die eine Zeile ;) .
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

miggun

#140
Wollte ich gerade testen. Habe es jetzt manuell angelegt.
Wenn es dann passt noch schnell abändern. Danke für den Tip.
Das war der Grund für's posten. Allein bin ich da doch aufgeschmissen.

Edit: Manuell bekomme ich es hin, aber leider nicht ins Template gegossen. Er haut da DEVNAME kaputt und schmeißt energy und power wild durcheinander.
Raspberry Pi 3 B+
MapleCUN
Shelly1, Shelly2, Shelly4pro, FS20

Beta-User

Hab' mich mal versucht:
# shelly4pro using original firmware
# NOTE: for each of the second to fourth channel, a new device will be created
name:shelly4pro
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/relay/0/command off\
  on:noArg shellies/DEVNAME/relay/0/command on
attr DEVICE readingList shellies/DEVNAME/relay/0:.* state
attr DEVICE getList shellies/DEVNAME/relay/0/power power1\
  shellies/DEVNAME/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVNAME/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/DEVNAME/relay/1/command off\
  on:noArg shellies/DEVNAME/relay/1/command on
attr DEVICE getList shellies/DEVNAME/relay/1/power power2\
  shellies/DEVNAME/relay/1/energy energy2
attr DEVICE comment Channel 2 for DEVICE, see also DEVICE, DEVICE_CH3 and DEVICE_CH4
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVNAME/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/DEVNAME/relay/2/command off\
  on:noArg shellies/DEVNAME/relay/2/command on
attr DEVICE getList shellies/DEVNAME/relay/2/power power3\
  shellies/DDEVNAME/relay/2/energy energy3
attr DEVICE comment Channel 3 for DEVICE, see also DEVICE, DEVICE_CH2 and DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVNAME/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/DEVNAME/relay/3/command off\
  on:noArg shellies/DEVNAME/relay/3/command on
attr DEVICE getList shellies/DEVNAME/relay/3/power power4\
  shellies/DEVNAME/relay/3/energy energy4
attr DEVICE comment Channel 4 for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3 and DEVICE_POWER
copy DEVICE DEVICE_POWER
attr DEVICE_POWER userReadings \
power { (ReadingsVal("DEVICE_POWER","power1",0)+ReadingsVal("DEVICE_POWER","power2",0)+ReadingsVal("DEVICE_POWER","power3",0)+ReadingsVal("DEVICE_POWER","power4",0))},\  energy { (ReadingsVal("DEVICE_POWER","energy1",0)+ReadingsVal("DEVICE_POWER","energy2",0)+ReadingsVal("DEVICE_POWER","energy3",0)+ReadingsVal("DEVICE_POWER","energy4",0))}attr DEVICE_POWER stateFormat P:power E:energy
attr DEVICE_POWER comment Power for DEVICE, see also DEVICE, DEVICE_CH2, DEVICE_CH3 and DEVICE_CH4

Aber:
Vom Gefühl her gehört da noch eine readingList dazu, damit die Daten auch ankommen (oder klappt das)?
Was mir an sich nicht gefällt, ist die "Umnummerierung". Da die firmware intern das erste Relais mit "0" belabelt, sollte man diese Zählweise m.E. insgesamt (auch bei Energy etc) beibehalten (ich vermute, da kommt ein Teil deiner Probleme her).
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 11 Dezember 2018, 11:16:17


# basic tasmota device with unprefixed readings
name:tasmota_noprefix_pure_base
filter:TYPE=MQTT2_DEVICE
deletereading DEVICE .*
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO.:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
attr DEVICE autocreate 0


ja das INFO. ist cool. Habe es getestet funktioniert tadellos.
Dazu das autocreate per device von rudolkoenig ist natürlich auch super.


name:tasmota_noprefix_sonoff_4ch
filter:TYPE=MQTT2_DEVICE
set DEVICE attrTemplate tasmota_noprefix_pure_base
attr DEVICE setList \
  p1:on,off cmnd/DEVICE/POWER1 $EVTPART1\
  p2:on,off  cmnd/DEVICE/POWER2 $EVTPART1\
  p3:on,off  cmnd/DEVICE/POWER3 $EVTPART1\
  p4:on,off  cmnd/DEVICE/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>"\
  }


Auch das habe ich soweit getestet und funktioniert sehr schön und elegant, das set DEVICE attrTemplate darin macht den Code noch kompakter und besser zu warten.

cmdIcon und ReadingsGroup schaue ich mir mal noch an bezüglich schalten über die Icons, hast du vermutlich gemeint.

Werde das nochmal durchtesten und noch ein template für relay+sensor machen. Die 3 Templates poste ich dann morgen. Das WemosD1 template kann dann raus.

Beta-User

Hallo zusammen!

Die gesammelten Werke sind im wesentlichen jetzt hier verarbeitet, Danke auch für die diversen Rückmeldungen zu meinen Vorschlägen.

Offen wären dann vorläufig noch:- 4-fach-Shelly als ein Device (bzw. ggf. mit der Erweiterung um ein 5. Device mit den Energy- etc-Werten)
- Shelly2 im roller-Mode (sollte sich auch wieder umstellen lassen, oder ;) )

@osr
Mir ist nicht klar, was die tasmota-Patche bewirken:
Wenn es andere Sendebefehle erforderlich macht oder andere Schreibweisen der Rückmeldungen, kann das uU. Schwierigkeiten machen (und wenn es nur bei der Anzeige ist). Das sollte daher möglichst ohne Modifikation gehen (oder mit einem comment, was zu tun ist, dass es geht).
Rest ist "nice-to-have".
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

OK das passt soweit alles. Habe es doch noch heute geschafft...

Von meiner Seite sollte das template tasmota_WemosD1 wieder raus.

Dann das template tasmota_noprefix_pure_base so geändert werden:





# basic tasmota device with unprefixed readings
name:tasmota_noprefix_pure_base
filter:TYPE=MQTT2_DEVICE
attr DEVICE autocreate 0
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO.:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
deletereading DEVICE .*



sowie tasmota_noprefix_ sonoff_4ch in tasmota_noprefix_4ch weil das für jedes Tasmota Gerät mit 4 Kanälen funktioniert:



# tasmota 4 channel as one FHEM device

name:tasmota_noprefix_4ch
filter:TYPE=MQTT2_DEVICE
set DEVICE attrTemplate tasmota_noprefix_pure_base
attr DEVICE setList \
  p1:on,off cmnd/DEVICE/POWER1 $EVTPART1\
  p2:on,off  cmnd/DEVICE/POWER2 $EVTPART1\
  p3:on,off  cmnd/DEVICE/POWER3 $EVTPART1\
  p4:on,off  cmnd/DEVICE/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"))\
  . "<>"\
  }



und schließlich neu tasmota_noprefix_1ch+motion+SI7021

# tasmota device with one relay, one motion sensor via switch
# and one SI7021 combined temperature and humidity sensor
# as one FHEM device

name:tasmota_noprefix_1ch+motion+SI7021
filter:TYPE=MQTT2_DEVICE
set DEVICE attrTemplate tasmota_noprefix_pure_base
attr DEVICE setList \
  on:noArg cmnd/DEVICE/POWER1 on\
  off:noArg  cmnd/DEVICE/POWER1 off
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)\
    ) . "<>"\
  }



webCmd ist hier wohl nicht notwendig. Jedenfalls erscheinen bei mir on und off auch so.


Mit dem Satz an tasmota_noprefix templates sollte, mit etwas Anpassung, vieles was mit Wemos und Konsorten über Tasmota möglich ist sehr einfach in einem Gerät in FHEM umgesetzt werden können. Auch meine Markisensteuerung habe ich damit umgesetzt. 2 Relay + Temperatursensor für draußen. Auch das Shellygerät sollte mit den Ideen in einem Gerät umgesetzt werden können. Davon wollte ich mir auch noch welche zu legen. Wie seid ihr denn mit denen so zufrieden? Würde die wohl aber eher mit Tasmota einsetzen ;-)


Vielen vielen Dank an Beta-User für die Ideen und an rudolkoenig für das schnelle umsetzen von autocreate auf MQTT2_DEVICE.

Beta-User

Danke für die Rückmeldung, hoffe es auf die Schnelle richtig eingearbeitet zu haben und Rudi hat das noch mitgekriegt.

Sonst gibt's die letzte Fassung dann morgen oder so...
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

miggun

#146
Shelly4Pro bekomme ich nicht ans laufen mit dem Template. Es erscheint ein PopUp, wo ich DEVNAME vergeben soll. Egal in welcher Variante ich es eingebe, er legt es nicht sauber an. Vorher hat es ja gut funktioniert. Ich denke, wir lassen Power raus. Wenn einer das haben will, soll er fragen oder lesen. Wenn ich das hin bekomme, bekommt das jeder hin.
Shelly2 im roller-Modus kommt noch. Ich muss da noch eins bestellen, was wirklich die eine Rolllade fährt, die nicht über die Zentralsteuerung läuft.
Raspberry Pi 3 B+
MapleCUN
Shelly1, Shelly2, Shelly4pro, FS20

osr

Zitat von: Beta-User am 12 Dezember 2018, 22:21:35

@osr
Mir ist nicht klar, was die tasmota-Patche bewirken:
Wenn es andere Sendebefehle erforderlich macht oder andere Schreibweisen der Rückmeldungen, kann das uU. Schwierigkeiten machen (und wenn es nur bei der Anzeige ist). Das sollte daher möglichst ohne Modifikation gehen (oder mit einem comment, was zu tun ist, dass es geht).
Rest ist "nice-to-have".

OK Tasmota verwendet ON nicht on wie sonst bei FHEM. Das wollte ich einheitlich haben. Deswegen (und für andere Voreinstellungen wie WIFI Passwort etc.) verwende ich eine selbst kompilierte Tasmota Firmware.

Habe das aber getestet es ist egal ob ich an ein Tasmota Device ON oder on sende. Das selbe gilt für off und toggle. Das heißt für meine Templates sollte die eventMap wie bei den anderen tasmota templates verwendet ergänzt werden. Dann funktioniert es sauber auch mit der Standard-Tasmota Firmware. Also in tasmota_noprefix_pure_base muss noch

attr DEVICE eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }

dazu. Bei mir hat das keine Auswirkungen und bei Standardfirmware wird dann das OFF bzw. ON auf off, on umgesetzt, so dass auch FHEM zufrieden ist und die Stati wie gewohnt in FHEM sind.

Beta-User

Danke für eure Rückmeldungen.

Das mit Tasmota hatte ich so vermutet, die Ergänzung kommt dann noch (Rudi hatte den "alten" patch schon eingepflegt).
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

@Rudi
Kurz ein Gedanke: Sowas in der Form wie unten  taucht im MQTT-Kontext ständig auf. Wäre es nicht einfacher, direkt über das Modul lowercase für (ON|OFF|On|Off) zu verwenden, sobald irgend ein Reading (incl. state) (von extern, also idR. vom Gerät kommend) auf genau einen der Werte gesetzt werden soll?

(Kann sein, dass das Änderungen bei dem zigbee-devStateIcon nach sich zöge, aber sonst fällt mir im Moment auf die Schnelle nichts ein, was unangenehme Nebenwirkungen anginge).

Zitat von: osr am 12 Dezember 2018, 22:56:21

attr DEVICE eventMap { dev=>{'^(.*)POWER(.?): OFF$'=>'$1POWER$2: off', '^(.*)POWER(.?): ON$'=>'$1POWER$2: on'} }

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