MQTT2+Shelly: erste Konfiguration und template-Entwicklung

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

Vorheriges Thema - Nächstes Thema

osr

Zitat von: Beta-User am 10 Dezember 2018, 16:32:38
Ein paar Anmerkungen, was mir auf die Schnelle auffällt:
- "WemosD1" ist eine bestimmte ESP8266-Hardware, auf der ganz unterschiedliche firmwares laufen können. Ist das Tasmota? Dann sollte der name: auch irgendwas mit Tasmota beinhalten ;) . Wenn es was anderes ist, dann eben das.

Klar Tasmota was sonst ;-) Aber ich nutze das auch für die sonoffBasic, die 4 Ports etc., also grundsätzlich für alle Tasmota Geräte. Nur stateFormat etc. lege ich dann unterschiedlich an. Aber readingList ist einheitlich. Ich fand autocreate schön, habe nur was gegen die Präfixe und auch die cmnd/.../POWER sind unnötig, aber mit POWER könnte ich im autocreate gut leben.

readingList sollte für Tasmota:

LWT für den Status ist ein muss
RESULT für die Antwort (egal wie POWER gesetzt wurde per FHEM, MQTT selbst oder per Hardware)
SENSOR um alle Sensordaten zu erhalten
STATE um die Stati alle paar Minuten zu erhalten von POWER etc.

enthalten. Mehr braucht es nicht für Tasmota, egal was da dran hängt. Relays, Sensoren (Temperatur, Feuchtigkeit, Helligkeit, ...), Switches wie Bewegungsmelder, Taster, ...

Werde mal ein paar Templates erstellen inklusive Kommentare etc ;-) und hier posten, mache dann auch mal einen für 4 Port mit setList und Stati etc.

Beta-User

Zitat von: gvzdus am 10 Dezember 2018, 16:54:38
Und nun wieder der Kollege mit seiner ollen Lampe :-)
;D ;D ;D
Zitat
Ja, die Idee mit dem "deletereading" im Template war gut. Denn der AutoCreate "verbessert" immer nur das "fehlende"
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
- damit kann man leben oder autocreate abschalten.
Danke für die Rückmeldung. Kannst du das direkt in das template mit aufnehmen? Dann hat man keine nachträglichen Änderungen mehr, die irgendjemanden irritieren könnten.

ZitatInzwischen bin auch schon recht dicht vor dem Finale:
- Farbtemperatur funzt
- Aus den Einzelwerten für red, green, blue einen Wert "rgb" wie bei den anderen Kindern basteln, um den Colorpicker zu füttern, funzt.
Sowas hört man doch gerne. Paßt denn der Zeitstempel für das userReading? (Ich will was ähnliches für die MiLights machen, glaube aber, dass das userreading immer aktualisiert wird, wenn sich irgendein Status ändert; aber da wird auch "anders" auf weiß geschaltet, unabhängig von der alten Farbe, und dann würde ein farbiges devStateIcon ggf. nicht mehr passen).

ZitatWo es hakt: das zigbee2mqtt_RGB2JSON gescheit weiterzuverarbeiten, um eine Farbe zu setzen. So, wie ich das definitiert habe, landet bei der Farbänderung
Da mußt du vermutlich die Funktion zigbee2mqtt_RGB2JSON() aus MQTT2_DEVICE mal in eine eigene myUtils übernehmen und entsprechend editieren. Die Art, wie zigbee2mqtt den JSON haben will, scheint deutlich anders zu sein. Dazu kannst du den MQTT2-Server auf "gesprächig" stellen (rawEvents), um das Ergebnis direkt zu prüfen.
Und wenn alles Perl-Code sein soll, muß die Klammer auch um das topic (schau mal im mqtt2template, da gab es ein Beispiel mit der Funktion, die dir hier nicht weiterhilft, soweit ich mich entsinne).

Zitat von: osr am 10 Dezember 2018, 17:05:26
Klar Tasmota was sonst ;-)
ESPEasy spricht auch MQTT, wenn ich das richtig verstanden habe. Und meine MiLight-Bridge ist auch ein D1-Mini, genau wie meine IR-Bridge, auf der wieder eine ganz andere Firmware läuft. Ergo: Nicht alle ESP8266 sind Tasmota, nicht mal alle WemosD1 :P .

Aber davon weg: "name:tasmota_pure_base"?

Ansonsten bin ich auf die templates gespannt.
Kann man darüber auch firmware-updates hauen, restarts auslösen und irgendwas abfragen (uptime...)? Dann wäre eine setList nicht übel :P .

