MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[OdfFhem]

Heute einige Tests mit dem ShellyPlus1PM durchgeführt und Folgendes festgestellt:

... MQTT2_CLIENT_general_bridge
    ... bridgeRegexp unterstützt noch nicht die neuen shellyp(lus|ro4pm)

... shellyPlus_1pm
    ... Firmware version 0.9.1
        - "Generic status update over MQTT" scheint notwendig
        - params-Readings werden nur sporadisch gesetzt ... temperature, voltage fast nie - ausser bei Schaltvorgängen
        - status/sys ändert Readings scheinbar nur beim Start des Geräts ... uptime und ähnliche Readings bislang sinnlos
        - status/switch_0 scheint momentan eine Schlüsselrolle einzunehmen, da nur dessen Readings ständig aktualisiert werden
        - jsonMap ... switch_aenergy_total existiert
          ... daher von params_switch_0_aenergy_total:aenergy_total auf switch_aenergy_total:aenergy_total ändern
        - devStateIcon nutzt Reading new_fw; dieses existiert aber nicht - überflüssig ?
    ... Firmware 0.9.2-beta2
        - erscheint aktuell unbrauchbar, da selbst die status/switch_0-Readings so gut wie nie aktualisiert werden
        - wieder zurück auf 0.9.1

[smoudo]

Ich denke wir machen in dem Thread weiter. Vielen Dank erstmal an @87insane , @OdfFhem und @Beta-User ! mir sind jetzt einige Sachen klarer.
Mein ShellyPlus_1pm ist auch angekommen und nr.1 verbaut. Mit dem neuen Template funktioniert das teil top! Allerdings nur mit aktiviertem Generic status update.

Das vorhandene Problemkind ShellyPlus_1 habe ich nochmal komplett gelöscht und neu anlegen lassen mit dem aktuellen Template. Für die Temperaturausgabe ist mir im jsonMap noch ein Fehler aufgefallen.
Das Reading vom Gerät heißt switch_temperature_tC. Anbei meine geänderte jsonMap zum testen.

Code Auswählen Erweitern

switch_state:state params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower switch_temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip
Allerdings aktualisiert sich der Shelly in FHEM nicht. Nur Restart oder Schaltvorgang setzt readings neu.
im ShellyPlus_1pm kommt jede Minute eine Aktualisierung. 

Kann man irgendwo in den Intervalleinstellungen eingreifen?

Noch eine verständnisfrage: sobald mit set attrTemplate ein Template gesetzt ist sollte das ganze laufen?! Muss das attr model weiterhin gesetzt werden?

Anbei noch das RAW vom Problemfall ShellyPlus_1

Code Auswählen Erweitern

defmod Strom_Strasse MQTT2_DEVICE shellyplus1_a8032abcdffc
attr Strom_Strasse 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 = FW_makeImage(ReadingsVal($name,'state','off'));; 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>Temp: $temp °C</div>)}
attr Strom_Strasse devicetopic shellyplus1-a8032abcdffc
attr Strom_Strasse event-on-change-reading .*
attr Strom_Strasse group Aussensteckdosen
attr Strom_Strasse icon message_socket
attr Strom_Strasse jsonMap switch_state:state params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower switch_temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip
attr Strom_Strasse model shellyPlus_1
attr Strom_Strasse 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:.* { $EVENT =~ s/"output":true/"state":"on"/g;; $EVENT =~ s/"output":false/"state":"off"/g;; json2nameValue($EVENT, 'switch_', $JSONMAP) }\
  fhem2shelly/rpc:.* {}
attr Strom_Strasse room Outdoor
attr Strom_Strasse setList toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Toggle","params": {"id":0}}\
  off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":false}}\
  on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true}}\
  on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Switch.Set","params": {"id":0,"on":true,"toggle_after":$EVTPART1}}\
  x_update:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Update","params": {"stage":"stable"}}\
  x_reboot:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Shelly.Reboot"}
attr Strom_Strasse setStateList on off toggle
attr Strom_Strasse webCmd : on:off

