Support-Thread Modul 36_Shelly.pm

[Matthias aka Mathes]

Hallo zusammen,

ich habe gerade einen ShellyUni in Betrieb genommen und der läuft auch wunderbar, nur leider wird die per ADC gemessene Spannung nicht im Device als Reading übernommen. Im WebInterface des Shelly ist sie vorhanden. Ist das ggf. gar nicht vorgesehen?

Aktuelle Version des Perl Moduls ist 36_Shelly.pm:v3.3.0-s24222/2021-04-11, sollte also passen. Unten noch die relevanten Daten aus dem Geräte Details.

Grüße
Matthias


DEF    192.168.2.17
DURATION 
  0
FUUID 
  619b5e35-f33f-ccbf-92e0-b5a99cbb6a26db9c
FVERSION
   36_Shelly.pm:v3.3.0-s24222/2021-04-11
INTERVAL
   5
NAME
   msdShellyUni1
NR
   177
SHELLYID
   shellyuni-3C6105E4EE1D
STATE
   OK
TCPIP
   192.168.2.17
TYPE
   Shelly




cloud
   disabled
   2021-11-22 10:09:09
energy
   0
   2021-11-22 10:23:55
firmware
   v1.11.7
   2021-11-22 10:23:55
network
   connected to 192.168.2.17
   2021-11-22 10:23:52
relay_0
   off
   2021-11-22 10:23:55
relay_1
   off
   2021-11-22 10:23:55
state
   OK
   2021-11-22 10:23:55



interval
   5
model
   shellyuni

[Matthias aka Mathes]

Hallo,

ich habe mir das 36_Shelly.pm mal angeschaut und eine Änderung eingebaut für das Auslesen und Schreiben der per ADC gemessenen Spannung, funktioniert einwandfrei.
Es müssten diese 2 Zeilen Code eingefügt werden in die Sub "Shelly_Status", nach Zeile 1081 (lt. Eclipse):

    $voltage = $jhash->{'adcs'}[0]{'voltage'};
    readingsBulkUpdateIfChanged($hash,"voltage",$voltage);

Dann natürlich noch $voltage aufnehmen in "my" in Zeile 1060.

Besteht eine Chance, dass das offiziell aufgenommen wird? Ich habe mich bislang noch gar nicht mit den Gepflogenheiten der FHEM (Modul-)Weiterentwicklung beschäftigt. Werden die Module gemeinschaftlich weiterentwickelt? Wie kann man da ggf. einsteigen? Ist es überhaupt üblich für "fremde" Modulen zu (mit-)zu entwickeln?

An dieser Stelle erstmal einen riesigen Dank an pah für dieses Modul!!!

Grüße
Matthias



Before:--------------
      readingsBulkUpdateIfChanged($hash,"overpower".$subs,$overpower)
        if(defined($overpower));
      if($model =~ /shelly(1|(plug)).*/){
        readingsBulkUpdateIfChanged($hash,"state",$ison)
      }else{
        readingsBulkUpdateIfChanged($hash,"state","OK");
      }
    }
Before:--------------

Änderung hier einfügen

After:----------------
    my $metern = ($model eq "shellyem")?"emeters":"meters";
    for( my $i=0;$i<$meters;$i++){
      $subs  = ($meters == 1) ? "" : "_".$i;
      $power = $jhash->{$metern}[$i]{'power'};
      $energy = int($jhash->{$metern}[$i]{'total'}/6)/10;
      readingsBulkUpdateIfChanged($hash,"power".$subs,$power);
After:----------------

[Prof. Dr. Peter Henning]

1. Bitte in den Posts die Code-Tages verwenden (Icon #)
2. Werd ich mir bei Gelegenheit ansehen. Keine Zeitangabe möglich - und in derselben Form werde ich es auch nicht übernehmen, weil dann negative Effekte für andere Hardware auftauchen
3.

Ich habe mich bislang noch gar nicht mit den Gepflogenheiten der FHEM (Modul-)Weiterentwicklung beschäftigt.

Na, das kann man ja nachholen.

LG

pah

[gvzdus]

Moin, Du kannst auch versuchen, das Modul "ShellyMonitor" zu verwenden. Allterco hat den CoIoT-Support doch bis jetzt nicht eingestellt. ShellyMonitor schreibt in angelegte Shelly-Devices automatisch alle Werte rein, die im Netz herumgeschickt werden, also auch Settings, die das Shelly-Modul nicht kennt.
Und die Alternative wäre MQTT.

Shelly (und ShellyMonitor) haben halt den Vorteil, dass man gleichzeitig die Cloud nutzen kann.

[Matthias aka Mathes]

Moin,

@pah:
zu 1) OK
zu 2) die gleiche Form hätte ich auch nicht erwartet... 
zu 3) das gehe ich dann mal an, sobald Zeit frei wird

@gvzdus:
ShellyMonitor werde ich mal ausprobieren, klingt interessant. Mit den Wolken ist so eine Sache, ich meide sie wo immer es noch geht.
Mit MQTT habe ich mich noch nicht beschäftigt. Hört sich so an, als ob da erstmal die Überwindung einiger Eintritts-Barrieren anstehen würde. Welche Vorteile hätte dieser Ansatz ggb. dem Shelly Modul bzw. Schelly Monitor? Als Nachteil sehe ich, dass man anscheinend zusätzlich erstmal eine Broker Instanz benötigt.

Grüße
Matthias

[gvzdus]

