gelöst: MQTT Befehle für Shelly Plus 1PM

Begonnen von romakrau, 19 November 2021, 18:02:29

Vorheriges Thema - Nächstes Thema

TomLee

#15
ReadingList nicht setList

ZitatreadingList shellyplus1pm_a8032abe179c:shellyplus1pm-a8032abe179c/online:.* online
shellyplus1pm_a8032abe179c:shellies/shellyplus1pm-a8032abe179c/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }
shellyplus1pm_a8032abe179c:shellies/shellyplus1pm-a8032abe179c/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
shellyplus1pm_a8032abe179c:shellies/shellyplus1pm-a8032abe179c/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }
shellyplus1pm_a8032abe179c:shellies/shellyplus1pm-a8032abe179c/status/switch_0:.* { json2nameValue($EVENT, 'switch_0_', $JSONMAP) }

romakrau

Hier noch mal das aktuelle list ohne Nutzung eines templates:

Internals:
   CFGFN     
   CID        shellyplus1pm_a8032abe179c
   DEF        shellyplus1pm_a8032abe179c
   DEVICETOPIC MQTT2_shellyplus1pm_a8032abe179c
   FUUID      619817e8-f33f-e93f-72e5-f09ec1cca830d1ce
   IODev      myBroker
   LASTInputDev myBroker
   MSGCNT     63
   NAME       MQTT2_shellyplus1pm_a8032abe179c
   NR         290
   STATE      off
   TYPE       MQTT2_DEVICE
   myBroker_MSGCNT 63
   myBroker_TIME 2021-11-19 22:52:02
   READINGS:
     2021-11-19 22:32:24   IODev           myBroker
     2021-11-19 22:32:24   mqtt_connected  true
     2021-11-19 22:32:24   online          true
     2021-11-19 22:52:02   rpc_dst         shellyplus1pm-a8032abe179c/events
     2021-11-19 22:52:02   rpc_method      NotifyStatus
     2021-11-19 22:32:24   rpc_params_mqtt_connected true
     2021-11-19 22:52:02   rpc_params_switch_0_aenergy_by_minute_1 0.000
     2021-11-19 22:52:02   rpc_params_switch_0_aenergy_by_minute_2 0.000
     2021-11-19 22:52:02   rpc_params_switch_0_aenergy_by_minute_3 0.000
     2021-11-19 22:52:02   rpc_params_switch_0_aenergy_minute_ts 1637358719
     2021-11-19 22:52:02   rpc_params_switch_0_aenergy_total 271.561
     2021-11-19 22:50:04   rpc_params_switch_0_apower 0
     2021-11-19 22:52:02   rpc_params_switch_0_id 0
     2021-11-19 22:50:06   rpc_params_switch_0_output true
     2021-11-19 22:50:06   rpc_params_switch_0_source WS_in
     2021-11-19 22:52:02   rpc_params_ts   1637358721.70
     2021-11-19 22:52:02   rpc_src         shellyplus1pm-a8032abe179c
     2021-11-19 22:48:05   state           off
     2021-11-19 22:52:01   switch_0_aenergy_by_minute_1 0.000
     2021-11-19 22:52:01   switch_0_aenergy_by_minute_2 0.000
     2021-11-19 22:52:01   switch_0_aenergy_by_minute_3 0.000
     2021-11-19 22:52:01   switch_0_aenergy_minute_ts 1637358719
     2021-11-19 22:52:01   switch_0_aenergy_total 271.561
     2021-11-19 22:52:01   switch_0_apower 0.000
     2021-11-19 22:52:01   switch_0_id     0
     2021-11-19 22:52:01   switch_0_output true
     2021-11-19 22:52:01   switch_0_source WS_in
     2021-11-19 22:52:01   switch_0_temperature_tC 52.3
     2021-11-19 22:52:01   switch_0_temperature_tF 126.2
     2021-11-19 22:52:01   switch_0_voltage 240.668
Attributes:
   readingList shellyplus1pm_a8032abe179c:shellyplus1pm-a8032abe179c/online:.* online
