FHEM - Hausautomations-Systeme > MQTT

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

<< < (6/7) > >>

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:

--- Code: ---{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>" }

--- Ende Code ---

devStateIcon  Definition für Shelly Plus 1PM:

--- Code: ---{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>"}

--- Ende Code ---

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


--- Code: ---###########################################
# 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
--- Ende Code ---

Merkzettel für mich selbst: evtl. kann auch hashKeyRename() weiterhelfen.

Otto123:
Mir sticht im ersten Wurf diese Zeile ins Auge ;)

--- Zitat ---on-for-timer shellies/light_bath_cabinet/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}\
--- Ende 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?

Beta-User:

--- Zitat von: Otto123 am 03 Januar 2022, 07:48:42 ---Mir sticht im ersten Wurf diese Zeile ins Auge ;)

--- Ende Zitat ---
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?

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

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

--- Ende Zitat ---

Vermutlich wäre alles etwas einfacher, wenn man die Hardware hätte, aber mein Impuls ist einfach: Bäh...

Otto123:

--- Zitat ---Scheinbar muss da "irgendwas" hin, und zu allem Überfluss bekommt man diesen Mist auch direkt wieder zurück...
--- Ende Zitat ---
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 ;)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln