Modul 36_ShellyMonitor

[Prof. Dr. Peter Henning]

Ich habe ihn seit mehreren Tagen nicht mehr geklickt. Und trotzdem hat er über MQTT sowohl gestern als auch heute seinen Status gemeldet.

LG

pah

[gvzdus]

Nix gegen MQTT, aber MQTTler stehen halt auf Schwatzen

[gvzdus]

Shelly Button & Shelly i3 werden mit der nächsten Version (= SVN jetzt, update morgen) optimiert supported.

Optimiert heisst: Die Eigenarten werden etwas umschifft. Konkret sind nicht nur die generischen Namen etwas konkreter ("shelly_i3" / "shelly_button"), sondern in der Betriebsart als Taster des i3 sowie für den Button generell kann man sich vernünftig mit notify o.ä. auf die Events des Readings "inputEvent_0" bzw. "inputEvent_0/1/2" beim i3 hängen.

Diese sollten jetzt bei einem (Mehrfach-)Tastendruck als Event ausgelöst werden. Anders als das normale Verhalten des Shelly-Moduls, was ShellyMonitor auch übernimmt, lösen ja normalerweise nur Änderungen am Reading Events aus. Natürlich ist aber ein kurzer Tastendruck um 23 Uhr auch dann ein neues Ereignis, wenn schon um 22 Uhr die Taste kurz gedrückt wurde. Dass ein neues Ereignis vorliegt, liesse sich ohne den gerade eingebauten Support sonst nur am eventCounter erkennen.

Und weil's ja sonst zu einfach wäre: Ist der ShellyButton im Batteriemodus, schickt er *immer* beim Aufwachen mit einem kurzen Tastendruck (als Beispiel): "EventCounter 1, Ereignis: S". Heisst: Ist das "wakeupEvent" "button", so wird jedes Ereignis weitergeleitet. Aber das alles nur zum Verständnis: Kurzfassung: Es sollte bequem und einfach funktionieren.

*Einen* Bug des Shelly Buttons habe ich aber nicht umschifft: Beim Aufwachen - also im Batteriemodus - schickt der Shelly Button vor Freude gleich 2 - völlig identische Events - identisch bis auf die Sequenz-Nummer. Im Batteriemodus sollte man also darauf gefasst sein, gleich 2 identische Events hintereinander zu bekommen.

Viel Spaß also mit dem i3 und Button!

P.S.:
Wer's genauer wissen will: Hier das Zitat meines Postings im i3-Thread:

Moin,
ich habe jetzt gerade meinen i3 im Zusammenhang mit COAP/CoIoT untersucht. Ich denke, die Implementierung geht dann morgen rein (schreibe ich noch in den ShellyMonitor-Thread), aber out of the box geht es auch schon halbwegs:

Das Folgende gilt jetzt für CoIoT und Shelly-Monitor, aber die Events sind vermutlich für MQTT ähnlich:

Wer wissen will, "ob das Licht an ist", also den Zustand auf der Leitung wissen will, muss (per Hand) in den "Toggle Switch"-Modus wechseln (default ist "Momentary"). Da wird auf dem Reading input_0 / input_1 / input_2 eine 0 oder 1 übertragen. 1 = gemäß Diagram Verbindung zu L.

Im "Momentary"-Modus werden Taster erwartet, und aus der Einschaltfolge "S", "SS", "SSS" oder "L"-Events erzeugt. (1 x kurz, 2 x  kurz, 3 x kurz, 1 x lang). Hier ist nun eine Anpassung in ShellyMonitor gefragt, um vernünftig und einfach darauf Events aufsetzen zu können. Wie (sicherlich) auch bei MQTT, wird ja der Event-Kanal alle 30 Sekunden wiederholt. Daher lässt sich das Auftreten des Events erst aus der Kombination mit "inputEventCnt_0/1/2 erhöht" ableiten. Die Logik muss also sein:

if (inputEventCnt_x > inputEventCnt_x(old)) {
  setze inputEvent_x als readingUpdate
}

Mod_Shelly arbeitet ja normalerweise immer mit readingsBulkUpdateIfChanged - ein Event wird also nur bei einer Änderung generiert. MQTT hingegen immer (?) mit readingsBulkUpdate. Der "MQTTler" müsste als ein "event-on-change" auf den inputEventCnt_x legen, darauf ein notify etc hängen, um dort inputEvent_x als Art des Ereignisses auszulesen.

