Support-Thread Modul 36_Shelly.pm

Begonnen von Prof. Dr. Peter Henning, 03 Februar 2021, 08:03:09

Vorheriges Thema - Nächstes Thema

Jamo

Hallo Starkstrombastler,
In der Version "5.00 26.10.2023" und neuer,  sind 2 Bugs drin:

Einmal in Zeile 890:
sub Refresh {
    fhem("trigger WEB JS:location.reload(true)");  # try a browser refresh ??
}
-> Bei mir und bei vermutlich anderen Usern gibt es keine fhemweb Instanz "WEB", die heissen bei mir anders.

Dann in Zeile 4027:
fhem("sleep 0.75");-> WARNING: sleep without additional commands is deprecated and blocks FHEM
-> Ausser Du beabsichtigst wirklich, fhem jedesmal für 0.75 Sekunden zu blockieren.

Das sleep hat mich den ganzen Abend gekosten, um herauszufinden wo das herkommt, weil ich dachte das wäre irgendwo in meiner eigenen 99_MyUtils.pm. Falls ein sleep gebraucht wird, sollte es immer eine ID also einen Namen haben, dann kannn man danach suchen. Ich habe mir aus der fhem.pl die ID ausgeben lassen, in diesem Fall war das immer so was wie WARNING: sleep .sleep_3225 ..... Gefunden habe ich es dann über die Dauer, weil bei mir in der 99_MyUtils.pm kein sleep mit 0.75 vorhanden war.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Starkstrombastler

Hallo Jamo,
danke für die Recherche.
Zitat von: Jamo am 29 Oktober 2023, 23:30:43Bei mir und bei vermutlich anderen Usern gibt es keine fhemweb Instanz "WEB"
Korrekt. Muss das selbst mal probieren, zu welchen Fehler(n) das führt. Vielleicht gibt es aber einen grundsätzlich eleganteren Weg, einen Refresh einzuleiten.

Das fhem("sleep 0.75"); ist ein Relikt aus einem (quick & dirty) Experiment, was ich versäumt hatte wieder zu entfernen. Bei anderen Usern ist das auch schon durch sehr lange Reaktionszeiten aufgefallen. Das sollte aber mit dem morgigen Update eliminiert sein.

Gruß und gute Nacht / sleep 21600


IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

JWRu

Bei der mit Update verteilten Version gibt es auch ein Problem mit dem Attribut "interval". Ich habe es bei meinem Shelly Plus 1PM auf 10 gestellt, damit ich in kurzen Zeitabständen "power"-Readings bekomme. Trotzdem wird "power" meistens nur etwa alle 7 Minuten aktualisiert. Das einzige Reading, das in deutlich kürzeren Zeitabständen aktualisiert wird (aber auch nicht durchgängig im 10-Sekunden-Rhythmus), ist "network_rssi".
ZBox; RasPi 3B; RasPi Zero W; Homematic; Z-Wave; EnOcean, Shelly; DuoFern; Oregon-Sensoren; TFA-Sensoren; Steuerung Viessmann-Heizung; Arduinos für Strom-, Wasser-, Gaszähler, Rauchmelder und FI-Schutzschalter

RalfRog

Wenn das Modul noch wie das Original arbeitet, werden die Readings nur bei Änderungen aktualisiert (analog zu Attribut event-on-change).

Gruß Ralf
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

JWRu

ZitatWenn das Modul noch wie das Original arbeitet, werden die Readings nur bei Änderungen aktualisiert (analog zu Attribut event-on-change).
Das Reading "power" ändert sich aber dauernd. Mit der letzten über diesen Thread verteilten Version hat das super geklappt - erst mit der über Update verteilten Version gibt es die Probleme.
ZBox; RasPi 3B; RasPi Zero W; Homematic; Z-Wave; EnOcean, Shelly; DuoFern; Oregon-Sensoren; TFA-Sensoren; Steuerung Viessmann-Heizung; Arduinos für Strom-, Wasser-, Gaszähler, Rauchmelder und FI-Schutzschalter

RalfRog

Ok.
War selber mal drüber gestolpert, daher der Hinweis.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

Starkstrombastler

on-for-timer und off-for-timer sollten jetzt auch bei Gen.2-Geräten funktionieren. Kann das mal jemand mit einem Walldisplay prüfen - bei mir macht das Walldisplay Probleme (mag keine Timer).

Zitat von: JWRu am 30 Oktober 2023, 15:17:00Bei der mit Update verteilten Version gibt es auch ein Problem mit dem Attribut "interval".
Das sollte jetzt gefixt sein. Ursache waren Änderungen, damit bei einem ablaufendem Timer mit Restlaufzeit < Intervall eine Aktualisierung direkt nach dem Ablauf angestoßen wird.


Zitat von: Jamo am 29 Oktober 2023, 23:30:43Bei mir und bei vermutlich anderen Usern gibt es keine fhemweb Instanz "WEB", die heissen bei mir anders.
FHEM stellt hierfür eine Konstante zur Verfügung, also ganz einfach. Der Refresh sollte jetzt überall funktionieren.


IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

Nobbynews

Guten Morgen,

ich habe gerade aktualisiert.
nach dem shutdown kommt auf meinem Testsystem mit einem einzelnen schellyplug folgende Meldung im Log-File
2023.10.31 08:17:42 1: PERL WARNING: Use of uninitialized value $comp in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2479.
2023.10.31 08:17:42 1: PERL WARNING: Use of uninitialized value $comp in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2491.

Norbert

Ibex

Hallo Starkstrombastler,

in der aktuellsten Version 5.03 ist in Zeile 3649 die Berechnungsfunktion der EM-Shellys für die übergebenen Werte des Smartmeter-Offstes deaktiviert.

Hab's wieder aktiviert und läuft seit einer halben Stunde Fehlerfrei.

Hardware: Shelly Pro 3EM
FW-Version: 1.0.6
Verbindung erfolgt über LAN

Danke für das überarbeitete Modul!


Schöne Grüße

Starkstrombastler

Hallo Ibex,
willkommen im Forum und Danke für die Nachricht.
Zitat von: Ibex am 31 Oktober 2023, 21:37:37in der aktuellsten Version 5.03 ist in Zeile 3649 die Berechnungsfunktion der EM-Shellys für die übergebenen Werte des Smartmeter-Offstes deaktiviert.
Der Grund dafür ist, dass die Shellies nicht saldieren. D.h. wenn es durch eine PV-Anlage zu einer Einspeisung auf einer Phase kommt, dann wird diese eingespeiste Energie nicht mit den anderen Phasen verrechnet. Im Ergebnis sind die Werte des Shelly für bezogene und eingespeiste Energie zu hoch.
Im Modul versuche ich die Saldierung so gut wie möglich nachzubilden. Es werden Readings mit der Endung '_S' für die originalen Shelly-Werte und mit '_T' (für Total), das sind die saldierten Werte, berechnet.
Das setzt aber voraus, dass ein niedriges Polling-Intervall (bei mir: 3 sec) eingestellt ist. Gut sichtbar wird dies, wenn mit dem Attribut Periods mindestens eine Kumulierungsperiode ausgewählt wird.
Das ganze muss noch für die Energymeter angepasst werden, daher waren die herausgenommen. Es wird aber trotzdem immer Abweichungen gegenüber den "amtlichen" Zählern geben.

Mit dem nächsten Update wird die Berechnung wieder frei geschaltet, aber bitte die Energymeter-Readings als experimentell betrachten!
Gruß
Starkstrombastler

IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

Ibex

Hallo Starkstrombastler,

danke für deine freundliche Rückmeldung.
Da ich derzeit noch keine PV-Anlage habe, war dieses Thema für mich bis jetzt nur am Rande interessant.
Vielleicht kann ich aber ein bisschen etwas zu dem Thema beitragen.

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.

Da ich gerne den Weg des geringsten Widerstandes gehe, habe ich mal das Shelly-Support-Forum durchforstet und siehe da, es gibt bereits eine "einfache" Lösung.

Forumslink:
https://www.shelly-support.eu/forum/thread/19204-saldierung-pro-3em-ja-nein-vielleicht/?pageNo=3
GitHub-Quelle für den "fast" fertigen Code:
https://github.com/sicanins/shelly-pro3EM-energycounter/tree/main
Shelly-Api für das Scriptehandling:
https://shelly-api-docs.shelly.cloud/gen2/Scripts/ShellyScriptLanguageFeatures

Wenn ich nun das ganze etwas weiterspinne, würde ich folgendes dazubauen:
1. Übergabe der SmartMeter-Daten [kWh] über HTTP-Post
2. Einrichten des Scripts per HTTP-Post-Daten

Die 2 Punkte hätten den Vorteil alles über FHEM pflegen zu können.

Derzeit läuft das Script bei mir mit folgenden Änderungen:
1. MQTT und die Ausgabe über den Namen habe ich deaktiviert.
2. Die periodische Abarbeitung habe ich auf 1000ms erhöht und die dahinterliegenden Berechnungen mit einer Variable angepasst.

So läuft es bei mir seit ein paar Stunden. Allerdings kann ich keine Aussage zur Saldierung im Bezug auf die Einspeisung treffen.

Schöne Grüße
Ibex

Starkstrombastler

Hallo Ibex,
da stimme ich dir voll und ganz zu:
Zitat von: Ibex am 02 November 2023, 23:38:07Die 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.
Ich habe auch schon mit einem Du darfst diesen Dateianhang nicht ansehen.  experimentiert. Allerdings ging dann die Performance des Systems zurück - das muss aber nicht unbedingt am Script gelegen haben. Ich habe das Thema dann erstmal aufgeschoben. Was mir auch nicht gefallen hat, war die Krücke mit der Rückgabe über den Namen....
In der Anlage das Script, welches ich mit /rpc/Script.GetCode gespeichert habe, für alle ShellyEM3Pro-User, die damit experimentieren möchten.

LG
Starkstrombastler
(nächste drei Tage offline)
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200

Nobbynews

Hallo Starkstrombastler,

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

2023.11.04 05:40:08 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 5167.
2023.11.04 05:40:08 1: stacktrace:
2023.11.04 05:40:08 1:     main::__ANON__                      called by fhem.pl (5167)
2023.11.04 05:40:08 1:     main::readingsBulkUpdate            called by ./FHEM/36_Shelly.pm (4628)
2023.11.04 05:40:08 1:     main::readingsBulkUpdateMonitored   called by ./FHEM/36_Shelly.pm (2882)
2023.11.04 05:40:08 1:     main::Shelly_proc1G                 called by ./FHEM/36_Shelly.pm (2490)
2023.11.04 05:40:08 1:     main::Shelly_status                 called by ./FHEM/36_Shelly.pm (2426)
2023.11.04 05:40:08 1:     main::__ANON__                      called by FHEM/HttpUtils.pm (755)
2023.11.04 05:40:08 1:     main::__ANON__                      called by fhem.pl (781)

Norbert

pcbastler

Hallo zusammen,
mir wurde beim Nachkaufen ein Shelly Plus Plug S (https://www.shelly.com/de/products/shop/shelly-plus-plug-s-1) geliefert.
Schalten lässt sich das Teil, das passende reading relay_0 zeigt den Status auch korrekt an.
Als State wird kurz OK angezeigt, danach nur "error". Im Log finde ich
[Shelly_proc1G] invalid JSON data for device shelly1Die Gerätedaten könnte ich komplett zur Verfügung stellen, evtl. hilft der Anfang:
  "deviceInfo": {
    "name": null,
    "id": "shellyplusplugs-80646fe13cd0",
    "mac": "80646FE13CD0",
    "slot": 0,
    "key": "entfernt",
    "batch": "2307-BroadwellCuco",
    "fw_sbits": "04",
    "model": "SNPL-00112EU",
    "gen": 2,
    "fw_id": "20231031-152250/1.0.7-g5db02bd",
    "ver": "1.0.7",
    "app": "PlusPlugS",
    "auth_en": false,
    "auth_domain": null
  },

Lässt sich die Unterstützung für das Gerät noch einbauen?

tobi01001

Zitat von: pcbastler am 05 November 2023, 13:09:33Auswählen Erweitern
[Shelly_proc1G] invalid JSON data for device shelly1

Die 2ndGen Plus Geräte hat Starkstrombastler bereits integriert. 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.
FHEM@UbuntuServer on Lenovo ThinkCentre M900 [i5-6500T / 8GB RAM] MySQL-DbLog, Grafana, FTUI3 / HmIP incl. CCU3 / LGESS / Wärempumpe über TA CMI und CANoE / Shellies u.v.m.