Darstellung Sonnenbatterie

Begonnen von dennis_n, 11 März 2021, 10:33:34

Vorheriges Thema - Nächstes Thema

yersinia

Die Frage ist ja vielmehr, ob man Autarkie und Eigenverbrauch als relativen Wert sehen möchte - fürs das gute Gefühl: Autarkie bei 98%, Eigenverbrauch bei 100%. ;)
Und wenn ja, wie und vor allem wo soll dies noch in pvvis dargestellt werden?
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

docolli

Zitat von: yersinia am 25 November 2022, 08:48:13
Die Frage ist ja vielmehr, ob man Autarkie und Eigenverbrauch als relativen Wert sehen möchte - fürs das gute Gefühl: Autarkie bei 98%, Eigenverbrauch bei 100%. ;)
Und wenn ja, wie und vor allem wo soll dies noch in pvvis dargestellt werden?

Nun ja, E3DC "verkauft" schon das gute Gefühl Autark zu sein. ;)
Wohin und wie in pvvis habe ich mir noch keine große Gedanken gemacht. Vielleicht unten neben dem Pylon, hat ja hauptsächlich was mit Einspeisung und Verbrauch zu tun.

eurofinder

Den Vorschlag von docolli finde ich gut.
Alternativ könnte ich mir vorstellen, dass Eigenverbrauch oben in/unter der Sonne und Autarkie in/unter dem Haus platziert wird.
Dank übrigens an alle, die sich hier beteiligen. Ich finde eine tolle Entwicklung.

Gruß
eurofinder
RPI3+; Raspbian Buster Lite; RPI-RF-MOD; piVCCU3, HMIP-eTRV-2, HmIP-SWDO, HmIP-SRH, HmIP-STHO, HmIP-SLO

docolli

#258
An "in die Sonne/Haus" hatte ich auch schon gedacht, das könnte man aber zumindest bei der Sonne mit dem Prozentwert der erzeugten Leistung im Vergleich zu Maximalleistung (kWp) verwechseln. Das ist zwar schon über die Sonnenfarbigkeit codiert, aber dennoch finde ich das dies vermutlich missverstanden wird.

Mir ist auch noch kein klar verständliches Symbol zu "Eigenstrom/Eigenverbrauch" bzw. "Autarkie" untergekommen. Ich behelfe mir grad einfach mit den Doppelpfeilen, die aber durchgestrichen sind. Es ist ja eben das, was NICHT bezogen bzw. eingespeist wird.

Rechnen würde ich nicht mit den aktuellen Leistungswerten der Stränge, sondern mit den Energiesummen des Tages. Somit hat man die Werte wenigstens von diesem Tag (today so far).


let selfConsume = (this.pvProdTdy!=0 ? (this.pvProdTdy - this.gridFeedTdy) / this.pvProdTdy * 100 : 0);
let autarky = (this.homeConsumeTdy!=0 ? ((1 - this.gridConsumeTdy / this.homeConsumeTdy)*100) : -1);


Oben habe "0" als Wert gewählt, wenn die Produktion noch "0.0" ist, da es mir logisch erscheint, dass wenn man noch nichts produziert hat, auch noch keinen Eigenverbrauch haben kann.
Bei der Autarkie bin ich mir noch nicht sicher. Wenn man noch nichts verbraucht hat, ist dann die Autarkie "0" oder "100%"? Darum mal "-1", dann sehe ich hier, dass ich/wir noch eine Entscheidung treffen müssen.

Edit: Zweites Bild mit Vorschlag Balken im Haus + Anzeige unterhalb. Mir ist klar, dass es noch zwei weitere "Haussymbole" gibt, wo das nicht so funktioniert.
Grundsätzlich denke ich aber die Anzeige(n) sollten ins/ans Haus.

docolli

#259
So, heute morgen sehe ich schon das erste Problem meiner Berechnung in pvvis.
Ich habe eine negative Autarkie! Warum?

Ich habe über Nacht das E-Auto geladen, damit habe ich fast 14kWh Netzbezug, aber mein Hausverbrauch war nur 5.2kWh. Mein FHEM Device integriert nur den reinen Hausverbrauch ohne Wallbox auf. Und so übergebe ich diesen auch an pvvis. Mir persönlich ist eine Trennung zwischen dem was das Haus verbraucht und was dann das E-Auto verbraucht wichtig. Darum ja auch der Parameter "no-wb-in-home".  ;)
Da das Netz sowohl Haus, als auch Wallbox versorgt, muss ich konsequenterweise auch Haus- UND den Wallboxverbrauch dazu in Relation setzen, um eine vernünftige Berechnung machen zu können. Es müsste also noch ein Parameter rein, der aus FHEM den integrierten Wallboxtagesverbrauch in kWh übergibt.

Den Wert hätte ich ... ;D

Oder die Berechnung muss ins FHEM-Device ausgelagert werden und pvvis stellt die Prozentwerte nur dar. Ich müsste dann z.B. gar nicht rechnen, weil mein E3DC mir diese beiden Kennzahlen zur Verfügung stellt.

yersinia

Zitat von: docolli am 26 November 2022, 11:47:19Oder die Berechnung muss ins FHEM-Device ausgelagert werden und pvvis stellt die Prozentwerte nur dar. Ich müsste dann z.B. gar nicht rechnen, weil mein E3DC mir diese beiden Kennzahlen zur Verfügung stellt.
Ja. Genau so stell' ich mir das eigentlich vor - viele Daten müssten dafür pvvis geleifert werden für eine Berechnung. Laienhaft stelle ich mir das so vor:
Autarkie = Anteil des selbst erzeugten Stroms am Gesamtverbrauch (Haus + Wallbox + Akkuladung); soweit Netzbezug dabei ist, schrumpft der Autarkiegrad
Der Eigenverbrauch ist ja analog zur Autarkie, nur das man die Netzeinspeisung mit einbezieht und dann den Wert bei steigender Netzeinspeisung entsprechend verringert.

Die Balkendarstellung im Haus sieht nach einem weinenden Haus aus. ;D Aber mir fällt auch keine bessere Darstellung ein. Allerdings ist ja links oben noch etwas Platz und man könnte eine Arte Ladebalken darstellen. Analog zu den flows, etwas kleiner und feiner und ohne Animation aber farblicher Verlauf (gradient) wie (optional) bei der Batterie.

Hat eigtl mal jemand getestet, ob man die units umstellen kann? Zb von Wh auf kWh wenn die Werte größer 1000 (Wh) sind? MMn müsste das eigtl out-of-the-box funktionieren.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

octek0815

Zitat von: yersinia am 27 November 2022, 20:35:08
Hat eigtl mal jemand getestet, ob man die units umstellen kann? Zb von Wh auf kWh wenn die Werte größer 1000 (Wh) sind? MMn müsste das eigtl out-of-the-box funktionieren.

Funktioniert nicht oder ich habs nicht verstanden was ich umstellen muss.
Grundsätzlich würde ich es begrüßen wenn die Anzeigen die in Watt geliefert werden automatisch bei größer 999 in kW angezeigt werden.
Es müsste sich dann allerding auch die angehängte Einheit automatisch von W aug kW umstellen.

yersinia

#262
Zitat von: octek0815 am 29 November 2022, 08:21:27Grundsätzlich würde ich es begrüßen wenn die Anzeigen die in Watt geliefert werden automatisch bei größer 999 in kW angezeigt werden.
Es müsste sich dann allerding auch die angehängte Einheit automatisch von W aug kW umstellen.
Da pvvis nicht weiss, welche Werte in welchen Einheiten übergeben werden und ich eigtl auch nicht auf optionalen Einheiten prüfen möchte, sehe ich da derzeit keine saubere Möglichkeit, dass zu implementieren.