Andere Sache noch: wenn es eine einheitliche Basis gibt, müßte man evtl. auch einfach ein set DEVICE attrTemplate tasmota_pure_base vorneweg schießen können, um dann nur noch nachzupflegen, was jeweils anders ist...
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

Mal noch eine andere Idee. Wäre es möglich (oder geht das bereits) das autocreate auch pro Device setzen zu können? Also globales autocreate=1 und mit dem template setzt man das lokale DEVICE autocreate auf 0 so dass readingList nicht mehr aktualisiert wird?

gvzdus

So, proudly presenting:
So ist in fertig:

# shellybulb using original firmware. Tested with 1.3
name:shellybulb
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/color/0/command off\
  on:noArg shellies/DEVNAME/color/0/command on\
  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}\
  temp:colorpicker,CT,3000,10,6500 shellies/DEVNAME/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/; "shellies/DEVNAME/color/0/set {\"ison\":true,\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2)."\"blue\":".hex($3) }
deletereading DEVICE status_.*
attr DEVICE readingList shellies/DEVNAME/color/0/status:.* {json2nameValue($EVENT)}
attr DEVICE userReadings rgb {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
attr DEVICE webCmd on:off:brightness:temp:rgb
attr DEVICE genericDeviceType light
attr DEVICE icon light_control


Sprich: So werden die Werte für RGB hin- und zurückgerechnet. MyUtils kommt nicht in die Tüte: Es ist ja für die Nachwelt :-)
Das Template liefert die Picker für Brightness, "Weißtemperatur" (Nutzung schaltet in den Modus "Weißlicht") oder eben den RGB-Colorpicker, dann wird auf Farbe umgeschaltet.
Hat einmal Device-Löschen und Neuerkennung überstanden, sollte also veröffentlichungsfähig sein.

Nee, den Bug mit dem Auto-Create, dass permanent ein unschönes Reading dazu zaubert, will ich nicht übertünchen. Vielleicht ist er ja bald Geschichte.
Ja, das userReadings "rgb" entsteht erst, wenn ein neuer Status reinkommt. Dafür muss man mindestens einmal an- oder ausschalten. Erwähnte ich, dass ich am Schönsten fände, wenn das Template gleich bei dem AutoCreate angezogen wird?  ::) Dann läge auch gleich ein Event vor.

Danke für die Unterstützung!

osr

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.

set Device p1on schaltet dann Kanal 1 ein, ...

Perfect wäre es wenn man mit dem template im device noch ein attribute autocreate=0 setzen könnte damit readingList auch bei global gesetztem autocreate nichts mehr ändert:

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

name:tasmota_noprefix_sonoff_4ch
filter:TYPE=MQTT2_DEVICE
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO1:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO2:.* { json2nameValue($EVENT) }\
  tele/DEVICE/INFO3:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
attr DEVICE setList \
  p1on:noArg cmnd/DEVICE/POWER1 on\
  p1off:noArg cmnd/DEVICE/POWER1 off\
  p2on:noArg cmnd/DEVICE/POWER2 on\
  p2off:noArg cmnd/DEVICE/POWER2 off\
  p3on:noArg cmnd/DEVICE/POWER3 on\
  p3off:noArg cmnd/DEVICE/POWER3 off\
  p4on:noArg cmnd/DEVICE/POWER4 on\
  p4off:noArg cmnd/DEVICE/POWER4 off
attr DEVICE webCmd p1on:p1off:p2on:p2off:p3on:p3off:p4on:p4off
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 webCmd p1on:p1off:p2on:p2off:p3on:p3off:p4on:p4off

Auf Wunsch könnte ich auch noch ein Beispiel für ein Gerät mit 1 Relay und Temperatursensor bereitstellen. Gerade für Anfänger sollte es damit dann möglich sein beliebige Konstellationen abzubilden.

Was hier auch noch ergänzt werden sollte wäre die eventMap. Ich verwende ein angepasstes Tasmota welches on, off und toggle fhem-konform kleingeschrieben sendet und nicht ON, OFF, TOGGLE. So brauche ich die eventMap nicht.

Ich hoffe mein Code ist sonst soweit gut. Das FW_makeImage habe ich auch erst heute gefunden. Aber damit wird der Code richtig kurz. Das einzige was mir noch fehlt wäre, dass die Relay toggeln wenn das Symbol geklickt wird. Aber vielleicht hat da ja noch jemand eine Idee wie man das umsetzt?

miggun

So, hier mal das erste Lebenszeichen vom Shelly1.
Werde auf der Grundlage mal das Template fertigen.

2018.12.11 11:11:18 5: CONNECT: (0)(4)MQTT(4)(2)(0)<(0)(14)shelly1-12B9BD
2018.12.11 11:11:18 4: MQTT2_SERVER_192.168.1.20_20537 shelly1-12B9BD CONNECT V:4 keepAlive:60
2018.12.11 11:11:18 5: PUBLISH: (0)(31)shellies/shelly1-12B9BD/relay/0on
2018.12.11 11:11:18 4: MQTT2_SERVER_192.168.1.20_20537 shelly1-12B9BD PUBLISH shellies/shelly1-12B9BD/relay/0:on
2018.12.11 11:11:18 5: MQTT2_SERVER: dispatch autocreate:shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:on
2018.12.11 11:11:18 2: autocreate: define MQTT2_shelly1_12_9__ MQTT2_DEVICE shelly1_12B9BD
2018.12.11 11:11:18 2: autocreate: define FileLog_MQTT2_shelly1_12_9__ FileLog ./log/MQTT2_shelly1_12_9__-%Y.log MQTT2_shelly1_12_9__
2018.12.11 11:11:18 5: PUBLISH: (0)(17)shellies/announce{"id":"shelly1-12B9BD"}
2018.12.11 11:11:18 4: MQTT2_SERVER_192.168.1.20_20537 shelly1-12B9BD PUBLISH shellies/announce:{"id":"shelly1-12B9BD"}
2018.12.11 11:11:18 5: MQTT2_SERVER: dispatch autocreate:shelly1_12B9BD:shellies/announce:{"id":"shelly1-12B9BD"}
2018.12.11 11:11:18 5: SUBSCRIBE: (0)(3)(0)(16)shellies/command(1)
2018.12.11 11:11:18 4: MQTT2_SERVER_192.168.1.20_20537 shelly1-12B9BD SUBSCRIBE
2018.12.11 11:11:18 4:   topic:shellies/command qos:1


2018-12-11 11:11:18 Global global DEFINED MQTT2_shelly1_12_9__
2018-12-11 11:11:18 Global global DEFINED FileLog_MQTT2_shelly1_12_9__
2018-12-11 11:11:18 Global global ATTR MQTT2_shelly1_12_9__ readingList shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:.* shellies/shelly1-12B9BD/relay/0
2018-12-11 11:11:18 MQTT2_DEVICE MQTT2_shelly1_12_9__ shellies/shelly1-12B9BD/relay/0: on
2018-12-11 11:11:18 Global global ATTR MQTT2_shelly1_12_9__ readingList shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:.* shellies/shelly1-12B9BD/relay/0 shelly1_12B9BD:shellies/announce:.* { json2nameValue($EVENT, 'announce_') }
2018-12-11 11:11:18 MQTT2_DEVICE MQTT2_shelly1_12_9__ announce_id: shelly1-12B9BD
Raspberry Pi 3 B+
MapleCUN
Shelly1, Shelly2, Shelly4pro, FS20

Beta-User

Zitat von: gvzdus am 10 Dezember 2018, 18:31:32
So, proudly presenting:
Gratulation, sieht gut aus, und ohne myUtils-Code auszukommen, ist richtig klasse!

patch dazu ist hier zu finden: https://forum.fhem.de/index.php/topic,91394.msg870402.html#msg870402

Zitat von: miggun am 11 Dezember 2018, 11:13:23
So, hier mal das erste Lebenszeichen vom Shelly1.
Werde auf der Grundlage mal das Template fertigen.
:)

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.
Das erste würde ich gerne mal so getestet wissen:
# 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) }


ZitatWas hier auch noch ergänzt werden sollte wäre die eventMap. Ich verwende ein angepasstes Tasmota welches on, off und toggle fhem-konform kleingeschrieben sendet und nicht ON, OFF, TOGGLE. So brauche ich die eventMap nicht.
M.E. sollten die templates die Standardkonfiguration abdecken, vor dem Einchecken sollte das also passen.

Für die weitere Entwicklung mal folgende Anregungen:

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>"
  }
Was die Darstellung angeht, könnte cmdIcon noch was für dich sein, aber einfacher dürfte es mit einer passenden ReadingsGroup werden. Zu cmdIcon habe ich nichts gefunden, ob da ein anderes Trennzeichen definiert werden kann (wie bei eventMap).

Und bitte nutze wenn möglich zukünftig die code-Tags; das ist einfach besser zu lesen...
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

#127
Template Shelly1:

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

miggun

#128
So sieht es jetzt aus.

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


Shelly2

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


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:SHELLY4PRO;Shelly4Pro name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/SHELLY4PRO/relay/0/command off\
  on:noArg shellies/SHELLY4PRO/relay/0/command on