shellyplus1pm_a8032abe179c:shellyplus1pm-a8032abe179c/events/rpc:.* { json2nameValue($EVENT, 'rpc_', $JSONMAP) }
shellyplus1pm_a8032abe179c:shellyplus1pm-a8032abe179c/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }
shellyplus1pm_a8032abe179c:shellyplus1pm-a8032abe179c/status/switch_0:.* { json2nameValue($EVENT, 'switch_0_', $JSONMAP) }
   room       MQTT2_DEVICE
   setList    off shellies/shellyplus1pm_a8032abe179c/relay/0/command off

TomLee


romakrau

Hallo Tom,
die readings werden gemäß der readinglist eingelesen (siehe list). Es geht um das Schalten !
GrußRoman

romakrau

Hallo Tom,
ich muss Abbitte leisten. Nachdem ich das template file gelesen habe glaube ich zu wissen was du mit den .*shellies.* meinst. Es bezieht sich auf den Filter zur Auflistung der gefilterten Templates. Werde Morgen weitermachen.
Gruß Roman

TomLee

Genau.

Was ich eben hatte war, das ich ein update eines Shelly 1 machte und gar nichts mehr danach per MQTT ging, erst ein Neustart des Shelly hat Abhilfe geschafft.
Hast du schonmal zwischendurch rebooted ?

Beta-User

Die API für die neuen Shelly ist anders, da muss man erst mal noch vieles zu Fuß machen.

Hotfix für's erste: https://forum.fhem.de/index.php/topic,123980.msg1185403.html#msg1185403
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

romakrau

Dank Euch beiden. Hat mir sehr geholfen.
Gruß
Roman

romakrau

Nachtrag: In meinem Fall braucht das altbekannte shellies nicht verwendet zu werden :

off trockner/rpc {"id":0, "src":"trockner/status", "method":"Switch.Set", "params":{"id":0,"on":false}}
on  trockner/rpc {"id":0, "src":"trockner/status", "method":"Switch.Set", "params":{"id":0,"on":true}}


Reicht vollkommen zum Schalten.

limes1337

#24
Hallo zusammen,

wie schon geschrieben wurde hat sich die MQTT Topic Struktur bei den neuen Shellies (meines Wissens bisher Shelly Plus Modelle und Shelly Pro 4PM) wesentlich geändert. U.a. für die Set Befehle werden die Methodenaufrufe nun nicht mehr als MQTT Topic(-struktur) übergeben sondern als Payload. Die Grundlage der Dokumentation sind dafür die RPC Befehle aus der Shelly Gen2 Device API. Damit funktionieren die bisher vorhandenen Shelly MQTT Templates nicht bzw. nur teilweise. Dafür sind die Steuermöglichkeiten über MQTT aber deutlich umfangreicher geworden.

Für die Set Befehle lautet die Topic Adressierung grundsätzlich <shelly-device>/rpc + payload
<shelly-device> ist dabei davon abhängig was ihr in der MQTT Definition des Shellies angegeben habt. Nachfolgend das Beispiel von einem Shelly Plus 1, der bei mir die Lichter in einem Badezimmerschrank steuert.

Die MQTT Definition des Shellies findet ihr im beigefügten Screenshot.

Die passenden Befehle aus der Set List lauten dann wie folgt. Neben Toggle, On, Off, Update habe ich mal noch einen Reboot und einen On-for-Timer eingefügt. Letzteres wird meines Wissen so nativ von den Gen1 Shellies per MQTT nicht unterstützt (den on-for-timer gibt es zwar in FHEM auch bei den bisherigen Shellies, der Timer wird hier aber von FHEM verwaltet - in der neuen Variante direkt im Shelly).


toggle:noArg shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Switch.Toggle","params": {"id":0}}
  off:noArg shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":false}}
  on:noArg shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":true}}
  on-for-timer shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}
  x_update:noArg shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Shelly.Update","params": {"stage":"stable"}}
  x_reboot:noArg shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Shelly.Reboot"}


Faktisch kann man noch sehr viel mehr Set Befehle ergänzen und die Readings müssen auch noch besser ausgewertet werden. Aus meiner Sicht macht es Sinn dafür ein eigenes Template zu erstellen. Sofern ich dazu komme, werde ich es gerne mit Euch teilen.

Grüße,
limes




limes1337