Ich kann mir allerdings vorstellen, dass es FHEM-seitig bereits (user)readings gibt, die dann entsprechend Werte umwandeln (zB ab 999[W] => 1[kW]). Demnach kann es ein weiteres (user)reading geben, welches dann entsprechend Wh auf kWh ändert und entsprechend eingebunden wird, in etwa so:
[unit-value]="DEVICE:READING"
[unit-sum]="DEVICE:READING"


Was schwierig werden funktionieren könnte ist eine pipe:
[unit-value]="DEVICE:READING | step('0:`W`, 1000:`kW`')"
weil und dann die Werte unter zB produce analog geändert werden müssten ändern (ungetestet):
[produce]="DEVICE:READING | v=>Number(v)>=1000?(v/1000):v"
Hat aber den Nachteil, dass pvvis in der Darstellung angepasst werden muss und der user alle readings gleichbehandeln muss: wenn zB produce von 3800W auf 3.8kW gekürzt wird, muss zB die Akkuladung (charge, discharge, charge-discharge) auch von 400W auf 0.4kW reduziert werden. Dies allein in FTUI3 bzw pvvis abzubilden ist quasi unmöglich (zumindest nach meinem derzeitigen Kenntnisstand) - daher: userReading in FHEM!
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

yersinia

Anbei ein Beispiel/Vorschlag/Diskussionsgrundlage, wie man die Autarkiegrad (unten rechts) und Eigenverbrauchsanteil (oben links) abbilden könnte. Beide Werte kommen aus FHEM und werden als % (0-100) übergeben. Die Balken färben sich dynamisch ein von 0%=rot zu 100%=grün (gleiche gradient funktion wie bei battery) und wachsen entsprechend prozentual in der Breite (progress bar). Die Werte sind nur Beispielhaft zum Testen herangezogen und haben mit den anderen Werten nichts zu tun.
Ich finde die Darstellung aber irgendwie noch nicht selbsterklärend. Daher, wie gesagt, eine Diskussionsgrundlage.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

papa

Ich bin zwar kein direkter Nutzer - aber hier mal ein Kommentar von mir.
Mittlerweile finde ich das ganze extrem überfrachtet. Werte lassen sich doch auch einfach mit FTUI-Hausmitteln in die Oberfläche anzeigen. Man kann mit HTML auch Sachen übereinanderlegen. Also warum alles in diese eine Widget einbauen ?

Ich habe z.B. meine "Großverbraucher" als Symbole über das Haus platziert. Aber das sind "ganz normale" FTUI-Symbole.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

yersinia

Zitat von: papa am 29 November 2022, 09:56:12Mittlerweile finde ich das ganze extrem überfrachtet. Werte lassen sich doch auch einfach mit FTUI-Hausmitteln in die Oberfläche anzeigen. Man kann mit HTML auch Sachen übereinanderlegen. Also warum alles in diese eine Widget einbauen?
Bequemlichkeit der Anwender? Weil nicht jeder in der Lage ist, Labels dynamisch in FTUI3 zu platzieren? Weil es so einfacher ist? Es offensichtlich Bedarf gibt? Die Frage der Überfrachtung subjektiv ist? Weil der Zug eigentlich hier schon abgefahren ist? Ansonsten dacor.
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

octek0815

Zitat von: yersinia am 29 November 2022, 09:26:03
Anbei ein Beispiel/Vorschlag/Diskussionsgrundlage, wie man die Autarkiegrad (unten rechts) und Eigenverbrauchsanteil (oben links) abbilden könnte. Beide Werte kommen aus FHEM und werden als % (0-100) übergeben. Die Balken färben sich dynamisch ein von 0%=rot zu 100%=grün (gleiche gradient funktion wie bei battery) und wachsen entsprechend prozentual in der Breite (progress bar). Die Werte sind nur Beispielhaft zum Testen herangezogen und haben mit den anderen Werten nichts zu tun.
Ich finde die Darstellung aber irgendwie noch nicht selbsterklärend. Daher, wie gesagt, eine Diskussionsgrundlage.

Finde ich nicht so optimal, und ich persönlich brauche es nicht.

octek0815

