Modul 36_ShellyMonitor

[gvzdus]

Dieses Modul wertet Multicast-Messages aus, die jedes Shelly-Gerät i.d.R. alle 30 Sekunden und bei wichtigen Zustandsänderungen im Netzwerk sendet.
Diese Pakete werden für 2 Zwecke verwendet:

• Readings in Geräten, die mit 36_Shelly.pm angelegt wurden, werden aktualisiert. Das Pollen im Shelly-Modul kann daher auf eine sehr niedrige Frequenz gestellt werden - z.B. um Readings wie verfügbare Firmwareupdates anzuzeigen.
• Auf der Übersichtsseite des "ShellyMonitor-Gerätes" selber wird eine Tabelle aufgebaut, in der alle gefundenen Shellys im Netzwerk aufgeführt werden. Bereits definierte Geräte werden mit ihrem Namen aufgeführt, neuen Geräten kann ein Name zugewiesen werden, und sie werden dann mit einem Klick als Shelly-Modul-Gerät angelegt (siehe auch Screenshot)

Einrichtung

Code Auswählen Erweitern

define shellymon ShellyMonitor
Sollte sich trotz vorhandener Shellys danach keine Tabelle aufbauen, weil keine Geräte auf dem primären Netzwerkinterface gefunden werden, kann es nötig sein, das Gerät zu löschen und mit

Code Auswählen Erweitern

define shellymon ShellyMonitor <interface>
anzulegen - z.B. "wlan0" als Interface.

Unterstützte Geräte
Soweit bekannt, werden alle Shelly-Geräte, die Mod_Shelly kennt, unterstützt. Nicht in Mod_Shelly bekannte Gerätemodelle werden als "generic"-Modell angelegt und alle im Netz publizierten Reading-Updates in das Gerät geschrieben.

Die Geräteerkennung erfolgt anhand der "Global Device Id" im Multicast-Paket. Im verbose-5-Modus werden diese Pakete geloggt. Verbesserungsvorschläge sind willkommen, insbesondere, wenn die "Global Device Id" bekannt ist. Dies ist in der Zeile

Code Auswählen Erweitern

URI: /cit/s, global_devid = SHPLG-S#B86612#2, validity=3840, serial=22563
z.B. das SHPLG-S

Das Modul ist ab 17.01.2021 in der aktuellen FHEM-Version enthalten

[cs-online]

Hallo,

etwas merkwürdiges ist grad bei mir passiert, ich weiß nicht, ob das am ShellyMonitor-Modul oder am FHEM liegt, denn die fhem.pl ist auch upgedatet worden. Ich lege das Device an:

Code Auswählen Erweitern


define ShellyMonitor ShellyMonitor


Dann wird das Device erzeugt und angezeigt. Es finden sich auch schon bekannte shellys, bei save config kommt das Fragezeichen, oben im Reiter dreht und dreht es sich. Dann einen kurzen Moment später ist die Seite blank, das Fragezeichen bei save config ist weg und wenn ich dann ein list ShellyMonitor absetze, sagt er, es gäbe kein solches Device... also neu angelegt, und so weiter, immer im Kreis...

Wenn ich einen Dummy anlege, passiert sowas nicht...

Hast du eine Idee ?

Grüße

Christian

[gvzdus]

Ich habe mit einem sekundenfrisch aktualisierten FHEM genau Deinen Befehl abgesetzt und kann es nicht reproduzieren.
Einzig vorstellen kann ich mir, dass es sonderbare Effekte gibt, wenn durch ShellyMonitor ein FHEMWEB-Reload getriggert wird und Du gleichzeitig auf etwas klickst. Deswegen warte vielleicht einmal 40 Sekunden, bis alle Shelly-Devices gefunden wurden (sie senden normalerweise alle 30 Sekunden). Dann sollte kein Reload mehr ausgelöst werden.

[cs-online]

...nach dem x-ten Versuch konnte ich tatsächlich speichern, bevor die Seite wieder refreshed wurde... und noch eine Frage hätte ich: Ich hatte das so verstanden, dass das Modul Readings in die angelegten Shelly-Devices schreibt, richtig ? Ich habe 6 Devices, Shelly1, Shelly 2 und Shelly2.5 sowie einen Dimmer. Aber: ich habe in keinem der Devices irgendein neues Reading gefunden, auch nach 15 Minuten nach der Define vom Shellymonitor... Sollte das so richtig sein ?

Grüße

Christian

[gvzdus]

Moin, prima. Ich habe mich bemüht, möglichst nur die Readings zu aktualisieren, die auch pah im Shelly-Modul "zieht". D.h.: Wenn Du z.B. ein "energy"-Reading hast, oder ein "power"-Reading mit häufig wechselnden Werten: Das sollte definitiv refreshed werden.
Nicht getestet ist allerdings:
Wenn hingegen ein Device auf model generic steht, dann sollte ShellyMonitor alles aus dem Netz in Readings schreiben.
Da Du ja nach den Sensoren beim 1PM suchst: Du kannst das mal so testen:
1) ShellyMonitor löschen
2) Shelly1PM-Device auf model generic umstellen
3) ShellyMonitor neu definieren
Dann *sollten* Readings im Shelly1PM-Device auftauchen. Der Umweg "Löschen, Ändern, Neu anlegen" ist nötig, weil ShellyMonitor das "model"-Attribut cacht. Dass Du die Seite eines Devices neu laden musst, um neue Readings zu sehen, weißt Du?

