Modul 36_ShellyMonitor

Begonnen von gvzdus, 16 Januar 2021, 14:18:47

Vorheriges Thema - Nächstes Thema

RalfRog

#135
Sodele das Ding ist im Verteiler und misst nun auf allen drei Phasen.

Im Modul "36_ShellyMonitor.pm" ist eingefügt:
# Copied from 36_Shelly, keep up to date..:
197 my %shelly_models = (
198     #(relays,rollers,dimmers,meters)
199     "generic" => [4,4,4,4],
200     "shellygeneric" => [4,4,4,4],
201     "shelly1" => [1,0,0,0],
202     "shelly1pm" => [1,0,0,1],
203     "shelly2" => [2,1,0,1],
204     "shelly2.5" => [2,1,0,2],
205     "shellyplug" => [1,0,0,1],
206     "shelly4" => [4,0,0,4],
207     "shellyrgbw" => [0,0,4,1],
208     "shellydimmer" => [0,0,1,1],
209     "shellyem" => [1,0,0,2],
210     "shelly3em" => [1,0,0,3],    # Ralf
211     "shellybulb" => [0,0,1,1],
212     );


Mit inaktivem "CoIoT" werden alle 180 durch das Modul "36_Shelly.pm" die Readings (bei Änderungen) aktualisiert. Soweit Ok!

cloud disabled 2022-12-25 21:08:47
energy_0 559.8 2022-12-27 20:23:23
energy_1 952.2 2022-12-27 20:23:23
energy_2 563.8 2022-12-27 20:23:23
firmware v1.12.1 2022-12-27 12:28:04
network connected to 10.20.30.92 2022-12-27 19:12:15
power_0 126.36 2022-12-27 20:23:23
power_1 172.48 2022-12-27 20:23:23
power_2 245.15 2022-12-27 20:23:23
relay off 2022-12-25 21:09:47
relay_0 off 2022-12-25 22:32:32
state OK 2022-12-27 19:13:24
voltage_0 227.21 2022-12-27 20:23:23
voltage_1 226.39 2022-12-27 20:23:23
voltage_2 226.69 2022-12-27 20:23:23


Nun habe ich "CoIoT" aktiviert und die UpdatePeriod von defaut = 15 auf 60 Sekunden erhöht (hat glaube ich keine Auswirkung, bzw. ich weiss nicht wo).
Was fällt auf:

  • reading relay wird durch ShellyMonitor aktualisiert, sofort beim Schalten / ohne ShellyMonitor Reading nicht vorhaden
  • reading relay_0 wird durch Shelly aktualisiert, beim Poll
  • im Pollintervall vom Shelly werden voltage_x (V) und power_x (W) und energy_x (Wh aufsummiert) aktualisiert, entsprechend Meldung http://<ip>/status
  • voltage_x und power_x werden anscheinend korrekt durch die CoIoT aktualisiert (aber auch häufiger als 60 sek
  • energy_x wird durch CoIoT aktualisiert allerdings mit 2stelligen Werten, wo auch immer das herkommt siehe Ausgabe EventMonitor im Anhang

Lass uns die Vorgehensweise abstimmen.

Gruß Ralf

Edit: Korrektur zu relay_0  muss ne Altlast sein, eventuell wg. attr model, heiss wohl nur relay!
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

gvzdus

Moin,
vermutlich kennst Du schon die etwas shelly-eigene Einheit "Wattminuten". Die kommt bei vielen Geräten, aber beim Shelly3EM hat Allterco dann offensichtlich ein Erbarmen gehabt und handelsüblichere "Wattstunden" genommen.

Da ich keine Geräte kannte, die Wattminuten senden, war mir nicht aufgefallen, dass ich *immer* umrechne.

Nächster Schritt wäre also, um Zeile 717 die Umrechnung von der Einheit abhängig zu machen:
Zitat717               } elsif ($rtype eq "energy") {
    718                 my $subs = ($shelly_models{$model}[3] ==1) ? "" : "_".$rno;
    719                 readingsBulkUpdateIfChanged($device, "energy" . $subs,
    720                    $defarr->{"unit"} eq "Wmin" ? int($svalue/6)/10 : $svalue);
    721               } elsif ($rtype eq "output") {

Klappt für meine Gen1-Shellys mit Wmin, wird für Dich wohl auch dann die doppelte Umrechnung Wmin -> Wh vermeiden.

Dann bliebe vermutlich als letzte Baustelle "energyReturned" - was ist das überhaupt?

RalfRog

#137
Hallo
Danke ich habe es "gepatched". Faktor 60 hätte man viellleicht auch sehen können  ::)