Der "Mod_Shellyianer" Stand jetzt genauso, aber ich werde das - gemeinsam für den Button - so implementieren, dass man bei Mod_Shelly sich direkt mit dem Notify auf inputEvent_x "hängen" kann.

Hoffe, damit zur Shelly-Forschung beigetragen zu haben - Vollzug melde ich dann im ShellyMonitor-Thread

[gvzdus]

Ich habe heute mal an meinen Shelly 1PM das Expansion-Board mit den DS18B20-Sensoren angeschlossen. Die entsprechenden Werte ("extTemp_0" / "extTemp_1" / "extTemp_2" plus das Fahrenheit-Pendant) sind bisher, wenn "model" auf "shelly1pm" statt generic stand, der "Nix durchlassen, was pah nicht in die Readings schreiben würde"-Regel zum Opfer gefallen.

Habe ich angepasst, jetzt kommen sie auch bei "model" = "shelly1pm" durch. Außerdem habe ich "Create" in "Define" in der Tabelle umbenannt - das ist mehr "FHEM-Deutsch".

[Prof. Dr. Peter Henning]

"Nix durchlassen, was pah nicht in die Readings schreiben würde"-Regel

Ist ja nett - aber aufgestellt habe ich diese Regel nicht.

LG

pah

[gvzdus]

Stichwort "Shelly Button":

Ich habe ihn seit mehreren Tagen nicht mehr geklickt. Und trotzdem hat er über MQTT sowohl gestern als auch heute seinen Status gemeldet.

Mein Button (aktuelle Firmware) ist definitiv ein Langschläfer. Vorhin das erste Mal seit 3 Tagen geklickt:

Code Auswählen Erweitern

   READINGS:
     2021-01-27 16:36:58   battery         90
     2021-01-24 08:43:08   cfgChanged      0
     2021-01-24 08:43:08   charger         0
     2021-01-24 08:43:08   inputEventCnt_0 1
     2021-01-27 16:36:58   inputEvent_0    S
     2021-01-24 16:45:14   network         not connected
     2021-01-24 08:43:08   sensorError     0
     2021-01-24 16:45:14   state           Error
     2021-01-24 08:43:08   wakeupEvent     button

Wäre er zwischendurch aufgewacht, wäre m.E. das wakeupEvent nicht "button" gewesen, und damit nicht seit dem 24.01. unverändert geblieben. Für den Button fällt mir übrigens kein besonderer Verwendungszweck ein, wenn man ohnehin schon andere Protokolle wie Zigbee im Haus hat. Begeistert bin ich hingegen vom Addon-Modul für Shelly 1pm und Co. mit den DS18B20-Sensoren. Habe mich endlich aufraffen können, Vorlauf- und Rücklauftemperatur der Heizung zu erfassen. Die Sensoren einfach in die Schaumisolierung um die Rohre geschoben. Das Bild anbei ist ohne jede glättende Nachbearbeitung:

[Prof. Dr. Peter Henning]

Ich halte mehr von 1-Wire-Busssystemen, die mehr als nur DS1820 verkraften. Dazu gibt es von mir 12 verschiedene Module.

LG

pah

[caldir65]

Moin,

ich habe das Modul und die Shellies bei mir im Netz alle jetzt angepasst, und es sieht gut aus.

Jetzt habe ich noch einen Shelly, der sich in einem anderen, per VPN mit meinem Netz verbundenen Netz befindet. Ich würde diesen Shelly jetzt gerne auch mit in den Monitor hinein bekommen (als Device ist er angelegt und funktioniert auch soweit gut).

Ein

Code Auswählen Erweitern

set <name> create <ip-des-VPN-Shelly> <ShellyName> ergibt nur ein

Code Auswählen Erweitern

Provided IP ^192\.168\.2\.37$ did not match any IPs

Ist es überhaupt möglich, dieses Device in den Monitor mit einzubinden?

Gruß, Christoph

[gvzdus]

Das wird sportlich: Grundsätzlich kann man MultiCast über Netzwerkgrenzen hinwegrouten (deswegen heißt es ja MultiCast), aber das musst Du in der VPN-Konfiguration vorsehen. Terminiert denn das VPN ebenfalls auf dem gleichen Rechner, auf dem auch FHEM läuft? Dann kann es sein, dass Du das ShellyMonitor-Device mit dem Interface-Parameter anlegen musst, bzw. ein zweites MonitorDevice anlegen musst.