[cs-online]

Ja, war mir bekannt, ich hatte die Devices aus dem Monitor neu aufgerufen, daher sollten die Readings da aktualisiert worden sein, dachte ich... Aber wenn sowieso nur die "normalen" Readings aktualisiert werden, ist das ganze für mich eher weniger interessant....

Aber danke für deine Hilfe anyway...

Grüße

Christian

[caldir65]

Moin, prima. Ich habe mich bemüht, möglichst nur die Readings zu aktualisieren, die auch pah im Shelly-Modul "zieht". D.h.: Wenn Du z.B. ein "energy"-Reading hast, oder ein "power"-Reading mit häufig wechselnden Werten: Das sollte definitiv refreshed werden.

Moin,
wie sollten denn die Readings angezeigt werden? Ich habe 16 Devices gefunden (Plugs und Shelly1), aber außer der Tabelle mit den angelegten Namen, den IPs sowie dem Modell bekomme ich keine weiteren Informationen. Es werden nur die empfangenen MSGs hochgezählt, z.B. Stausänderungen o.ä. gibt es nicht...

Code Auswählen Erweitern

Internals:
   CFGFN     
   FD         25
   FUUID      600432e5-f33f-378b-0b52-13f8547e658c4c09
   NAME       Shelly.Monitor
   NOTIFYDEV  global
   NR         1656
   NTFY_ORDER 50-Shelly.Monitor
   STATE      Statistics: 3189 msg received, 0 broken, 0 ignored, 16 devices
   TYPE       ShellyMonitor
   READINGS:
     2021-01-17 14:41:45   state           Statistics: 3189 msg received, 0 broken, 0 ignored, 16 devices
Attributes:
   DbLogExclude .*
   event-on-change-reading .*
   group      Shelly
   room       System->Geräte

Gruß, Christoph

[gvzdus]

Die Seite ist nur eine Übersichtsseite. Wenn Du auf das einzelne Gerät gehst, siehst Du die Readings. Sie werden halt sobald aktualisiert, sobald eine Nachricht eintrifft, und nicht erst, wenn das Pollintervall abgelaufen ist.

Beispielsweise solltest Du bei Deinen Sonos-Shellyplugs, wenn Du auf die Geräteseite gehst und ein bissel an der Lautstärke spielst, gleich im power-Reading die Veränderung des Stromverbrauchs sehen.

[caldir65]

Hm, wenn ich das jetzt richtig sehe, wird damit also das "normale" Shelly-Device geöffnet, aber über das ShellyMonitor-Device werden die Readings auch bei einem Intervall=43200 (1/2 Tag) trotzdem sofort aktualisiert, wenn sich was ändert?

Gruß, CHristoph

[gvzdus]

Richtig!
Du kannst das Poll-Intervall gigantisch hochdrehen, die Readings sind so aktuell wie mit MQTT.
Vorteil ggü. MQTT sehe ich darin, dass z.B. der Parallelbetrieb mit der Shelly-Cloud möglich ist, oder auch mehrere FHEM-Instanzen auf das gleiche Gerät zugreifen können.

[Wetterhexe]

Hab mich schon sehr auf das Modul gefreut, genau das was ich suche. Leider killt es reproduzierbar mein fhem

Ich habe acht shellyplug-S. Nachdem ich das Modul definiere, sehe ich von den shelly's die IPs reinrauschen.  Nach einigen Sekunden ist fhem nicht mehr erreichbar. Im log findet sich folgendes:

Code Auswählen Erweitern


Can't use string ("Wohnzimmer") as a HASH ref while "strict refs" in use at ./FHEM/36_ShellyMonitor.pm line 722.


"Wohnzimmer" ist einer meiner definierten rooms (wollt ich nur festhalten auch wenns eh klar sein dürfte).

[gvzdus]

Danke für Deinen Test! Diese Meldung kenne ich, und ich wollte sie vor dem Launch beheben. Letztlich konnte ich es nicht eingrenzen. Ich habe dafür zwar "Sicherheitszeilen" im Code eingebaut, aber die scheinen nicht zu greifen. Kannst Du mir aus dem fhem.log sagen, in welcher Zeile FHEM abgestürzt ist? Du hast noch eine Stelle gefunden, und ich rätsele, wo der Fehler reinkommt.

[Wetterhexe]

kann ich etwas beitragen um den Fehler zu finden? loglevel hochdrehen? oder andere Ideen?

[gvzdus]

Nein, ich habe den Fehler bei mir selber auch bei Loglevel 5 nicht eingrenzen können, aber auch nicht reproduzieren können.
Die gerade eben ins SVN eingestellte Version prüft bei jedem Cache-Lesen die Datentypen - damit fange ich hoffentlich den Fehler ab.

Außerdem habe ich Joachims Punkt behoben: Das Modul erkennt IP-Wechsel von Shelly-Geräten und aktualisiert die Definition in FHEM. Joachim war aufgefallen, dass das nicht für noch nicht angelegte Geräte gilt: Die tauchten bei einem IP-Wechsel doppelt auf. Ist jetzt geändert.

Wenn Du die angehängte Version vorab testen kannst, wäre es gut - sonst ist sie morgen per Update verfügbar.

[MadMax-FHEM]

Ich werde das heute Abend (wenn tatsächlich Zeit ist/bleibt) mal testen...
...und außerdem: hänge ich jetzt hier auch "dran"

Gruß, Joachim