Shelly: usage dependent measure logic following installation standards

[thierolm]

The measure logic is following now installation standards, following the power flow direction depending of the shelly device usage.

Refer to discussion #18824

[andig]

Brauchts das denn wirklich? Warum kann man bei einer Installation mit falscher Richtung nicht einfach die Sensoren drehen? Sind die wirklich hart montiert? Alternativ: wäre ein „invert“ oder „scale“ evtl. ein besserer Parameter?

[thierolm]

Mein Gedanke hinter dem Parameter war, dass bestehende Konfigurationen von evcc Shelly Nutzern nichts ändern müssen. Bei invert oder scale könnten Teile Probleme bekommen, da es dann darauf ankäme wie die Messzange montiert ist. Können es aber gerne invert nennen, den Wert dann mit -1 multiplizieren und als breaking Change markieren.

[premultiply]

Bei den Energiezählern ändert sich nicht das Vorzeichen aber das Zählregister (Import vs. Export).

[andig]

Die Zange ist doch schnell gedreht, oder? Ich würde unterstellen, dass ein Grossteil der Anwender es i.S. Der App installiert hat.

[thierolm]

@premultiply der PR adressiert nur den Power Messwert act_power.

Für TotalEnergy der Energiezähler bilde ich die Differenz der beiden Zählregister total_act_energy und total_act_ret_energy.

evcc/meter/shelly/switch.go

Lines 145 to 151 in ff9a6c3

	switch d.channel {
	case 1:
	energy = res.Switch1.Aenergy.Total + res.Pm1.Aenergy.Total + resem.Em1Data.TotalActEnergy - resem.Em1Data.TotalActRetEnergy
	case 2:
	energy = res.Switch2.Aenergy.Total + res.Pm2.Aenergy.Total + resem.Em2Data.TotalActEnergy - resem.Em2Data.TotalActRetEnergy
	default:
	energy = res.Switch0.Aenergy.Total + res.Pm0.Aenergy.Total + resem.Em0Data.TotalActEnergy - resem.Em0Data.TotalActRetEnergy

Mein Ziel war möglichst viele Shelly Typen zu unterstützen.

[premultiply]

Oha. Das sollten wir dann aber auch noch ändern.
Ich verstehe deine Intension aber es darf hier nur ein definiertes Zählregister pro Richtung verwendet werden. Sonst stimmen die Energiemengen im Gesamtsystem nicht mehr.
Differenzbildung ist definitiv falsch.
Normalerweise Lösen wir die Zuordnung jeweils über usage.

[mucki12]

Also alle die ich kenne und die einen Shelly EM zB auch in anderen HEMS Systemen nutzen, klemmen die Zange idR so an, dass der Wert beim Zielsystem korrekt ist (also selbstverständlich ein positiver Wert für den Ertrag).

Aber wie schon mal an anderer Stelle geschrieben, passe mich da gerne der Allgemeinheit an und klemme die Zange auch falsch herum an. Hauptsache es werden nicht positive und negative Werte als PV-Ertrag gewertet :-)

[thierolm]

Normalerweise Lösen wir die Zuordnung jeweils über usage.

@premultiply hast du ein Beispiel irgendwo im Code, das ich mir anschauen kann?

[premultiply]

Ja, z.B. hier https://github.com/evcc-io/evcc/blob/master/templates/definition/meter/bge_tech_ds100.yaml

[thierolm]

Ok, schau ich mir an. Würde dann aber nicht den ganzen Shelly Code in eine Custom Meter Umsetzung migrieren, sondern usage als Parameter mitnehmen und dann entsprechend im go Code eine Fallunterscheidung machen.
Beim Einsatz mit usage = grid, müsste ich aber dann immer noch entscheiden, was ich nehme, oder?
Macht der Einsatz eines einphasigen EM Shellies als grid überhaupt Sinn?

Und die es wird immer noch das Problem bleiben, dass die Messung vom Einsatz Mess-Zange abhängig ist.

[premultiply]

Also alle die ich kenne und die einen Shelly EM zB auch in anderen HEMS Systemen nutzen, klemmen die Zange idR so an, dass der Wert beim Zielsystem korrekt ist (also selbstverständlich ein positiver Wert für den Ertrag).