Vorschlag:
Erst mit tcpdump überprüfen, ob und auf welchem Interface Du Pakete vom Remote-Shelly siehst. Dann erst den ShellyMonitor entsprechend konfigurieren.

[caldir65]

Terminiert denn das VPN ebenfalls auf dem gleichen Rechner, auf dem auch FHEM läuft?

Ich habe beide Netze über die beiden vorhandenen Fritzboxen verbunden - für die Zwecke war es bisher vollkommen ausreichend, sogar Fernwartung war darüber einigermaßen machbar

Erst mit tcpdump überprüfen, ob und auf welchem Interface Du Pakete vom Remote-Shelly siehst. Dann erst den ShellyMonitor entsprechend konfigurieren.

Hm, das wird dann eine Herausforderung für mich ... soo bewandert bin ich jetzt nicht mit Netzwerk(un-)tiefen ... Mal sehen, ob und was ich da so erreiche ...
edit: ein paar Zeilen Ausgabe:

Code Auswählen Erweitern

sudo tcpdump src 192.168.2.37
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
21:03:35.578093 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [S.], seq 555510, ack 1734417956, win 2144, options [mss 520,nop,nop,sackOK], length 0
21:03:35.680769 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [P.], seq 1:537, ack 319, win 1826, length 536: HTTP: HTTP/1.1 200 OK
21:03:35.725857 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [P.], seq 537:1041, ack 319, win 1826, length 504: HTTP
21:03:35.769532 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [F.], seq 1041, ack 319, win 1826, length 0
21:03:35.770125 IP 192.168.2.37.http > christoph-desktop.fritz.box.47880: Flags [.], ack 320, win 1825, length 0
21:03:40.783461 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [S.], seq 558687, ack 1373581608, win 2144, options [mss 520,nop,nop,sackOK], length 0
21:03:40.886688 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [P.], seq 1:537, ack 319, win 1826, length 536: HTTP: HTTP/1.1 200 OK
21:03:40.975601 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [P.], seq 537:1041, ack 319, win 1826, length 504: HTTP
21:03:41.020137 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [F.], seq 1041, ack 319, win 1826, length 0
21:03:41.020229 IP 192.168.2.37.http > christoph-desktop.fritz.box.47884: Flags [.], ack 320, win 1825, length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel




Gruß, Christoph

[gvzdus]

192.168.2.37 ist die Shelly-Kiste über das VPN?
Dann läuft da gegenwärtig kein Multicast über das VPN, denn Du siehst nur die HTTP-Antwortpakete - mutmaßlich auf das Pollen. Wenn Du es damit vergleichst, was Dir die lokalen Shellies schicken, siehst Du den Unterschied. Sowas:

Code Auswählen Erweitern

21:44:05.709074 IP 192.168.0.98.5683 > 224.0.1.187.5683: UDP, length 204
21:44:13.248156 IP 192.168.0.98.5683 > 224.0.1.187.5683: UDP, length 204
21:44:28.250845 IP 192.168.0.98.5683 > 224.0.1.187.5683: UDP, length 204


Das ist das, was ShellyMonitor "mitliest".

Wenn es Dir zu komplex mit dem Ändern des VPN vorkommt - oder gar nicht möglich ist, würde ich auf MQTT gehen. Ist vielleicht einfacher.

[caldir65]

Moin,

ok, dann werde ich den einen Shelly wahrscheinlich außen vor lassen - so wichtig ist es dann auch wieder nicht

Gruß, Christoph

[bombardi]

Leider hat pah den Thread für 36_Shelly geschlossen.
Hat jemand hier einen Tip, wie man jetzt erfährt welche updates von 36_Shelly gemacht wurden.
Ich frage, weil das sich ja auf das Zusammenspiel mit Shellymonitor auswirken kann.

[JWRu]

Es gibt einen neuen Thread für das Shelly-Modul:
https://forum.fhem.de/index.php/topic,118446.0.html

[JWRu]

Kurze Frage:
Kann ich die Button-URL (get ... status), die ich zur sofortigen Meldung von lokalen Schaltungen an FHEM in den Shellys eingetragen habe, rauswerfen,
wenn ich ShellyMonitor verwende?