Hi, die Diskussion Shelly-Modul versus MQTT ist oft im Forum geführt worden und wäre hier sowohl redundant wie auch falsch platziert. Du wirst mit der Suchfunktion oder Google viele Beiträge finden.

[Matthias aka Mathes]

Hi,

ok, danke. Über diese Diskussion bin ich noch nicht gestolpert hier im Forum, war mir daher nicht bekannt.

Grüße
Matthias

[caldir65]

Moin,

bestehen eigentlich Pläne, die neuen Shelly Plus einzubinden? Wenn es an der HW mangeln sollte - ich würde einen Shellyplus 1 dann zur Verfügung stellen (ich kann selber leider nicht programmieren...), um zumindest auf diese Weise dazu beitragen zu können 

Gruß, Christoph

[gvzdus]

Ich muss demnächst mal einen Bastel-Tag einlegen, ich habe vor mir einen 4pm pro sowie einen 1pm plus, und den Shelly TRV soeben bestellt.

[caldir65]

Moin,

ist dann nur noch zu klären, in wieweit der 1plus und der 1pm plus gleich behandelbar sind - mal von Power abgesehen ...

Gruß, Christoph

[gvzdus]

Ich habe jetzt mal 1-2 h "gespielt". Alles gilt für "Shelly Gen2" - also Plus1, Plus1pm, PlusI4, Pro4 und mutmaßlich TRV.
Die Doku findet sich hier: https://shelly-api-docs.shelly.cloud/gen2/, und sollte wirklich von oben nach unten gelesen werden.

Was hat sich geändert?

• Shelly wollte aufräumen und hat das recht radikal gemacht
• CoIoT ist tot (ShellyMonitor-Modul als Ergänzung zum Shelly-Modul), live/push-Updates gibt es weiterhin per MQTT oder - neu - per Websocket
• Es ist z.B. jetzt möglich, Shelly-Cloud und MQTT gleichzeitig zu verwenden (übrigens geht auch MQTT über TLS)

Was ergibt sich daraus?
Zwar klappt z.B. noch das "An / Aus" für den Shelly Pro1pm, wenn man Shelly 1pm auswählt. Aber schon das Status-Auslesen funktioniert nicht.

D.h., eigentlich müsste das Shelly-Modul grundsätzlich und tiefgreifend auf Websocket umgeschrieben werden. Dafür spräche aus Nutzersicht, dass das Shelly-Modul (m.E.) immer noch "schöner" in den Readings ist und ein Stückchen einfacher aufzusetzen ist als die Abfolge "MQTT-Server (einmalig) einrichten", MQTT auf dem Shelly zu konfigurieren, neues Device suchen, Attribut-Template anzubinden.

Andererseits: Auch kleine Änderungen am Shelly-Modul haben ja bisher ihre Reifezeit benötigt, und hier geht es um eine größere Änderung.

Soweit zum Stand meines Abendbastelns.

[Prof. Dr. Peter Henning]

Hmm. Ich habe in den nächsten Wochen wieder einmal viel um die Ohren, und werde zu einer so gigantischen Änderung schwerlich kommen. Ich bin mir auch nicht sicher, ob ich mein zentrales FHEM-System mit einer ganzen Zahl von Websocket-Verbindungen belasten will. Wäre für mich eher ein Grund, das Modul aufzugeben und komplett auf MQTT umzustellen.

LG

pah

[TobiL]

Hallo,

an dieser Stelle schon mal danke für die Entwicklung und Wartung dieses Moduls.

Ich habe einen ShellyEM im Einsatz und mir ist aufgefallen, dass die Skalierung des Energiewertes hier nicht in Watt-Minuten (wie bei den bisherigen Shelly-Modellen) sondern in Watt-Stunden zurückgegeben wird. Auf der Weboberfläche ist außerdem der Leistungsfaktor mit dargestellt.

Folgende Code-Anpassungen habe ich zum Test ab Zeile 1082 durchgeführt. Wäre schön wenn sie bei Gelegenheit den Weg in das offizielle Modul finden würden.

Code Auswählen Erweitern


my $metern = ($model eq "shellyem")?"emeters":"meters";
for( my $i=0;$i<$meters;$i++){
  $subs  = ($meters == 1) ? "" : "_".$i;
  $power = $jhash->{$metern}[$i]{'power'};
  readingsBulkUpdateIfChanged($hash,"power".$subs,$power);
  if ($model eq "shellyem") {
    my $voltage = $jhash->{$metern}[$i]{'voltage'};
    readingsBulkUpdateIfChanged($hash,'voltage'.$subs,$voltage);
    my $reactivePower = $jhash->{$metern}[$i]{'reactive'};
    my $apparentPower = sqrt( ($power * $power) + ($reactivePower * $reactivePower) );
    my $powerFactor = ($apparentPower != 0)?(int($power / $apparentPower * 100) / 100):"0";
    readingsBulkUpdateIfChanged($hash,'powerFactor'.$subs,$powerFactor);
    $energy = $jhash->{$metern}[$i]{'total'};
  }else{
    $energy = int($jhash->{$metern}[$i]{'total'}/6)/10;
  }
  readingsBulkUpdateIfChanged($hash,"energy".$subs,$energy);
}



Grüße, Tobias

[Xell1984]

Zur Info: Das TRV ist ein Gen1 Device lt. CEO von Allterco.

[Prof. Dr. Peter Henning]

@TobiL:

Wäre schön wenn sie bei Gelegenheit den Weg in das offizielle Modul finden würden.

Soso. In meinem Universum gibt es dafür ein magisches Wort.

pah