Darstellung Sonnenbatterie

[Adimarantis]

Schaut ja echt toll aus. Versuche das gerade in mein FTUI3 Design einzubauen.
Allerdings blicke ich bei den vielen Felder nicht mehr durch, wie ich das mappen müsste.
Habe eine ältere Sonnenbatterie (eco 8.0).
Das JSON schaut so aus

Code Auswählen Erweitern

{"Apparent_output":232,"BackupBuffer":"0","BatteryCharging":false,"BatteryDischarging":false,"Consumption_Avg":1560,"Consumption_W":3470,
"Fac":50.00400161743164,"FlowConsumptionBattery":false,"FlowConsumptionGrid":true,"FlowConsumptionProduction":true,"FlowGridBattery":false,
"FlowProductionBattery":false,"FlowProductionGrid":false,"GridFeedIn_W":-3271,"IsSystemInstalled":1,"OperatingMode":"2","Pac_total_W":-5,
"Production_W":205,"RSOC":4,"RemainingCapacity_Wh":237,"Sac1":78,"Sac2":78,"Sac3":77,"SystemStatus":"OnGrid",
"Timestamp":"2022-11-14 11:03:54","USOC":0,"Uac":234,"Ubat":48,"dischargeNotAllowed":false,"generator_autostart":false,"NVM_REINIT_STATUS":0}

Hat das evtl. schon jemand gemapped?

[yersinia]

Das JSON schaut so aus

Wie sind denn die readings des FHEM-Devices (und was bedeuten sie)?

[Adimarantis]

Die Readings sind dann 1:1 das selbe via HTTPMOD

Ganz sicher was diese im einzelnen bedeuten bin ich mir auch nicht. Soweit habe ich es identifiziert:

Code Auswählen Erweitern

[charge-discharge]=????
[soc]="Sonnenbatterie:USOC"
[produce]="Sonnenbatterie:Production_W"
[feed-receive]="Sonnenbatterie:GridFeedIn_W | multiply(-1)"  ????

in GridFeedIn_W steht die Einspeisung ins Netz bzw. negativ wieviel aus dem Netz gezogen wird.
Consumption_W ist der absolute Verbrauch (egal woher)
Die Richtung des Stromflusses ist durch die true/false "Flow....." Readings festgelegt.
Ich befürchte einige Werte muss man anhand dieser Flags aus den anderen Zahlen ausrechnen.
Also je nachdem was in "charge-discharge" und "feed-receive" erwartet wird muss ich evtl. noch extra readings berechnen.

[yersinia]

Schau mal in #157:

[feed]: reading; Einspeisung ins Stromnetz/an EVU; als Wert wird ein Wert >= 0 erwartet
[receive]: reading; Bezug aus Stromnetz/von EVU; als Wert wird ein Wert >= 0 erwartet
Alternativ: [feed-receive]: reading (wenn nur ein Reading für feed und receive zur Verfügung steht und anstelle von feed und receive zu nutzen); dabei gilt:
feed-receive => Wert > 0 (positiv) => Einspeisen ins Stromnetz/an EVU => wird feed zugeschrieben (receive ist damit 0)
feed-receive => Wert < 0 (negativ) => Verbrauch aus Stromnetz/vom EVU => wird zur Anzeige und weiteren Berechnung zum positiven konvertiert und receive zugeschrieben (feed ist damit 0)

[charge]: reading; Ladewert des Akkus; als Wert wird ein Wert >= 0 erwartet
[discharge]: reading; Entladung des Akkus; als Wert wird ein Wert >= 0 erwartet
Alternativ: [charge-discharge]: reading (wenn nur ein Reading für charge und discharge zur Verfügung steht und anstelle von charge und discharge zu nutzen); dabei gilt:
charge-discharge => Wert < 0 (negativ) => Akku entladen => wird zur Anzeige und weiteren Berechnung zum positiven konvertiert und discharge zugeschrieben (charge ist damit 0)
charge-discharge => Wert > 0 (positiv) => Akku laden => wird charge zugeschrieben (discharge ist damit 0)

Interessant wäre das Reading wenn der Akku ge/entladen wird, dies(e) kannst du dann entsprechend in charge, discharge oder charge-discharge einsetzen.

Code Auswählen Erweitern

[soc]="Sonnenbatterie:USOC"
scheint falsch zu sein - ist der Ladestand des Akkus wirklich 0%? Oder sollte es eher

Code Auswählen Erweitern

[soc]="Sonnenbatterie:Ubat"
sein?

In deinem Auszug wird ja die Batterie weder ge- noch entladen, oder?

Code Auswählen Erweitern

"BatteryCharging":false,"BatteryDischarging":false
Spannend wären die Werte, wenn der Akku ge/entladen wird.