Klappt!!

Die Returned-Werte fehlen leider (noch) im Shelly-Modul.

Der 3EM misst in beide Richtungen.
Die Power kann dabei je nach Stromflussrichtung negativ werden (vermutlich über den neg. pf berechnet).
Das Gerät summiert zur Trennung Bezug / Einspeisung (z.B. für PV) die positiven Werte als "total" und die negativen Werte als "total_returned" und liefert sie über http://<ip>/status aus.
Die Werte werden aufsummiert und sollen auch nach Stromausfall erhalten bleiben.

Bei Verwendung vom "mqtt" kommt lt. Doku noch energy / returned_energy dazu, die aber nicht persistent sind.
Für CoIot oder die API stehen diese beiden Werte nicht zur Verfügung.

Darüber hinaus speichert das Gerät 4 csv-Dateien mit den minütlichen Energiewerten pro Phase und Gesamt http://<ip>/emeter/{index}/em_data.csv (index =0|1|2|3)
=> wurde ab SW 1.12 verändert auf Energie und Voltage für je drei Phasen, habe daher zurückgerüstet

Inwieweit diese Dinge über die Timer-Werte zu beeinflussen sind weiss ich (noch) nicht.

Beispiel CSV - Wh-Werte immer nur für die eine Minute (müsste man selber für einen längeren Zeitraum addieren).
Date/time UTC,Active energy Wh,Returned energy Wh
2022-12-27 23:00,7.53,0.00
2022-12-27 23:01,7.68,0.00
2022-12-27 23:02,7.76,0.00
2022-12-27 23:03,7.67,0.00
2022-12-27 23:04,7.47,0.00
2022-12-27 23:05,7.48,0.00
2022-12-27 23:06,7.89,0.00
2022-12-27 23:07,7.43,0.00
2022-12-27 23:08,7.28,0.00
2022-12-27 23:09,7.32,0.00
2022-12-27 23:10,7.25,0.00
2022-12-27 23:11,6.64,0.00
2022-12-27 23:12,6.28,0.00
2022-12-27 23:13,6.23,0.00
2022-12-27 23:14,6.25,0.00
2022-12-27 23:15,6.24,0.00
2022-12-27 23:16,8.54,0.00
2022-12-27 23:17,8.58,0.00
2022-12-27 23:18,8.37,0.00
2022-12-27 23:19,8.31,0.00
2022-12-27 23:20,8.29,0.00
2022-12-27 23:21,8.37,0.00
2022-12-27 23:22,8.27,0.00
2022-12-27 23:23,8.23,0.00
2022-12-27 23:24,8.18,0.00
2022-12-27 23:25,6.57,0.00


Gruß Ralf


Edit P.S.   
Frage:  kannst du über den Monitor die Erzeugung der 3 "total_returned" Readings provozieren?

Edit 2

Verbose 5 vom Monitor:
2022.12.28 21:12:21.368 4 : Received data from 10.20.30.92
2022.12.28 21:12:21.370 4 : 10.20.30.92: in cache, devices=shelly_3em_haus (size=1)
2022.12.28 21:12:21.372 5 : URI: /cit/s, global_devid = SHEM-3#244CAB42CE6B#2, validity=2253, serial=7700
2022.12.28 21:12:21.375 5 : Found device shelly_3em_haus, model shelly3em
2022.12.28 21:12:21.377 5 : cfgChanged = 15
2022.12.28 21:12:21.379 5 : output_0 = 0
2022.12.28 21:12:21.381 5 : power_0 = 126.5
2022.12.28 21:12:21.383 5 : energy_0 = 1798.1
2022.12.28 21:12:21.385 5 : energyReturned_0 = 0
2022.12.28 21:12:21.387 5 : voltage_0 = 227.87
2022.12.28 21:12:21.389 5 : current_0 = 0.88
2022.12.28 21:12:21.391 5 : powerFactor_0 = 0.63
2022.12.28 21:12:21.393 5 : power_1 = 102.25
2022.12.28 21:12:21.395 5 : energy_1 = 2336.2
2022.12.28 21:12:21.397 5 : energyReturned_1 = 0
2022.12.28 21:12:21.399 5 : voltage_1 = 228.02
2022.12.28 21:12:21.400 5 : current_1 = 0.65
2022.12.28 21:12:21.402 5 : powerFactor_1 = 0.69
2022.12.28 21:12:21.404 5 : power_2 = 112.81
2022.12.28 21:12:21.406 5 : energy_2 = 3415.6
2022.12.28 21:12:21.408 5 : energyReturned_2 = 0
2022.12.28 21:12:21.410 5 : voltage_2 = 228.09
2022.12.28 21:12:21.411 5 : current_2 = 0.55
2022.12.28 21:12:21.413 5 : powerFactor_2 = 0.9
2022.12.28 21:12:21.415 5 : overpower_0 = 0


So heissen die Werte des Rückgabe JSON (hier Beispiel Phase 0) energy = total / energyReturned = total_returned
http://<IP>/emeter/0
{"power":125.00,"pf":0.62,"current":0.87,"voltage":227.61,"is_valid":true,"total":1804.6,"total_returned":0.0}
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

gvzdus

Moin, das schaffen wir auch noch:
In Zeile 699 ergänze bitte mal, dass "energyReturned" auch ausgewertet wird:
699           if ($rname =~ /^(power|output|energy|energyReturned|brightness|extTemp)_(.).*/ || $rname =~ /^(roller.*|mode|L-.*|colorTemp)$/) {

Das muss dann im Folgenden auch in 2 Zeilen geändert werden:

    717               } elsif ($rtype =~ /^energy/) {
    718                 my $subs = ($shelly_models{$model}[3] ==1) ? "" : "_".$rno;
    719                 readingsBulkUpdateIfChanged($device, $rtype . $subs,
    720                    $defarr->{"unit"} eq "Wmin" ? int($svalue/6)/10 : $svalue);


(Achtung: 717 und 719 geändert).

Ich glaube, dann haben wir es :-)

RalfRog

#139
 ;D Passt (Screenshot)

Hoffe es gib keine Nebenwirkungen.
Das Polling vom Shelly-Modul ist damit zwar nicht mehr ganz übereinstimmend, aber das Ziel ist ja CoIot einzufangen.
Polling allenfalls alle 6 Stunden.

Was davon bringst Du ins Monitor-Modul?

Gruß Ralf

P.S:
muss jetzt nur bis zum Frühjahr warten, dass mein PV-Balkonmodul genug für Return liefert  :-[

P.S.2

Es gibt noch die Gesamtleistung "total_power": 341.27 (obere JSON Ebene) s.u. damit erübrigt sich ein Usererading, dass die drei Phasen addiert.
Die Frage ist natürlich ob das so in Konzept mit den anderen Shellies passt oder sich zu weit vom ShellyModul entfernt.
{
"wifi_sta": {
},
"cloud": {
},
"mqtt": {
},
"relays": [
],
"emeters": [
],
"total_power": 341.27,
"fs_mounted": true,
"update": {
},
"ram_total": 49440,
"ram_free": 31424,
"fs_size": 233681,
"fs_free": 156875,
"uptime": 86237
}


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

gvzdus

> Was davon bringst Du ins Monitor-Modul?

Würdest Du von irgendwas abraten?  :)

Die Änderungen sind eingecheckt, also sollten sie ab morgen per Update in FHEM drin sein.
Habe noch einen ganz kurzen Test bei mir gemacht.

RalfRog

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

RalfRog

#142
Hinweis für Nutzer des Monitors

Beim Shelly Modul (36_ShellyMonitor.pm) geht die Entwicklung weiter (Testversion) -> https://forum.fhem.de/index.php?msg=1271563
Tests laufen noch / Stand 12. April ist noch das bisherige Modul im SVN.

Achtet bei Updates darauf ob die beiden Module zusammenarbeiten.
  • FHEM/36_ShellyMonitor.pm (26929 2022-12-29)
  • FHEM/36_Shelly.pm (letzte alte Vesion im SupportThread 4.02f / SVN 4.01)

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

RalfRog

#143
Im Shelly Support Thread wird schon erwähnt, dass die Weiterentwicklung mit dem Monitor zusammenarbeitet.

=> https://forum.fhem.de/index.php?msg=1274631

Edit:    für Gen1 mit CoIoT
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

RalfRog

Hallo
mit dieser Test-Version https://forum.fhem.de/index.php?msg=1274963 habe ich die Zusammenarbeit (Shelly-Monitor, -Modul) positiv getestet.
Mit eingeschränkter Modelvielfalt: PlugS, 1PM, 3EM

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

gvzdus

Ich lese mit, und wenn es was zu verbessern gibt, mache ich das.
"Historisch" wusste es ShellyMonitor halt immer aktueller als das Shelly-Modul, deswegen schreibt das Modul alles, was es mitbekommt.

RalfRog

Die eingeschränkte Vielfalt betraf meinen Zoo ;)
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

RalfRog

Aktuell meldet der Monitor
Identified Devices
IP           Name         Model   
11.12.13.10  Shelly_Plug  shellyplug, n.s.   
11.12.13.11  S1PM         shelly1pm, n.s.   
11.12.13.12  S3EM         shelly3em, n.s.   
n.s. = not supported by Mod_Shelly

Ist die n.s. Meldung so richtig?

Schon das "alte" Mod_Shelly 4.02f kennt die drei Typen.

Ok macht sicher Sinn zu warten bis Starkstrombasteler offiziell eincheckt.
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

gvzdus

Der ist einfach:
Was "ich" (ShellyMonitor) mache:
<code>
  LoadModule "Shelly";
  my $fn = $modules{"Shelly"}{"AttrList"};
  if($fn && $fn=~/ model:([^ ]+)( |$)/) {
    map { $shelly_models_by_mod_shelly{$_} = 1 } split (/,/, $1);
    Log3 $hash->{NAME}, 2, "Shelly-Module loaded supports models: " . join(',', keys %shelly_models_by_mod_shelly);
  }
</code>

Früher begann die Liste mit "verbose model:", jetzt steht "model" ganz vorne. Und ich suche nach "<space>model".
Nimm' einfach erst mal das Space weg, also:
<code>
  if($fn && $fn=~/model:([^ ]+)( |$)/) {
</code>

Wie weit ich nachziehe und was pah sagt, muss ich mal schauen. Ich finde es toll, dass jemand am Shelly-Modul entwickelt und auch, dass pah das zulässt. Aber die Anpassungen der Readings-Namen finde ich einen kompletten Holzweg. Es ist schon besch... genug, dass z.B. "Leistung" nicht überall "power" in FHEM als Reading heisst, sondern unterschiedliche Devices unterschiedliche Namen benutzen. Hier noch einzudeutschen, oder im Englischen Uppercase einzuführen, ist m.E. falsch. Genauso finde ich grundfalsch, wenn Reading-Namen sich ändern, je nachdem ob man Mod_Shelly oder MQTT benutzt. Da sollte jeder hin- und herwechseln können, wie er mag.

RalfRog

Jo wech  :)  In der 4.02f mit dem Monitor passt es noch.

Starkstrombastler fehlt bei der Weiterentwicklung eventuell der ein oder andere Zusammenhang - aber PAH hatte sich ja positiv geäußert.
Zitat von: Prof. Dr. Peter Henning am 31 Januar 2023, 15:52:20...
Genau das war der Grund, warum ich es nicht mehr machen konnte. Danke für die hineingesteckte Arbeit, beim Testen helfe ich gerne wieder mit.
...


Ich sehe es jetzt auch wo die Read.-Updates vom Monitor reinfliegen  ::)
Zitat von: gvzdus am 06 Mai 2023, 21:45:23...
Aber die Anpassungen der Readings-Namen finde ich einen kompletten Holzweg. Es ist schon besch... genug, dass z.B. "Leistung" nicht überall "power" in FHEM als Reading heisst, sondern unterschiedliche Devices unterschiedliche Namen benutzen. Hier noch einzudeutschen, oder im Englischen Uppercase einzuführen, ist m.E. falsch.
...

War mir nicht aufgefallen. Ja stimmt besch...


Kommt das energyReturned von meinem Vorschlag Anfang des Jahres (neben current)? Ich befürchte!
Das hatte ich mir ja ins Shelly-Modul von PAH selber reingepatched um die Register zur Verfügung zu haben - über Namensgebung hatte nicht nachgedacht.

Starkstrombastler hat die Einspeisewerte analog zum Shelly (total_returned_x) energy_returned_x genannt. Wäre wohl stimmiger.

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