attr DEVICE readingList shellies/DEVICE/relay/0:.* state
attr DEVICE getList shellies/DEVICE/relay/0/power power1\
  shellies/DEVICE/relay/0/energy energy1
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH2
copy DEVICE DEVICE_CH2
attr DEVICE_CH2 readingList shellies/DEVICE/relay/1:.* state
attr DEVICE_CH2 comment Channel 2 for DEVICE
attr DEVICE_CH2 setList \
  off:noArg shellies/SHELLY4PRO/relay/1/command off\
  on:noArg shellies/SHELLY4PRO/relay/1/command on
attr DEVICE getList shellies/DEVICE/relay/1/power power2\
  shellies/DEVICE/relay/1/energy energy2
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH3
copy DEVICE DEVICE_CH3
attr DEVICE_CH3 readingList shellies/DEVICE/relay/2:.* state
attr DEVICE_CH3 comment Channel 3 for DEVICE
attr DEVICE_CH3 setList \
  off:noArg shellies/SHELLY4PRO/relay/2/command off\
  on:noArg shellies/SHELLY4PRO/relay/2/command on
attr DEVICE getList shellies/DEVICE/relay/2/power power3\
  shellies/DEVICE/relay/2/energy energy3
attr DEVICE comment Channel 1 for DEVICE, see also DEVICE_CH4
copy DEVICE DEVICE_CH4
attr DEVICE_CH4 readingList shellies/DEVICE/relay/3:.* state
attr DEVICE_CH4 comment Channel 4 for DEVICE
attr DEVICE_CH4 setList \
  off:noArg shellies/SHELLY4PRO/relay/3/command off\
  on:noArg shellies/SHELLY4PRO/relay/3/command on
attr DEVICE getList shellies/DEVICE/relay/3/power power4\
  shellies/DEVICE/relay/3/energy energy4
Raspberry Pi 3 B+
MapleCUN
Shelly1, Shelly2, Shelly4pro, FS20

Beta-User

Zitat von: miggun am 11 Dezember 2018, 11:20:18
Template Shelly1:
Klasse!

(war noch nicht fertig mit tippen zum shelly1, aber die Anmerkungen/Änderungen gelten entsprechend auch für die anderen templates).

Kannst du mal folgendes bitte testen:
# 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

Anmerkung: bisher waren alle Parameter ausschließlich groß geschrieben, und in der bulb heißt es jetzt DEVNAME, das wäre m.E. ein möglicher Standard. Und irgendwie habe ich das Gefühl, dass der Parameter einheitlich sein sollte (hier ist er evtl. nur zufällig gleich; das könnte aber abweichen, wenn jemand das Teil vorher umbenennt...).

Aus dem Code von gvzdus, für den Fall, dass es nicht so recht will:
par:DEVNAME;Shelly1 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
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

Mist, wenn ich das Template auf das automatisch angelegte MQTT2-DEVICE anwende, wird es nicht richtig angelegt, Da autocreate den falschen Eintrag verwendet.

So sieht es aus:
defmod MQTT2_shelly1_12_9__ MQTT2_DEVICE shelly1_12B9BD
attr MQTT2_shelly1_12_9__ IODev MQTT2_SERVER
attr MQTT2_shelly1_12_9__ readingList shellies/MQTT2_shelly1_12_9__/relay/0:.* state\
shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:.* shellies/shelly1-12B9BD/relay/0
attr MQTT2_shelly1_12_9__ room MQTT2_DEVICE
attr MQTT2_shelly1_12_9__ setList off:noArg shellies/shelly1/relay/0/command off\
  on:noArg shellies/shelly1/relay/0/command on


So sollte es aussehen:
defmod MQTT2_shelly1_12B9BD MQTT2_DEVICE shelly1_12B9BD
attr MQTT2_shelly1_12B9BD IODev MQTT2_SERVER
attr MQTT2_shelly1_12B9BD readingList shellies/shelly1-12B9BD/relay/0:.* state\
shelly1_12B9BD:shellies/shelly1-12B9BD/relay/0:.* shellies/shelly1-12B9BD/relay/0
attr MQTT2_shelly1_12B9BD room MQTT2_DEVICE
attr MQTT2_shelly1_12B9BD setList off:noArg shellies/shelly1-12B9BD/relay/0/command off\
  on:noArg shellies/shelly1-12B9BD/relay/0/command on
Raspberry Pi 3 B+
MapleCUN
Shelly1, Shelly2, Shelly4pro, FS20

Beta-User