Das ist leider nicht immer so ganz einfach, denn da gibt es mindestens zwei unterschiedliche Sichtweisen.

Im Elektrobereich werden separate Zähler genormt immer so verbaut, dass aus Sicht des Anschlusses zum übergeordneten Netz als definierte Wurzel der Verbrauch positiv (A+) und die Einspeisung negativ (A-) erfasst wird. Das ist völlig eindeutig.

Die Erwartungshaltung des Normalanwenders ist jedoch häufig abweichend und eher aus der Hauptfunktion des jeweiligen Systems betrachtet.
Dazu kommen noch Nischenfälle wo dem Anwender nicht klar ist, dass z.B. ein PV-WR teilweise erheblichen Netzbezug durch eigenverbrauch generieren kann, den man trotzdem nicht einfach ignorieren wenn eine Abrechnung oder Statistik halbwegs korrekt sein soll.

[mucki12]

Die Erwartungshaltung des Normalanwenders ist jedoch häufig abweichend und eher aus der Hauptfunktion des jeweiligen Systems betrachtet. Dazu kommen noch Nischenfälle wo dem Anwender nicht klar ist, dass z.B. ein PV-WR teilweise erheblichen Netzbezug durch eigenverbrauch generieren kann, den man trotzdem nicht einfach ignorieren wenn eine Abrechnung oder Statistik halbwegs korrekt sein soll.

Wie gesagt, passe mich da gerne an wie es für evcc am besten passt. Notfalls drehe ich die Werte halt in meinem HEMS.

Aber genau wegen dem was du geschrieben hast (Eigenverbrauch des Erzeugers) habe ich den Shelly ja als custom meter umgesetzt.

[thierolm]

@mucki12 + @premultiply ich switch mal aus dem PR hier zurück in unsere Diskussion. Diskutiert ihr bitte dort mit mir weiter. Habe Fragen. :-)

[thierolm]

@premultiply + @andig können wir nicht diesen PR von der neuen Diskussion bezüglich der korrekten Abbildung der TotalEnergy abkoppeln und mergen? Mit dem invert Parameter ist jeder Nutzer in der Lage den Power Wert entsprechend seines UseCases zu ändern.

[andig]

Energy ist ein anderes Thema. Ich vermisse hier aber die Entscheiden, das per BC einfach immer beim EM zu invertieren. Falls der sich die Implementierung teil würde ich zu scale statt invert tendieren.

[premultiply]

Können wir schon, gehört aber andererseits auch zusammen.

[andig]

Alles gehört zusammen. Kann man trotzdem schön einzeln lösen und die diffs klein halten. Macht auch die Fehlersuche viel einfacher (auch wenns hier nicht relevant ist).

[thierolm]

Bitte nicht mergen! Bin am Testen ...

[thierolm]

Sieht jetzt m.E. gut aus. Die Shellies liefern jetzt wie von @premultiply empfohlen abhängig von der usage folgende Rückgabewert-Zuordnungen bzw. Vorzeichen:

• pv oder battery: power: *-1, energy: total_returned
• alle anderen: power: *1, energy: total

Für alle Nutzer, die ihre Shellies falsch/verdreht angeschlossen haben, bieten wir die invert Option, die einfach die Auslese-Logik umdreht. Imho passt invert besser als scale, weil scale ja suggeriert, dass man auch noch an den Werten drehen kann ...

[thierolm]

@andig ich habe mir mit der Shelly Pro EM-50 Response von @SolarPower2024 aus #20060 einen einfachen Shelly API Simulator gebaut und damit die PR Version mit folgender Config getestet:
(Da @SolarPower2024 seine negativen Power Messwerte durch Einsatz seines EM-50 für seine PV-Module gemessen hat, werden sie bei der Nutzung mit usage=charge auch negativ ausgegeben. Kämen die Messwerte von einem Verbraucher wären sie ja positiv)