Ergänzend zum vorhergehenden Eintrag habe ich auf Grundlage von den MQTT shelly1 und shelly1_w_energy_measuring Templates, die devStateIcon Definition für Shelly Plus 1 und Shelly Plus 1PM überarbeitet.
Ich habe bisher nichts an der ReadingList Definition überarbeitet - die Grundlage ist also die ReadingsList aus dem jeweiligen Template + das was die Shelly Plus Devices zusätzlich per MQTT senden.

devStateIcon  Definition für Shelly Plus 1:

{my $onl = ReadingsVal($name,"online","false") eq "false" ? "rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "gelb" : "gruen"; my $light = ReadingsVal($name,"state","off"); my $show = '<a href="';$show .= $onl eq "gelb" ? "/fhem?cmd.dummy=set $name x_update&XHR=1\">" : "http://".ReadingsVal($name,"ip","none").' "target="_blank">'; $show .= FW_makeImage("10px-kreis-".$onl)."</a>"; "<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a></div>" }


devStateIcon  Definition für Shelly Plus 1PM:

{my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ?
"10px-kreis-gelb" : "10px-kreis-gruen";
my $light = ReadingsVal($name,"output","false") eq "false"?"off" : "on";
my $cons = ReadingsVal($name,"params_switch_0_apower","unknown");
my $total = ReadingsVal($name,"params_switch_0_aenergy_total","unknown") eq "unknown"?"unknown" : round(ReadingsVal($name,"params_switch_0_aenergy_total","unknown")/1000,1);
my $temp = ReadingsVal($name,"temperature_tC","-100");
"<a href=\"http://".ReadingsVal($name,"params_wifi_sta_ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a>
<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a>
<div>Verbrauch: $cons W / Total: $total kwh / Temp: $temp °C</div>"}

Beta-User

Irgendwie gibt es jetzt an verschiedenen Stellen diverse "Häppchen", aber das sinnstiftend zusammenzubasteln, ist irgendwie schwierig.

Hier mal ein erster Wurf zum Thema als Diskussionsgrundlage, mit "ein bißchen von hier und ein bißchen von da".

Irgendwie werde ich den Verdacht nicht los, dass man da manches noch streamlinen kann und sollte, v.a. wg. dieses "true"=>"on"-Themas, aber dazu fehlt irgendwie auch etwas "Futter" (also der vollst. MQTT-Verkehr für diverse Fälle)...

###########################################
# SHELLY plus section
#
# shelly devices using the V2 MQTT API https://shelly-api-docs.shelly.cloud/gen2/Overview/RPCChannels#mqtt
# Shelly Plus 1PM using original firmware.
name:shellyPlus_1pm
filter:TYPE=MQTT2_DEVICE
par:DEV_TOPIC;Shelly name in the topic;{ AttrVal('DEVICE','devicetopic',AttrVal('DEVICE','readingList','')) =~ m<(shellies/[^/]+/|shellyplus[^/:_]{4,}+)> ? $1 : undef }
par:CALLSPEECHRECOGN;Set this to 0 to not set any speech recogn. related attributes;{ 1 }
order:A_20
par:ICON;ICON as set, defaults to message_socket;{ AttrVal('DEVICE','icon','message_socket') }
deletereading -q DEVICE (?!associatedWith|IODev).*
attr DEVICE icon ICON
attr DEVICE devicetopic DEV_TOPIC
attr DEVICE setList\
  toggle:noArg $\DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Toggle","params": {"id":0}}\
  off:noArg $\DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":false}}\
  on:noArg $\DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":true}}\
  on-for-timer shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}\
  x_update:noArg $\DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Shelly.Update","params": {"stage":"stable"}}\
  x_reboot:noArg $\DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Shelly.Reboot"}
attr DEVICE readingList $\DEVICETOPIC/online:.* online\
  $\DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  $\DEVICETOPIC/status/mqtt:.* { json2nameValue($EVENT, 'mqtt_', $JSONMAP) }\
  $\DEVICETOPIC/status/sys:.* { json2nameValue($EVENT, 'sys_', $JSONMAP) }\
  $\DEVICETOPIC/status/switch_0:.* { json2nameValue($EVENT, 'switch_0_', $JSONMAP) }