Zitat von: miggun am 11 Dezember 2018, 11:54:10
Mist, wenn ich das Template
Welches? Eines von deinen oder das von mir modifizierte ;) ?
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

 
ZitatWäre es möglich (oder geht das bereits) das autocreate auch pro Device setzen zu können?
Habe autocreate in MQTT2_DEVICE eingebaut: die Voreinstellung ist 1, falls es auf 0 gesetzt wird, dann unterbleibt die Erweiterung der ReadingList.
Weiterhin habe ich die Voreinstellung fuer autocreate in MQTT2_SERVER von 0 auf 1 geaendert.
In MQTT2_CLIENT bliebt sie auf 0.

Ich meine immer noch, dass per Voreinstellung readingList mit { json2nameValue($EVENT, 'Praefix_') } erweitert werden sollte, aber mit AttrTemplate und autocreate=0 hat man die Moeglichkeit, es fuer einzelne Geraete besser zu loesen.

ZitatAlso habe jetzt mal in my.template folgendes für meine Wemos hinterlegt:
Habs mit dem Namen tasmota_WemosD1 hinzugefuegt.

ZitatSo, proudly presenting:
Hinzugefuegt.

ZitatSo habe mal 2 templates angelegt [...] Perfect wäre es wenn man mit dem template im device noch ein attribute autocreate=0 setzen könnte damit readingList auch bei global gesetztem autocreate nichts mehr ändert:
Hinzugefuegt, und jeweils mit "attr DEVICE autocreate 0" ergaenzt.

Mit den weiteren Shellies bin ich verwirrt, da brauche ich eine klare Ansage zum Einchecken.
Btw.: will nicht jemand die Patenschaft fuer mqtt2.template uebernehmen? :)
   

Beta-User

#133
ZitatMit den weiteren Shellies bin ich verwirrt, da brauche ich eine klare Ansage zum Einchecken.
Da war mind. in dem shelly1-template von miggun noch ein bug drin, wenn ich das richtig deute. Wenn du sicher beurteilen kannst, dass meine Fassung paßt, könnte man die auch einchecken, den Rest eher nicht (da geht es m.E. noch ein wenig durcheinander).

ZitatBtw.: will nicht jemand die Patenschaft fuer mqtt2.template uebernehmen? (https://forum.fhem.de/Smileys/default/smiley.gif)
:o ??? ??? ??? ???
Puhhh, ich vermute mal, du denkst an jemanden bestimmten...
An sich glaube ich, zwischenzeitlich sowohl mqtt(2) wie auch die Mechanismen im template selbst halbwegs verstanden zu haben. Was mich aber schreckt, sind die Administrationswerkzeuge. Die wollte ich eigentlich nicht auch noch lernen ::) . Mit sowas hatte ich jedenfalls bislang nie was zu tun...
Aber an sich würde ich erwarten, dass das mit der Einpflegerei irgendwann auch mal deutlich weniger wird, und dann steigt eben wieder das Risiko, dass "derjenige" das dann irgendwann in der Zukunft falsch macht, weil er die Werkzeuge nicht beherrscht.

Wenn das mit dem Einarbeiten und derh Handhabung der Tools halbwegs überschaubar ist: Weil du mich so nett fragst...

EDIT:
Noch was anderes: Ich hatte - leider erfolglos - versucht, die set-Funktion in MQTT2_DEVICE entsprechend dem code in Dummy so umzubauen, dass man ein Reading setzt (und nicht state), wenn der Name in der setList auftaucht (mit einem Doppelpunkt dahinter). An sich sah das nicht schwierig aus, aber leider hat es nicht funktioniert und ich kann nicht genug Perl, um das in einigermaßen überschaubarer Zeit zu fixen...
Vielleicht hättest du 10 Min über, um das anzusehen?

Konkret will ich erreichen, dass z.B. bei der zigbee2mqtt-Bridge ein Reading "permit_join" mit dem Wert "true" oder "false" auftaucht, statt eben "permit_join" ohne weitere Angabe in "state".
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

Zitat von: Beta-User am 11 Dezember 2018, 11:36:39
Klasse!

(war noch nicht fertig mit tippen zum shelly1, aber die Anmerkungen/Änderungen gelten entsprechend auch für die anderen templates).

Kannst du mal folgendes bitte testen:
# 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



Funktioniert.  :)
Jetzt legt er Shelly1 sauber an, mit Adresse und allem. Ich musste nur das Backslash hinter off ergänzen, da er sonst meckert.
So wie ich das sehe ist Beta-User der perfekte Mann um diese templates zu betreuen, oder?
Raspberry Pi 3 B+
MapleCUN
Shelly1, Shelly2, Shelly4pro, FS20