Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shelly: Standardize measure logic + invert parameter #18841

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

thierolm
Copy link
Contributor

@thierolm thierolm commented Feb 15, 2025

Breaking change:
Instead of providing always positive power values, shelly users can invert the power value.
Additionally the measure logic is following now installation standards.

Refer to discussion #18824

@andig
Copy link
Member

andig commented Feb 16, 2025

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?

@andig andig added the devices Specific device support label Feb 16, 2025
Copy link
Contributor Author

@thierolm thierolm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@thierolm thierolm changed the title Shelly: add IgnorePowerDirection parameter Shelly: add invert parameter Feb 16, 2025
@premultiply
Copy link
Member

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

@andig
Copy link
Member

andig commented Feb 16, 2025

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

@thierolm
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Contributor

mucki12 commented Feb 16, 2025

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
Copy link
Contributor Author

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

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

@premultiply
Copy link
Member

@thierolm
Copy link
Contributor Author

thierolm commented Feb 16, 2025

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
Copy link
Member

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
Copy link
Contributor

mucki12 commented Feb 16, 2025

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
Copy link
Contributor Author

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

@thierolm
Copy link
Contributor Author

@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
Copy link
Member

andig commented Feb 16, 2025

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
Copy link
Member

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

@andig
Copy link
Member

andig commented Feb 16, 2025

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 thierolm changed the title Shelly: add invert parameter Shelly: Standardize measure logic + invert parameter Feb 16, 2025
@thierolm
Copy link
Contributor Author

Bitte nicht mergen! Bin am Testen ...

@thierolm
Copy link
Contributor Author

thierolm commented Feb 16, 2025

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 ...

@andig andig marked this pull request as draft February 17, 2025 07:41
@andig
Copy link
Member

andig commented Feb 17, 2025

Ich finds unglucklich, dass wir jetzt 2 Einstellungen haben welche die Vorzeichen drehen. Reicht es nicht das über Usage zu tun? Ich würde davon ausgehen, dass der Shelly gem. App installiert ist. Falls nein: Zangen drehen. Das ist ja wirklich kein Aufwand.

@thierolm
Copy link
Contributor Author

thierolm commented Feb 17, 2025

Ich meine im Forum schon User Feeback gelesen zu haben, die sich die Shellies haben einbauen lassen. Wenn sie dann nochmal den Installateur ihrer Wahl holen müssen um die Zange(n) zu drehen wäre die Invert Funktion eine Option. Hab' sie auch als advanced Option markiert.

Mit der invert Option die Änderung über das neue Web-UI. Hätten wir nur die usage, müsste das Meter über die config.yaml korrigiert werden, oder?

image
image

@andig andig mentioned this pull request Feb 22, 2025
2 tasks
@andig
Copy link
Member

andig commented Feb 22, 2025

Ich verstehe den PR nicht (mehr). Bitte entscheidet ihr.

@thierolm
Copy link
Contributor Author

thierolm commented Feb 22, 2025

Ich verstehe den PR nicht (mehr)
Tasmota SML hat nichts mit der Shelly Logik hier zu tun. Das Tasmota-SML (nicht Shelly) Template lässt aktuell nur die usage grid zu ...

params:
- name: usage
choice: ["grid"]
- name: host
- name: user
required: false

Das kann ich gerne schnell ändern. Die Tasmota Umsetzung nutzt abs NICHT!

@thierolm
Copy link
Contributor Author

@VolkerK62 welche usage wäre denn für Tasmota SML möglich?
grid, pv, charge, battery?

@VolkerK62
Copy link
Contributor

Ich denke grid alleine ist richtig.
alles andere ist eine seltene Ausnahme und dafür gibt es doch "tasmota"?

@thierolm
Copy link
Contributor Author

@VolkerK62 ich switche wieder in den #19041 chat

@thierolm
Copy link
Contributor Author

Ich verstehe den PR nicht (mehr). Bitte entscheidet ihr.

Ich bin für den Merge und stehe für evtl. nötige fixes und evtl. notwendige Kommunikation mit Usern, die die Messzange falsch eingebaut haben bereit.

@mucki12
Copy link
Contributor

mucki12 commented Feb 22, 2025

Ich bin für den Merge und stehe für evtl. nötige fixes und evtl. notwendige Kommunikation mit Usern, die die Messzange falsch eingebaut haben bereit.

Ich war ein paar Tage evcc mäßig offline (musste meinen Server komplett neu aufbauen) und stehe jetzt für einen Test nach wie vor zur Verfügung.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
devices Specific device support
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants