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?

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

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

@premultiply der PR adressiert nur den Power Messwertact_power.

Für TotalEnergy der Energiezähler bilde ich die Differenz der beiden Zählregistertotal_act_energy undtotal_act_ret_energy.

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

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

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 :-)

Normalerweise Lösen wir die Zuordnung jeweils überusage.

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

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

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 mitusage =grid, müsste ich aber dann immer noch entscheiden, was ich nehme, oder?
Macht der Einsatz eines einphasigen EM Shellies alsgrid überhaupt Sinn?

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

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.

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.

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

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

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

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

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

Bitte nicht mergen! Bin am Testen ...

Sieht jetzt m.E. gut aus. Die Shellies liefern jetzt wie von@premultiply empfohlen abhängig von derusage 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 dieinvert Option, die einfach die Auslese-Logik umdreht. Imho passtinvert besser alsscale, weilscale ja suggeriert, dass man auch noch an den Werten drehen kann ...

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.

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.

@andig +@premultiply: Um die Sonderimplementierung des ShellyEnergyMeters zurückbauen zu können, habe ich die Funktionen für die PhaseVoltages, PhaseCurrents und PhasePowers in das Shelly Meter integriert.
In der aktuellen Version würde bei negativen Power werten diese auch negativ bei den Phasen Powers ausgegeben.

Frage: Sind negative Werte für die PhasePowers API erlaubt, oder muss ich sicherstellen, dass es positive Werte sind?

Beispiel:

shelly-pro-em-50-0-pv---------------------Power:          332WEnergy:         144.8kWhCurrent L1..L3: 1.47A 0A 0AVoltage L1..L3: 227V 0V 0VPower L1..L3:   -332W 0W 0W

Negative Stromwerte sind sogar bevorzugt. 🙂

@andig ich werde aus dem integration test Fehler nicht schlau. Hast du eine Idee was die timeouts auslösen könnte?

Hallo@andig , ich hab die ganze historisch nicht nur durch mich gewachsene Shelly Codebasis mal konsolidiert. Die Wartung und Pflege sollte jetzt wesentlich einfacher sein.
Getestet habe ich alles mit den mir zur Verfügung stehenden gen1, gen2 + gen3 Devices und den mir zur Verfügung stehenden jsons des EM 50.

Ich bräuchte nur Unterstützung beim lokalisieren des Integration Fehlers.

Negative Stromwerte sind sogar bevorzugt. 🙂

@premultiply : Ok :-)

Eine Frage noch zur Sicherstellung positiver Power Werte im Falle das Einsatzes eines Shelly als PV oder Batterie Meters, was ich auf Basis deines Feedbacks eingebaut habe:
Für die PV Usage kann ich das verstehen, da eine Solaranlage Strom ja nur produzieren kann.
Eine Batterie kann aber Strom ins Hausnetz einspeisen (wie eine Solaranlage) aber auch aufnehmen.
Wäre da das Vorzeichen bei Power nicht wichtig? (oder habe ich dich bezgl. Batterie usage falsch verstanden :-) )

Negative Stromwerte sind sogar bevorzugt. 🙂

@premultiply : Ok :-)

Eine Frage noch zur Sicherstellung positiver Power Werte im Falle das Einsatzes eines Shelly als PV oder Batterie Meters, was ich auf Basis deines Feedbacks eingebaut habe: Für die PV Usage kann ich das verstehen, da eine Solaranlage Strom ja nur produzieren kann. Eine Batterie kann aber Strom ins Hausnetz einspeisen (wie eine Solaranlage) aber auch aufnehmen. Wäre da das Vorzeichen bei Power nicht wichtig? (oder habe ich dich bezgl. Batterie usage falsch verstanden :-) )

Habe mir gerade eine Batteriebox ( Stromspeicher) gebaut und will die Werte über ein Shelly PM mini Gen3 erfassen, leider macht mir auch hier die Vorzeichenbehandlung von evcc ein Strich durch die Rechnung und die Ladeleistung wird als entladen angezeigt, obwohl der Wert vom Shelly negativ ausgegeben wird.

@Robodrill1131: Das spricht doch dann für die Sicherstellung des positiven Powerwertes nur für die PV usage ...

@premultiply +@andig : richtig? Dann nehme ich die Vorzeichenbehandlung für battery aus der Logik raus.

@Robodrill1131 könntest du mir eine evcc trace Ausgabe deines Shelly PM mini Gen3 schicken.
Mich interessieren die json Ausgaben ...
... und gibt es im Menü des Shellys eine Option bei Bedarf das von Power Vorzeichen zu drehen?

@thierolm JSON Auszug mach ich mich morgen dran.
Das Vorzeichen passt bei mir, denn wenn die Batterie geladen wird soll es ja negativ sein und beim einspeisen in das Netz soll der Wert positiv sein.

@naltatis könntest du bitte bei Gelegenheit auch mal über den "Integration" Testfehler schauen?
Ich hab mir das ganze Log jetzt einmal angeschaut aber keinen Hinweis auch die Abbruchursache gefunden. Es scheint aber mit den UI Tests zu tun zu haben.
Ich komme nicht weiter. :-(

Hab' das Problem im /shelly Simulator gefunden:https://github.com/thierolm/evcc/blob/1413c4bd9de34999e8c946228b2d5ea5f633634f/tests/simulator/api.js#L74
Der Status Endpoint passt nicht mehr ...

führt zu

Mit den UI Tests über npx playwrigth test habe ich wieder was dazu gelernt :-)
Aber ich würde sagen der PR steht zum mergen bereit.