setstate Strom_Strasse off
setstate Strom_Strasse 2022-01-10 23:47:50 IODev MQTT2_FHEM_Server
setstate Strom_Strasse 2022-01-10 23:50:07 attrTemplateVersion 20220104
setstate Strom_Strasse 2022-01-11 00:05:40 dst shellyplus1-a8032abcdffc/events
setstate Strom_Strasse 2022-01-10 23:50:28 ip 192.168.1.50
setstate Strom_Strasse 2022-01-11 00:05:40 method NotifyStatus
setstate Strom_Strasse 2022-01-10 23:50:28 mqtt_connected true
setstate Strom_Strasse 2022-01-10 23:50:28 online true
setstate Strom_Strasse 2022-01-10 23:50:28 params_mqtt_connected true
setstate Strom_Strasse 2022-01-11 00:05:40 params_switch_0_id 0
setstate Strom_Strasse 2022-01-11 00:05:40 params_switch_0_output false
setstate Strom_Strasse 2022-01-11 00:05:40 params_switch_0_source MQTT
setstate Strom_Strasse 2022-01-10 23:50:38 params_sys_available_updates_beta_version 0.9.2-beta2
setstate Strom_Strasse 2022-01-11 00:05:40 params_ts 1641855941.17
setstate Strom_Strasse 2022-01-10 23:50:28 params_wifi_rssi -58
setstate Strom_Strasse 2022-01-10 23:50:28 params_wifi_ssid homenet 24
setstate Strom_Strasse 2022-01-10 23:50:28 params_wifi_status got ip
setstate Strom_Strasse 2022-01-11 00:05:40 src shellyplus1-a8032abcdffc
setstate Strom_Strasse 2022-01-11 00:05:40 state off
setstate Strom_Strasse 2022-01-11 00:05:40 switch_id 0
setstate Strom_Strasse 2022-01-11 00:05:40 switch_source MQTT
setstate Strom_Strasse 2022-01-10 23:51:42 switch_temperature_tC 45.5
setstate Strom_Strasse 2022-01-11 00:05:40 switch_temperature_tF 114.4
setstate Strom_Strasse 2022-01-10 23:50:38 sys_available_updates_beta_version 0.9.2-beta2
setstate Strom_Strasse 2022-01-10 23:50:38 sys_cfg_rev 45
setstate Strom_Strasse 2022-01-10 23:50:38 sys_fs_free 241664
setstate Strom_Strasse 2022-01-10 23:50:38 sys_fs_size 458752
setstate Strom_Strasse 2022-01-10 23:50:38 sys_mac A8032ABCDFFC
setstate Strom_Strasse 2022-01-10 23:50:38 sys_ram_free 180928
setstate Strom_Strasse 2022-01-10 23:50:38 sys_ram_size 249676
setstate Strom_Strasse 2022-01-10 23:50:38 sys_restart_required false
setstate Strom_Strasse 2022-01-10 23:50:38 sys_time 23:50
setstate Strom_Strasse 2022-01-10 23:50:38 sys_unixtime 1641855038
setstate Strom_Strasse 2022-01-10 23:50:38 sys_uptime 11
setstate Strom_Strasse 2022-01-11 00:05:40 temperature 45.8



viele Grüße

Matze

[seule3008]

Hallo an alle und ein Frohes neues Jahr wünsche ich euch.

Ich habe ein Problem und evtl hat einer von euch eine Lösung dafür. Es geht um das readingList im Shelly RGBW2 Weiß template. Ich würde gerne die readings des RGBW2 durch die eines Shelly 2.5 ersetzen. Wieso möchte ich das? Ich habe einen Shelly 2.5 der den Trafo schaltet hinter dem dann der RGBW2 angeschlossen ist. Beim Einschalten habe ich also beim 2.5 den state on und beim RGBW2 den state set_on bis er sich im Wlan angemeldet hat. Dann wechselt der state auf on. Beim Abschalten wiederum habe ich beim 2.5 den state off und beim RGBW2 den state set_off. Dieser wechselt allerdings nich auf off da der RGBW2 kein Strom mehr hat. Daraus ergibt sich das Problem, dass im HomeKit der RGBW2 auf on bleibt. Nun habe ich im RGBW2 die zweite Zeile des readingList, die ersten 2 Zeilen des SetList umgeschrieben und es gibt noch ein NOTIFY, dass die Schaltzustände abgleicht egal ob ich über den Taster, in Fhem oder im HomeKit schalte. Das on bzw off wird nun vom 2.5 genommen und angezeigt. Allerdings funktioniert das Dimmen jetzt nicht mehr. Es kommt immer set_brightness und weiter passiert nichts. Ich verstehe nicht ganz was der State mit dem dimmwert zu tun hat. Einen anderen Ansatz das Problem über das HomebridgeMapping zu lösen habe ich versucht aber set_off als off zu übergeben klappt scheinbar nicht.

Anbei noch ein List der Ansätze die nicht funktioniert haben:

HomebridgeMapping

Code Auswählen Erweitern

On=state,values=on:on;set_on:on;off:off;set_off:off,cmdOn=on,cmdOff=off
Brightness=brightness,cmd=brightness

HomebridgeMapping die 2.

Code Auswählen Erweitern

On=state,valueOn=/on|set_on/;ValueOff=/off|set_off/,cmdOn=on,cmdOff=off
Brightness=brightness,cmd=brightness

readingList

Code Auswählen Erweitern

shellies/shellyrgbw2-DE53C8/white/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}
  shellies/shellyswitch25-E8DB84ACE5FC/relay/0:.* state
  shellies/shellyrgbw2-DE53C8/white/0/set:.* { json2nameValue($EVENT) }
  shellies/shellyrgbw2-DE53C8/online:.* online
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-DE53C8...mac.*, ? json2nameValue($EVENT) : return }

setList

Code Auswählen Erweitern

off:noArg shellies/shellyswitch25-E8DB84ACE5FC/relay/1/command off
  on:noArg shellies/shellyswitch25-E8DB84ACE5FC/relay/1/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-DE53C8/white/0/set {"mode":"white","brightness":"$EVTPART1"}
brightness_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-DE53C8/white/0/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
  x_update:noArg shellies/shellyrgbw2-DE53C8/command update_fw
  x_mqttcom shellies/shellyrgbw2-DE53C8/command $EVTPART1

und ein List des ganzen Device

Code Auswählen Erweitern

Internals:
   CID        shellyrgbw2_DE53C8
   DEF        shellyrgbw2_DE53C8
   DEVICETOPIC Dimmer_Spitze
   FUUID      61dc11d1-f33f-b214-0112-5e6c07f3ae9b7543
   IODev      MQTT2
   LASTInputDev MQTT2
   MQTT2_MSGCNT 108
   MQTT2_TIME 2022-01-11 00:11:59
   MSGCNT     108
   NAME       Dimmer_Spitze
   NR         102
   STATE      set_off
   TYPE       MQTT2_DEVICE
   READINGS:
     2022-01-10 12:05:03   associatedWith  MQTT2_shellyrgbw2_DE53C8_CH2,MQTT2_shellyrgbw2_DE53C8_CH3,MQTT2_shellyrgbw2_DE53C8_CH4
     2022-01-10 12:05:02   attrTemplateVersion 20200531
     2022-01-11 00:10:19   brightness      69
     2022-01-11 00:10:19   has_timer       false
     2022-01-11 00:10:19   ison            true
     2022-01-11 00:10:19   mode            white
     2022-01-11 00:11:59   online          false
     2022-01-11 00:10:19   overpower       false
     2022-01-10 16:50:52   pct             47
     2022-01-11 00:10:19   power           9.83
     2022-01-11 00:10:19   source          mqtt
     2022-01-11 00:12:06   state           set_off
     2022-01-11 00:10:19   timer_duration  0
     2022-01-11 00:10:19   timer_remaining 0
     2022-01-11 00:10:19   timer_started   0
     2022-01-11 00:10:19   transition      0
     2022-01-10 12:05:03   x_mqttcom       set announce
Attributes:
   IODev      MQTT2
   autocreate 0
   comment    Channel 1 for MQTT2_shellyrgbw2_DE53C8, see also MQTT2_shellyrgbw2_DE53C8_CH2, MQTT2_shellyrgbw2_DE53C8_CH3 and MQTT2_shellyrgbw2_DE53C8_CH4
   genericDeviceType light
   group      Licht
   homebridgeMapping On=state,values=on:on;set_on:on;off:off;set_off:off,cmdOn=on,cmdOff=off
Brightness=brightness,cmd=brightness
   icon       light_control
   model      shelly2rgbw_4w_split
   readingList shellies/shellyrgbw2-DE53C8/white/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}
  shellies/shellyrgbw2-DE53C8/white/0:.* state
  shellies/shellyrgbw2-DE53C8/white/0/set:.* { json2nameValue($EVENT) }
  shellies/shellyrgbw2-DE53C8/online:.* online
  shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-DE53C8...mac.*, ? json2nameValue($EVENT) : return }
   room       Dachgeschoss,Homekit
   setList    off:noArg shellies/shellyswitch25-E8DB84ACE5FC/relay/1/command off
  on:noArg shellies/shellyswitch25-E8DB84ACE5FC/relay/1/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-DE53C8/white/0/set {"mode":"white","brightness":"$EVTPART1"}
brightness_on:colorpicker,BRI,0,1,100 shellies/shellyrgbw2-DE53C8/white/0/set {"ison":"true","mode":"white","brightness":"$EVTPART1"}
  x_update:noArg shellies/shellyrgbw2-DE53C8/command update_fw
  x_mqttcom shellies/shellyrgbw2-DE53C8/command $EVTPART1
   setStateList on off brightness
   webCmd     on:off:brightness

Ich hoffe das jemand sowas schonmal hatte. Ich denke ja nicht, dass das so ungewöhnlich ist den Trafo abzuschalten oder??

Vielen Dank im Voraus und viele Grüße

Christian

[OdfFhem]

Für die Temperaturausgabe ist mir im jsonMap noch ein Fehler aufgefallen ...

Code Auswählen Erweitern

switch_state:state params_switch_0_aenergy_total:aenergy_total params_switch_0_apower:apower switch_temperature_tC:temperature temperature_tF:0 params_wifi_sta_ip:ip

Hier gibt es (vermutlich) noch mehr Korrekturbedarf:
- "temperature_tF:0" müsste "switch_temperature_tF:0 " lauten; Deine RAW zeigt, dass das tF-Reading bislang weiterhin aktualisiert wird
- apower bzw. aenergy_total gibt es mangels Leistungsmessung beim reinen 1er nicht (s.a. RAW) und sollte entfernt werden

Kann man irgendwo in den Intervalleinstellungen eingreifen?

Scheint aktuell noch nicht möglich, kommt aber vielleicht noch ...
Bei meiner Analyse der 1pm-Variante änderte sich relativ oft das temperature- bzw. voltage-Reading; weiterhin aber auf jeden Fall jede Minute mindestens ein ts-Reading (z.B. params_ts). Ich hatte bei mir deshalb die ts-Readings via jsonMap-Attribut geerdet; erscheinen auf den ersten Blick doch ähnlich nutzlos wie die tF-Readings. So wirkt die "Flut" der FHEM-Events etwas erträglicher ...

[smoudo]

Das ist korrekt. Um das Tf mapping habe ich mich erstmal nicht gekümmert, da nicht in Benutzung. Muss der vollständigkeit halber noch getan werden.
Nichts destotrotz wird Kein Reading ohne Schalthandlung aktualisiert. Das heißt da steht bis zum nächsten Zeitschaltpunkt alles auf Readingtime 2022-01-11 00:05:40.
Beim Shellyplus_1pm bekomme ich jede volle Minute eine Aktualisierung von div. Readings.

[Beta-User]

Ich habe ein Problem und evtl hat einer von euch eine Lösung dafür. Es geht um das readingList im Shelly RGBW2 Weiß template.

Hmm, würde vorschlagen, für dieses etwas spezielle Thema einen eigenen Thread zu starten, das ist kein Konfigurationsthema im engeren Sinne. Tendenziell würde ich das nur "one-way" via notify lösen und das state -reading im "off"-Fall übertragen, sonst nicht.

Das mit set_brightness kommt daher, dass du das in setStateList aufgenommen hast, im attrTemplate "shelly2rgbw_4w_split" steht da (aus gutem Grund, wie ich meine) nur on und off...

Nichts destotrotz wird Kein Reading ohne Schalthandlung aktualisiert. Das heißt da steht bis zum nächsten Zeitschaltpunkt alles auf Readingtime 2022-01-11 00:05:40.
Beim Shellyplus_1pm bekomme ich jede volle Minute eine Aktualisierung von div. Readings.

MAn. ist das doch super: der "normale" 1-er kann eigentlich nur on/off, und die Temperatur ist eh "für den Arsch", weil intern gemessen. Da sollte auch nach meinem Gefühl nur eine Aktualisierung kommen, wenn sich was ändert (das mit den ständigen unnötigen updates war an den alten schlecht!).
Beim 1pm wird gemessen, also regelmäßige updates. Da stellt sich dann nur die Frage, was wann in FHEM zu aktualisieren ist, also wie ggf. eocr&Co. (v.a. für "state") zu setzen sind .

Eure Vorschläge (auch zum M2C-bridgeRegexp-Ding) sollten mit dem heutigen update eigentlich soweit eingearbeitet sein. DANKE, dass da jetzt (endlich) konstruktive Bewegung reinkommt .


Nachdem sich in letzter Zeit wieder die Beiträge gehäuft haben, bei denen diverse Leute mit meinen Anregungen überfordert gewesen zu sein scheinen, habe ich mal einen Wiki-Artikel angefangen zur Frage, wie man eigentlich vorgehen sollte, wenn man sich einem "unbekannten MQTT-Gerät" nähert: https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt

Wer dazu konstruktive Anmerkungen hat, darf gerne mit drin rumbasteln und/oder Fragen im Wiki-Bereich des Forums loswerden.

[smoudo]

Ansich hast du recht, eine Logik im Gerät, auch gerade mit den wechselnden Readings kann ich nicht immer erkennen. Und wenn man zum Schluss nicht 100% weiß wie sich das Gerät verhält, wird am Template ewig rumgebastelt. Gibt es von Seiten Shelly irgendeine offizielle readinglist o.ä. Welche man bemühen kann?
Ansonsten ist das anstrengend. Ich werde nachher das Teil mal vom Strom nehmen um zu schauen ob die online/offline bzw. Present/absent Funktion geht. Das bezweifle ich nämlich stark wenn das Teil sich nicht meldet.

[Beta-User]

Gibt es von Seiten Shelly irgendeine offizielle readinglist o.ä. Welche man bemühen kann?

Es gibt die offiziellen API-Beschreibungen, mit denen kann man sich das eine oder andere zusammenpuzzeln, wenn man etwas Übung oder Phantasie hat...

Ansonsten ist das anstrengend. Ich werde nachher das Teil mal vom Strom nehmen um zu schauen ob die online/offline bzw. Present/absent Funktion geht. Das bezweifle ich nämlich stark wenn das Teil sich nicht meldet.

Ist eine "LWT"-Funktionalität, und die wird vom MQTT-Server überwacht. Wenn also überhaupt irgendeine online-Meldung mal ankam, geht das Ding auch offline...

[smoudo]

Online/offline Anzeige funktioniert.
Temperatur ist so ziemlich nutzlos.
Ich finde Temperaturwerte garnicht so doof, die könnte man überwachen lassen das die Teile nicht abfackeln.

[seule3008]

Hmm, würde vorschlagen, für dieses etwas spezielle Thema einen eigenen Thread zu starten, das ist kein Konfigurationsthema im engeren Sinne. Tendenziell würde ich das nur "one-way" via notify lösen und das state -reading im "off"-Fall übertragen, sonst nicht.

Das mit set_brightness kommt daher, dass du das in setStateList aufgenommen hast, im attrTemplate "shelly2rgbw_4w_split" steht da (aus gutem Grund, wie ich meine) nur on und off...
MAn. ist das doch super: der "normale" 1-er kann eigentlich nur on/off, und die Temperatur ist eh "für den Arsch", weil intern gemessen. Da sollte auch nach meinem Gefühl nur eine Aktualisierung kommen, wenn sich was ändert (das mit den ständigen unnötigen updates war an den alten schlecht!).
Beim 1pm wird gemessen, also regelmäßige updates. Da stellt sich dann nur die Frage, was wann in FHEM zu aktualisieren ist, also wie ggf. eocr&Co. (v.a. für "state") zu setzen sind .

Eure Vorschläge (auch zum M2C-bridgeRegexp-Ding) sollten mit dem heutigen update eigentlich soweit eingearbeitet sein. DANKE, dass da jetzt (endlich) konstruktive Bewegung reinkommt .


Nachdem sich in letzter Zeit wieder die Beiträge gehäuft haben, bei denen diverse Leute mit meinen Anregungen überfordert gewesen zu sein scheinen, habe ich mal einen Wiki-Artikel angefangen zur Frage, wie man eigentlich vorgehen sollte, wenn man sich einem "unbekannten MQTT-Gerät" nähert: https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt

Wer dazu konstruktive Anmerkungen hat, darf gerne mit drin rumbasteln und/oder Fragen im Wiki-Bereich des Forums loswerden.

Hallo Beta-User

Wenn ich beide Brightness Zeilen entferne, kann ich nicht mehr dimmen. Allerdings, wenn ich nur die Zeile brightness_on lösche, kommt auch set_brightness aber es verschwindet nach maximal 30sec, wenn das reading vom Shelly zurück kommt. Aber damit kann ich leben, denn im HomeKit funktioniert alles perfekt.

Vielen Dank für den Tip.

Ich begebe mich jetzt mal an das Notify von dir und versuche es von 2 auf 3 Device  umzuschreiben. Mal sehen ob ich das hinbekomme die Schaltzustände abzugleichen.

Grüße

Christian

[OdfFhem]

Aktuelle Beobachtungen beim Einsatz von ShellyPlus1PM:

... Template shellyPlus_1
    ... analog zu on-for-timer nutze ich derzeit auch off-for-timer
        ... Gerät wird mit Ausführung sofort ausgeschaltet (sofern nicht sowieso schon aus)
        ... Gerät wird nach der angegebenen Anzahl Sekunden autom. "umgeschaltet"
        ... mögliche Ergänzung von setList

Code Auswählen Erweitern


off-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params": {"id":0,"on":false,"toggle_after":$EVTPART1}}\

... Template shellyPlus_1pm
    ... keine neuen Vorschläge

... Firmware version 0.9.2
    ... offiziell verfügbar seit 14.01.2022
    ... die Anzahl der MQTT-Aktualisierungen ist stark zurückgegangen
        ... falls eingeschaltet, finden (erwartungsgemäß) regelmäßige Aktualisierungen statt
        ... falls ausgeschaltet, gilt: es muss etwas ausgelöst werden, ansonsten herrscht Funkstille
    ... es gibt jetzt auch einen zunächst experimentellen "Economy mode" (betamäßig auch für die alten Shellies)
        ... wird dieser aktiviert, wird der Shelly im "low-power mode" betrieben
        ... dadurch kann/soll dann z.B. die (meist hohe) Betriebstemperatur im eingeschalteten Zustand um bis zu 15° sinken
        ... kann nur indirekt aktiviert/deaktiviert werden (u.a. nicht über Oberfläche) ... vermutlich ein Feature für setList - interessant ?

[Beta-User]

off-for-timer sollte mit allen 2.gen-Shelly funktionieren, hab's (überall&korrekt?) eingebaut.

Den reduzierten Traffic finde ich jedenfalls vom Ansatz her gut - mal schauen, wie die allgemeine Resonanz dazu ist.

Was den low-power-Modus angeht: Prinzipiell finde ich es gut, wenn man als Anwender nicht zu sehr frickeln muss, um sinnvolle Dinge umzusetzen. Da es vermutlich frickelig ist, stellt sich eigentlich nur die Frage, ob es sinnvoll ist bzw. welche Nebenwirkungen das ggf. hat...? Warte daher mal auf Rückmeldungen dazu, es wäre aber nicht verkehrt, wenn die MQTT-Kommandos dazu bekannt wären, dann kann man es ggf. auch einfach in comment/das Wiki, ... übernehmen oä..

[OdfFhem]

Aktuelle Beobachtungen beim Einsatz von ShellyPlus1PM:

... Template shellyPlus_1pm
    ... vorhandenes MQTT2-Device komplett gelöscht
    ... Anwendung von Version 20220114 bzw. eigentlich 20220115 wegen integriertem shellyPlus_1-Template
    ... funktioniert grundsätzlich wie vorgesehen - soweit getestet
    ...
    ... nachdem ich über FHEM geschaltet hatte, fiel mir im Attribut readingList neben "fhem2shelly/rpc:.* {}" auch "shellies/testSwitch2/rpc:.* { json2nameValue($EVENT) }" auf
        ... folglich könnte/sollte noch "$\DEVICETOPIC/rpc:.* {}" unterstützt werden
    ... Attribut devStateIcon habe ich bzgl. aenergy_total von 1 auf 3 Nachkommastellen erweitert
        ... sonst sieht man sehr lange Zeit nur 0.0 - hängt halt nur ein Klein(st)verbraucher dran

