Support-Thread Modul 36_Shelly.pm

[spi3845]

Um Events zu loggen müssen sie überhaupt erstmal erzeugt werden. Die Event* Attribute filtern die Events - wenn kein Event da war hilft auch keines der Attribute es her zu zaubern.
(andersherum wird ein Schuh draus: wenn alle 15 sek. ein Event entsteht würdest du mit "event-min-interval .*:60" dafür sorgen, dass es nur alle min. 60 sek. durchkommt und geloggt wird)

sie werden ja erzeugt und landen im FileLog, nur halt selten. Und ich hätte gerne zwei der Readings wiederholt alle 60 Sekunden...

[RalfRog]

sie werden ja erzeugt und landen im FileLog, nur halt selten. Und ich hätte gerne zwei der Readings wiederholt alle 60 Sekunden...

Wenn selten z.B. alle 4 Stunden ist geht es nicht öfter als alle 4 Stunden oder das Modul muss umgeschrieben werden.

Das umgehst du ja mit der Ergänzung "addLog Haustuer:button.*:60,Haustuer:relay.*:60" um alle 60 Sekunden den letzten Wert nochmal zu schreiben.

Edit:
Oder du definierst mit JsonMod eine neues Device um den Shelly auszulesen.
Dann bekommst du die Werte ausgelesen sooft du pollst.

Code Auswählen Erweitern

Beispiel Gen2
define shly JsonMod http://<IP>/rpc/Shelly.GetStatus/
--------------------------------

Ich habe im Livesystem noch das Originalmodul und hole den Zustand des Button für Shelly1PM alle 5 Minuten / es ist so definiert:

define shly JsonMod http://<IP>/status/
attr shly interval */5 * * * *
attr shly readingList single(jsonPath('$.inputs[0].input'),'Tor_Status');single(jsonPath('$.inputs[0].event_cnt'),'Tor_Count');

Hier war auch ein Beispiel Beiträge #426 #427
https://forum.fhem.de/index.php?msg=1279638

[Starkstrombastler]

Ich meine beim OriginalModul irgendwo in den Erklärungen von PAH gelesen zu haben, dass intern im Modul nur dann Events erzeugt werden wenn die ausgelesenen Werte  sich geändert haben. Da gibt es wohl unterschiedliche Funktionen (readingsBulkUpdateIfChanged) in FHEM für die Developer.

Wenn Starkstrombastler das Modul-Gerüst so belassen hat, wird sich daran nichts geändert haben.

Genau so ist das. Es gibt mehrere Möglichkeiten Events zu erzeugen. Im Modul werden die meisten Readings aber nur dann erzeugt, wenn sich deren Wert verändert hat. Dann nützen auch die diversen Attribute nichts - ohne Updates keine Events.

Auf der anderen Seite kann man bei jedem Update ein Event erzeugen. Es ist dann Aufgabe des Users, die Flut an Events mittels passend gesetzter Attribute einzudämmen. Bei großen Systemen und schwacher Hardware könnte das aber zum Problem werden.

Welche Readings sollten denn so, und welche anders behandelt werden? Wenn sich eine einfache Regel formulieren lässt, wäre das dann für alle Nutzer nachvollziehbar.
 
Vorschlag: "Systemreadings" (cloud, network, firmware, config) erzeugen nur bei Änderung ein Event
"zyklische Readings", also alle anderen, erzeugen bei jedem zyklischen oder azyklischen Update ein Event
Es bleiben einige Readings, die nur durch Actions/Webhooks gepusht werden (z.B. input...). Die ändern z.T. noch nicht einmal ihren Status (z.B. ein Taster der immer wieder "short-push" liefert).

[RalfRog]

Uhhh schwierige Frage... 

Bisher komme ich (spreche natürlich nur für mich) mit dem aktuellen Verhalten gut zurecht.
Hängt aber sicher stark davon ab was man machen möchte (z.B. alle 60 sek. Button/Relaiszustand ins Log schreiben) und wie man das (sinnvoll) erreichen kann - Beispiel spi3845 der sich statt per gewünschtem Event mit addLog beholfen hat.

Da mag der ein oder andere mit mehr Hintergundwissen und Gefühl für FHEM fundierter eine Aussage treffen können (ich nehme an PAH hatte Gründe für die Verwendung von "readingsBulkUpdateIfChanged").

Insbesondere beim Shelly 3EM kann ich mich seit Jahresanfang an einige Beiträge erinnern (weiss nur nicht mehr ob Modul oder MQTT) die die Datenflut und deren Eindämmung zum Thema hatten.

Ich habe nicht die ganze Gerätefamilie im Kopf - im Prinzip kommt ja für alles mit Messwerten eher häufig (abhängig vom Pollintervall) ein Event mit verändertem Wert (Power, Energie, Voltage, Current etc.). Andererseits verhindern zyklische Powerwerte besonders 0 Watt Plotabrisse.
-> Da muss man sowieso überlegen was man wie häufig haben/loggen will.
Relais und Buttons etc. sind demgegenüber deutlich träger und oft von geringerer Anzahl - wobei, beim 1PM-Gen1 verdoppelt sich mit zyklischen Updates die Anzahl der Readings mit vielen Events.

Gar nicht so einfach die passende Strategie zu finden - zählen zu Systemreadings auch inttemp*, overpower, source, timer, reason, protection.


Edit:
Auf der anderen Seite, wenn man die Pollintervalle nicht so ultrakurz haben möchte wäre MQTT wohl der Ausweg, da die Shellys darüber ihre Änderungen spontan und selbständig absetzen.

[spi3845]

