Support-Thread Modul 36_Shelly.pm

[Starkstrombastler]

Die Fehlermeldung liest sich als wäre das Modul auf der "alten" Version und/oder das Attrribut "model" noch auf ein "1st Gen Plug" gesetzt.

Neue Shellies werden am zuverlässigsten als neues Device angelegt, d.h.: define <name> Shelly <ip-adr>  Nach ca. 30 Sekunden können dann die Attribute gesetzt werden. Das Attribut model wird im Gegensatz zur älteren Modulversion automatisch ermittelt und sollte in diesem Fall shellyplusplug lauten.

Alternativ sollte auch  get <name> model   helfen.

Die aktuelle Modulversion 5.04 ist über reguläres Update verfügbar.

[Starkstrombastler]

ich habe hier immer mal wieder folgende Meldung im Log stehen:

Sollte mit dem morgigen Update behoben sein.

[pcbastler]

Die Fehlermeldung liest sich als wäre das Modul auf der "alten" Version und/oder das Attrribut "model" noch auf ein "1st Gen Plug" gesetzt.

Neue Shellies werden am zuverlässigsten als neues Device angelegt, d.h.: define <name> Shelly <ip-adr>  Nach ca. 30 Sekunden können dann die Attribute gesetzt werden. Das Attribut model wird im Gegensatz zur älteren Modulversion automatisch ermittelt und sollte in diesem Fall shellyplusplug lauten.

Alternativ sollte auch  get <name> model   helfen.

Die aktuelle Modulversion 5.04 ist über reguläres Update verfügbar.

Update hat geholfen Vielen Dank!

[x86]

Hi Starkstrombastler,

das Modul läuft bei mir auch auf dem alten Pi jetzt gut und ohne Verzögerungen oder nennenswert höhere CPU-Last. Super, danke!

Allerdings habe ich einen neuen Effekt festgestellt: das neue Modul hat ja ein neues Attribut, "ShellyName", eingeführt, das ja scheinbar den in der Shelly-GUI vergebenen Namen enthalten soll und automatisch ausgelesen wird. Jetzt habe ich leider den Effekt, dass es beim Neustart von FHEM (z.B. nach einem Update) regelmäßig passiert (aber zufällig), dass bei einem oder mehreren meiner 5 Shellys plötzlich das "ShellyName" mit dem Wert seines FHEM-Namens überschrieben wird statt des Shelly-Namens.

Abgesehen davon, dass mir der Sinn dieses Attributs nicht ganz klar ist, frage ich mich: könnte man die Logik nicht dahingehend erweitern, dass nur dann versucht wird, den ShellyName auszulesen und als Attribut zu setzen, wenn das Attribut ShellyName nicht bereits besteht?

Meine Vermutung ist nämlich, dass es hin und wieder passiert, dass einer der Shellys gerade mal für ein paar Sekunden aus dem WLAN geflogen ist (passiert bei dem am weitesten entfernten hin und wieder) und wenn das genau bei FHEM-Neustart der Fall ist, wird der ShellyName auf einmal geändert - vom richtigen "sprechenden" Shelly-Namen zum FHEM-Namen.

