Support-Thread Modul 36_Shelly.pm

[erdnar]

Moin zusammen,

hat schon jemand erfolgreich geschafft, einen ShellyPro3EM über FHEM einzubinden?
...

Am 24.8.23 hat Starkstrombastler hier ein modifizierte Modul veröffentlicht. Damit klappt es.
ErdnaR

[LuWoody]

Hallo ErdnaR,
oh hat sich überschnitten, danke dir für deine schnelle Antwort 

[Dr. Boris Neubert]

Gibt es eigentlich Erfahrungserte zur Genauigkeit der Shelly-Meter? Ein User hier im Forum hatte über 5% Abweichung bei einem ShellyPro3EM berichtet.

Habe seit ein paar Wochen einen Shelly Plus Plug S vor ein Energiemessgerät Brennenstuhl PM231E gesteckt. Die angeschlossene Durchschnittsleistung ist ca. 17 W und pendelt zwischen 13 W und 40 W. Der Brennenstuhl maß 12,800 kWh und der Shelly 12,353 kWh in derselben Periode von einem Monat (Differenz der Ablesezeiten Anfang Ende je max. 1 Minute). Das entspricht ca. 3,5 % relative Abweichung. Ohne ein geeichtes Gerät ist es aber nicht möglich, die Genauigkeit verbindlich zu bestimmen. Ich vergleiche hier ja auch nur zwei ungenaue Geräte miteinander.

[VB90]

@Boris
Vergessen darf man auch immer nicht den Eigenverbrauch der Geräte.
Grundsätzlich kalkuliere ich Shelly etc. - zugegeben sehr grob - mit 0,5Watt, pro Gerät. Shelly selbst gibt "<1Watt" in den Unterlagen an.
Wenn man mal unterstellt, das die Brennenstuhl ähnlich viel verbraucht (die Batterien dienen ja nur als Buffer für den internen Speicher), dann muss! die Shelly mehr messen, als die Brennenstuhl. Nämlich eben jene 0,5Watt Eigenverbrauch der Brennstuhl.

So gesehen sind deine beiden Geräte zwar nicht geeicht, aber im direkten Vergleich doch zumindest annähernd gleich (un-)genau und die Abweichung dürfte deutlich geringer sein?
Wieviel misst die Shelly denn ohne Last hinter der Brennenstuhl?


Wegen des Teils hohen Eigenverbrauch macht es - um Energie zu sparen - in meiner Welt keinen Sinn, jede Steckdose smart zu machen.
Auch die 0,5Watt summieren sich, so das der Spargedanke schnell ad absurdum geführt wird.


Zum Thema Genauigkeit:
Vom 31.08. - 30.09 hat mein offizieller Zähler 131,2kWh gemessen.
Im gleichen Zeitraum hat mein Shelly 3EM 124,4kWh ermittelt.

Ein Grund für einen Teil der Abweichung:
Die Ablesung erfolgte am 31. nachmittags.
Der Shelly zählte aber für September erst ab 01.09. 00:00Uhr
Die Stunden dazwischen verschwinden also in der Betrachtung erstmal im Nirvana.
Ich hoffe, das sie im Jahresmittel wieder in Erscheinung treten.

Weiterer Grund: der Eigenverbrauch des 3EM
Der wird zwar natürlich vom Zähler erfasst, aber nicht vom 3EM selbst.
Shelly selbst gibt auch hier den Eigenverbraucht mit "<1Watt" an.
1Watt..., wenn ich richtig rechne liegt der Eigenverbrauch des 3EM dann auf 30 Tage schon bei 0,7kWh!?

Wenn man all das in Betracht zieht, ist der direkte Vergleich der Werte immer mit einer gewissen "Unschärfe" versehen.
Von daher bin ich aktuell zufrieden.

vb

[FhemPiUser]

Tolles Modul, vielen Dank an den Entwickler!

Ein Featurewunsch hätte ich noch: Eine "disable" Funktion finde ich nicht. Das wäre sehr hilfreich, denn momentan habe ich den Shelly nicht im Betrieb und das Modul meldet ständig "nicht erreichbar".

[MadMax-FHEM]

Ein Featurewunsch hätte ich noch: Eine "disable" Funktion finde ich nicht. Das wäre sehr hilfreich, denn momentan habe ich den Shelly nicht im Betrieb und das Modul meldet ständig "nicht erreichbar".

attr Devicename interval 0

Gruß, Joachim

[Dr. Boris Neubert]

Vergessen darf man auch immer nicht den Eigenverbrauch der Geräte.

Das ist ein wichtiger Hinweis.

Ich habe mir gerade das Setup angeschaut und festgestellt, dass es anders herum ist als eben geschildert: der Shelly steckt im Brennenstuhl. Der Brennenstuhl misst also das, was der Shelly misst, plus den Eigenverbrauch des Shelly. So gesehen ist es also erst einmal plausibel, dass der Brennenstuhl mehr Energie als der Shelly gemessen hat.

Die Messung betraf den September mit 30 Tagen à 24 Stunden. 1 Watt im Dauerbetrieb verbrät 0,720 kWh. Der Brennenstuhl hat 0,447 kWh mehr als der Shelly gemessen. Mal angenommen, beide Geräte würden exakt gleich messen, dann hätte der Shelly eine Leistungsaufnahme von 0,6 W. Und das ist konsistent mit der Tatsache, dass der Durchschnittsverbrauch des Setups (gemessen mit dem Brennenstuhl) nach dem Anstecken des Shelly um ca. 0,6 W (von 17,2 auf 17,8) gestiegen ist.

[bombardi]

Super das sich jemand des Moduls angenommen hat und die Gen.2 Geräte integriert.
Ich habe vor einer Weile das letzte 36_Shelly.pm, das ich in diesem Threat finden konnte eingespielt in mein Operativsystem und bisher keine Probleme feststellen können.
Der state ist zwar nicht mehr Error wenn die Verbindung gestört ist aber das habe ich über die Abfrage von Network auf "not connected" gelöst.
Gibt es noch Gründe warum das Modul nicht im FHEM Modulstamm aktualisiert werden sollte ?

[tobi01001]

Hallo zusammen,

nachdem ich einen 3EM erfolgreich integriert habe (Danke für das Modul und die Erweiterung), habe ich mir direkt mal ein paar Shelly Plus PMMini bestellt.

Nach der Einrichtung musste ich feststellen, dass sie "nur" als generic erkannt werden und eine JSON Error anzeigten.
Es war Sonntag und ich ungeduldig. Also habe ich mich durch den Modulcode und die API-Beschreibung gewühlt...
Ein

Code Auswählen Erweitern

../rpc/Shelly.GetStatus liefert neben den Statusinformationen auch die Werte zurück, die ich haben wollte: Current, Voltage, Power und Energy. Allerdings sind die hier verschachtelt unter "pm1:0".
Ein

Code Auswählen Erweitern

../rpc/pm0.GetStatus?id=0 liefert die Daten direkt (also ohne die anderen Statusmeldungen zurück). Das erfordert dann aber einen zusätzlichen HTTP-Aufruf.

Daher habe ich mich entschieden, das Device "Quick&Dirty" über

Code Auswählen Erweitern

Shelly.GetStatus auszulesen.

Folgende Änderungen am Modul habe ich dazu eingebaut:

Code Auswählen Erweitern

Zeile 41 -> damit man das unterschiden kann
my $version = "4.09_pmmini 09.10.2023";

Zeile 293 in shelly_vendor_ids
my %shelly_vendor_ids = (
...
  "SNSW-001X16EU" => "shellyplus1",
  "SNPM-001PCEU16" => "shellypluspmmini",
  "SNSW-001P16EU" => "shellyplus1pm",
...

Zeile 340 in shelly_models

my %shelly_models = (
...
  "shellyplus1pm" => [1,0,0, 1,1,1],
  "shellypluspmmini" => [0,0,0, 1,1,0],
  "shellyplus2pm" => [2,1,0, 2,1,2],
...

und letztlich in der Shelly.GetStatus Auswertung nach diesem wifi block

       if( $wifi_status eq "got ip"){
              readingsBulkUpdateIfChanged($hash,"network_ssid",$jhash->{'wifi'}{'ssid'});
              readingsBulkUpdateIfChanged($hash,"network_rssi",$jhash->{'wifi'}{'rssi'}.$si_units{'rssi'}[$hash->{units}]);
       }else{ #    if( $wifi_status eq "disconnected"){
              readingsBulkUpdateIfChanged($hash,"network_ssid",'-');
              readingsBulkUpdateIfChanged($hash,"network_rssi",'-');
       }

## hier folgt das auslesen des shellypluspmmini
                if($model eq "shellypluspmmini" && $meters > 0)
{
Log3 $name,4,"[Shelly_proc2G] $name of $model as $comp returned $data";
#checking for errors (if present)
$errors  = $jhash->{'errors'}[0];  ##R  new
$errors = "none"
   if (!$errors);

$voltage = $jhash->{'pm1:0'}->{'voltage'}.$si_units{'voltage'}[$hash->{units}];
$current = $jhash->{'pm1:0'}->{'current'}.$si_units{'current'}[$hash->{units}];
$power   = $jhash->{'pm1:0'}->{'apower'} .$si_units{'power'}[$hash->{units}];
$pfactor = $jhash->{'pm1:0'}->{'pf'};
$freq    = $jhash->{'pm1:0'}->{'freq'};
$energy  = shelly_energy_fmt($hash,$jhash->{'pm1:0'}->{'aenergy'}{'total'},"Wh");
$minutes = shelly_energy_fmt($hash,$jhash->{'pm1:0'}->{'aenergy'}{'by_minute'}[0],"mWh");  # Energy consumption by minute (in Milliwatt-hours) for the last minute
 
Log3 $name,4,"[Shelly_proc2G] $name $comp voltage=$voltage, current=$current, power=$power";
   
readingsBulkUpdateMonitored($hash,"voltage",$voltage); 
readingsBulkUpdateMonitored($hash,"current",$current); 
readingsBulkUpdateMonitored($hash,"power",$power);
readingsBulkUpdateMonitored($hash,"pfactor",$pfactor) if( defined($pfactor) );   # PF not supported by all models, eg. ShellyPlusPlugS
readingsBulkUpdateMonitored($hash,"frequency",$freq)  if( defined($freq) );   # frequency supported from fw 1.0.0
readingsBulkUpdateMonitored($hash,"energy",$energy); 
readingsBulkUpdateMonitored($hash,"energy_lastMinute",$minutes);
readingsBulkUpdateMonitored($hash,"protection",$errors);
if( defined($jhash->{'temperature'}{'tC'}) ){
readingsBulkUpdateMonitored($hash,"inttemp",$jhash->{'temperature'}{'tC'}.$si_units{'tempC'}[$hash->{units}]);
}elsif( defined($jhash->{'temperature:0'}{'tC'}) ){
readingsBulkUpdateMonitored($hash,"inttemp",$jhash->{'temperature:0'}{'tC'}.$si_units{'tempC'}[$hash->{units}]);
}
}
...

Ich häng das geänderte Du darfst diesen Dateianhang nicht ansehen.-Modul mal hier dran  in der Hoffnung es hilft jemanden. Vielleicht kann das jemand korrekt oder besser integrieren und vll finden die neuen Shellys ja so auch irgendwann den weg ins offizielle Repo?


Gruß,
Tobias

[Starkstrombastler]

Gibt es noch Gründe warum das Modul nicht im FHEM Modulstamm aktualisiert werden sollte ?

na ja, wenn man das noch nie gemacht hat muss man sich dafür ein bischen Zeit nehmen...

Vielleicht kann das jemand korrekt oder besser integrieren und vll finden die neuen Shellys ja so auch irgendwann den weg ins offizielle Repo?

In der nächsten Version wird dieser Vorschlag übernommen, er scheint ja so zu funktionieren.

[tobi01001]

Vielleicht kann das jemand korrekt oder besser integrieren und vll finden die neuen Shellys ja so auch irgendwann den weg ins offizielle Repo?

In der nächsten Version wird dieser Vorschlag übernommen, er scheint ja so zu funktionieren.

Jeeeiiinnn.
Im Prinzip funktionierte es ganz gut. Allerdings fehlt da eine gewisse Fehlerbehandlung. Hatte da seltsame Effekte bei denen sich Readings außerhalb des Intervals aber dennoch im Intervallabstand gelöscht haben und sich Warnigns im Log häuften...

Also Fehlersuche....
Im define macht das Modul erst:
Shelly_status mittels Timer und dann Shelly_shelly ebenfalls mittels Timer.
Shelly_status kann auch manuell über get angestoßen werden...

Code Auswählen Erweitern

/rpc/Shelly.GetStatus wird über Shelly_shelly für die 2g Shellies abgefragt.
Soweit so gut....
Wenn man allerdings einmal "shelly_status" aufgerufen hat, erfolgt im Zweig für die 2g Devices ein

Code Auswählen Erweitern

my $comp = AttrVal($name,"mode","relay");Nachdem das attr nicht gesetzt ist, haben wir den Ersatzwert "relay" und der führt in der Folge durch das if..elsif..else zu einem Aufruf von:

Code Auswählen Erweitern

http://ShellyURL/rpc/Switch.GetStatus?id=0 nonblocking mit Shelly_proc2G als callback (wegen 2g Shelly). Das wird vom pmmini mit:

Code Auswählen Erweitern

{"code":404,"message":"No handler for Switch.GetStatus"} beantwortet.
Da das gültiges JSON ist, erfolgt keine direkte Fehlerbehandlung und die Readings werden fälschlicherweise mit nichts überschrieben.

Das Problem dabei ist, dass Shelly_proc2G den Timer erneut auf Shelly_status setzt, und das beim normalen Durchlauf, als auch in der Fehlerbehandlung.

Bei Shelly_shelly erfolgt das Setzen der Timer in Shelly_shelly direkt. Da dort aber ebenfalls Shelly_proc2G Callback ist, werden die Timer für shelly_status wieder gesetzt...

Long Story short:
Ich habe mir jetz quick&dirty dadurch beholfen, in der Shelly_status for der HTTP-Aufruf-Schleife (bzw. direkt nach dem else für 2g devices) ein

Code Auswählen Erweitern

return undef if($model eq "shellypluspmmini"); da die entsprechenden Readings ja über Shelly_shelly bereits im gleichen Intervall aktualisiert werden und merh abfragen für den pmmini nicht erforderlich sind.

Das schaut aber insgesamt recht suboptimal aus und wirkt hinsichtlich Modul wohl eher in Richtung Fragemtierung. Vielleicht habe ich mal Zeit und Lust das zu optimieren und strukturieren....

[Starkstrombastler]

Das schaut aber insgesamt recht suboptimal aus und wirkt hinsichtlich Modul wohl eher in Richtung Fragemtierung.

Der Versuch zeigt mir aber, dass das Modul zwar wegen seiner Größe unübersichtlich erscheinen mag, aber trotzdem gelingt es zusätzliche Funktionalität einzubauen.

Vom Grundsatz her ist aber die Schleife für das PMmini falsch eingebaut. Sie gehört nicht in Shelly_shelly() sonder in Shelly_status():
Shelly_status() erledigt das operative zyklische Abfragen des Shelly, evtl. mit sehr kurzen Intervallen;
Shelly_shelly() ist für das Abfragen von Randbedingungen, wie z.B. Firmwarestand, zuständig und kommt mit langen Intervallen aus.

Das wird in den nächsten Tagen in einer Testversion richtig eingebaut sein. Diese Testversion wird auch eine Saldierung für den ShellyPro3EM enthalten.

Damit die Erweiterungen für alle Modulnutzer ohne Umwege zur Verfügung stehen, muss das aktuelle Modul noch im SVN eingecheckt werden. Hierzu steht noch eine Freigabe des ursprünglichen Modulentwicklers aus. Falls PAH hier mitliest möge er bitte mal in sein PM-Postfach schauen.

[tobi01001]

Das schaut aber insgesamt recht suboptimal aus und wirkt hinsichtlich Modul wohl eher in Richtung Fragemtierung.

Der Versuch zeigt mir aber, dass das Modul zwar wegen seiner Größe unübersichtlich erscheinen mag, aber trotzdem gelingt es zusätzliche Funktionalität einzubauen.

Vom Grundsatz her ist aber die Schleife für das PMmini falsch eingebaut. Sie gehört nicht in Shelly_shelly() sonder in Shelly_status():
Shelly_status() erledigt das operative zyklische Abfragen des Shelly, evtl. mit sehr kurzen Intervallen;
Shelly_shelly() ist für das Abfragen von Randbedingungen, wie z.B. Firmwarestand, zuständig und kommt mit langen Intervallen aus.

Das war mir aufgefallen. Aber (aktuell):

• wird Shelly_shelly im gleichen Intervall aufgerufen
• liefert ein /rpc/Shelly.GetStatus die Messwerte unter pm1:0 direkt mit.

Um den Traffic nicht doppelt zu haben, hatte ich das über Shelly.GetStatus ausgelesen und eingebaut.

Wenn man jetzt natürlich das Intervall für Shelly_shelly auf ein vielfaches von INTERVAL setzt, und evtl. ein minimum von x Minuten, ist es mit dedizierter Abfrage des Kanals ../rpc/pm0.GetStatus?id=0 in Shelly_status besser aufgehoben.

Solange sich die Namen der Readings nicht ändern, sollte sich das ja rückwirkungsfrei ändern lassen.

[tobi01001]

Das schaut aber insgesamt recht suboptimal aus und wirkt hinsichtlich Modul wohl eher in Richtung Fragemtierung.

Der Versuch zeigt mir aber, dass das Modul zwar wegen seiner Größe unübersichtlich erscheinen mag, aber trotzdem gelingt es zusätzliche Funktionalität einzubauen.

Vom Grundsatz her ist aber die Schleife für das PMmini falsch eingebaut. Sie gehört nicht in Shelly_shelly() sonder in Shelly_status():
Shelly_status() erledigt das operative zyklische Abfragen des Shelly, evtl. mit sehr kurzen Intervallen;
Shelly_shelly() ist für das Abfragen von Randbedingungen, wie z.B. Firmwarestand, zuständig und kommt mit langen Intervallen aus.

Das war mir aufgefallen. Aber (aktuell):

• wird Shelly_shelly im gleichen Intervall aufgerufen
• liefert ein /rpc/Shelly.GetStatus die Messwerte unter pm1:0 direkt mit.

Um den Traffic nicht doppelt zu haben, hatte ich das über Shelly.GetStatus ausgelesen und eingebaut.

Wenn man jetzt natürlich das Intervall für Shelly_shelly auf ein vielfaches von INTERVAL setzt, und evtl. ein minimum von x Minuten, ist es mit dedizierter Abfrage des Kanals ../rpc/pm0.GetStatus?id=0 in Shelly_status besser aufgehoben.

Solange sich die Namen der Readings nicht ändern, sollte sich das ja rückwirkungsfrei ändern lassen.

Alsooo: Das lange Intervall in Shelly_shelly wird lediglich für den shellypro3em auf ein vielfaches von 60 gesetzt. Alle anderen werden mit dem eingestellten intervall aktualisiert. Schaut nach "Copy/Paste" vom 3em aus.

Ich habe das jetzt auskommentiert und den shellypluspmmini in Shelly_status als "eMeter" eingebaut.
Bedeutet:
Shelly.(GetStatus|GetConfig|GetDeviceInfo) nur noch alle x*60 Sekunden.
Shelly_status im normalen Intervall.

Saldierung für den 3em ist da nicht drin, da ich die nicht kenne....

Kannst du von hier gerne übernehmen: Du darfst diesen Dateianhang nicht ansehen.

LG,
Tobias

[mannil]

Hallo,

ich verzweifele gerade

Gestern habe ich einen Shelly Plus 1PM mini verbaut und wollte ihn gerade in FHEM integrieren.
Eingerichtet habe ich ihn analog zum Plus 1PM (ohne mini). Ich "sehe" auch alle Daten, kann aber zum Verrecken nicht schalten.
Per http Kommando <IP>/rpc/Switch.Set?id=0&on=false oder true kann ich den Shelly ansprechen.

Kann mir da jemand weiterhelfen?
Falls noch weitere Informationen benötigt werden, stelle ich diese gerne zur Verfügung.

Danke und ein schönes Wochenende!