Shelly: zusätzliche Felder abrufen (und schreiben?)

[gestein]

Hallo,

Es ist ja mittlerweile wirklich toll, wie einfach man die Shellys mittels MQTT und den templates in fhem einbinden kann.
Funktioniert auch wirklich wunderbar.

Die Shellys stellen aber viel mehr Parameter für Einstellungen zur Verfügung als in den Devices angezeigt werden.
Alleine im Reiter "Settings" gibt es Einstellungen zu "POWER ON DEFAULT MODE", "BUTTON TYPE", "DEVICE NAME" etc.

Wäre es möglich diese ebenfalls im Device als Readings anzulegen?

Und wäre es möglich in diese Felder am Shelly auch zu schreiben?
Dann hätte ich in fhem eine schöne Übersicht, was alles eingestellt ist.
Und dann müßte ich nicht jedesmal die Webseite des Shelly aufrufen um da was zu ändern bzw. nachzuschauen.

Und in weiterer Ferne wäre vielleicht ein Backup/Restore möglich oder Standardkonfigurationen ...

Danke für jeden Tipp, denn in JSON bin ich absolut kein Wissender (merkt man wahrscheinlich schon an den Fragen ).
lg, Gerhard

[Beta-User]

Hallo,

Es ist ja mittlerweile wirklich toll, wie einfach man die Shellys mittels MQTT und den templates in fhem einbinden kann.
Funktioniert auch wirklich wunderbar.

Die Shellys stellen aber viel mehr Parameter für Einstellungen zur Verfügung als in den Devices angezeigt werden.
Alleine im Reiter "Settings" gibt es Einstellungen zu "POWER ON DEFAULT MODE", "BUTTON TYPE", "DEVICE NAME" etc.

Wäre es möglich diese ebenfalls im Device als Readings anzulegen?

Und wäre es möglich in diese Felder am Shelly auch zu schreiben?
Dann hätte ich in fhem eine schöne Übersicht, was alles eingestellt ist.
Und dann müßte ich nicht jedesmal die Webseite des Shelly aufrufen um da was zu ändern bzw. nachzuschauen.

Und in weiterer Ferne wäre vielleicht ein Backup/Restore möglich oder Standardkonfigurationen ...

Danke für jeden Tipp, denn in JSON bin ich absolut kein Wissender (merkt man wahrscheinlich schon an den Fragen ).
lg, Gerhard

Vorab mal danke für das feedback .

Was die ganzen Fragen angeht: Ist das jetzt MQTT-spezifisch? Dann verschiebe den Thread (und den anderen...) dann doch in den MQTT-Bereich.

Ansonsten baue ich gerne in die attrTemplate ein, was darüber ggf. an Konfiguration via MQTT geht. Allerdings sind die Möglichkeiten zumindest früher etwas beschränkt gewesen, kann sein, dass sich die firmwares zwischenzeitlich so entwickelt haben, dass da jetzt mehr geht.
Es gibt zur Konfiguratin über zusätzliche HTTP-Kommandos auch einen Thread von supernova-irgendwas (?), der sollte eigentlich über die "Praxisbeispiele" zu finden sein.

[OT]
MAn. sind die attrTemplate zu Shelly teils renovierungsbedürftig (dein jsonMap-Thema ist vermutlich nur die Spitze des Eisbergs).
Da steckt einiges an Fleißaufgabe dahinter, vielleicht magst du dich da etwas eindenken? (Mein statement dazu, weitere eventuell hilfreiche Links und eventuelle Mitstreiter findest du hier: Antw:MQTT2+Shelly: erste Konfiguration und template-Entwicklung)

[gestein]

Hallo Beta-User,

Danke für die Hinweise.
Wie immer an dieser Stelle: ich habe leider wenig Zeit dafür.
Aber ich schau mir das gerne an.

Ein paar Dinge habe ich gegenüber den Templates schon geändert, mal schauen was ich noch zusammenbringe.

lg, Gerhard

[Beta-User]

Kein Ding, ist eher dein Problem wie meins...

Was https://forum.fhem.de/index.php/topic,116757.msg1111296.html#msg1111296 angeht: "geschalten" heißt das Relay geschalten oder das Ding neu gebootet? IP&Co kommen typischerweise nur bei reboot oder auf Anforderung...

[gestein]

ich habe jetzt mal folgendes probiert:

Code Auswählen Erweitern

defmod Shelly_Test_60 HTTPMOD http://192.168.0.60/settings 120
attr Shelly_Test_60 event-on-change-reading .*
attr Shelly_Test_60 room 0_Testing
attr Shelly_Test_60 extractAllJSON 2