meters:
- name: shelly-pro-em-50-0-pv
  type: template
  template: shelly-1pm
  usage: pv
  host: localhost:8080 # IP-Adresse oder Hostname
  channel: 0 # Optional
  invert: false # Optional

- name: shelly-pro-em-50-0-charge
  type: template
  template: shelly-1pm
  usage: charge
  host: localhost:8080 # IP-Adresse oder Hostname
  channel: 0 # Optional
  invert: false # Optional

- name: shelly-pro-em-50-1-pv
  type: template
  template: shelly-1pm
  usage: pv
  host: localhost:8080 # IP-Adresse oder Hostname
  channel: 1 # Optional
  invert: false # Optional

- name: shelly-pro-em-50-1-charge
  type: template
  template: shelly-1pm
  usage: charge
  host: localhost:8080 # IP-Adresse oder Hostname
  channel: 1 # Optional
  invert: false # Optional

Ergebnis (debug):

thierolm@LAPTOP-KQMMVN3H:~/git-repos/evcc$ ./evcc -c ./evcc_shelly_test.yaml -l debug meter
[main  ] INFO 2025/03/24 23:28:22 evcc 0.201.1 (d74b5c63c)
[main  ] INFO 2025/03/24 22:52:25 using config file: ./evcc_shelly_test.yaml
[db    ] INFO 2025/03/24 22:52:25 using sqlite database: /home/thierolm/.evcc/evcc.db
shelly-pro-em-50-0-pv
---------------------
Power:  332W
Energy: 144.8kWh

shelly-pro-em-50-0-charge
-------------------------
Power:  -332W
Energy: 1.3kWh

shelly-pro-em-50-1-charge
-------------------------
Power:  -38W
Energy: 48.0kWh

shelly-pro-em-50-1-pv
---------------------
Power:  38W
Energy: 33.2kWh

Ergebnis ein Meter (trace):

thierolm@LAPTOP-KQMMVN3H:~/git-repos/evcc$ ./evcc -c ./evcc_shelly_test.yaml -l trace meter
[main  ] INFO 2025/03/24 23:28:22 evcc 0.201.1 (d74b5c63c)
[main  ] INFO 2025/03/24 23:01:13 using config file: ./evcc_shelly_test.yaml
[db    ] INFO 2025/03/24 23:01:13 using sqlite database: /home/thierolm/.evcc/evcc.db
[db    ] TRACE 2025/03/24 23:01:13 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="settings" -1 <nil>
...
[shelly] TRACE 2025/03/24 23:01:13 GET http://localhost:8080/shelly
[db    ] TRACE 2025/03/24 23:01:13 SELECT * FROM `configs` WHERE `configs`.`class` = 2 0 <nil>
[shelly] TRACE 2025/03/24 23:01:13 {"name":"PV Balkon","id":"shellyproem50-08f9e0e7a170","mac":"08F9E0E7A170","slot":1,"model":"SPEM-002CEBEU50","gen":2,"fw_id":"20241011-114451/1.4.4-g6d2a586","ver":"1.4.4","app":"ProEM","auth_en":false,"auth_domain":null}
[shelly] TRACE 2025/03/24 23:01:13 POST http://localhost:8080/rpc/Shelly.GetStatus
[shelly] TRACE 2025/03/24 23:01:13 {"id":0,"on":false,"src":"evcc","method":"Shelly.GetStatus"}
--
{"ble":{},"bthome":{"errors":["bluetooth_disabled"]},"cloud":{"connected":true},"em1:0":{"act_power":-332.2,"aprt_power":335,"calibration":"factory","current":1.473,"freq":50,"id":0,"pf":0.99,"voltage":226.9},"em1:1":{"act_power":-38.5,"aprt_power":97.4,"calibration":"factory","current":0.428,"freq":50,"id":1,"pf":0.38,"voltage":227},"em1data:0":{"id":0,"total_act_energy":1264.15,"total_act_ret_energy":144792.28},"em1data:1":{"id":1,"total_act_energy":48002.83,"total_act_ret_energy":33241.59},"eth":{"ip":null},"modbus":{},"mqtt":{"connected":false},"switch:0":{"id":0,"output":false,"source":"HTTP_in","temperature":{"tC":46.4,"tF":115.5}},"sys":{"available_updates":{"beta":{"version":"1.5.1-beta2"}},"cfg_rev":12,"fs_free":188416,"fs_size":524288,"kvs_rev":0,"mac":"08F9E0E8AF2C","ram_free":107492,"ram_size":249680,"reset_reason":3,"restart_required":false,"schedule_rev":1,"time":"10:42","unixtime":1742809323,"uptime":3671372,"webhook_rev":0},"wifi":{"rssi":-61,"ssid":"Spaetzlewerk","sta_ip":"192.168.1.120","status":"got ip"},"ws":{"connected":false}}
[shelly] TRACE 2025/03/24 23:01:13 POST http://localhost:8080/rpc/Shelly.GetStatus
[shelly] TRACE 2025/03/24 23:01:13 {"id":0,"on":false,"src":"evcc","method":"Shelly.GetStatus"}
--
{"ble":{},"bthome":{"errors":["bluetooth_disabled"]},"cloud":{"connected":true},"em1:0":{"act_power":-332.2,"aprt_power":335,"calibration":"factory","current":1.473,"freq":50,"id":0,"pf":0.99,"voltage":226.9},"em1:1":{"act_power":-38.5,"aprt_power":97.4,"calibration":"factory","current":0.428,"freq":50,"id":1,"pf":0.38,"voltage":227},"em1data:0":{"id":0,"total_act_energy":1264.15,"total_act_ret_energy":144792.28},"em1data:1":{"id":1,"total_act_energy":48002.83,"total_act_ret_energy":33241.59},"eth":{"ip":null},"modbus":{},"mqtt":{"connected":false},"switch:0":{"id":0,"output":false,"source":"HTTP_in","temperature":{"tC":46.4,"tF":115.5}},"sys":{"available_updates":{"beta":{"version":"1.5.1-beta2"}},"cfg_rev":12,"fs_free":188416,"fs_size":524288,"kvs_rev":0,"mac":"08F9E0E8AF2C","ram_free":107492,"ram_size":249680,"reset_reason":3,"restart_required":false,"schedule_rev":1,"time":"10:42","unixtime":1742809323,"uptime":3671372,"webhook_rev":0},"wifi":{"rssi":-61,"ssid":"Spaetzlewerk","sta_ip":"192.168.1.120","status":"got ip"},"ws":{"connected":false}}
Power:  332W
Energy: 144.8kWh

[andig]

@thierolm gem #20060 (comment) lass uns den PR gerne splitten. Hier war nicht ganz einfach nachvollziehbar, was warum geändert wurde. Es wäre hilfreich das Diff klein zu halten (z.B. sind by types.go Strukturen verschoben aber ohne Änderung- vllt. könnten wir die am alten Platz lassen?). Dann lass uns bitte neuen PR nur für die Channelanpassungen machen. Ist dafür usage notwendig? Dann brauchen wir auch eine Idee, was ein neuer Parameter für bestehende Installationen bedeutet.

Den PR hier können wir dann aus master wieder updaten/rebasen und die verbleibenden Änderungen sortenrein anschauen.

[thierolm]

OK, mach ich asap ...

[thierolm]

@andig Den ersten PR habe ich mit #20141 gerade erstellt.

[thierolm]

@andig hab' jetzt in diesem PR den invert Parameter rausgenommen und nur noch die Usage und Installationskonforme Logikanpassung drin gelassen (keine Verrechnung ein- und ausgehenden Energymesswerte bei den EM Shellies)

[andig]

Welchen BC Break verursachen wir jetzt damit?

[andig]

Ich habs nochmal durch geschaut. Es ist unglücklich, dass wir die usage (Logik) jetzt in Connection (Technik) mit drin haben. Schöner wäre es, die Usage auf Ebene des Meter/Chargers zu halten und bei Bedarf ein anderes API der Connection aufzurufen.

[thierolm]

OK, verstehe, dann baue ich es entsprechend um.
BC wäre dann die mögliche Änderung des Powervorzeichens und der Energywerte, je nach individuellem/r Einsatz/Installation.