Wenn ich dein JSON richtig verstehe, dann ist das multiply(-1) hier falsch

Code Auswählen Erweitern

[feed-receive]="Sonnenbatterie:GridFeedIn_W | multiply(-1)"
und kannst du eigtl weglassen, weil

Code Auswählen Erweitern

"GridFeedIn_W":-3271
-> entspricht meines Verständnisses eines Bezugs aus dem Netz (GrdiFeed wäre imho positiv wenn du ins Netz einspeist).

[Adimarantis]

Danke. Mit richtigem Vorzeichen, schaut es doch gleich besser aus.
USOC macht schon Sinn (Was UBat ist weiss ich nicht - evtl. 50 Hz? Meine Batterie ist fast leer)
In RSOC stehen 4% (weil noch Tiefentladungsreserve) aber USOC mit 0% ist die nutzbare Kapazität

BatteryCharging/Discharging sind ja auch nur true/false Flags.
Das muss ich wohl echt ausrechnen:
[charge-discharge]="Sonnenbatterie:Production_W - Sonnenbatterie:Consumption_W - Sonnenbatterie:GridFeedIn_W"
Kann man so aber wahrscheinlich nicht eintragen, sondern braucht ein Userreading in FHEM
Edit: Erst beim Ausrechnen gesehen: das müsste "Pac_total_W" sein. Nur beim Vorzeichen bin ich mir nicht sicher.

Die Flags sollten dann eigentlich egal sein.
Muss dann nur mal warten, dass die Batterie wirklich lädt. Leider NWW Dach (auf SSO geht noch alles zu guten Konditionen in die Einspeisung), daher wird dann in dieser Jahreszeit meistens alles gleich verbraten.

[yersinia]

Erst beim Ausrechnen gesehen: das müsste "Pac_total_W" sein. Nur beim Vorzeichen bin ich mir nicht sicher.

Ja, ich komm aber auf 6 und nicht -5.
Warte mal bis der Akku geladen wird und schau dir dann die Werte an. Alles andere ist, ohne weitere Doku der Schnittstelle, stochern im Dunkeln.

Btw, was ist das für ein Wert?

Code Auswählen Erweitern

Apparent_output":232

[mr_petz]

Bestimmt 232V

[docolli]

[FTUI3]
@docolli: cool. Danke fürs Teilen! Ist auch weniger überfrachtet als ich befürchtet habe. Wenn hier mehr Interesse besteht, übernehme ich das in die 'offizielle' Version.

Na, dann stelle ich den Code hier mal zur Diskussion. Ich habe noch die heutigen <text> Änderungen von @yersinia eingebaut. Meine Texte sind in einer mir passenden Größe, die Min/Max Werte dazu in der CSS muss man vielleicht noch anpassen. Durch die Änderung haben sich aber die Textgrößen der Energieflusswerte geändert. Wo kann ich das jetzt wieder so wie vorher einstellen? In der <pvvis> Definition mit class="size-x"?

Edit: Ja, mit class="size-2" sind die Textgrößen wieder ungefähr so, wie sie es vorher waren.

Edit2: Mir fällt gerade auf, dass die Berechnung der Akkurestzeit in meinem Code nur funktioniert, wenn als [soc] ein Prozentwert des aktuellen Akkustands übergeben wird (also Werte von 0 bis 100). Wer den Akkustand in Wh übergibt, bei dem stimmt die berechnete Zeit leider nicht!

[iron.eagle]

@iron.eagle
Hast du width gesetzt?
Eigentlich gehe ich davon aus, dass durch setzen des width Attributs das SVG entsprechend skaliert - dementsprechend auch die Texte größer werden.
Du kannst zum Testen die font-size Definitionen aus der pvvis.component.css auskommentieren (mit /* am Anfang und */ am Ende der Zeile), als Beispiel für den Produktionstext:

Code Auswählen Erweitern