attr DEVICE devStateIcon {my $onl = ReadingsVal($name,'online','false') eq 'false'?'10px-kreis-rot': ReadingsVal($name,'new_fw','false') eq 'true' ? '10px-kreis-gelb' : '10px-kreis-gruen'; $onl = FW_makeImage($onl); my $light = ReadingsVal($name,'output','false') =~ m{false|off}?'off':'on'; $light = FW_makeImage($light); my $cons = ReadingsNum($name,'apower',0); my $total = round(ReadingsNum($name,'aenergy_total',0)/1000,1); my $temp = ReadingsVal($name,'temperature','-100'); my $ip = ReadingsVal($name,'ip','none'); qq(<a href="http://$ip"target="_blank">${onl}</a><a href="/fhem?cmd.dummy=set $name toggle&XHR=1">${light}</a><div>Verbrauch: $cons W / Total: $total kwh / Temp: $temp °C</div>)}
attr DEVICE jsonMap params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip
attr DEVICE model shellyPlus_1pm
setreading DEVICE attrTemplateVersion 20211122
option:{ CALLSPEECHRECOGN }
set DEVICE attrTemplate speechcontrol_type_switch


Merkzettel für mich selbst: evtl. kann auch hashKeyRename() weiterhelfen.
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

Otto123

Mir sticht im ersten Wurf diese Zeile ins Auge ;)
Zitaton-for-timer shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}\

Mich irritiert ja in der API der RPC Begriff - der macht in meinem Kopf immer was unangenehmes - aber scheinbar ist das hier einfach ein einheitlicher json String der "egal" über welchen Weg (MQTT HTTP) wirkt?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: Otto123 am 03 Januar 2022, 07:48:42
Mir sticht im ersten Wurf diese Zeile ins Auge ;)
Der "erste Wurf" wurde zwischenzeitlich überarbeitet, wir sollten also daher über den aktuellen attrTemplate-Satz diskutieren. Dazu gehören aktuell zwei templates...

Zitat
Mich irritiert ja in der API der RPC Begriff - der macht in meinem Kopf immer was unangenehmes - aber scheinbar ist das hier einfach ein einheitlicher json String der "egal" über welchen Weg (MQTT HTTP) wirkt?
Die Art und Weise, wie die "plus"-Shelly "ticken", ist unangenehm, ich hätte sofort den Impuls, die firmware runterzuwerfen...

Aber ja, das Interface scheint einheitlich zu sein, und die korrekte Antwort auf
Zitat von: Otto123 am 03 Januar 2022, 07:57:59
muss da noch sowas davor "id":0, "src":"trockner/status", - da ist mir der benötigte Inhalt von src nicht klar. Das sieht in den Beispielen für mich bisher wie "egal" aus.
kenne ich auch noch nicht. Scheinbar muss da "irgendwas" hin, und zu allem Überfluss bekommt man diesen Mist auch direkt wieder zurück...
Zitat von: Beta-User am 27 Dezember 2021, 06:44:42
Weiß nicht recht, das ist unschön, v.a., weil das "unendlich" ist: mqttexplorer/rpc
Mein Eindruck ist weiter, dass das nicht richtig durchdacht ist.

Im Moment neige ich eher dazu, den "fhem"-Zweig mit einem leeren Perl ins Nirvana zu schicken bzw. ggf. fhem2shelly daraus zu machen, damit man das direkt mit einer ignoreRegexp am IO rausfiltern kann. Wenn man den originalen Topic nehmen würde, hat man eine Doppelung von Senden und Empfangen auf demselben Topic, und das geht gefühlt gar nicht.

Vermutlich wäre alles etwas einfacher, wenn man die Hardware hätte, aber mein Impuls ist einfach: Bäh...
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

Otto123

ZitatScheinbar muss da "irgendwas" hin, und zu allem Überfluss bekommt man diesen Mist auch direkt wieder zurück...
Oder es muss nur dahin wenn man etwas zurück haben will?
Versteh ich zumindest hier so: https://shelly-api-docs.shelly.cloud/gen2/Overview/RPCChannels/#mqtt

Ich meine die Hardware: ein vierfach Relais für die Hutschiene mit Ethernet Anschluss - liest sich nicht schlecht ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz