Shelly - MQTT: update für templates

[gestein]

Hallo,

ich habe mich in den letzten Tagen ein bisschen mit dem Thema Shellys und MQTT beschäftigt.
Dabei ist mir aufgefallen, dass die templates zwar toll sind, aber (1) inkonsistent und (2) nicht alle Werte darstellen bzw. abfragen.
Mit der neuen Firmware wurden auch neue Möglichkeiten eingeführt https://shelly-api-docs.shelly.cloud/#mqtt-support
Ich würde daher die Templates gerne überarbeiten und updaten.
Alleine kann ich das aber (noch) nicht. Und sehr wahrscheinlich übersehe ich auch etliches.
Daher würde ich vor einem Update der Templates diese Themen gerne diskutieren.

Meine Shellys sind über den internen MQTT2-Server (MQTT2_SERVER) eingebunden und daher als MQTT2_DEVICE in fhem.
Um den Shellys die Gesprächigkeit abzugewöhnen, habe ich folgenden Befehl benutzt (wie im wiki angegeben).

Code Auswählen Erweitern

http://<ip-des-shelly>/settings?mqtt_update_period=0
Damit scheinen die statischen Updates ausgeschaltet zu sein.

1) Um trotzdem die Announces und Infos einlesen zu können (sei es auch um die Readings neu anzulegen), würde ich vorschlagen, dass alle Shelly-templates zusätzlich 2 neue Kommandos (unter setList) bekommen:

Code Auswählen Erweitern

info:noArg shellies/DEVNAME/command info
announce:noArg shellies/DEVNAME/command announce
Prinzipiell kann man das natürlich auch mit einem mqttcom lösen, aber so ist es intuitiver.

Das führt zur nächsten Frage:
2) Wie sollen die Felder aus announce und info als Reading benannt werden?

Meistens wird folgendes verwendet z.B.:

Code Auswählen Erweitern

shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }
Damit bekommen die Readings die gleichen Namen.
Es gibt aber auch eine Variante in der die Readings den Namen mit dem Prefix "announce_" bzw. "info_" bekommen.
Was wäre besser?
Man hätte dann folgende Namen:

Code Auswählen Erweitern

announce_fw_ver 20201228-093009/v1.9.3@ad2bb4e3
announce_id shelly1pm-8CAAB5057256
announce_ip 192.168.0.71
announce_mac 8CAAB5057256
announce_model SHSW-PM
announce_new_fw false

Code Auswählen Erweitern

info_actions_stats_skipped 0
info_cfg_changed_cnt 2
info_cloud_connected false
info_cloud_enabled false
info_fs_free 143321
info_fs_size 233681
info_has_update false
info_inputs_1_event
info_inputs_1_event_cnt 0
info_inputs_1_input 0
info_mac 8CAAB5057256
info_meters_1_counters_1 0.000
info_meters_1_counters_2 0.000
info_meters_1_counters_3 0.000
info_meters_1_is_valid true
info_meters_1_overpower 0.00
info_meters_1_power 0.00
info_meters_1_timestamp 1609874314
info_meters_1_total 2854
info_mqtt_connected true
info_overtemperature false
info_ram_free 37696
info_ram_total 50288
info_relays_1_has_timer false
info_relays_1_ison false
info_relays_1_overpower false
info_relays_1_source input
info_relays_1_timer_duration 0
info_relays_1_timer_remaining 0
info_relays_1_timer_started 0
info_serial 4584
info_temperature 42.60
info_temperature_status Normal
info_time 19:18
info_tmp_is_valid true
info_tmp_tC 42.60
info_tmp_tF 108.69
info_unixtime 1609870714
info_update_has_update false
info_update_new_version 20201228-093009/v1.9.3@ad2bb4e3
info_update_old_version 20201228-093009/v1.9.3@ad2bb4e3
info_update_status idle
info_uptime 271374
info_wifi_sta_connected true
info_wifi_sta_ip 192.168.0.xx
info_wifi_sta_rssi -70
info_wifi_sta_ssid XYZXYZ

3) Neue Felder sollten eingefügt werden, soweit es nicht automatisch passiert.

4) Darstellung des defStateIcon:
Momentan werden die Icons bei etlichen Modellen mit der Glühbirne und links davor mit farblichen Punkten gekennzeichnet.
Diese Punkte haben aber je nach Modell unterschiedliche Bedeutung (bei den Schaltern bedeutet ein grüner Punkt "online", ein gelber "new firmware" und ein roter "offline"). Ein Klick auf den Punkt führt zur Webpage des Shelly. Bei den Dimmern bedeutet ein roter Punkt aber "loaderror".
Daher würde ich vorschlagen, das zu vereinheitlichen. Alle Shelly sollten die Punkte haben, mit der gleichen Bedeutung:
grüner Punkt "online", gelber "new firmware" und roter "offline"
Da die Shellys auch Fehler melden (z.B. loaderror und overtemperatur) hätte ich dafür 2 neue Icons, die den Zustand im defStateIcon darstellen (Vorschläge siehe Anhang).

Code Auswählen Erweitern

{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,"relays_1_overpower","true") eq "true"?"light_overload" : ReadingsVal($name,"overtemperatur","true") eq "true"?"light_overtemperatur" : ReadingsVal($name,"state","off");; my $cons = ReadingsVal($name,"relay_0_power","unknown");; my $temp = ReadingsVal($name,"temperature","-100");;"<div><a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> Aktuell: $cons W / Temp.: $temp °C</div>"}

Das gleiche könnte man auch für die Dimmer und die anderen Devices machen.
Bei mir laufen z.B. Dimmer auch mit "Color::devStateIcon".

5) Weiß jemand, wie man die Timer an den Shellys (z.B. Shelly 1pm) für ein "on-for-timer" über MQTT aktiviert?

Ich bin mir sicher, ich habe noch einiges übersehen oder nicht bedacht.
Bin gespannt auf Eure Meinungen.
lg, Gerhard

p.s.: Ist es gut einen neuen Thread zu beginnen oder sollte man das im Rahmen eines bereits bestehenden tun?

[Beta-User]

 

Vorab mal herzlichen Dank, dass du den Ball aufgegriffen hast und diesen Teil der attrTemplate-file nochmal von Grund auf durchleuchten möchtest!

Ich lese einfach mal mit, wenn konkrete Fragen zur Umsetzung sind, könnt ihr mich gerne direkt ansprechen, ansonsten möchte ich mich eigentlich eher zurückhalten .

Gutes Gelingen!