Und siehe da, alle möglichen Felder erscheinen automatisch als Readings, z.B. diese Readings bzgl. MQTT:

Code Auswählen Erweitern

mqtt_clean_session 1 2020-12-17 21:06:36
mqtt_enable 1 2020-12-17 21:06:36
mqtt_id shelly1-68C63AFA0078 2020-12-17 21:06:36
mqtt_keep_alive 60 2020-12-17 21:06:36
mqtt_max_qos 0 2020-12-17 21:06:36
mqtt_reconnect_timeout_max 60 2020-12-17 21:06:36
mqtt_reconnect_timeout_min 2 2020-12-17 21:06:36
mqtt_retain 0 2020-12-17 21:06:36
mqtt_server 192.168.xx.xxx:1883 2020-12-17 21:06:36
mqtt_update_period 30 2020-12-17 21:06:36
mqtt_user 2020-12-17 21:06:36

Das sind im Großen und Ganzen die Standard-Parameter des Shelly.
Sind die für fhem optional?
Oder sollte man da was ändern?

lg, Gerhard

[Prof. Dr. Peter Henning]

Es macht überhaupt keinen Sinn, irgendwelche Einstellungswerte am Shelly, die sich in einer stabilen Konfiguration nicht ändern, als Reading nach FHEM zu übertragen. Das sollte man nur bei Geräten machen, die man nicht direkt über den Browser ansprechen kann - wie etwa HomeMatic.

LG

pah

[Beta-User]

Na ja, die möglichen Einstellungen sind ja auch auf der Herstellerseite gut dokumentiert.

Sind die für fhem optional?

Die Frage verstehe ich schon nicht so richtig. Wenn man die MQTT-Schnittstelle verwenden will, muss man zumindest den Server angeben.

Oder sollte man da was ändern?

Im Wiki steht bislang lediglich der Hinweis, dass es _möglich_ ist, "mqtt_update_period=0" über den Browser abzusetzen.

Ansonsten ist mir derzeit schlicht und ergreifend unbekannt, was die optimale Einstellung ist, ich _vermute_, dass "mqtt_update_period=0" eine gute Idee ist, aber nochmal: Ob das wirklich generell und (noch) für alle Varianten gilt, ist genau eine der Fragen, die m.E. mal etwas systematischer geklärt werden sollten, und es ist auch nicht zielführend, diese "zurückzudelegieren".

Kurz und bündig: ich habe derzeit genau einen Shelly im Einsatz; der ist ok, und ich habe ihn soweit "gebändigt", dass das für meine Zwecke paßt, aber es ist WLAN, was bedeutet, dass der rausfliegen wird, sobald ich eine andere funktionierende Lösung für dieses spezielle Problem gefunden habe!
Ergo werde ich den Bereich Shelly nicht vertiefen, und fordere daher die Community auf, sich des Themas anzunehmen und mir für mqtt2.template die Infos so aufzubereiten, dass ich sie als Shelly-DAU für die Community zentral aufbereiten kann, so dass am Ende "Otto Normaluser" ein "Kochrezept" hat, das er auch umsetzen kann.

Wenn du das alleine nicht kannst, verstehe ich das, aber dann mach doch einfach einen Thread dazu im MQTT-Bereich auf und suche dir Hilfe... (Das ist übrigens für dich selbst auch nicht umsonst, am Ende wirst du die allgemeine Funktionsweise von FHEM und einige FHEMWEB-Attribute  besser verstehen).

[gestein]

Hallo,

mein HTTPMOD Device ist auch nur ein erster Versuch.
Und ich bin so stolz darauf, dass ich das halt im Post geschrieben habe.

Natürlich ist das kein endgültiges Ergebnis, sondern für mich ein wichtiger, erster Schritt.
Alle Werte immer wieder abzufragen, macht ja auch keinen Sinn. Stimmt.
Die Readings in fhem zu haben, macht für mich schon Sinn, weil ich die dann weitrverarbeiten bzw. in fhem anzeigen kann (z.B. Übersicht).
In weiterer Ferne wäre das auch als Erweiterung der Templates zu sehen (Backup/Restore).

Ausserdem bin ich einem Fehler bei meinen Shellys auf der Spur, weil etliche davon sich einfach mal nach einiger Zeit verabschieden, sprich offline gehen.
Die sind dann nicht mehr per IP ansprechbar, keine Reaktion auf ping, keine Webseite mehr.
Egal ob ich DHCP verwende oder die IP-Adresse statisch vergebe.
Da hilft dann nur mehr Sicherung raus und wieder rein.
Und das ich echt blöd und das möchte ich einfach vermeiden.