.pvvis-produce-txt {
  text-anchor: start;
/*  font-size: 20px; <-- hier */
  fill: var(--pvvis-color-grey, #ccc);
}
Und dann zB class="size-2" in der component setzen.

@yersinia
Mit Schreibfehler gesetzt, deswegen war alles so klein 

[docolli]

Weiter geht's mit den Ideen. Ich finde es besser, die noch im Speicherakku befindlichen kWh angezeigt zu bekommen, als die genaue Prozentzahl. Hier genügt mir der ungefähre Wert über das Batteriesymbol (0/25/50/75/100).

Wenn man in meiner pvvis Version den Parameter "unit-soc" mit "kWh" definiert, so wird über "battmax" und "soc" die Restkapazität berechnet und dargestellt. Bei allen anderen Werten ist es so wie vorher.
Konsequenz ist, dass nun über "soc" unbedingt der Füllstand (0 - 100%) übergeben werden muss! Ein anderer Wert (z.B. in kWh) führt zu einer falschen Berechnung.
Aber wenn ich den Code der Füllstandsdarstellung im Batteriesymbol von @yersinia richtig verstehe, benötigt auch dieser in "soc" einen Prozentwert.

Hier eine Darstellung und der aktuelle Code.

[yersinia]

soc muss aber nicht in % angegeben werden, du kannst es auch mit kWh übergeben; musst dann aber zwangsweise auch battstep anpassen.

Du kannst natürlich prüfen ob soc als % oder kWh übergeben wird und dann soc für die ladebalken dynamisch aus battmax errechnen. Dann hat deine Zeitberechnung auch keine Probleme...
Edit: ich glaube, so einfach wird das nicht. soc kann %, Wh aber kWh sein. Wenn du dein Akku mit 8000Wh (battmax) und den soc mit 1200Wh angibst, kannst du die Berechnung gut auseinanderhalten. Wenn du allerdings kWh übergibst (battmax=8 und soc=1.2), dann wird es schon schwieriger, Wh von % auseinanderzuhalten. Für eine generische Version würde ich erstmal die Zeitberechnung weglassen.
Edit2: man könnte natürlich einen Parameter/Schalter einbauen, der das ganze übersteuert; sowas wie bat-remain-soc-not-percent evtl; dann kann der Benutzer selbst steuern

btw, ich bin gerade dabei alle deine Ideen zu übenehmen. Gefällt mir, ist nicht zu überladen und abwärtskompatibel.

[docolli]

Einen extra Parameter wollte ich nicht schon wieder einführen, darum schaue ich bei soc schon auf die Einheit "kWh" und rechne nur dann.

battstep hatte ich nicht auf dem Schirm, da ich das nicht brauche. Aber ja, da wird's dann langsam kompliziert. Man müsste wirklich fordern, dass unit-soc gesetzt wird und dann eventuell ein Switch, um die Anzeige von Unit(s) ausblenden zu können.

btw: da ich grad das Auto lade fällt mir auf, dass seit dem text Umbau die Position der Wallboxleistung nicht mehr stimmt. Ich habe jetzt folgende Position genommen:

Code Auswählen Erweitern

<text id="home-car-txt" x="70" y="295"  class="pvvis-text" style="text-anchor: start;"></text>


Aktuell habe ich mir eine gelbe Linie gebaut, die innerhalb der Batteriesegmente zwischen 0 und 100% hochgeht und somit optisch den genauen Füllstand anzeigt. Die Linie sollte (nicht getestet) auch korrekt bei soc in Wh bzw. kWh und andere battstep Werte gesetzt werden. Siehe Bild.

Für die Darstellung des Füllstandes hätte ich noch eine andere Idee, basierend auf SVG Masken, mit denen man Teile eines Objektes transparent machen kann. Damit könnte man die Trennstriche realisieren und bräuchte nur zwei oder drei Rechtecke. Eines von unten bis zum aktuellen Füllstand (ohne Transparenz). Darüber eines vom Füllstand bis zu 100% mit hoher Transparenz. Entweder blinkt dies komplett, oder man legt noch ein drittes dazwischen mit einer gewissen Höhe, das blinkt. Somit bräuchte man nicht aufwendig die einzelnen Segmente herausfinden (25/50/75/100), sondern legt über den kontinuierlichen Füllstand einfach die Trennstriche drüber. Man könnte sogar eine andere Anzahl als 4 Segmente realisieren. Ist ja nur eine Maske, die drüber liegt.
Leider hab ich das noch nicht im SVG hinbekommen, aber siehe hier: https://stackoverflow.com/questions/22579508/subtract-one-circle-from-another-in-svg

Oh, ich sehe gerade man kann mit Inkscape auch ein optimiertes SVG speichern, das wäre eine gute Grundlage.
Das Bild zeigt links die 3 Trenner in schwarz (gruppiert), rechts habe ich diese als Maske vom grünen Rechteck abgezogen.
Der Kreis scheint nun durch.

[mr_petz]

...
btw: da ich grad das Auto lade fällt mir auf, dass seit dem text Umbau die Position der Wallboxleistung nicht mehr stimmt. Ich habe jetzt folgende Position genommen:

Code Auswählen Erweitern

<text id="home-car-txt" x="70" y="295"  class="pvvis-text" style="text-anchor: start;"></text>

....

Das geht auf meine Kappe
Sorry

LG

[docolli]

@ mr_petz: kein Problem 

Ich habe inzwischen einen Prototypen der Akkuanzeige gebastelt.
Habe auf die korrekten Proportionen nicht geachtet, nur per Auge nachgebaut.
Mir ging es darum herauszfinden, was nötig ist.

z.B. braucht man ein weißes Rechteck in der Maske. Nur was dieses überdeckt wird auch dargestellt!

Code Auswählen Erweitern

<?xml version="1.0" encoding="UTF-8"?>
<svg width="300px" height="300px" version="1.1" xmlns="http://www.w3.org/2000/svg">
<defs>
  <mask id="pvvis-batseparatormask">
   <rect x="40" y="80" width="40" height="100" fill="#fff"/>
   <g>
    <rect x="39" y="100" width="42" height="5" color="#000000"/>
    <rect x="39" y="125" width="42" height="5" color="#000000"/>
    <rect x="39" y="150" width="42" height="5" color="#000000"/>
   </g>
  </mask>
</defs>
  <g fill="#2f7126" mask="url(#pvvis-batseparatormask)">
   <rect id="pvvis-batsocremain" x="40" y="80" width="40" height="35" fill-opacity=".8"/>
   <rect id="pvvis-batsoc" x="40" y="115" width="40" height="60"/>
  </g>
</svg>

Edit: das angehängte SVG passt exakt zur bisherigen Batterie und zeigt, wohin es gehen kann.
Darin sind zwei Masken definiert (25 und 20% Abstand). Man muss nur den mask Bezug ändern.

[yersinia]

[FTUI3]
Man, man, man - so schnell komm ich gar nicht nach mit frickeln so wie die Ideen hier sprudeln.
Wie schon angedroht, habe ich eigentlich alle deine Ideen adaptiert übernommen - vielen Dank für die vielen Vorschläge. Wegen der "Abwärtskompatibilität" musste ich natürlich auch schauen, was mit den Elementen passieren soll, wenn Werte wie car-temp oder grid-feed-tdy nicht definiert werden.

Das der WB-Wert falsch verortet war, ist mir gar nicht aufgefallen. Ist aber korrigiert mit dieser Version

Anbei eine neue Version, mit folgenden Erweiterungen:
- kleiner fix der Ladebalkenanzeige des Akkus wenn soc nicht als % vorliegt (verdammte textsortierung); in diesem Zusammenhang noch der Hinweis: wenn soc nicht als % vorliegt, sollte battstep entsprechend angepasst werden
- alle Ideen von docolli inklusive neuer (wieviel Paramater wollt ihr? JA!) und angepasster (!) parameter sowie optional zu setzender units zum frei wählen:

[car-soc]: reading, optional; Ladestand des Akku vom eAuto
unit-car-soc: fester Wert, optional; setzt die Einheit für den Ladestand des eAuto
[car-temp]: reading, optional; Innentemperatur des eAuto in °C

[pv-prod-tdy]: reading, optional; heutiger PV-Ertrag (in kWh)

[pv-forecast]: reading, optional; voraussichtlicher heutiger PV-Ertrag (in kWh)

[home-consume-tdy]: reading, optional; bisheriger Tages-Stromverbrauch

[grid-feed-tdy]: reading, optional; bisherige/heutige Einspeisung ins Stromnetz

[grid-consume-tdy]: reading, optional; bisherige/heutige Entnahme aus dem Stromnetz

unit-sum: fester Wert, optional; setzt die Einheit für die Summen (zB kWh)

battmax: fester Wert, optional; Hausakkukapazität in Wh (muss gesetzt werden wenn Ent/Ladezeitschätzung angezeigt werden soll -> siehe calc-bat-remain-time)
batmax: fester Wert, optional; Hausakkukapazität in Wh (muss gesetzt werden wenn Ent/Ladezeitschätzung angezeigt werden soll -> siehe calc-bat-remain-time)
calc-bat-remain-time: optional; wenn gesetzt, wird die (stark vereinfachte) geschätzte Ent/Ladezeit des Akkus basierend auf dessen Kapazität berechnet und angezeigt; dafür muss zwingend battmax gesetzt sein
calc-bat-remain-soc-not-percent: optional; sollte gesetzt werden wenn calc-bat-remain-time gesetzt ist und soc nicht als prozentualer Wert vorliegt; dies kann pvvis nicht selbst ermitteln.

flow-threshold: fester Wert, optional; Schwellwert, ab dem der Energiefluss durch Animation und leuchtender Farbe visualisiert wird

- wenn car-soc definiert ist, wird der Ladestand des Autos farblich dargestellt; (anteilig) gelb wenn nicht geladen und grün wenn geladen wird (wb-feed > 0)
- der Ladestand des Akkus wird nun als schmaler roter Balken nebst Pfeil rechts neben dem Akku angezeigt
- es gelten die bestehenden Parameter => post #157

Für jene mit bestehender FTUI3-pvvis Definition können, sofern sie wollen, diese Version eigentlich ohne Einschränkungen übernehmen - allerdings beide files (css & js). Backup nicht vergessen.

Viel Spaß beim & Danke fürs Testen!