... low-power-mode
    ... ein möglicher Eintrag für setList wäre
        x_eco:true,false $\DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
    ... als Reaktion wird u.a. das sys-Subtopic generiert und teilt mit, dass ein reboot notwendig ist
        ... entspricht dem Attribut sys_restart_required
        ... sollte man (vielleicht sogar generell) beachten und dementsprechend im Attribut devStateIcon integrieren

[Beta-User]

Anmerkungen (ist immer schwierig, wenn man die Interaktion mit dem Device nicht hat):

    ... nachdem ich über FHEM geschaltet hatte, fiel mir im Attribut readingList neben "fhem2shelly/rpc:.* {}" auch "shellies/testSwitch2/rpc:.* { json2nameValue($EVENT) }" auf

...stellt sich die Frage, ob das nicht eine prinzipielle Änderung in 0.9.2 in Richtung auf das hin ist, was bei 4er schon der Fall war: automatische Updates, ohne dass man den "generic update" aktivieren muss. Anders gesagt: ich vermute, dass man eigentlich eher den bisher genutzten Topic stillegen sollte und nur noch diesen rpc hier verwenden? (Code analog 4-er, erste Kanal)

    ... Attribut devStateIcon habe ich bzgl. aenergy_total von 1 auf 3 Nachkommastellen erweitert
        ... sonst sieht man sehr lange Zeit nur 0.0 - hängt halt nur ein Klein(st)verbraucher dran

...was auch immer ein für alle sinnvoller Wert sein mag wird eingebaut. Hatte das aus den alten Shelly übertragen (?).

... low-power-mode
    ... ein möglicher Eintrag für setList wäre
        x_eco:true,false $\DEVICETOPIC/rpc {"id":0,"src":"fhem2shelly","method":"Sys.SetConfig","params": {"config": {"device": {"eco_mode": $EVTPART1}}}}
    ... als Reaktion wird u.a. das sys-Subtopic generiert und teilt mit, dass ein reboot notwendig ist
        ... entspricht dem Attribut sys_restart_required
        ... sollte man (vielleicht sogar generell) beachten und dementsprechend im Attribut devStateIcon integrieren

Stellt sich die Frage, ob man die reboot-Anweisung nicht generell hinterherschieben sollte? Müßt man halt dann in Perl notieren, aber tragisch wäre das nicht, jedenfalls einfacher, als devStateIcon anzupassen...

[OdfFhem]

...stellt sich die Frage, ob das nicht eine prinzipielle Änderung in 0.9.2 in Richtung auf das hin ist, was bei 4er schon der Fall war: automatische Updates, ohne dass man den "generic update" aktivieren muss. Anders gesagt: ich vermute, dass man eigentlich eher den bisher genutzten Topic stillegen sollte und nur noch diesen rpc hier verwenden? (Code analog 4-er, erste Kanal)

Hat definitiv nichts mit der Firmware-Änderung zu tun. Ich hatte jetzt noch einmal genauer geschaut und hängt wohl mit den gepflegten MQTT-Parametern zusammen. Von Anfang an (vor ca. 2 Monaten) hatte mein Attribut devicetopic schon den Wert "shellies/testSwitch2"; auch in meiner ersten readingList stand schon besagtes rpc-Topic.

Stellt sich die Frage, ob man die reboot-Anweisung nicht generell hinterherschieben sollte? Müßt man halt dann in Perl notieren, aber tragisch wäre das nicht, jedenfalls einfacher, als devStateIcon anzupassen...

Ich überlege gerade, wie hinterschieben funktionieren könnte ... denn die eigentliche Aktion muss ja definitiv erst einmal abgeschlossen sein ... also wäre der offensichtlichste Weg, dass man auf die Änderung von Reading sys_restart_required reagiert ... notify oder so ähnlich oder ...