Zitat von: yersinia am 29 November 2022, 08:42:26
Da pvvis nicht weiss, welche Werte in welchen Einheiten übergeben werden und ich eigtl auch nicht auf optionalen Einheiten prüfen möchte, sehe ich da derzeit keine saubere Möglichkeit, dass zu implementieren.

Ich kann mir allerdings vorstellen, dass es FHEM-seitig bereits (user)readings gibt, die dann entsprechend Werte umwandeln (zB ab 999[W] => 1[kW]). Demnach kann es ein weiteres (user)reading geben, welches dann entsprechend Wh auf kWh ändert und entsprechend eingebunden wird, in etwa so:
[unit-value]="DEVICE:READING"
[unit-sum]="DEVICE:READING"


Was schwierig werden funktionieren könnte ist eine pipe:
[unit-value]="DEVICE:READING | step('0:`W`, 1000:`kW`')"
weil und dann die Werte unter zB produce analog geändert werden müssten ändern (ungetestet):
[produce]="DEVICE:READING | v=>Number(v)>=1000?(v/1000):v"
Hat aber den Nachteil, dass pvvis in der Darstellung angepasst werden muss und der user alle readings gleichbehandeln muss: wenn zB produce von 3800W auf 3.8kW gekürzt wird, muss zB die Akkuladung (charge, discharge, charge-discharge) auch von 400W auf 0.4kW reduziert werden. Dies allein in FTUI3 bzw pvvis abzubilden ist quasi unmöglich (zumindest nach meinem derzeitigen Kenntnisstand) - daher: userReading in FHEM!

Alles klar, kein Problem und sehe ich ein.
Kam nur auf die Idee, da es in Fronius Solarweb auch so dargestellt wird...

yersinia

Zitat von: octek0815 am 29 November 2022, 12:07:22Finde ich nicht so optimal, und ich persönlich brauche es nicht.
Die Darstellung wäre sowieso optional und muss explizit durch setzen der Werte aktiviert werden. Hast/brauchst du die Werte nicht, wird es nicht angezeigt. So zumindest die Idee

viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

docolli

#269
Zitat von: yersinia am 29 November 2022, 12:33:06
Die Darstellung wäre sowieso optional und muss explizit durch setzen der Werte aktiviert werden. Hast/brauchst du die Werte nicht, wird es nicht angezeigt. So zumindest die Idee

So hatte ich es auch immer gedacht, die zusätzlichen Werte nur optional darzustellen. Werden sie nicht übergeben, so sieht pvvis so aus wie "früher", bevor der Zug durch meinen Kommentar in dieser Richtung losgerollt ist... ::)
Ich bin auch der Meinung, wir sind jetzt an einem Punkt, an dem der verfügbare Platz voll ausgereizt ist. Dein Vorschlag zu Eigenverbrauch (EV) und Autarkie (AU) ist mir auch viel zu überfrachtet. Liegt einerseits an den großen Schriften für die Leistungswerte und die Prozentbalken für EV und AU sind auch vieeel zu mächtig und verdrängen die Aufmerksamkeit von den Energieflussdarstellung. Aber ich habe es ja mit meinem "weinenden Haus" auch nicht besser hinbekommen.  ;)

Machen wir also von mir aus einen Schnitt und bleiben beim KISS Prinzip. Wer mehr möchte, muss sich weitere darüber liegende FTUI Elemente / UserReadings selber basteln.

@papa: Danke für den Vorschlag, dass man ja FTUI Elemente per HTML übereinander legen könnte. Da würde mich mal interessieren, wie man das konkret macht. Bislang dachte ich, dass man, wenn man den freien Platz in pvvis nutzen möchte, auch in pvvis rein muss und das dort einbauen muss.

@yersinia: Auch deine Anregung mit der Umrechnung von W auf kW finde ich spannend! Was geht denn da so alles in den pipes? Bislang dachte ich, da gehen nur in FTUI3 definierte Befehle, aber anscheinend geht dort noch wesentlich mehr. Gibt es dazu eine Doku? 8)