Genau so ist das. Es gibt mehrere Möglichkeiten Events zu erzeugen. Im Modul werden die meisten Readings aber nur dann erzeugt, wenn sich deren Wert verändert hat. Dann nützen auch die diversen Attribute nichts - ohne Updates keine Events.

Ah, ok - dann hatte ich da einen Denkfehler. Ich bin davon ausgegangen, dass nach event-min-interval Sekunden ein Event generiert wird - und zwar unabhängig davon, ob es ein Update oder eine Änderung bei dem entsprechenden Reading gab. Hoffentlich verstehe ich das jetzt richtig, dass der Event ausgelöst wird, sofern es ein Update oder Änderung des Readings gab und mindestens event-min-interval Sekunden vergangen sind. Ich kann das Wiki immer wieder lesen und finde immer wieder Neues 

[spi3845]

Edit:
Auf der anderen Seite, wenn man die Pollintervalle nicht so ultrakurz haben möchte wäre MQTT wohl der Ausweg, da die Shellys darüber ihre Änderungen spontan und selbständig absetzen.

Das mache ich auch mit allen anderen Shellies - nur diesen einen wollte ich nicht über MQTT anbinden. Wenn jemand die Pollintervalle nicht so kurz haben möchte, könnte er auch auf dem Shelly ein Script hinterlegen, das seinen Status regelmässig analog den Action-URLs an fhem sendet. Habe das für einige per MQTT angebundene Gen2-Shellies gemacht, um ein Verhalten der Gen1 zu imitieren (oder umgekehrt, erinnere mich nicht mehr  ).

[bene80]

Hallo,

mit der letzten Version werden beim shelly Plus 2PM die urls der actions verändert.
Die IP wird gelöscht, es bleibt nur mehr "8084&cmd=get%20shelly_Bad_LiLu%20status%20" über.

Außerdem hat sich immer das devStateIcon rot verfärbt wenn eine Rollo gerade fährt. Das scheint jetzt auch nicht mehr zu funktionieren.

Habe jetzt die vorletzte Version 2023-05-06 in Verwendung und die pct Zeile abgeändert. Jetzt funktioniert wieder alles

[Starkstrombastler]

Die IP wird gelöscht, es bleibt nur mehr "8084&cmd=get%20shelly_Bad_LiLu%20status%20" über.

Hallo bene80, diesen Fehler habe ich auch schon gesehen, nur weiß ich noch nicht, wie er überhaupt entsteht. Wurde der Fhem-Server neu gestartet? Wurde die Action mittels des Attributs "webhook" generiert oder war das ein manueller Eintrag?

Was meinst du mit "die pct Zeile abgeändert"?

[bene80]

Hi, ich habe die Actions direkt im Shelly eingetragen.
Gestartet habe ich nichts neu. Es dauert auch nicht lange bis die Action geändert wird

Der Slider für Pct war ja bis zur letzten Version ausgeblendet. Das habe ich jetzt selber geändert.

LG Bernhard

[Michi1978]

Hallo,

ich hatte einen defekten Shelly 2.5 den ich heute durch einen Shelly 2 Plus PM ersetzt habe. Nun habe ich das Problem das das Modul das neue Model noch nicht kennt und dieser daher nicht funktioniert.
Weis zufällig jemand wie den neuen Shelly mit dem 36_Shelly Modul trotzdem ans laufen bekomme?

VG

[bene80]

Hallo Michi,

du musst die Version welche hier vor kurzem gepostet wurde verwenden. Die offizielle kennt glaube ich die neuen Shellies noch nicht

SG Bernhard

[Michi1978]

Hallo Michi,

du musst die Version welche hier vor kurzem gepostet wurde verwenden. Die offizielle kennt glaube ich die neuen Shellies noch nicht

SG Bernhard

Vielen Dank für die Info!
Weist du evtl. noch auf welcher Seite das zu finden ist? 

::EDIT::
Habs gefunden Danke !!!

[Starkstrombastler]

Hallo Shelly-Fans,

es gibt wieder ein Update des Shelly-Moduls

Neben einigen Korrekturen gibt es diese Neuerungen:

Attribut "ShellyName": Mit diesem Attribut wird der im Shelly gespeicherte Name in Fhem zur Verfügung gestellt. Ist im Shelly kein Name vorhanden, wird der Name des Fhem-Devices genutzt. Der Name kann mit diesem Attribut vom User geändert werden.

Attribut "Periodes" (nur für ShellyPro3EM): Es können mehrere Zeit-Perioden ausgewählt werden, zu denen die Total-Energy-Readings aggregiert werden:
Minuten, Stunden, Tage, Wochen sowie Viertelstunden, 6-Stunden und 8-Stunden. Die Readings werden immer zu vollen Minuten, Stunden etc. angelegt. Für die Perioden Tag und Woche werden Sommerzeit/Winterzeit und Zeitzone MEZ zu Grunde gelegt.
Wichtig: Da der Shelly Zähler nicht über die Phasen hinweg saldiert, entstehen in Perioden, in denen auf den Phasen zeitgleich unterschiedliche Energierichtungen bestehen, Abweichungen zu geeichten (saldierenden) Zählern.

[Michi1978]

Hallo,

leider habe ich mit den neuen Shelly Plus2PM immer noch Probleme. Es tut sich nichts...
Die Shelly 2.5 laufen einwandfrei mit der neusten Version.

Code Auswählen Erweitern

state Error: JSON

network invalid JSON data


[Starkstrombastler]

Hallo Michi1978,

bitte sicher stellen, dass die neuen Shelly die aktuelle Firmware haben.

Wurde der ShellyPlus2PM als neues Device angelegt?
Das kannst du auf jeden Fall auch parallel zu schon bestehenden Definitionen probieren:

Code Auswählen Erweitern

define neuerName IP-des-Shelly