Nicht, dass das ein großartiger Beinbruch wäre, aber es führt dazu, dass sich die fhem.cfg bei Neustarts regelmäßig "ungewollt" ändert (ich mache regelmäßig Backups der cfg und wenn sich dabei die Dateigröße ändert, ohne dass ich selbst Änderungen vorgenommen habe, werde ich immer erstmal hellhörig.. .

Vielleicht könnte man eine entsprechende Logik wie oben vorgeschlagen einbauen, oder aber das ShellyName-Attribut abschaltbar machen?

Danke schonmal und viele Grüße,
Fabian

[Prof. Dr. Peter Henning]

Die Berechnungen sollten meiner Meinung nach am Gerät selbst so Hardwarenahe wie möglich erfolgen und das am besten jede Sekunde. Da die Shellys seit Version 0.9.0 über eine Script-Komponente verfügen, ist der naheliegendste Schritt dies darüber zu implementieren. Habe die Shelly-Script-Features überflogen und alle Funktionen sind hierfür gegeben. Somit entfällt das Polling von 3 Sekunden. Selbst die Einstellungen (Script-Handling) im Shelly-Gerät könnten über FHEM erfolgen und gepflegt werden.

Das ist, pardon, ziemlicher Unsinn (und da ich seit 16 Jahren eine PV-Anlage betreibe, weiß ich hoffentlich, was ich sage).

Erstens hat inzwischen jeder einigermaßen brauchbare Wechselrichter eine Möglichkeit zur Abfrage diverser Daten. Das ist heute sogar viel besser gelöst, als noch bei meinem alten NT5000 - für den musste ich ein eigenes FHEM-Modul schreiben, siehe contrib-Ordner. Und bevor ich FHEM kannte, habe ich das sogar über einen Mikro-Webserver abgefragt.

Zweitens ist die Energiemessung in den meisten Shelly-Devices, vorsichtig gesagt, ziemlich ungenau (wenn es sich nicht um ein dezidiertes Modul zum Messen der Wirkleistung handelt...). Damit auch noch Berechnungen irgendeiner Art zu machen, ist nicht sehr erfolgversprechend.

Drittens: Was um Himmels Willen sollte man mit einer Energiemessung im Sekundentakt anfangen? Für so etwas interessiert sich kein rational denkender Mensch. Gerade bei PV-Anlagen kann es zu sehr kurzfristigen Schwankungen der erzeugten Leistung kommen.

LG

pah

[Starkstrombastler]

Was um Himmels Willen sollte man mit einer Energiemessung im Sekundentakt anfangen?

Wir reden hier über den ShellyPro3EM Dreiphasen-Leistungs- und Energiezähler im Einsatz als "SmartMeter" in der Zuleitung hinter dem Zähler des Netzbetreibers.

Der ShellyPro3EM verfügt leider über keine phasenübergreifende Saldierung. Solange das nicht in der Firmware vorhanden ist, kann man versuchen das mittels Fhem oder (besser) mittels Script zu realisieren. Dazu muss die bezogene und eingespeiste Leistung in kurzen Intervallen vom Shelly über alle drei Phasen hinweg integriert werden. Im Ergebnis erhält man getrennte Werte für die bezogene und die eingespeiste Energie, was dann (hoffentlich) einigermaßen mit dem "amtlichen" Zähler übereinstimmt. Der Shelly stellt keine derartigen Werte zur Verfügung und die schlichte Addition der Werte der einzelnen Phasen führt zu abweichenden Werten, wenn gleichzeitig eingespeist und auf einer anderen Phase bezogen wird.

[JoWiemann]

Hallo Starkstrombastler,

in der aktuellen Version des Moduls hast Du in Zeile 4662 ein Logging mit verbose 3 hinterlegt, dass mir sekündlich das Log ergänzt. Ich halte das für echt übertrieben. Aus meiner Sicht gehört hier ein Verbose 5 oder mindesten 3 hin.

Grüße Jörg

Code Auswählen Erweitern

       Log3 $hash->{NAME},3,"$reading: maxAge=$MaxAge ReadingsAge="
                        .ReadingsAge($hash->{NAME},$reading,0)." new value=$value vs old="
                        .ReadingsVal($hash->{NAME},$reading,"")
                        #.($changed?":: $changed":"  ::-0-")
                        ;


[betateilchen]

hier ein Verbose 5 oder mindesten 3 hin.

Wohl eher 5 oder 4.
Denn 3 ist es ja schon 

[JoWiemann]

hier ein Verbose 5 oder mindesten 3 hin.

Wohl eher 5 oder 4.
Denn 3 ist es ja schon 

Krumme Finger. Gemeint war 4.

Grüße Jörg

[grappa24]

moin zusammen,

bin gestern erst auf das Modul 36_Shelly.pm gestoßen, weil meine neuen ShellyPlusPlugS mangels template nicht mehr (so richtig) mit MQTT funktionieren.

Ich frag mich jetzt ob ich meine 6 Stück Shelly1, Shelly1L, ShellyPlugS nicht auch von MQTT auf 36_Shelly.pm umstellen soll oder doch für die neuen MQTT templates entwickeln/suchen soll (gibt ja einen entspr. thread).

Die Frage gehört hier nicht her, aber vlt. könnt ihr mir doch paar Anregungen Pro und Contra geben.

Danke, Dieter

[betateilchen]

Grundsätzlich binde ich alle meine Shelly nur per mqtt ein.

Da muss man nicht auf die Umsetzung und Anpassung in einem speziellen Modul warten, denn mqtt kann man jederzeit als Anwender auch selbst und ohne bereitgestelltes template so einrichten, wie man es gerne hätte. (Ich habe noch nie irgendein template verwendet, das ist mir viel zu suspekt.)

[caldir65]

Moin,

kann es sein, daß die neue Version irgendwo in Sachen set- oder toggle-Steuerung umgestrickt wurde? Seit dem letzten Update Anfang Nov. (vorher hatte ich die 36_shelly.pm vom Update ausgenommen) kann ich Shellys nur noch über die WebUI von fhem schalten, jedoch nicht mehr über FUIP (s.a. in diesem Thread)

Bekomme statt dessen nur

Code Auswählen Erweitern

2023.11.10 10:51:11.661 1: [Shelly_Set] Error: wrong channel 'on' for device ShellyPlugS_Buero_3dPrinter, must be <integer>
2023.11.10 10:51:13.360 1: [Shelly_Set] Error: wrong channel 'off' for device ShellyPlugS_Buero_3dPrinter, must be <integer>
wenn ich mittels FIUP zu schalten versuche ...

Gruß, Christoph

[Starkstrombastler]

kann es sein, daß die neue Version irgendwo in Sachen set- oder toggle-Steuerung umgestrickt wurde?

Ja, das stimmt.
Welchen Befehl sendet denn FUIP?
Bitte den Schaltvorgang mit verbose=5 loggen und hier posten.

[Starkstrombastler]

Hallo grappa24,

Ich frag mich jetzt ob ich meine 6 Stück Shelly1, Shelly1L, ShellyPlugS nicht auch von MQTT auf 36_Shelly.pm umstellen soll oder doch für die neuen MQTT templates entwickeln/suchen soll (gibt ja einen entspr. thread).

So ähnlich haben bisher nur Einsteiger gefragt, ohne MQTT Erfahrung. Für diese sollte sich das Shelly-Modul zunächst als die einfachere Variante darstellen.
Ansonsten könntest du es einfach mal auf einen Versuch ankommen lassen und das Shelly-Modul ausprobieren. Mir ist nicht bekannt, dass das nicht parallel zu MQTT gehen sollte. 

[Starkstrombastler]

Hallo x86,

Allerdings habe ich einen neuen Effekt festgestellt: das neue Modul hat ja ein neues Attribut, "ShellyName", eingeführt, das ja scheinbar den in der Shelly-GUI vergebenen Namen enthalten soll und automatisch ausgelesen wird. Jetzt habe ich leider den Effekt, dass es beim Neustart von FHEM (z.B. nach einem Update) regelmäßig passiert (aber zufällig), dass bei einem oder mehreren meiner 5 Shellys plötzlich das "ShellyName" mit dem Wert seines FHEM-Namens überschrieben wird statt des Shelly-Namens.

Es ist wahrscheinlich ausreichend, den im Shelly eingetragenen Namen als Reading anzuzeigen. Das werde ich in einer der nächsten Versionen vereinfachen.