Mal sehen, wie weit ich da komme.

@Beta-User: Klar, den Server habe ich für MQTT angegeben.
Meine Frage war auch eher auf die anderen Werte gemünzt - z.B. mqtt_keep_alive, mqtt_max_qos, mqtt_reconnect_timeout_max, mqtt_reconnect_timeout_min, mqtt_retain ...
Da werden halt die Standardwerte von Shelly benutzt.
Vielleicht ist ja was anderes besser?
Ich probier mal einfach rum ...

Danke!
lg, Gerhard

[Beta-User]

Hmm, ich _glaube_, das mit HTTPMOD ist nicht unbedingt "best practice", was _dauerhafte Infos_ in FHEM angeht (für eine schnelle erste Übersicht oder eine Analyse mag das was anderes sein).
Auf der MQTT-Seite sollte man m.E. sicherstellen, dass man LWT-Messages auswertet. Darüber bekommt man nämlich dann mit, ob man ernsthafte Probleme hat und kann gezielt eingreifen. Da scheint es uU. Probleme mit zu geben:

Default LWT topic and message are shellies/<shellymodel>-<deviceid>/online, false. If these are not set after a firmware upgrade -- perform a factory reset of the device.

Das mit dem "Weghängen" läßt bei mir direkt die "WLAN-Alarmglocke" bimmeln . Das bitte ich dann aber nicht hier zu vertiefen, es gibt dazu bereits so viele Threads, v.a. wenn man die Kombi "FritzBox" und "ESP8266" als Suchworte verwendet sollte was zu finden sein...

Bevor du mit den "speziellen" anderen Parametern zu sehr rumspielst, solltest du dir deren Bedeutung ansehen, denn bei QoS und retain kommt es uU. sehr darauf an, wie das Umfeld aussieht. MAn. wäre da viel mehr dazu (auch hier im Forum) zu finden, wenn an der Stelle ernsthaft Bedarf bestünde (aber evtl. hat es auch einfach noch keiner untersucht, das kann durchaus auch sein...).

Für "retain" haben wir hier ein paar Einträge, aber eher im Zusammenhang mit MQTT_GENERIC_BRIDGE, externem MQTT-Server und der Frage, wo (vermeintliche) "Geisterschaltungen" herkommen. (Brauchst das nicht nachzuschlagen, ist nur der Hinweis, dass das mit retain wirklich ein Thema ist, das in Standardinstallationen eher keine allzu große Rolle spielt).

Zu den Timeout-Einstellungen kann ich dagegen nichts sagen, da kann es durchaus sein, dass allgemeine Handlungsempfehlungen Sinn machen (oder bereits anderswo verfügbar sind?).

[gestein]

Hallo,

Da hast Du vollkommen recht HTTPMOD ist sicherlich nur der erste meiner Versuche.
Aber damit habe ich erstmal eine Übersicht (auch das Interval mit 120 ist nicht sinnvoll).

Danke für die Tipps in die unterschiedlichen Richtungen.
Nun habe ich ein paar Ansatzpunkte.
Das die Shellys offline gehen, wollte ich hier eh nicht diskutieren 

Und dass das nicht einfach wird, haben mir meine ersten Suchen schon gezeigt.
Jetzt muss ich mich mal mehr in MQTT und JSON einarbeiten ...

lg, Gerhard

[Beta-User]

Jetzt muss ich mich mal mehr in MQTT und JSON einarbeiten ...

...du darfst dann gerne Rückmeldung zum "workshop" geben, du bist inhaltlich grade bei "Einstieg" gelandet ...

Vielleicht ein Hinweis dazu: Ich finde es bei neuen, mir unbekannten "JSON-Sprechern" immer hilfreich, nicht nur das zu sehen, was json2nameValue() daraus macht, sondern auch, wo und wie es "pur" reinkommt.

Dazu kann man die betreffende Zeile dann einfach "doppeln" und den JSON unausgepackt in ein Reading umleiten. Beispiel aus deiner readingList:

Code Auswählen Erweitern

[...]
shellydimmer2_D8BFC01A0128:shellies/shellydimmer2-D8BFC01A0128/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }\
[...]
wird zu:

Code Auswählen Erweitern

[...]
shellies/shellydimmer2-D8BFC01A0128/announce:.* { json2nameValue($EVENT, 'announce_', $JSONMAP) }\
shellies/shellydimmer2-D8BFC01A0128/announce:.* announce\
[...]