Hallo,
ich habe eine PV Anlage mit einem Sonnenspeicher. Den habe ich auch entsprechend in fhem einbinden können und habe alle Daten als Readings zur Verfügung.
Zur Steuerung von fhem nutze ich Tablet UI und ein iPad im Wohnzimmer.
Jetzt würde ich gerne diese schöne Grafik, die bei dem Sonnenspeicher angezeigt wird, in Tablet UI darstellen.
Gibt es eine Möglichkeit oder Widget, um eine Flussrichtung anzuzeigen? Wenn nicht, hat jemand eine Idee wie man das realisieren könnte?
Beispielsweise mit animated Gif's oder so?
Hier mal ein Beispiel, wie ich es in der App dargestellt bekomme:
Die Readings zur Azeige der Flussrichtung lauten:
FlowConsumptionBattery --> 0
FlowConsumptionGrid --> 0
FlowConsumptionProduction --> 1
FlowGridBattery --> 0
FlowProductionBattery --> 0
FlowProductionGrid --> 1
Je nach Wert soll dann die Flussrichtung angezeigt werden.
Danke
Gruss
Dennis
Habe sowas mal angefangen mit SVG umzusetzen. Sieht dann in etwa so aus wie im angehängten Example-HTML. Die Energieströme werden abhängig von Readingswerten per SVG-Animation animiert.
Könnte heute Abend mal den Widget-Stand zur Verfügung stellen. Vielleicht hat ja jemand mehr Zeit, das mal richtig fertig zu machen.
Oh das sieht schonmal sehr interessant aus.
Wie versprochen der aktuelle Stand. Wie gesagt, habe leider keine Zeit, um da schnell vorwärts zu kommen.
fhem-tablet-ui-user.css muss ins css-Verzeichnis. widget_pvvis.js ins Widget-Verzeichnis. Folgende Attribute werden unterstützt:
data-device - Gerät, das den Refresh triggert
data-get - Verbrauch Haus
data-feed - Einspeisungs in Netz
data-produce - Production PV-Anlage
data-charge - Ladung Akku
data-discharge - Entladung Akku
data-soc - Ladezustand Battery
data-pv-max - Maxiamle Leistung PV
data-width - Breite des Widget
data-height - Höhe des Widget
Meine Definition ist:
<div data-type="pvvis" data-device="SB25MBus"
data-get="PowerMeter:power_consumption" data-feed="PowerMeter:power_feed"
data-produce="SB25MBus:SPOT_PACTOT" data-pv-max="1700"
data-width="340" data-height="340" class="centered">
</div>
Akku kommt erst nächste Woche :-)
Hi,
ich danke Dir schonmal und schaue mir das mal an.
Vielleicht bekomme ich es ja hin das Plugin fertig zu machen.
Habe damit aber keinerlei Erfahrung.
Vielleicht können wir uns ja mal per PN austauschen.
Gruss
Dennis
Also ich habe mir das alles mal angeschaut und muss leider zugeben, dass ich damit hoffnungslos überfordert bin (mit der Fertigstellung eines solchen Plugins)
Mir fehlt da einfach das nötige Grundwissen, da ich ja kein Programmierer bin.
Aber so wie ich das als absoluter Laie beurteilen kann, scheint ja wirklich nicht mehr viel zu fehlen.
Wäre echt klasse wenn das jemand gertig machen würde.
Es haben doch bestimmt noch mehr Personen Interesse an einem solchen Plugin. ::)
Gruss
Dennis
Ich könnte das gut gebrauchen als Plugin:-)
Gruß
eurofinder
Ich habe mir da jetzt mal was gebastelt. Die grünen Pfeile ändern entweder dir Richtung oder werden nicht angezeigt. Je nach Wert, der ausgelesen wird.
Ist nicht schön, aber fürs erste ok.
Vielleicht schafft es papa ja noch seine Arbeit zu vollenden ;)
Gruss
Dennis
Zitat von: papa am 11 März 2021, 20:19:29
Wie versprochen der aktuelle Stand. Wie gesagt, habe leider keine Zeit, um da schnell vorwärts zu kommen.
fhem-tablet-ui-user.css muss ins css-Verzeichnis. widget_pvvis.js ins Widget-Verzeichnis. Folgende Attribute werden unterstützt:
data-device - Gerät, das den Refresh triggert
data-get - Verbrauch Haus
data-feed - Einspeisungs in Netz
data-produce - Production PV-Anlage
data-charge - Ladung Akku
data-discharge - Entladung Akku
data-soc - Ladezustand Battery
data-pv-max - Maxiamle Leistung PV
data-width - Breite des Widget
data-height - Höhe des Widget
Meine Definition ist:
<div data-type="pvvis" data-device="SB25MBus"
data-get="PowerMeter:power_consumption" data-feed="PowerMeter:power_feed"
data-produce="SB25MBus:SPOT_PACTOT" data-pv-max="1700"
data-width="340" data-height="340" class="centered">
</div>
Akku kommt erst nächste Woche :-)
Hallo bin zufällig auf dieses Thema gestoßen. Wollte mal nachfragen ob es dazu einen aktuellen Stand gibt?
Vielen Dank
Gruß Alex
Moin,
ich habe zwar keinen Speicher, aber alles andere läuft bei mir über solarforecast (https://forum.fhem.de/index.php/topic,117864.msg1224325.html#msg1224325) - da gibt es auch ein FTUI-Widget für zum "Nachrüsten" ...
Bietet allerdings deutlich mehr als nur eine reine Visualisierung ...
Gruß, Christoph
Hallo
Vielen Dank für den Tipp. Ich habe mir Papa seinen Stand für mein Kostal WR angepasst.
Ich habe es wie folgt definiert.
<div data-type="pvvis" data-device="WR_1"
data-get="SW_Home_own_consumption_from_grid" data-feed="Total_Active_P_EM"
data-produce="SW_Total_DC_P_sumOfAllPVInputs" data-pv-max="5500" data-pvhome="SW_Home_own_consumption_from_PV"
data-chargedischarge="Actual_Battery_charge_-minus_or_discharge_-plus_P" data-soc="Act_state_of_charge"
data-width="220" data-height="220" class="centered">
</div>
VG Alex
Hat eventuell jemand schon so ein wiegt für FTUI3 entwickelt?
Mit freundlichen Grüßen
Zitat von: Shadow3561 am 22 Juni 2022, 17:08:17Hat eventuell jemand schon so ein wiegt für FTUI3 entwickelt?
Hier ein quick'n'dirty schnellschuß basierend auf papas FTUI2 widget; allerdings ohne es getestet zu haben (hab weder Hardware noch FHEM-Devices zum testen) - den Code direkt in FTUI3 übernehmen, ggfs noch umschließen (mit einer ftui-cell o.ä.), da es nur die svg ist.
Device und die Readings müssen ersetzt werden (suchen und ersetzen vor dem Kopieren); folgende device:reading kombination ist vorhanden (den : beibehalten) - Nomenklatur analog zu papas Version (https://forum.fhem.de/index.php/topic,119440.msg1138919.html#msg1138919).
DEVICE:SOC
DEVICE:DISCHARGE
DEVICE:FEED
DEVICE:GET
DEVICE:CHARGE
DEVICE:PVHOMEVAL <- das FTUI2 Widget berechnet dies; hier würde ich (erstmal) auf ein userReading zurückgreifen welches dann
(PRODUCE - CHARGE - FEED) rechnet
Die CSS aus #3 (https://forum.fhem.de/index.php/topic,119440.msg1138919.html#msg1138919) wird weiterhin benötigt.
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 400">
<script type="text/javascript"><![CDATA[
function doround(value) {
if( value === undefined ) return 0;
return Math.round(value);
}
]]></script>
<g ftui-binding id="sun" fill="yellow" transform="translate(152,0),scale(4)" [style]="DEVICE:sunOpacity | prepend('opacity:') | append(';')">
<path d="M6.76 4.84l-1.8-1.79-1.41 1.41 1.79 1.79 1.42-1.41zM4 10.5H1v2h3v-2zm9-9.95h-2V3.5h2V.55zm7.45 3.91l-1.41-1.41-1.79 1.79 1.41 1.41 1.79-1.79zm-3.21 13.7l1.79 1.8 1.41-1.41-1.8-1.79-1.4 1.4zM20 10.5v2h3v-2h-3zm-8-5c-3.31 0-6 2.69-6 6s2.69 6 6 6 6-2.69 6-6-2.69-6-6-6zm-1 16.95h2V19.5h-2v2.95zm-7.45-3.91l1.41 1.41 1.79-1.8-1.41-1.41-1.79 1.8z"/>
</g>
<g id="home" fill="grey" transform="translate(0,150),scale(4)">
<path d="M10 20v-6h4v6h5v-8h3L12 3 2 12h3v8z"/>
</g>
<g id="battery" opacity="0.2" fill="#090" stroke="#090" transform="translate(300,150),scale(.3)">
<line x1="75" y1="30" x2="75" y2="280" style="stroke-width: 12px;"></line>
<line x1="225" y1="30" x2="225" y2="280" style="stroke-width: 12px;"></line>
<line x1="69" y1="30" x2="231" y2="30" style="stroke-width: 12px;"></line>
<line x1="69" y1="284" x2="231" y2="285" style="stroke-width: 12px;"></line>
<line x1="105" y1="20" x2="195" y2="20" style="stroke-width: 25px;"></line>
<rect ftui-binding id="bat25" x="92" y="221" width="116" height="48" [style]="DEVICE:SOC | step('0:`stroke-width:0px;opacity:0.2;`, 25:`stroke-width:0px;opacity:1;`')"></rect>
<rect ftui-binding id="bat50" x="92" y="163" width="116" height="48" [style]="DEVICE:SOC | step('0:`stroke-width:0px;opacity:0.2;`, 50:`stroke-width:0px;opacity:1;`')"></rect>
<rect ftui-binding id="bat75" x="92" y="105" width="116" height="48" [style]="DEVICE:SOC | step('0:`stroke-width:0px;opacity:0.2;`, 75:`stroke-width:0px;opacity:1;`')"></rect>
<rect ftui-binding id="bat100" x="92" y="47" width="116" height="48" [style]="DEVICE:SOC | step('0:`stroke-width:0px;opacity:0.2;`, 96:`stroke-width:0px;opacity:1;`')"></rect>
</g>
<g id="grid" fill="gray" transform="translate(150,300),scale(4)">
<path d="M20,5V4c0-0.55-0.45-1-1-1h-2c-0.55,0-1,0.45-1,1v1h-1v4c0,0.55,0.45,1,1,1h1v7c0,1.1-0.9,2-2,2s-2-0.9-2-2V7 c0-2.21-1.79-4-4-4S5,4.79,5,7v7H4c-0.55,0-1,0.45-1,1v4h1v1c0,0.55,0.45,1,1,1h2c0.55,0,1-0.45,1-1v-1h1v-4c0-0.55-0.45-1-1-1H7 V7c0-1.1,0.9-2,2-2s2,0.9,2,2v10c0,2.21,1.79,4,4,4s4-1.79,4-4v-7h1c0.55,0,1-0.45,1-1V5H20z"/>
</g>
<g transform="translate(50,50),scale(0.5)" stroke-width="40" fill="none">
<path ftui-binding id="pv-home" d="M255,100 L255,180 C255,255,255,255,180,255 L100,255" stroke="yellow" [class]="DEVICE:PVHOMEVAL | step('0:`inactive`, 1:`active1`, 1000:`active2`, 2000:`active3`')" />
<path ftui-binding id="bat-home" d="M500,300 L100,300" stroke="green" [class]="DEVICE:DISCHARGE | step('0:`inactive`, 1:`active1`, 1000:`active2`, 2000:`active3`')" />
<path ftui-binding id="pv-grid" d="M300,100 L300,500" stroke="yellow" [class]="DEVICE:FEED | step('0:`inactive`, 1:`active1`, 1000:`active2`, 2000:`active3`')" />
<path ftui-binding id="pv-bat" d="M345,100 L345,180 C345,255,345,255,420,255 L500,255" stroke="yellow" [class]="DEVICE:CHARGE | step('0:`inactive`, 1:`active1`, 1000:`active2`, 2000:`active3`')" />
<path ftui-binding id="grid-home" d="M255,500 L255,420 C255,345,255,345,180,345 L100,345" stroke="red" [class]="DEVICE:GET | step('0:`inactive`, 1:`active1`, 1000:`active2`, 2000:`active3`')" />
<text id="pv-home-txt" x="210" y="230" style="fill: #ccc; font-size: 38px; text-anchor: end;"><ftui-label [text]="DEVICE:PVHOMEVAL | round()"></ftui-label></text>
<text id="grid-home-txt" x="210" y="400" style="fill: #ccc; font-size: 38px; text-anchor: end;"><ftui-label [text]="DEVICE:GET | round()"></ftui-label></text>
<text id="pv-bat-txt" x="390" y="230" style="fill: #ccc; font-size: 38px; text-anchor: start;"><ftui-label [text]="DEVICE:CHARGE | round()"></ftui-label></text>
<text id="bat-home-txt" x="390" y="355" style="fill: #ccc; font-size: 38px; text-anchor: start;"><ftui-label [text]="DEVICE:DISCHARGE | round()"></ftui-label></text>
<text id="pv-grid-txt" x="330" y="451" style="fill: #ccc; font-size: 38px; text-anchor: start;"><ftui-label [text]="DEVICE:FEED | round()"></ftui-label></text>
</g>
</svg>Animation der Sonne fehlt noch da mir noch nicht ganz klar ist, wie man das elegant im SVG berechnet -
könnte man über ein userReading FTUI3 zur Verfügung stellen. Berechnung aus dem Widget ist
(0.2 + (0.8 * (PRODUCE / PV-MAX))).
Wie gesagt, komplett ungetestet, keine Ahnung ob dies funkltioniert.
Moin,
und danke für deine Mühe.
Leider funktioniert es so nicht.
Ftui3 arbeitet anders als ftui2.
irgendwann wird jemand ein PV-Widget erstellen und es hier hoffentlich zur Verfügung stellen. Es werden ja täglich mehr PV-Anlagen und somit stirbt meine Hoffnung zu letzt.
Vielleicht steigt papa ja auch irgendwann mal zu FTUI3 um und passt sein Widget entsprechend an.
Mit freundlichen Grüßen
Zitat von: Shadow3561 am 23 Juni 2022, 17:44:00Leider funktioniert es so nicht.
Also bei mir hat es, bis auf die Werte/Texte, gut funktioniert. ich habe aber auch nur einen Dummy zum testen.
Zitat von: Shadow3561 am 23 Juni 2022, 17:44:00Ftui3 arbeitet anders als ftui2.
Ja, und vor allem benötigt man nicht für alles ein Widget da sich vieles schon mit den FTUI3-Basifunktionen realisieren lässt.
Zitat von: Shadow3561 am 23 Juni 2022, 17:44:00irgendwann wird jemand ein PV-Widget erstellen und es hier hoffentlich zur Verfügung stellen. Es werden ja täglich mehr PV-Anlagen und somit stirbt meine Hoffnung zu letzt.
Vielleicht steigt papa ja auch irgendwann mal zu FTUI3 um und passt sein Widget entsprechend an.
Aber da es mit den Texten irgendwie doof ist und ich schon immer mal wissen wollte, wie man eine FTUI3 component baut, hab ich basierend auf papas grandioser Vorarbeit (Danke!) etwas gefrickelt.
Das anhängende Archiv entpacken und den Ordner pvvis unter components in ablegen. Einbinden der component in FTUI3 dann über:
<ftui-pvvis
[charge]="DEVICE:CHARGE"
[discharge]="DEVICE:DISCHARGE"
[feed]="DEVICE:FEED"
[produce]="DEVICE:PRODUCE"
[pvmax]="DEVICE:PVMAX"
[receive]="DEVICE:GET"
[soc]="DEVICE:SOC">
</ftui-pvvis>Einfach entsprechend DEVICE und die readings ersetzen, analog zu:
Zitat von: papa am 11 März 2021, 20:19:29data-get - Verbrauch Haus
data-feed - Einspeisungs in Netz
data-produce - Production PV-Anlage
data-charge - Ladung Akku
data-discharge - Entladung Akku
data-soc - Ladezustand Battery
data-pv-max - Maxiamle Leistung PV
Nur zur Info: zum Testen (mangels Hardware) nutze ich einen Dummy, die Werte sind wahrscheinlich Schwachsinn:
Internals:
NAME SolarTest
TYPE dummy
READINGS:
2022-06-24 07:27:19 CHARGE 320
2022-06-24 07:41:38 DISCHARGE 25
2022-06-24 13:46:39 FEED 150
2022-06-24 13:46:39 GET 250
2022-06-24 14:03:22 PRODUCE 2850
2022-06-24 07:31:57 PVMAX 3200
2022-06-24 12:53:34 SOC 48
Danke.
Leider funktioniert es bei mir nicht und ich habe keine Ahnung woran es liegen könnte.
FHEM und FTUI3 sind up to date
Ich habe deine ZIP entpackt und den pvvis-Ordner in den components-Ordner von FTUI3 kopiert.
dann habe ich folgende html-Datei
<ftui-grid-tile row="1" col="2" height="5" width="5" shape="round">
<header>PV-Anlage / Strombedarf</header>
<ftui-pvvis
[charge]="SE3500H:CHARGE"
[discharge]="SE3500H:DISCHARGE"
[feed]="SE3500H:Hausverbrauch"
[produce]="SE3500H:AC_current_W"
[pvmax]="SE3500H:3500"
[receive]="SE3500H:Power"
[soc]="SE3500H:SOC">
</ftui-pvvis>
</ftui-grid-tile>
<ftui-grid-tile row="6" col="2" height="5" width="10" shape="round">
<header>PV-Anlage / Grafik</header>
<ftui-chart height="320px" width="100%" popup-target="pvleistung">
<ftui-chart-data label="Verbrauch" log="logdb" file="HISTORY" spec="SE3500H:Hausverbrauch"
fill background-color="#ffcc0050" color="#ffcc00" point-radius="0"></ftui-chart-data>
<ftui-chart-data label="PV-Leistung" log="logdb" file="HISTORY" spec="SE3500H:AC_current_W"
fill background-color="#00cc3350" color="#00cc33" point-radius="0"></ftui-chart-data>
</ftui-chart>
</ftui-grid-tile>
</ftui-grid-tile>
Das sieht dann bei mir so aus wie bei dem Bild im Anhang.
Das Grid bleibt leider leer.
Server wurde neu gestartet und den Cache im Browser habe ich ebenso geleert.
Woran es liegt, weiß ich wie gesagt nicht.
Die user_css liegt im ftui-theme-Ordner.
Schade
@yersinia, @Shadow3561
Die Anzeige ist im nicht sichtbaren Bereich.
Ich habe mal die viewBox auf 100 100 100 100 gestellt und noch ein width="50px" in die Definition als styleAttribute zum Testen hinzugefügt.
Jetzt ist es sichtbar.
LG mr_petz
ps. @yersinia, schön das du dich jetzt auch ans proggen versuchst ;)
Edit: Schneller Lösungsvorschlag in der css folgendes bei pvvisbox eintragen:
.pvvisbox {
width: 200px;
}
oder halt deine Größe die du brauchst. Und dann ist es sichtbar(zumindest jetzt bei mir).
Das könnte @yersinia als Attribute mit reinnehmen in den Code...
@yersinia
Beispiel wie man es machen könnte:
in den super(Object.assign(FtuiPvvis.properties, properties)):
this.div = this.shadowRoot.querySelector('.pvvisbox');
in den static get properties():
width: '200px',
und im onConnected():
this.div.style.width = this.width;
Edit2: nur ein Hinweis. Den import fhemService
brauchst du hier nicht, da du ihn nicht verwendest.
@mr_petz
ZitatEdit: Schneller Lösungsvorschlag in der css folgendes bei pvvisbox eintragen:
.pvvisbox {
width: 200px;
}
oder halt deine Größe die du brauchst. Und dann ist es sichtbar(zumindest jetzt bei mir).
Das wars.
jetzt klappt es wie gewünscht.
@mr_pet , @yersinia
Vielen lieben dank euch beiden.
Moin und einen schönen Samstag.
Ich benötige noch einmal eure Hilfe. Das ist mein erster Versuch mit Javascript, seid also bitte etwas nachsichtig mit mir.
Ich habe das Widget jetzt auf meine Bedürfnisse (habe keinen Akku) angepasst.
Die Sonne wechselt auf grau wenn keine PV-Produktion mehr stattfindet,
das Grid-Symbol wechselt die Farbe je nach Einspeisung oder Bezug
und natürlich sind der Akku und die dazu gehörenden Flusslinien weg.
Nur leider stimmt irgend etwas mit der Berechnung nicht, der Eigenverbrauch hat manchmal mehrer Nachkommastellen obwohl in den Readings des Wechselrichter-Device (FHEM) nur eine Nachkomma-Stelle vorhanden ist.
EDIT: Ich habe mir jetzt in FHEM Ganzzahlen als userreadings erstellt. Jetzt scheint es zu funktionieren.
Ich habe zu Verdeutlichung mal Bilder angehängt und die Widget Datei. Die css ist unangetastet.
Definiert ist das Widget so:
<ftui-pvvis
[feed]="SE3500H:Momentanleistung_Einspeisung"
[produce]="SE3500H:AC_current_W"
[pvmax]="SE:3500H:3500"
[receive]="SE3500H:Momentanleistung_Bezug"
[home]="SE3500H:Hausverbrauch"
</ftui-pvvis>
Mit freundlichen Grüßen
@Shadow3561
Schau dir toFixed() an:
https://www.w3schools.com/jsref/jsref_tofixed.asp
Hier sollte aber @yersinia die Zügel weiter in der Hand halten.
Er könnte die Batterie/Speicher auch mit einem Attribute anzeigen bzw. entfernen.
LG mr_petz
Zitat von: mr_petz am 25 Juni 2022, 12:29:11
@Shadow3561
Schau dir toFixed() an:
https://www.w3schools.com/jsref/jsref_tofixed.asp
Hier sollte aber @yersinia die Zügel weiter in der Hand halten.
Er könnte die Batterie/Speicher auch mit einem Attribute anzeigen bzw. entfernen.
LG mr_petz
Das habe ich bereits getan, ebenso Math.round()
Aber wie gesagt, es war das ersten mal js.
Habe es jetzt erst mal anders gelöst.
Wäre schön wenn sich yersinia des Widgets annehmen würde damit auch andere die Vorzüge eine schönen Darstellung in FTUI3 genießen dürfen.
Mit freundlichen Grüßen
Hi mr_petz & Shadow3561,
vielen Dank fürs Testen und das Feedback. Ich habe eure Vorschläge und Adaptionen übernommen:
- Werte werden gerundet (ohne Nachkommastelle)
- Grid wechselt die Farbe je nachdem ob man bezieht oder abgibt (Code von Shadow3561)
- wenn soc nicht definiert oder 0 ist, bleibt der Akku ausgegraut
- wenn es keinen Akku gibt, kann man über has-no-battery den Akku-Strang ausblenden
- die Breite ist nun auch definiert bzw definierbar über width="xxx" (Voreingestellt sind 200px)
- lasst die Werte, die ihr nicht habt, einfach weg (zB wenn kein Akku/Batterie vorhanden ist, muss auch [soc] nicht definiert werden)
Sieht, soweit ich das mit meinem Dummy testen kann, erst mal ganz gut aus.
Hi yersinia,
Sieht soweit gut aus.
Du könntest noch aus:
let sunOpacity = 0.2 + (0.8 * (this.produce / this.pvmax));
this.shadowRoot.getElementById('pvvissun').style.opacity = sunOpacity.toFixed(3);
einen Einzeiler machen:
this.shadowRoot.getElementById('pvvissun').style.opacity = (0.2 + (0.8 * (this.produce / this.pvmax))).toFixed(3);
1. Hinweis:
hier muss man nur mit dem addieren aufpassen, weil + ist auch zum anhängen gedacht.
2. Hinweis:
let nimmt man für flexibel veränderbare Variablen und
const für feste konstante Variablen
Die Hinweise sind nur meine Erfahrungen...
Ok das war es von meiner Seite.
LG mr_petz
Danke fürn x-check, das hilft. :)
Zitat von: mr_petz am 26 Juni 2022, 16:58:03einen Einzeiler machen:
this.shadowRoot.getElementById('pvvissun').style.opacity = (0.2 + (0.8 * (this.produce / this.pvmax))).toFixed(3);
Ich könnte noch ein
this.sun.style.opacity = (0.2 + (0.8 * (this.produce / this.pvmax))).toFixed(3);
daraus machen, da wir ja sun schon als objekt deklariert haben...
Moin,
habe es auch gerade probiert.
has-no-battery funktioniert perfekt.
die grid färbe ändert sich bei mir leider nicht und das sun icon ist zu dunkel.
ich hänge mal meine version an, kannst ja mal rüber schauen ob du etwas daraus gebrauchen kannst.
Mit freundlichen Grüßen
Mmmh, dies kann ich nicht nachvollziehen. Ich muss aber gestehen, dass ich keine Hardware zum Nachstellen habe. Es würde sehr helfen wenn du zum einen Device-List(s) (anonymisiert) und die HTML Einbindung posten würdest. So ist es schwer, das ganze aus der Ferne nachzustellen.
Hast du mal ein list der typischen Werte von
Zitat[feed]="SE3500H:Hausverbrauch"
[produce]="SE3500H:AC_current_W"
[pvmax]="SE3500H:3500"
[receive]="SE3500H:Power"
Meines Verständnis nach sind
- feed => Einspeisung PV ins Stromnetz
- receive => Entnahme aus dem Stromnetz
- produce => aktuell generierte Energie PV Anlage
- pvmax => ist die Maximalleistung der PV Anlage
Demnach müsste doch eigentlich sich die Einspeisung/Verbrauch aus dem Stromnetz aus (receive - feed) ergeben und ist nur dann negativ, wenn man mehr einspeist als verbraucht, korrekt? Dann würde ich die Farbe eher aus der Differenz ableiten, in etwa so:
colorGrid() {
let gridconsumption = this.receive - this.feed;
if(this.gridconsumption > 0 ) { this.grid.style.fill = "red"; } else { this.grid.style.fill = "yellow"; }
}Rot wenn positiv (Verbrauch), gelb wenn 0 oder negativ (Einspeisung)
Im Übrigen ist dies falsch, wenn das Device SE3500H
kein Reading '3500' hat:
[pvmax]="SE3500H:3500"Wenn du einen statischen Wert für die Maximalleistung haben möchtest, nimm
pvmax="3500"Möglicherweise ist dies der Grund, dass deine Sonne zu dunkel bleibt. Die Helligkeit errechnet sich aus dem Verhältnis von aktueller Leistung (produce) zu Maximalleistung (pvmax).
Die eckigen Klammern benötigst du bei FTUI3 (und ins hier) nur wenn du Readings aus einem Device auslesen möchtest. Statische Werte definierst du dann einfach ohne eckige Klammern.
Der Vollständigkeit-halber ein paar Beispieldefinitionen von pvvis in FTUI3. Wobei gilt:
receive - Verbrauch Haus
feed - Einspeisungs in Netz
produce - Production PV-Anlage
charge - Ladung Akku
discharge - Entladung Akku
soc - Ladezustand Battery
pvmax - Maximale Leistung PV
width - Breite des Widget (opptional; standard ist 200px)
has-no-battery - kein Akku vorhanden (optional)Alle Werte aus Devicen ausgelesen über FTUI3 typische [parameter]="DEVICE:READING" Notation mit eckigen Klammern.
1. mit Batterie und alle Werte liegen als Reading vor - Breite ist auf 200px festgelegt
<ftui-pvvis
[charge]="DEVICE:CHARGE"
[discharge]="DEVICE:DISCHARGE"
[feed]="DEVICE:FEED"
[produce]="DEVICE:PRODUCE"
[pvmax]="DEVICE:PVMAX"
[receive]="DEVICE:GET"
[soc]="DEVICE:SOC">
</ftui-pvvis>2. ohne Batterie und pvmax wird mit 3500 fix vorgegeben - Breite ist auf 200px festgelegt
<ftui-pvvis
[feed]="DEVICE:FEED"
[produce]="DEVICE:PRODUCE"
pvmax="3500"
[receive]="DEVICE:GET"
has-no-battery>
</ftui-pvvis>3. mit Batterie und alle Werte liegen als Reading vor - Breite ist auf 65% begrenzt
<ftui-pvvis
[charge]="DEVICE:CHARGE"
[discharge]="DEVICE:DISCHARGE"
[feed]="DEVICE:FEED"
[produce]="DEVICE:PRODUCE"
[pvmax]="DEVICE:PVMAX"
[receive]="DEVICE:GET"
[soc]="DEVICE:SOC"
width="65%">
</ftui-pvvis>
Moin,
du hast recht,
die Sonne hat ihre Farbe nicht verändert weil ich [pvmax] falsch definiert habe.
Jetzt funktioniert es wie du es möchtest, jedenfalls bei mir.
Die Änderung der colorGrid() kann ich mittels fehlender Produktion gerade nicht testen. Werde ich die Tage dann nachholen.
Wenn ich
width="65%"
angebe, bekomme ich kein Widget mehr angezeigt.
ändere ich es in
width="300px"
dann funktioniert die Grössenänderung.
Meine Readings im Device sind analog zu der Bezeichnung.
[feed]="SE3500H:Momentanleistung_Einspeisung"
[produce]="SE3500H:Produktion"
[pvmax]="3500"
[receive]="SE3500H:Momentanleistung_Bezug"
[home]="SE3500H:Hausverbrauch"
Zitat von: Shadow3561 am 27 Juni 2022, 17:49:04Wenn ich
width="65%"
angebe, bekomme ich kein Widget mehr angezeigt.
ändere ich es in
width="300px"
dann funktioniert die Grössenänderung.
Ah, danke für das Feedback - die 65% hier beziehen sich afaik auf das Elternelement und wenn dort nichts definiert ist, sind 65% von nichts immer noch nichts. Aber gut wenn es mit fester px-Angabe funktioniert.
Zitat von: Shadow3561 am 27 Juni 2022, 17:49:04Meine Readings im Device sind analog zu der Bezeichnung.
[feed]="SE3500H:Momentanleistung_Einspeisung"
[produce]="SE3500H:Produktion"
[pvmax]="3500"
[receive]="SE3500H:Momentanleistung_Bezug"
[home]="SE3500H:Hausverbrauch"
Spar' dir die [] bei pvmax, da es kein Reading aus einem FHEM-Device ist:
[feed]="SE3500H:Momentanleistung_Einspeisung"
[produce]="SE3500H:Produktion"
pvmax="3500"
[receive]="SE3500H:Momentanleistung_Bezug"
[home]="SE3500H:Hausverbrauch"
Anbei eine neue Version.
mr_petz hat eine dynamischere Batterieladestandanzeige beigesteuert - die natürlich nur dann angezeigt wird, wenn eine Batterie vorhanden ist. Die Batterieladestandanzeige richtet sich im Standard an der Prozentangabe:
0 - Batterie ist ausgegraut
1 bis 24 - kein Balken
25 bis 49 - ein Balken
50 bis 74 - zwei Balken
75 bis 94 - drei Balken
ab 95 - vier Balken
Diese Wertegrenzen können manipuliert werden durch das optionale Attribut battstep. Die oben genannten Wertegrenzen entsprechen:
battstep="24,49,74,95"
Es werden also vier Werte erwartet - ansonsten fallen die Werte auf den Standard zurück. Wird battstep nicht gesetzt bleibt es bei oben genannten Grenzwerten.
Weiterhin wird die Animation der Ladeflüsse in Abhängigkeit der Leistung der PV Anlage berechnet. Vorher gab es feste Werte: inaktiv bei 0, bis 1000 langsame Animation, bis 2000 mittlere Animation, über 2000 schnelle Animation. Der Grenzwert 1000 wird durch 1/3 von pvmax, der Grenzwert 2000 durch 2/3 von pvmax ersetzt. Setzt also pvmax (als Beispiel mit 3500):
pvmax="3500"
Anbei eine neue Version.
mr_petz hat die Auswertung von battstep robuster gestaltet. Danke dafür.
Der Parameter battstep erwartet genau vier Werte - mehr oder weniger werden einfach ignoriert.
Weiterhin verfärbt sich die Batterie grün wenn geladen und rot wenn entladen wird. Die Batteriebalken (Ladestandsanzeige) sind animiert und zeigen an, dass die Batterie Ge/Entladen wird.
Die Farben sind dem FTUI3 Farbschema angepasst worden.
Zitat von: yersinia am 30 Juni 2022, 12:30:31
Anbei eine neue Version.
mr_petz hat die Auswertung von battstep robuster gestaltet. Danke dafür.
Der Parameter battstep erwartet genau vier Werte - mehr oder weniger werden einfach ignoriert.
Weiterhin verfärbt sich die Batterie grün wenn geladen und rot wenn entladen wird. Die Batteriebalken (Ladestandsanzeige) sind animiert und zeigen an, dass die Batterie Ge/Entladen wird.
Die Farben sind dem FTUI3 Farbschema angepasst worden.
Moin yersinia,
sehr colles Widget!
Ich hätte noch einen Wunsch und eine kleine Korrektur...
- Wäre es möglich zentriert unter dem "Häuschen" noch einen Wert für die aktuelle Gesamtleistung des Hauses darzustellen
Quasi TotalConsumption oder so ähnlich. Ich errechne mir das - (PV Gesammt - Einspeisung) + Bezug.
- Und noch eine Anpassung des Abstandes zu der Werte zu den Horizontalen geschrichelten Linien, vieleicht um einige wenige Pixel (ählich wie beim Wert der Einspeisung in Netz).
LG
Olli
Hi octek0815,
Gute Idee, hab ich übernommen - der Hausverbrauch ergibt sich aus pvhomeval (entspricht PV Gesamt - Einspeisung - Charge (der Wert oben links)) + discharge + receive. In diesem Zuge habe ich den Ladestand der Batterie auch gleich übernommen.
Die Abstände habe ich auch angepasst. Schau mal ob es dir so passt.
(Btw, diese Component ist für FTUI3, FTUI2 gibt es in papas post (https://forum.fhem.de/index.php/topic,119440.msg1138919.html#msg1138919))
@yersinia
Vielleicht sollte man hier immer oben als Betreff [FTUI3] hinzufügen wenn man Antwortet.
Ja es geht zwar im Allgemeinen um die Darstellung der Sonnenbatterie, aber wer vorn Anfängt mit lesen ist bei [FTUI2].
Soll nur ein Hinweis sein... ;)
LG mr_petz
Guter Hinweis, hab es in meinen Posts ergänzt.
Ist sowieso gefährlich da wir hier FTUI2 (https://forum.fhem.de/index.php/topic,119440.msg1138919.html#msg1138919) (bis etwa #10 (https://forum.fhem.de/index.php/topic,119440.msg1225606.html#msg1225606)) und ab da dann (https://forum.fhem.de/index.php/topic,119440.msg1225796.html#msg1225796) mit FTUI3 angefangen haben.
Oder einfach einen neuen Thread aufmachen und das Modul vorstellen. Denn es werden bestimmt mehrere daran interessiert sein und es lässt sich leichter über die Suche finden.
Mit freundlichen Grüßen
Dafür hätte ich aber gern erst hier mehr Testberichte - ich nehme an, dass einige Nutzer das Widget bereits unter FTUI2 genutzt haben und dies nun unter FTUI3 nutzen wollen. Mir fehlt zB ein vernünftiger Test da mir die Hardware fehlt. Und so wie ich das sehe, gibt es erst drei user (Shadow3561, mr_petz und octek0815), die sich das mal angesehen haben. Ist für mich noch keine kritische Masse für ein eigenen Thread.
Zitat von: Yersinia am 04 Juli 2022, 16:58:58
Dafür hätte ich aber gern erst hier mehr Testberichte - ich nehme an, dass einige Nutzer das Widget bereits unter FTUI2 genutzt haben und dies nun unter FTUI3 nutzen wollen. Mir fehlt zB ein vernünftiger Test da mir die Hardware fehlt. Und so wie ich das sehe, gibt es erst drei user (Shadow3561, mr_petz und octek0815), die sich das mal angesehen haben. Ist für mich noch keine kritische Masse für ein eigenen Thread.
Muss dich leider enttäuschen. :(
Ich habe offline ohne dummy getestet mit fixen Werten.
Mein Test ist somit null und nichtig.
Leider. Aber ich unterstütze dich weiterhin gern.
Bin auch der Meinung bei dem Tool muss man nicht erst einen neuen Thread auf machen wenn es hier sowieso darum geht.
Ob ftui2 oder 3 muss halt nur mit in den Betreff.
LG
Man sollte wenigstens den Titel ändern damit mehr Leute darauf aufmerksam werden. Die Sonnenbatterie von Sonnen sollten nicht so viele verbaut haben, eine PV-Anlage mit Speicher von anderen Herstellern schon. Und es ist ja auch für Nicht-Speicher-Inhaber interessant geworden.
"Darstellung PV-Anlage mit und ohne Speicher" zum Beispiel.
Der Thread ist ja schon über 1 Jahr alt und hat nicht wirklich viele Antworten ergo wohl auch nicht so viele Interessenten. Mir erging es ähnlich und ich habe ihn bis vor kurzem nicht beachtet.
Frag doch einfach mal bei @dennis_n nach ob er den Titel ändern möchte.
Mit freundlichen Grüßen
Ich bin auf den Thread aufmerksam geworden, als die Portierung nach FTUI3 erfolgte.
Ich habe das Widget jetzt nach einigen Anlaufschwierigkeiten seit 3 Tagen mit echten Werten am Laufen. (z.Zt. noch ohne Speicher)
Vielen Dank für die tolle Arbeit!! :)
Meine Schwierigkeiten resultierten daher, dass bei mir feed und receive dasselbe Reading des Zählers (...:power) ist. Bei Einspeisung mit negativem Vorzeichen und bei Bezug mit positivem Vorzeichen.
Habe mir mittels DOIF zwei getrennte Readings für feed und receive geschaffen. Seitdem funktioniert es anstandslos.
photon68
Hi Photon68,
vielen Dank fürs Testen und die Rückmeldung.
Zitat von: Photon68 am 05 Juli 2022, 20:53:52Meine Schwierigkeiten resultierten daher, dass bei mir feed und receive dasselbe Reading des Zählers (...:power) ist. Bei Einspeisung mit negativem Vorzeichen und bei Bezug mit positivem Vorzeichen.
Interessant, sowas fällt bei einem Trockentest gar nicht auf.
Kannst du angehängte Version testen? Dabei kannst du nun für feed und receive das gleiche Reading angeben, in etwa so (DEVICE durch dein Device ersetzen):
[feed]="DEVICE:power"
[receive]="DEVICE:power"pvvis prüft stupide ob
- receive negativ ist und setzt es auf 0
- feeds wert gleich receives wert ist und setzt feed auf 0; wenn feed negativ sein sollte, wird es zum entsprechenden positiven Wert konvertiert
btw
Zitat von: Photon68 am 05 Juli 2022, 20:53:52Habe mir mittels DOIF zwei getrennte Readings für feed und receive geschaffen. Seitdem funktioniert es anstandslos.
Wäre mit userReadings (https://wiki.fhem.de/wiki/UserReadings) wahrscheinlich eleganter gegangen. Aber hoffentlich benötigst du es nicht mehr. ;)
Zitat von: yersinia am 01 Juli 2022, 13:07:27
Hi octek0815,
Gute Idee, hab ich übernommen - der Hausverbrauch ergibt sich aus pvhomeval (entspricht PV Gesamt - Einspeisung - Charge (der Wert oben links)) + discharge + receive. In diesem Zuge habe ich den Ladestand der Batterie auch gleich übernommen.
Die Abstände habe ich auch angepasst. Schau mal ob es dir so passt.
(Btw, diese Component ist für FTUI3, FTUI2 gibt es in papas post (https://forum.fhem.de/index.php/topic,119440.msg1138919.html#msg1138919))
Moin yersinia,
vielen Dank für die Änderungen. Ich hätte noch zwei weitere Wünsche.
1. Entweder über der Sonne oder unter der Sonne die momentane PV Erzeugung (also "produce").
2. Ich hätte gern ein anderes Symbol (Strommast) für die Einspeisung ins Netz oder alternativ die Möglichkeit selbst das Symbol zu bestimmen.
VG
Olli
Hallo Yersinia,
danke für die Änderungen. Leider zeigt die neue Version bei mir gar nichts an (weder mit neuen noch mit meinen alten Readings).
Bin wieder zurück zur Version vom 1.7.. Die funktioniert nach wie vor mit meinen selbstgebastelten Readings.
Gruß Photon68
EDITZitat von: octek0815 am 06 Juli 2022, 12:34:351. Entweder über der Sonne oder unter der Sonne die momentane PV Erzeugung (also "produce").
Schau mal im Anhang, wäre rechts der Sonne auch ok? Für über oder unter der Sonne müsste ich das SVG umstrukturieren und dazu fehlt mir derzeit die Motivation.
Zitat von: octek0815 am 06 Juli 2022, 12:34:352. Ich hätte gern ein anderes Symbol (Strommast) für die Einspeisung ins Netz oder alternativ die Möglichkeit selbst das Symbol zu bestimmen.
Ich habe den Strommast von Shadow3561 (https://forum.fhem.de/index.php/topic,119440.msg1226092.html#msg1226092) übernommen und dieser kann nun ausgewählt werden. Dafür gibt es einen zusätzlichen
optionalen paramater
grid-icon welcher zurzeit die Werte
cable (für das Kabel von papa; Standardwert) oder
pylon (Strommast) annehmen kann. Ist der Wert nicht gesetzt, wird der Standard als cable definiert. Den Strommast gibt es mit
grid-icon="pylon"das Kabel entsprechend mit
grid-icon="cable"Da cable aber Standard ist, kann man den Parameter weg lassen. Invalide Werte wie
grid-icon="BraunkohlekraftwerkJänschwalde"werden ignoriert und durch cable ersetzt.
Neue FTUI3 Version anhängend.
Zitat von: Photon68 am 06 Juli 2022, 13:10:25Leider zeigt die neue Version bei mir gar nichts an (weder mit neuen noch mit meinen alten Readings).
Bin wieder zurück zur Version vom 1.7.. Die funktioniert nach wie vor mit meinen selbstgebastelten Readings.
Wie rufst du pvvis in FTUI3 auf? zeig doch mal den HTML Code.
Hallo Yersinia,
anbei mein Code:
<ftui-grid-tile class="semitransparent" row="1" col="16" height="3" width="3" shape="round" color="secondary">
<ftui-pvvis
[produce]="PVZ:power | multiply(-1)"
pvmax="5280"
[receive]="Verbrauch:receive"
[feed]="Verbrauch:feed | multiply(-1)"
[home]="Verbrauch:LeistungHaus"
has-no-battery>
</ftui-pvvis>
</ftui-grid-tile>
Dieser funktioniert mit der Version vom 1.7. anstandslos. Die Readings Verbrauch:feed und Verbrauch:receive werden von mir mittels DOIF gefüllt, die nichts anderes machen, als du für die veränderte (bei mir nicht funktionierende) Version beschreibst.
Meine Hinweis zu meinen Anlaufschwierigkeiten wollte ich soweiso nicht als Änderungswunsch verstanden haben, sondern eher als Tipp für Nutzer mit dem gleichen Problem wie ich (gleiches Reading für feed und receive).
Gruß Photon 68
Dank für den Code. Zum Einen gibt es kein parameter
home und zum Anderen lass mal die Pipe weg wenn du die Testversion von 39 (https://forum.fhem.de/index.php/topic,119440.msg1227030.html#msg1227030) nutzt:
<ftui-grid-tile class="semitransparent" row="1" col="16" height="3" width="3" shape="round" color="secondary">
<ftui-pvvis
[produce]="PVZ:power"
pvmax="5280"
[receive]="Verbrauch:receive"
[feed]="Verbrauch:feed"
has-no-battery>
</ftui-pvvis>
</ftui-grid-tile>Und versuch mal für receive und feed das gleiche Reading zu nutzen. du hast geschrieben, dass es ein Device mit power reading gebe, welches entweder negativ (einspeisung) oder positiv (verbrauch) sein kann, daher erwarte ich eine Aufruf eher so:
<ftui-grid-tile class="semitransparent" row="1" col="16" height="3" width="3" shape="round" color="secondary">
<ftui-pvvis
[produce]="PVZ:power"
pvmax="5280"
[receive]="DEVICE:power"
[feed]="DEVICE:power"
has-no-battery>
</ftui-pvvis>
</ftui-grid-tile>Zitat von: Photon68 am 06 Juli 2022, 14:55:22
Die Readings Verbrauch:feed und Verbrauch:receive werden von mir mittels DOIF gefüllt, die nichts anderes machen, als du für die veränderte (bei mir nicht funktionierende) Version beschreibst.
Meine Hinweis zu meinen Anlaufschwierigkeiten wollte ich soweiso nicht als Änderungswunsch verstanden haben, sondern eher als Tipp für Nutzer mit dem gleichen Problem wie ich (gleiches Reading für feed und receive).
Schön wäre es aber, wenn die Componente das selbstständig eliminiert und man nicht noch unnötig weitere Readings (via DOIF, at, userReadings usw) erzeugen muss - insb wenn es zusätzliche events generiert.
Alternative Lösungswege sind darüber hinaus immer willkommen. :)
Hallo Yersinia,
ich glaube wir missverstehen uns. Der neue Code:
<ftui-grid-tile class="semitransparent" row="1" col="16" height="3" width="3" shape="round" color="secondary">
<ftui-pvvis
[produce]="PVZ:power"
pvmax="5280"
[receive]="EVZ:power"
[feed]="EVZ:power"
[home]="Verbrauch:LeistungHaus"
has-no-battery>
</ftui-pvvis>
</ftui-grid-tile>
zeigt mit der Version aus 39 gar nichts an, wohl aber mit der Version vom 1.7.. Nur dann sind natürlich die Werte Blödsinn, weshalb ich ja meine Readings gebastelt habe.
ps: Die Version mit dem GridIcon zeigt mit obigem Code wieder was an. Allerdings blödsinnige Werte, wenn ich nicht die selbstgebastelten Readings benutze. Die Umstellung auf den Strommast funktioniert super.
Gruß Photon 68
ok, gut zu wissen. Hast du mal ein list vom Reading EVZ:power (und für den Trockentest auch auch PVZ:power)? Mich interessieren die Werte.
Hast du Fehlermeldungen vom FTUI?
Übrigens - das kannst du weglassen, dafür hat pvvis keine Verwendung:
[home]="Verbrauch:LeistungHaus"Zitat von: Photon68 am 06 Juli 2022, 15:33:02ps: Die Version mit dem GridIcon zeigt mit obigem Code wieder was an. Allerdings blödsinnige Werte, wenn ich nicht die selbstgebastelten Readings benutze. Die Umstellung auf den Strommast funktioniert super.
Ja klar, die enthält ja noch nicht die 'Optimierung'. ;) Kannst also erstmal auf die neuere Version (https://forum.fhem.de/index.php/topic,119440.msg1227063.html#msg1227063) upgraden.
Hi Photon68,
anbei eine neue Testversion. Mir gelingt es nicht, zwei properties an ein Reading zu binden - es ist wahrscheinlich auch nicht vorgesehen und ergibt im Prinzip auch keinen Sinn. Daher gibt es einen weiteren (langsam wird das hier ein Moloch ;D) parameter feed-receive. Es müsste bei dir ungefähr so funktionieren:
<ftui-grid-tile class="semitransparent" row="1" col="16" height="3" width="3" shape="round" color="secondary">
<ftui-pvvis
[produce]="PVZ:power"
pvmax="5280"
[feed-receive]="EVZ:power"
has-no-battery>
</ftui-pvvis>
</ftui-grid-tile>
Dafür brauchst du weder feed noch receive definieren, darum kümmert sich pvvis - ist der Wert kleiner 0 wird es feed, bei größer 0 wird es receive zugerechnet. In meinem Trockentest sieht es soweit gut aus.
Also entweder ein parameter/reading mit feed-receive oder zwei parameter/readings für jeweils feed und receive - je nachdem wie es vorliegt und genutzt wird.
Die anderen sind natürlich auch eingeladen unter ihren Einsatzbedingungen zu testen. Wer bereits feed und receive als getrennte Readings definiert hat, kann dies beibehalten.
Hallo yersinia,
erst einmal vielen Dank für deine tolle Leistung hier, es freut mich ungemein!
Bei mir ist es wie bei Photon68, je ein Reading für Feed und Batterie mit positiven und negativen Werten, hier mal meine Definition:
<ftui-grid-tile row="1" col="2" height="8" width="8" shape="round" >
<ftui-pvvis
[charge]="PVA_BT:AktLeistung"
[soc]="PVA_BT:AktBattLadezustand"
[produce]="PVA_PV:Wirkleistung"
[pvmax]="9520"
[feed-receive]="SMA_EM:Saldo_Wirkleistung"
width="300px">
</ftui-pvvis>
</ftui-grid-tile>
ich hoffe, dass Du für [charge],[discharge] ebenfalls einen zusätzlichen Parameter anlegen wirst ::)
mit deiner letzten aktuellen Version fehlt mir allerdings die Numerische Anzeige vom Feed, kann aber auch sein, dass ich da was falsch definiert habe.
VG
habl
Hi Yersinia,
die Version von 17:13 tut es!! Alle Werte sind stimmig, so wie ich sie nach meinen derzeitigen Readings erwarten würde.
Da im Moment jedoch nur Bezug stattfindet, muss ich mangels Sonne morgen abwarten, ob es auch bei Export ins Netz funktioniert.
<ftui-grid-tile class="semitransparent" row="1" col="16" height="3" width="3" shape="round" color="secondary">
<ftui-pvvis
[produce]="PVZ:power | multiply (-1)"
pvmax="5280"
[feed-receive]="EVZ:power"
grid-icon="pylon"
has-no-battery>
</ftui-pvvis>
</ftui-grid-tile>
Vielen Dank für die tolle Arbeit bisher!
Gruß Photon 68
..jetzt wollte ich das Widget mit meiner PV Anlage und meiner FTUI3-Instanz ausprobieren. Nach vielen wirren Beiträgen habe ich auch das JS-File gefunden. Aber kann es sein, dass noch andere Files braucht? SVG? Icons? Ich sehe nichts...
Ist relativ schwierig über 30 Beiträge die relevanten Parameter zu identifizieren :-)
UPDATE: Mein Wechselrichter gibt auch die Batterie Ladung/Entladung im gleichen Reading aus - ein alternatives, kombiniertes Attribut für die Batterie wäre also auch sehr nützlich...
Moin Yersinia,
ich kann bstätigen, dass bei mir die Testversion aus #47 mit dem Kombireading [feed-receive] anstatt zwei Readings feed und receive sowohl bei Strombezug, als auch bei Einspeisung ins Netz mit meinem Code aus #49 funktioniert und auch alle Werte die angezeigt werden stimmig sind.
Damit sollte ein ähnliches Kombireading [charge-discharge] bei vorhandenem Speicher in ähnlicher Weise möglich sein. Dort bin ich beim Testen aber mangels Hardware raus.
Vielleicht ist an der Stelle eine Erläuterung an alle Mitlesenden zu meiner Situation hilfreich. Das Device EVZ ist bei mir der Zweirichtungsstromzähler der mittels OBIS in Echtzeit die Verbrauchswerte liefert. Das dortige Reading power ist die aktuelle Wirkleistungsbilanz, also mit negativem Vorzeichen bei Einspeisung ins Netz und mit positivem Vorzeichen bei Bezug aus dem Netz. Ich verfüge dementsprechend nicht wie im ursprünglichen Widget vorgesehen über getrennte Readings für feed bzw. receive. Diese kann ich mir nur in Kombitation mit dem Device PVZ=Photovoltaikerzeugungszähler ausrechnen.
Yersinia hat durch das alternative Kombireading [feed-receive] meine Situation jetzt direkt in das Widget übernommen.
Danke und Gruß
Photon68
Guten Morgen zusammen und vielen Dank für die zahlreichen Tests sowie Rückmeldung!
@Photon68: eine Frage zu deiner Code-Definiton:
[produce]="PVZ:power | multiply (-1)"Verstehe ich richtig, dass wenn PV Anlage bei dir Strom produziert, das Reading negativ ist? (was auch gar nicht mal unlogisch, da ja ins Hausnetz eingespeist wird, der Verbrauch der PV Anlage bei Einspeisung also negativ ist)
Wenn dem so wäre, könnte man dies auch noch abfangen und du brauchst nur mit
[produce]="PVZ:power"arbeiten.
Die anhängende Testversion sollte dies schon abdecken. Bitte einmal testen.
@Nogga: du hast wahrscheinlich die
Testversion aus #47 (https://forum.fhem.de/index.php/topic,119440.msg1227117.html#msg1227117) runtergeladen - du benötigst aber erst die derzeit aktuelle Version aus #42 (https://forum.fhem.de/index.php/topic,119440.msg1227063.html#msg1227063). Dort ist ein ZIP-File - dies runterladen und die zwei Dateien nach
components/pvviskopieren (den Ordner musst du ggf erst anlegen). Danach kannst du mit den Testversionen rumspielen indem du die js-Datei entsprechend ersetzt (vorher eine Kopie des Originals anfertigen).
Bezgl des einen Readings für Charge/Discharge der Batterie/Akkus: ist es analog zum feed-receive reading, dass der Wert negativ ist wenn geladen und positiv wenn entladen wird?
Es wäre schön wenn ihr die entsprechenden Werte (auch beispiele) der readings zur Verfügung stellen würdet, dann kann ich das besser (Trocken-)testen.
@habl: pvmax benötigt keine eckigen klammern:
<ftui-grid-tile row="1" col="2" height="8" width="8" shape="round" >
<ftui-pvvis
[charge]="PVA_BT:AktLeistung"
[soc]="PVA_BT:AktBattLadezustand"
[produce]="PVA_PV:Wirkleistung"
pvmax="9520"
[feed-receive]="SMA_EM:Saldo_Wirkleistung"
width="300px">
</ftui-pvvis>
</ftui-grid-tile>Auch bei dir die Frage bezgl des einen Readings für Charge/Discharge der Batterie/Akkus: ist es analog zum feed-receive reading, dass der Wert negativ ist wenn geladen und positiv wenn entladen wird? In der anhängenden Testversion kannst du mit
[charge-discharge]="PVA_BT:AktLeistung"bzw
<ftui-grid-tile row="1" col="2" height="8" width="8" shape="round" >
<ftui-pvvis
[charge-discharge]="PVA_BT:AktLeistung"
[soc]="PVA_BT:AktBattLadezustand"
[produce]="PVA_PV:Wirkleistung"
pvmax="9520"
[feed-receive]="SMA_EM:Saldo_Wirkleistung"
width="300px">
</ftui-pvvis>
</ftui-grid-tile>das Ent/Laden mittels einem Reading definieren.
Auch hier interessieren mich Beispielwerte von
SMA_EM:Saldo_Wirkleistung sowie
PVA_BT:AktLeistungZitat von: habl am 06 Juli 2022, 20:09:38mit deiner letzten aktuellen Version fehlt mir allerdings die Numerische Anzeige vom Feed, kann aber auch sein, dass ich da was falsch definiert habe.
Das könnte am Code liegen: feed und receive werden nicht vorbelegt und bleiben solange leer bis sich etwas am Reading tut.
Die angehängte Testversion belegt die werte mit 0 vor.
bei mir ist es eher so, dass negative Zahlen eher "schlecht" sind, soll heißen:
Negative Zahlen ziehen Strom von der EVU oder die Batterie wird entladen.
Positive Zahlen die PV produziert Strom, die Batterie wird geladen oder es wird in das öffentliche Netz eingespeist.
Bin da aber offen, ich weiß ja jetzt wie ich es negieren kann :)
hier ein paar Ausgaben vom Event Monitor, ich meine das alles dabei ist
BT: laden (+) und entladen (-) und ein AktBattLadezustand: 99 ist auch dabei.
PV: produziert Strom (+)
EM: Einspeisung (+) und Bezug (-)
2022-07-07 13:06:47 dummy PVA_BT AktLeistung: -707
2022-07-07 13:09:03 dummy PVA_BT AktLeistung: 119
2022-07-07 13:07:39 dummy PVA_BT AktBattLadezustand: 99
2022-07-07 13:07:03 dummy PVA_PV Wirkleistung: 3019
2022-07-07 13:06:52 dummy SMA_EM Saldo_Wirkleistung: 221.9
2022-07-07 13:08:28 dummy SMA_EM Saldo_Wirkleistung: -227.0
und falls Du mehrere Beispiele brauchst :)
2022-07-07 13:02:11 dummy PVA_PV Wirkleistung: 2693
2022-07-07 13:02:13 dummy SMA_EM Saldo_Wirkleistung: 2507.5
2022-07-07 13:02:15 dummy PVA_PV Wirkleistung: 2706
2022-07-07 13:02:17 dummy SMA_EM Saldo_Wirkleistung: 2514.4
2022-07-07 13:02:19 dummy PVA_PV Wirkleistung: 2720
2022-07-07 13:02:19 dummy SMA_EM Saldo_Wirkleistung: 2231.9
2022-07-07 13:02:23 dummy SMA_EM Saldo_Wirkleistung: 2238.1
2022-07-07 13:02:25 dummy PVA_PV Wirkleistung: 2735
2022-07-07 13:02:25 dummy SMA_EM Saldo_Wirkleistung: 2541.2
2022-07-07 13:02:28 dummy SMA_EM Saldo_Wirkleistung: 2549.5
2022-07-07 13:02:29 dummy PVA_PV Wirkleistung: 2749
2022-07-07 13:02:31 dummy SMA_EM Saldo_Wirkleistung: 2558.9
2022-07-07 13:02:35 dummy SMA_EM Saldo_Wirkleistung: 2564.0
2022-07-07 13:02:35 dummy PVA_PV Wirkleistung: 2762
2022-07-07 13:02:40 dummy SMA_EM Saldo_Wirkleistung: 2569.3
2022-07-07 13:02:43 dummy PVA_PV Wirkleistung: 2775
2022-07-07 13:02:49 dummy SMA_EM Saldo_Wirkleistung: 1583.2
2022-07-07 13:02:52 dummy SMA_EM Saldo_Wirkleistung: 863.3
2022-07-07 13:02:55 dummy SMA_EM Saldo_Wirkleistung: 897.4
2022-07-07 13:02:58 dummy SMA_EM Saldo_Wirkleistung: 869.3
2022-07-07 13:02:59 dummy PVA_PV Wirkleistung: 2764
2022-07-07 13:03:01 dummy SMA_EM Saldo_Wirkleistung: 549.7
2022-07-07 13:03:04 dummy SMA_EM Saldo_Wirkleistung: 555.7
2022-07-07 13:03:05 dummy PVA_PV Wirkleistung: 2754
2022-07-07 13:03:07 dummy SMA_EM Saldo_Wirkleistung: 860.4
2022-07-07 13:05:15 dummy PVA_PV Wirkleistung: 2348
2022-07-07 13:05:16 dummy SMA_EM Saldo_Wirkleistung: 781.8
2022-07-07 13:05:19 dummy PVA_PV Wirkleistung: 2359
2022-07-07 13:05:19 dummy SMA_EM Saldo_Wirkleistung: 791.8
2022-07-07 13:05:22 dummy SMA_EM Saldo_Wirkleistung: 809.8
2022-07-07 13:05:23 dummy PVA_PV Wirkleistung: 2381
2022-07-07 13:05:25 dummy PVA_PV Wirkleistung: 2392
2022-07-07 13:05:27 dummy PVA_PV Wirkleistung: 2413
2022-07-07 13:05:27 dummy SMA_EM Saldo_Wirkleistung: 754.1
2022-07-07 13:05:29 dummy PVA_PV Wirkleistung: 2429
2022-07-07 13:05:30 dummy SMA_EM Saldo_Wirkleistung: -912.6
2022-07-07 13:05:31 dummy PVA_PV Wirkleistung: 2444
2022-07-07 13:05:33 dummy PVA_BT AktLeistung: -81
2022-07-07 13:05:33 dummy PVA_PV Wirkleistung: 2466
2022-07-07 13:05:33 dummy SMA_EM Saldo_Wirkleistung: -348.1
2022-07-07 13:05:35 dummy PVA_BT AktLeistung: -492
2022-07-07 13:05:35 dummy PVA_PV Wirkleistung: 2487
2022-07-07 13:05:36 dummy SMA_EM Saldo_Wirkleistung: -183.6
2022-07-07 13:05:37 dummy PVA_PV Wirkleistung: 2503
2022-07-07 13:05:38 dummy SMA_EM Saldo_Wirkleistung: -72.5
2022-07-07 13:05:39 dummy PVA_PV Wirkleistung: 2527
2022-07-07 13:05:39 dummy PVA_BT AktLeistung: -726
2022-07-07 13:05:41 dummy PVA_PV Wirkleistung: 2544
2022-07-07 13:05:41 dummy PVA_BT AktLeistung: -801
2022-07-07 13:05:41 dummy SMA_EM Saldo_Wirkleistung: -102.7
2022-07-07 13:05:43 dummy PVA_PV Wirkleistung: 2558
2022-07-07 13:05:44 dummy SMA_EM Saldo_Wirkleistung: -295.7
2022-07-07 13:05:45 dummy PVA_BT AktLeistung: -873
2022-07-07 13:05:45 dummy PVA_PV Wirkleistung: 2578
2022-07-07 13:05:47 dummy PVA_PV Wirkleistung: 2593
2022-07-07 13:05:47 dummy PVA_BT AktLeistung: -1051
2022-07-07 13:06:47 dummy PVA_BT AktLeistung: -707
2022-07-07 13:06:49 dummy PVA_PV Wirkleistung: 2867
2022-07-07 13:06:49 dummy PVA_BT AktLeistung: -682
2022-07-07 13:06:49 dummy SMA_EM Saldo_Wirkleistung: -67.0
2022-07-07 13:06:51 dummy PVA_PV Wirkleistung: 1614
2022-07-07 13:06:52 dummy SMA_EM Saldo_Wirkleistung: 221.9
2022-07-07 13:06:53 dummy PVA_BT AktLeistung: -755
2022-07-07 13:06:53 dummy PVA_PV Wirkleistung: 2956
2022-07-07 13:06:55 dummy PVA_PV Wirkleistung: 2969
2022-07-07 13:06:55 dummy PVA_BT AktLeistung: -912
2022-07-07 13:06:55 dummy SMA_EM Saldo_Wirkleistung: 161.1
2022-07-07 13:06:58 dummy SMA_EM Saldo_Wirkleistung: 86.7
2022-07-07 13:06:59 dummy PVA_PV Wirkleistung: 2992
2022-07-07 13:06:59 dummy PVA_BT AktLeistung: -754
2022-07-07 13:07:01 dummy PVA_PV Wirkleistung: 3004
2022-07-07 13:07:01 dummy PVA_BT AktLeistung: -670
2022-07-07 13:07:03 dummy PVA_PV Wirkleistung: 3019
2022-07-07 13:07:04 dummy SMA_EM Saldo_Wirkleistung: 17.6
2022-07-07 13:07:05 dummy PVA_BT AktLeistung: -621
2022-07-07 13:07:07 dummy PVA_PV Wirkleistung: 3043
2022-07-07 13:07:07 dummy SMA_EM Saldo_Wirkleistung: -155.1
2022-07-07 13:07:09 dummy PVA_BT AktLeistung: -563
2022-07-07 13:07:10 dummy SMA_EM Saldo_Wirkleistung: -103.8
2022-07-07 13:07:11 dummy PVA_PV Wirkleistung: 3064
2022-07-07 13:07:11 dummy PVA_BT AktLeistung: -691
2022-07-07 13:07:13 dummy PVA_PV Wirkleistung: 3075
2022-07-07 13:07:13 dummy SMA_EM Saldo_Wirkleistung: 116.6
2022-07-07 13:07:15 dummy PVA_PV Wirkleistung: 3086
2022-07-07 13:07:16 dummy SMA_EM Saldo_Wirkleistung: 194.6
2022-07-07 13:07:17 dummy PVA_BT AktLeistung: -599
2022-07-07 13:07:17 dummy PVA_PV Wirkleistung: 3103
2022-07-07 13:07:19 dummy PVA_PV Wirkleistung: 3117
2022-07-07 13:07:19 dummy SMA_EM Saldo_Wirkleistung: 62.7
2022-07-07 13:07:21 dummy PVA_PV Wirkleistung: 3127
2022-07-07 13:07:21 dummy PVA_BT AktLeistung: -505
2022-07-07 13:07:22 dummy SMA_EM Saldo_Wirkleistung: 0.4
2022-07-07 13:07:23 dummy PVA_PV Wirkleistung: 3146
2022-07-07 13:07:23 dummy PVA_BT AktLeistung: -456
2022-07-07 13:07:25 dummy PVA_PV Wirkleistung: 3158
2022-07-07 13:07:25 dummy SMA_EM Saldo_Wirkleistung: 88.4
2022-07-07 13:07:27 dummy PVA_BT AktLeistung: -437
2022-07-07 13:07:28 dummy SMA_EM Saldo_Wirkleistung: 76.3
2022-07-07 13:07:29 dummy PVA_BT AktLeistung: -414
2022-07-07 13:07:29 dummy PVA_PV Wirkleistung: 3177
2022-07-07 13:07:31 dummy SMA_EM Saldo_Wirkleistung: 10.4
2022-07-07 13:07:33 dummy PVA_PV Wirkleistung: 3189
2022-07-07 13:07:33 dummy PVA_BT AktLeistung: -394
2022-07-07 13:07:34 dummy SMA_EM Saldo_Wirkleistung: 23.5
2022-07-07 13:07:35 dummy PVA_PV Wirkleistung: 3211
2022-07-07 13:07:35 dummy PVA_BT AktLeistung: -383
2022-07-07 13:07:37 dummy SMA_EM Saldo_Wirkleistung: 43.7
2022-07-07 13:07:39 dummy PVA_BT AktBattLadezustand: 99
2022-07-07 13:07:39 dummy PVA_PV Wirkleistung: 3231
2022-07-07 13:07:39 dummy PVA_BT AktLeistung: -364
2022-07-07 13:07:40 dummy SMA_EM Saldo_Wirkleistung: -438.3
2022-07-07 13:07:41 dummy PVA_PV Wirkleistung: 3243
2022-07-07 13:07:41 dummy PVA_BT AktLeistung: -340
2022-07-07 13:07:43 dummy PVA_PV Wirkleistung: 3259
2022-07-07 13:07:43 dummy SMA_EM Saldo_Wirkleistung: 60.8
2022-07-07 13:07:45 dummy PVA_PV Wirkleistung: 3271
2022-07-07 13:07:45 dummy PVA_BT AktLeistung: -416
2022-07-07 13:07:46 dummy SMA_EM Saldo_Wirkleistung: 21.3
2022-07-07 13:07:47 dummy PVA_PV Wirkleistung: 3295
2022-07-07 13:07:47 dummy PVA_BT AktLeistung: -364
2022-07-07 13:07:49 dummy PVA_PV Wirkleistung: 3312
2022-07-07 13:07:49 dummy SMA_EM Saldo_Wirkleistung: -146.6
2022-07-07 13:07:51 dummy PVA_PV Wirkleistung: 3328
2022-07-07 13:07:51 dummy PVA_BT AktLeistung: -456
2022-07-07 13:07:52 dummy SMA_EM Saldo_Wirkleistung: 265.0
2022-07-07 13:07:53 dummy PVA_PV Wirkleistung: 3350
2022-07-07 13:07:53 dummy PVA_BT AktLeistung: -530
2022-07-07 13:07:55 dummy PVA_PV Wirkleistung: 3366
2022-07-07 13:07:55 dummy SMA_EM Saldo_Wirkleistung: 118.5
2022-07-07 13:07:57 dummy PVA_PV Wirkleistung: 3378
2022-07-07 13:07:57 dummy PVA_BT AktLeistung: -380
2022-07-07 13:07:58 dummy SMA_EM Saldo_Wirkleistung: 67.6
2022-07-07 13:07:59 dummy PVA_PV Wirkleistung: 3410
2022-07-07 13:07:59 dummy PVA_BT AktLeistung: -305
2022-07-07 13:08:01 dummy PVA_PV Wirkleistung: 3431
2022-07-07 13:08:01 dummy SMA_EM Saldo_Wirkleistung: 56.5
2022-07-07 13:08:03 dummy PVA_PV Wirkleistung: 3452
2022-07-07 13:08:03 dummy PVA_BT AktLeistung: -260
2022-07-07 13:08:04 dummy SMA_EM Saldo_Wirkleistung: 45.3
2022-07-07 13:08:05 dummy PVA_PV Wirkleistung: 3472
2022-07-07 13:08:07 dummy PVA_PV Wirkleistung: 3492
2022-07-07 13:08:07 dummy PVA_BT AktLeistung: -224
2022-07-07 13:08:07 dummy SMA_EM Saldo_Wirkleistung: 191.6
2022-07-07 13:08:09 dummy PVA_PV Wirkleistung: 3505
2022-07-07 13:08:09 dummy PVA_BT AktLeistung: -497
2022-07-07 13:08:10 dummy SMA_EM Saldo_Wirkleistung: 87.2
2022-07-07 13:08:11 dummy PVA_PV Wirkleistung: 3528
2022-07-07 13:08:13 dummy PVA_PV Wirkleistung: 3548
2022-07-07 13:08:13 dummy PVA_BT AktLeistung: -368
2022-07-07 13:08:13 dummy SMA_EM Saldo_Wirkleistung: 70.2
2022-07-07 13:08:15 dummy PVA_PV Wirkleistung: 3564
2022-07-07 13:08:15 dummy PVA_BT AktLeistung: -296
2022-07-07 13:08:16 dummy SMA_EM Saldo_Wirkleistung: 50.9
2022-07-07 13:08:17 dummy PVA_PV Wirkleistung: 3585
2022-07-07 13:08:19 dummy PVA_BT AktLeistung: -244
2022-07-07 13:08:19 dummy PVA_PV Wirkleistung: 3600
2022-07-07 13:08:19 dummy SMA_EM Saldo_Wirkleistung: 42.3
2022-07-07 13:08:21 dummy PVA_BT AktLeistung: -208
2022-07-07 13:08:22 dummy SMA_EM Saldo_Wirkleistung: 22.5
2022-07-07 13:08:23 dummy PVA_PV Wirkleistung: 3635
2022-07-07 13:08:25 dummy PVA_PV Wirkleistung: 3649
2022-07-07 13:08:25 dummy PVA_BT AktLeistung: -195
2022-07-07 13:08:27 dummy PVA_PV Wirkleistung: 3667
2022-07-07 13:08:27 dummy PVA_BT AktLeistung: -175
2022-07-07 13:08:28 dummy SMA_EM Saldo_Wirkleistung: -227.0
2022-07-07 13:08:29 dummy PVA_PV Wirkleistung: 3677
2022-07-07 13:08:31 dummy PVA_PV Wirkleistung: 3697
2022-07-07 13:08:31 dummy SMA_EM Saldo_Wirkleistung: -65.9
2022-07-07 13:08:33 dummy PVA_PV Wirkleistung: 3709
2022-07-07 13:08:33 dummy PVA_BT AktLeistung: -303
2022-07-07 13:08:33 dummy SMA_EM Saldo_Wirkleistung: 250.2
2022-07-07 13:08:35 dummy PVA_PV Wirkleistung: 3719
2022-07-07 13:08:36 dummy SMA_EM Saldo_Wirkleistung: 124.8
2022-07-07 13:08:37 dummy PVA_PV Wirkleistung: 3738
2022-07-07 13:08:37 dummy PVA_BT AktLeistung: -235
2022-07-07 13:08:39 dummy PVA_PV Wirkleistung: 3753
2022-07-07 13:08:39 dummy PVA_BT AktLeistung: -134
2022-07-07 13:08:39 dummy SMA_EM Saldo_Wirkleistung: 72.9
2022-07-07 13:08:41 dummy PVA_PV Wirkleistung: 3776
2022-07-07 13:08:42 dummy SMA_EM Saldo_Wirkleistung: 39.6
2022-07-07 13:08:43 dummy PVA_BT AktLeistung: -73
2022-07-07 13:08:43 dummy PVA_PV Wirkleistung: 3795
2022-07-07 13:08:45 dummy PVA_PV Wirkleistung: 3813
2022-07-07 13:08:45 dummy PVA_BT AktLeistung: -48
2022-07-07 13:08:45 dummy SMA_EM Saldo_Wirkleistung: 44.9
2022-07-07 13:08:48 dummy SMA_EM Saldo_Wirkleistung: 35.5
2022-07-07 13:08:49 dummy PVA_PV Wirkleistung: 3840
2022-07-07 13:08:49 dummy PVA_BT AktLeistung: -16
2022-07-07 13:08:51 dummy PVA_PV Wirkleistung: 3851
2022-07-07 13:08:51 dummy SMA_EM Saldo_Wirkleistung: 23.1
2022-07-07 13:08:53 dummy PVA_PV Wirkleistung: 3865
2022-07-07 13:08:55 dummy PVA_BT AktLeistung: 20
2022-07-07 13:08:55 dummy PVA_BT AktLeistung: 35
2022-07-07 13:08:56 dummy SMA_EM Saldo_Wirkleistung: 53.5
2022-07-07 13:08:57 dummy PVA_BT AktLeistung: 51
2022-07-07 13:08:57 dummy PVA_PV Wirkleistung: 3879
2022-07-07 13:09:01 dummy PVA_PV Wirkleistung: 3906
2022-07-07 13:09:01 dummy PVA_BT AktLeistung: 92
2022-07-07 13:09:02 dummy SMA_EM Saldo_Wirkleistung: 47.0
2022-07-07 13:09:03 dummy PVA_BT AktLeistung: 119
2022-07-07 13:09:03 dummy PVA_PV Wirkleistung: 3929
2022-07-07 13:09:05 dummy PVA_PV Wirkleistung: 3945
2022-07-07 13:09:05 dummy SMA_EM Saldo_Wirkleistung: 8.4
2022-07-07 13:09:07 dummy PVA_BT AktLeistung: 147
2022-07-07 13:09:07 dummy PVA_PV Wirkleistung: 3964
2022-07-07 13:09:08 dummy SMA_EM Saldo_Wirkleistung: -222.0
2022-07-07 13:09:09 dummy PVA_PV Wirkleistung: 3986
Zitatpvmax benötigt keine eckigen klammern:
stimmt, hätte ich mir denken können, ist ja ein fixer Wert.
freu mich schon es heute Abend zu testen, ist hier auf der Arbeit momentan nicht möglich.
VG
habl
Danke für die Werte und Erklärungen - dies hilft zumindest mir das ganze besser zu verstehen.
Demnach gibt es seitens des Setups keinen einheitlichen Standard ob die Werte entweder negativ oder positiv sind. Dies scheint jede Anlage individuell zu betrachten.
Stand jetzt ewartet pvvis folgende Werte.
1. bei verschiedenen Readings für jeweils Netzbezug/Einspeisen und Akku ent/laden:
charge => Akku laden wenn Werte >0 (positiv)
discharge => Akku entladen wenn Werte >0 (positiv)
feed => Einspeisen ins Stromnetz/an EVU Werte >0 (positiv)
receive => Verbauch aus dem Stromnetz/vom EVU Werte >0 (positiv)
2. bei kombinierten (sprich einem) Readings für jeweils Netzbezug/Einspeisen und Akku ent/laden:
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)
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)
Kann man sich hier auf ein Vorgehen einigen? Im Zweifel müssen die Werte vorher entsprechend konvertiert werden (via pipe und multiply(-1) wie von Photon68 gezeigt).
Vielen Dank an alle nochmals fürs fleißige Testen. :)
EDIT: verständnis korrigiert
Warum machst Du nicht einfach folgendes:
Wenn charge & discharge definiert sind -> einfach nehmen
Nur charge definiert -> discharge = -charge
Nur discharge definiert -> charge = -discharge
Das selbe für feed/receive.
So habe ich das irgendwann mal noch in das "originale" Widget eingebaut.
Hallo Yersinia,
Rückmeldung zur Testversion von heute morgen aus #52.
Es werden stets die positiven Werte bei produce angezeigt, egal ob sie negativ sind oder nicht. Habe die Version mit und ohne pipe getestet. Die Anzeige im Widget bleibt unverändert.
Ergo Test erfolgreich.
Zitat von: yersinia am 07 Juli 2022, 09:12:48
@Photon68: eine Frage zu deiner Code-Definiton:
[produce]="PVZ:power | multiply (-1)"
Verstehe ich richtig, dass wenn PV Anlage bei dir Strom produziert, das Reading negativ ist? (was auch gar nicht mal unlogisch, da ja ins Hausnetz eingespeist wird, der Verbrauch der PV Anlage bei Einspeisung also negativ ist)
Wenn dem so wäre, könnte man dies auch noch abfangen und du brauchst nur mit
.. genau so ist es bei mir.
@all
Ich denke an dieser Stelle ist wegen der zahlreichen Konstellationen eine Festlegung sinnvoll, ob positive oder negative Werte bei den jeweiligen Parametern [produce] etc. erwartet werden, bzw. was positive/negative Werte bei den kombinierten Parametern [feed-receive] etc. bedeuten.
Jeder User kann bei Bedarf bei der Widgetdefinition mit der pipe multiply(-1) das Vorzeichen ändern, wenn bei ihm die Werte genau das "falsche" Vorzeichen haben.
Heißt ich stimme Yersinia mit seinen Festlegungen in Beitrag #54 zu.
Gruß Photon68
Zitat von: papa am 07 Juli 2022, 14:38:54Warum machst Du nicht einfach folgendes:
Wenn charge & discharge definiert sind -> einfach nehmen
Nur charge definiert -> discharge = -charge
Nur discharge definiert -> charge = -discharge
Das selbe für feed/receive.
Weil mir (noch) nicht klar ist, wie ich das sicher prüfen kann. Mir schien erstmal die zusätzlichen optionalen paramater passender.
@Proton68: danke für die Rückmeldung. :)
es wird also mal wieder Zeit für eine neue Version. 8) Zusammenfassend nochmal alle Parameter, die in dieser Version implementiert sind:
pvmax: maximale Leistung der PV Anlage - dies ist ein fester Wert
[produce]: reading; Produktion der PV Anlage (der Wert wird zu einem positiven Wert konvertiert)
[soc]: reading; Ladestand des Akkus (kann % aber auch Wh annehmen)
[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:
Zitat von: yersinia am 07 Juli 2022, 14:05:28feed-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:
Zitat von: yersinia am 07 Juli 2022, 14:05:28charge-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)
battstep: optional; Grenzwerte für die Ladestandsanzeige des Akkus:
Zitat von: yersinia am 08 Juli 2022, 09:14:04
Ich habe battstep um einen unteren Schwellenwert erweitert, das heisst battstep muss mit genau 5 Werten Kommagetrennt definiert werden, als Beispiel:
battstep="21,35,51,75,95"
Dabei ist 21 der untere Schwellenwert unter dem der Akku grau bleibt. Diese Definition entspricht:
0 bis 21 - Batterie ist ausgegraut
21 bis 35 - kein Balken
35 bis 51 - ein Balken
51 bis 75 - zwei Balken
75 bis 95 - drei Balken
ab 95 - vier Balken
(Standardwerte sind übrigens
battstep="1,24,49,74,95")
has-no-battery: optional; wenn gesetzt wird der Akkustrang rechts ausgeblendet
grid-icon: optional; wenn Wert
pylon definiert ist, wird der Strommast angezeigt; Standard ist
cableZitat von: yersinia am 06 Juli 2022, 13:29:22Ich habe den Strommast von Shadow3561 (https://forum.fhem.de/index.php/topic,119440.msg1226092.html#msg1226092) übernommen und dieser kann nun ausgewählt werden. Dafür gibt es einen zusätzlichen optionalen paramater grid-icon welcher zurzeit die Werte cable (für das Kabel von papa; Standardwert) oder pylon (Strommast) annehmen kann. Ist der Wert nicht gesetzt, wird der Standard als cable definiert. Den Strommast gibt es mit
grid-icon="pylon"
das Kabel entsprechend mit
grid-icon="cable"
Da cable aber Standard ist, kann man den Parameter weg lassen. Invalide Werte wie
grid-icon="BraunkohlekraftwerkJänschwalde"
werden ignoriert und durch cable ersetzt.
width: optional; Breite der Grafik
Zitat von: yersinia am 07 Juli 2022, 17:11:04
Weil mir (noch) nicht klar ist, wie ich das sicher prüfen kann. Mir schien erstmal die zusätzlichen optionalen paramater passender.
So geht es im alten FTUI - keine Ahnung, wie das API jetzt ist
// read values
var consume = elem.getReading('get').val;
var feed = elem.getReading('feed').val;
var produce = elem.getReading('produce').val;
var charge = elem.getReading('charge').val;
var discharge = elem.getReading('discharge').val;
var soc = elem.getReading('soc').val;
var lp1 = elem.getReading('lp1').val;
var lp1pow = elem.getReading('lp1pow').val;
if( discharge === undefined ) {
discharge = 0;
if( charge < 0 ) {
discharge = -charge;
charge = 0;
}
}
else if( charge === undefined ) {
charge = 0;
if( discharge < 0 ) {
charge = -discharge;
discharge = 0;
}
}
Hallo Yersinia,
Version aus #57 funktioniert bei mir so wie dort beschrieben. (getetest ohne Batterie)
Gruß Photon
Hallo yersinia,
wie bei mir mit Batterie funktioniert soweit alles.
Wenn Du noch Lust hast, einen kleinen Wunsch hätte ich noch:
Wenn die Batterieanzeige grau werden sollte, habe ich dickes Problem mit einem tiefentladenen Akku 8)
Meine Batterie schaltet sich im Winter schon bei ~20% ab. Schön wäre es, wenn das Icon dann ebenfalls ausgegraut angezeigt wird.
Daher mein Wunsch entweder:
a) bei battstep ein Wert hinzufügen, das bei unterschreiten die Batterieanzeige ausgegraut wird oder
b) ein Reading auswerten, meine Batterie-Device liefert ein Reading "Anbindung" das entweder "Stromnetz" oder "Getrennt" annehmen kann, wobei über ein Mapping die Werte sicherlich angepasst werden können.
aber nur wenn Du langeweile hast ::)
VG
habl
Die letzte Version funktioniert!
Meine Definition:
<ftui-pvvis
[pvmax]="10000"
[charge-discharge]="my_rct_device:power_battery | multiply(-1)"
[feed-receive]="my_rct_device:power_grid_total"
[soc]="my_rct_device:battery_soc"
[produce]="my_rct_device:power_solarCombined"
grid-icon="pylon"
width="400px"
>
>
</ftui-pvvis>
Das ist mit einem RCT-System mit Batterie...
Wenn ich noch einen Wunsch äußern darf:
Bei meiner Anlage wird in jedem Reading immer ein bisschen was angezeigt. Z.b. Bei reinem Batteriebetrieb sind trotzdem z.B. noch 2 Watt aus dem Netz.
Könnte man zu jedem Wert einen Schwellwert definieren bis zum diesem das Reading auf 0 in der Anzeige gesetzt wird? Und zwar immer absolut.
Also so in etwa Pseudocode:
feed = (abs(feed) <= feed-threshold) ? 0 : feed;
@Nogga
Hinweis.
pvmax braucht keine eckigen Klammern, da es ein fixer Wert zum Berechnen der angezeigten Werte ist.
Aber schön das es funktioniert.
LG mr_petz
Nachtrag:
pvmax berechnet die Geschwindigkeit der angezeigten Stränge je nach Benutzung.
Danke nochmals an alle fürs Testen und die Rückmeldungen. :)
Zitat von: Nogga am 07 Juli 2022, 22:10:53Bei meiner Anlage wird in jedem Reading immer ein bisschen was angezeigt. Z.b. Bei reinem Batteriebetrieb sind trotzdem z.B. noch 2 Watt aus dem Netz.
Könnte man zu jedem Wert einen Schwellwert definieren bis zum diesem das Reading auf 0 in der Anzeige gesetzt wird? Und zwar immer absolut.
Das Problem eines Schwellenwert ist, dass er je nach Anlage, Anwendungsfall und reading variabel ist. Demnach müsste quasi für jedes Reading ein Schwellwert zur Verfügung gestellt werden, was ich, bei der derzeitigen Anzahl der Parameter und in Anbetracht des Mehrwerts, nicht für Sinnvoll erachte. Ich bin eher dazu geneigt, das ganze entweder über FTUI3 eigene Funktionen (sprich über pipes in der Reading-Definition) oder als userReadings im FHEM-Device selbst abwickeln zu lassen.
Zitat von: habl am 07 Juli 2022, 20:20:36Wenn Du noch Lust hast, einen kleinen Wunsch hätte ich noch:
Wenn die Batterieanzeige grau werden sollte, habe ich dickes Problem mit einem tiefentladenen Akku 8)
Meine Batterie schaltet sich im Winter schon bei ~20% ab. Schön wäre es, wenn das Icon dann ebenfalls ausgegraut angezeigt wird.
Daher mein Wunsch entweder:
a) bei battstep ein Wert hinzufügen, das bei unterschreiten die Batterieanzeige ausgegraut wird
Interessant, das mit der Tiefentladung hab ich null bedacht - aber im battstep etwas flexibler sein zu können kommt mir bekannt vor (looking submissively at you mr_petz). Ich habe battstep um einen unteren Schwellenwert erweitert, das heisst battstep muss mit genau 5 Werten Kommagetrennt definiert werden, als Beispiel:
battstep="21,35,51,75,95"Dabei ist 21 der untere Schwellenwert unter dem der Akku grau bleibt. Diese Definition entspricht:
0 bis 21 - Batterie ist ausgegraut
21 bis 35 - kein Balken
35 bis 51 - ein Balken
51 bis 75 - zwei Balken
75 bis 95 - drei Balken
ab 95 - vier Balken
(Standardwerte sind übrigens
battstep="1,24,49,74,95")
Die anhängende Version zum Testen.Edit: eine Frage habe ich noch - bisher sind alle werte Einheitenfrei. Gibt es Bedarf (optional?) Einheiten hinter den Werten zu sehen (%, W, etc)? Wenn ja, welche wären es?
moin yersinia,
das mit dem ausgrauen funktioniert, vielen Dank!
ZitatEdit: eine Frage habe ich noch - bisher sind alle werte Einheitenfrei. Gibt es Bedarf (optional?) Einheiten hinter den Werten zu sehen (%, W, etc)? Wenn ja, welche wären es?
Bei mir werden alle Werte in Watt angezeigt, bis auf Batterie SOC in %.
Mir ist es eigentlich egal, ob eine Einheit angehangen wird. Aber wenn, dann würde ich eher zu kW tendieren, damit der Text nicht zu lang wird.
Übrigens, gerade ist ein Sonne/Wolkenmix und es sieht richtig cool aus wie das Sonneicon immer wieder dunkel/heller wird :)
VG
habl
@yersinia
wenn du magst kannst du das "home-consume-txt" und "pv-produce-txt" ja noch variabel machen.
has-home-consume-txt=true/false"
has-pv-produce-txt="true/false"
oder so ähnlich
Mit freundlichen Grüßen
Für diejenigen, die meine Idee vom "Threshold" gut finden, habe ich das als Helper implementiert - danke für den Tipp yersinia!
Vor der FTUI-JS Definition folgende Zeile einfügen:
<head>
<script>
// Pipe-helper to set any Values lower than threshold to Zero
const thresholdZero = value => input => Math.abs(Number(input)) <= value ? input * 0 : input;
</script>
<script src="ftui.js"></script>
Dann könnt Ihr per Pipe angeben, bis zu welchem Wert etwas genullt werden soll, weil irrelevant. Ist natürlich nur der Optik wegen:
<ftui-pvvis
pvmax="10000"
[charge-discharge]="my_rct_device:power_battery | multiply(-1) | thresholdZero(10)"
[feed-receive]="my_rct_device:power_grid_total | multiply(-1) | thresholdZero(15)"
[soc]="my_rct_device:battery_soc"
[produce]="my_rct_device:power_solarCombined | thresholdZero(20)"
grid-icon="pylon"
width="400px"
class="fixed"
style="left: 600px;"
></ftui-pvvis>
In meinem Fall werden z.B. die Werte für das Netz (Bezug/Einspeisen) bis 15 Watt auf 0 gesetzt - erst darüber werden sie "durchgelassen".
Analog für den PV-Etrag erst ab 20 Watt...
Zitat von: yersinia am 08 Juli 2022, 09:14:04
Danke nochmals an alle fürs Testen und die Rückmeldungen. :)
Das Problem eines Schwellenwert ist, dass er je nach Anlage, Anwendungsfall und reading variabel ist. Demnach müsste quasi für jedes Reading ein Schwellwert zur Verfügung gestellt werden, was ich, bei der derzeitigen Anzahl der Parameter und in Anbetracht des Mehrwerts, nicht für Sinnvoll erachte. Ich bin eher dazu geneigt, das ganze entweder über FTUI3 eigene Funktionen (sprich über pipes in der Reading-Definition) oder als userReadings im FHEM-Device selbst abwickeln zu lassen.
Interessant, das mit der Tiefentladung hab ich null bedacht - aber im battstep etwas flexibler sein zu können kommt mir bekannt vor (looking submissively at you mr_petz). Ich habe battstep um einen unteren Schwellenwert erweitert, das heisst battstep muss mit genau 5 Werten Kommagetrennt definiert werden, als Beispiel:
battstep="21,35,51,75,95"
Dabei ist 21 der untere Schwellenwert unter dem der Akku grau bleibt. Diese Definition entspricht:
0 bis 21 - Batterie ist ausgegraut
21 bis 35 - kein Balken
35 bis 51 - ein Balken
51 bis 75 - zwei Balken
75 bis 95 - drei Balken
ab 95 - vier Balken
(Standardwerte sind übrigens
battstep="1,24,49,74,95")
Die anhängende Version zum Testen.
Edit: eine Frage habe ich noch - bisher sind alle werte Einheitenfrei. Gibt es Bedarf (optional?) Einheiten hinter den Werten zu sehen (%, W, etc)? Wenn ja, welche wären es?
Moin,
ich würde W und % favorisieren.
LG
@yersinia
Leider haben der Hausverbrauch und PV-Home-Flow nicht immer die gleichen Werte (siehe Bild).
Ich habe bei mir jetzt die Math.abs() durch Math.round() ersetzt. Jetzt scheint es zu stimmen.
Mit freundlichen Grüßen
@Shadow3561
yersinia hatte extra Math.abs() eingebaut, da andere Nutzer mit negativen Werten kamen und Math.abs() diese auf einen positiven Wert setzt für die weitere Berechnung.
Math.abs() ist nur dafür da und nicht zum runden.
Wenn dann könnte yersinia Bsp. Math.round(Math.abs(this.produce) - this.charge - this.feed) kombinieren.
Ich denke aber, dass der Hausverbrauch auch bei Math.round() unterschiedlich sein kann. Da brauch nur die Kommastelle einmal <0.5 und einmal >0.5 sein der Einspeisungen zum Hausverbrauch...
LG mr_petz
Dann bleibt mir wohl nur die Option userReadings im Device selbst zu definieren und dann die angezeigten Werte in pvvis nicht zu berechnen sondern nur aus dem Device zu übernehmen.
Es sieht auf alle Fälle seltsam aus wenn die PV 1 Watt zu wenig anzeigt.
Mit freundlichen Grüßen
Könntest du bitte mal die jetzigen Werte aus dem Device zeigen?
Sind das unterschiedliche Devices die deine Watt zählen?
LG
Ich hoffe du meinst die Readings aus FHEM
READINGS:
2022-07-09 17:21:50 AC_Lifetime_Energy_production_kWh 7061.03
2022-07-09 17:22:00 AC_current_W 752.8
2022-07-09 17:21:55 ActiveStateCode On - SearchingMPPT
2022-07-09 17:22:00 DC_current_A 2.05
2022-07-09 17:22:01 DC_current_V 371.7
2022-07-09 17:21:52 DC_current_W 762.2
2022-07-09 17:10:59 Device_model SE3500H-RW000BNN4
2022-07-09 17:22:01 Eigenverbrauch 4.87
2022-07-09 17:22:01 Ersparnis_Einkauf 1.58
2022-07-09 17:22:01 Ersparnis_Gesamt 2.72
2022-07-09 17:22:01 Ersparnis_Verkauf 1.14
2022-07-09 17:22:01 Hausverbrauch 465.8
2022-07-09 17:22:01 Hausverbrauch_uitable -465.80
2022-07-09 17:21:53 Heat_Sink_Temperature 34.96
2022-07-09 17:11:10 Inverter_map single.phase
2022-07-09 17:10:49 Manufacturer SolarEdge
2022-07-09 17:12:26 Meter_Device_model SE-MTR-3Y-400V-A
2022-07-09 17:12:13 Meter_Manufacturer SolarEdge
2022-07-09 17:11:05 Modbus_Address 5
2022-06-24 19:35:22 Momentanleistung 0
2022-07-09 17:22:01 Momentanleistung_Bezug 0
2022-07-09 17:22:01 Momentanleistung_Bezug_FTUI3 0
2022-07-09 17:22:01 Momentanleistung_Einspeisung 287
2022-06-24 19:35:22 Momentanleistung_feed 607
2022-07-09 17:21:56 Power 287
2022-07-09 17:22:01 Power_uitable -287
2022-07-09 17:22:01 Produktion 753
2022-07-09 17:11:00 SW_Version_Inverter_CPU 4.9.33
2022-07-09 17:11:24 Serialnumber ........
2022-07-09 17:22:01 TagesErtrag 15.92
2022-07-09 17:22:01 TagesExport 11.05
2022-07-09 17:22:01 TagesImport 3.49
2022-07-09 17:22:01 TagesImport_Kosten 1.13
2022-07-09 17:22:01 TagesImport_uitable -3.49
2022-07-08 22:59:00 kWh_last_day 7045.11
2022-07-08 22:50:00 kWh_last_day_exported 3783.862
2022-07-08 23:59:59 kWh_last_day_imported 5877.884
2022-07-08 21:59:30 last_day_ertrag 16.72
2022-07-08 21:59:00 last_day_exported 9.20
2022-07-08 23:59:59 last_day_imported 0.00
2022-07-09 12:06:09 state opened
2022-07-09 17:21:57 total_Energy_Exported_kWh 3794.917
2022-07-09 17:21:57 total_Energy_Imported_kWh 5881.372
Ok ja ich meinte natürlich Fhem Device :D
Ich schau mal durch ob es an den Berechnungen im Modul oder an den Werten die kommen liegt.
Mal schauen ob ich was finde....
LG
Edit:
sind das noch deine Werte?->
[feed]="SE3500H:Momentanleistung_Einspeisung"
[produce]="SE3500H:Produktion"
pvmax="3500"
[receive]="SE3500H:Momentanleistung_Bezug"
[home]="SE3500H:Hausverbrauch"
z.Z. nutze ich es so
<ftui-pvvis
has-no-battery
grid-icon="pylon"
[feed-receive]="SE3500H:Power"
[produce]="SE3500H:AC_current_W"
pvmax="3000"
width="300px">
Edit:
Es liegt wohl am "Power" Reading. Dies ist immer einen Ganzzahl. Positiv bei Einspeisung und negatives Vorzeichen bei Bezug.
Das "AC_current_W" ist dagegen mit einer Nachkommastelle.
Edit:
Irgendetwas stimmt in der Berechnung, zumindest bei mir, nicht (siehe Screenshot)
Wenn ich es so einzeln definiere stimmt alles
[feed]="SE3500H:Momentanleistung_feed"
[receive]="SE3500H:Momentanleistung_Bezug"
Ok ich konnte es nachstellen.
Es ist ein wenig kompliziert zu erklären, aber es liegt an der Kommazahl von produce (AC_current_W).
Power hingegen scheint eine schon gerundete Zahl zu sein.
Wenn du testweise so toFixed(1) bei den Berechnungen schreibst, wirst du sehen, dass es nicht 465 sondern 465.8 sind und durch toFixed() die 8 gestrichen wird.
Als erstes würde ich schon für dich es so Vorschlagen:
[feed-receive]="SE3500H:Power | round(0)"
Edit:
[produce]="SE3500H:AC_current_W | round(0)"
Ich hoffe die pipe funktioniert mit dem Modul.
alternativ sollte es auch so bei dir gehen (im Code ändern):
this.pvhomeval = Math.round(Math.abs(this.produce) - this.charge - this.feed);
Hier muss aber yersinia die anderen Berechnungen auch mit anpassen.
LG
Edit: Ok du warst scheller... :D
Habe erst mal den genommen.
this.pvhomeval = Math.round(Math.abs(this.produce) - this.charge - this.feed);
Ich werde beobachten und melde mich wieder.
[feed-receive]="SE3500H:Power | round(0)"
du meinst sicher [feed-receive]="SE3500H:AC_current_W | round(0)"
Mit freundlichen Grüßen
Ok sorry, aber wenn dann so:
[produce]="SE3500H:AC_current_W | round(0)"
:D
funktioniert die pipe?
LG
das habe ich nicht ausprobiert. Die Frau kocht im Moment und es springe alle Werte hin und her.
Ich gehe aber einfach mal davon aus, dass pipe funktioniert, siehe #61
Mit freundlichen Grüßen
Edit:
Habe es jetzt mit pipe probiert und es funktioniert ebenso.
Danke dir
Mit freundlichen Grüßen
@yersinia
Ich habe mir die Freiheit genommen und etwas geändert.
Die Wattzahl vom Netzbezug wird nur angezeigt wenn Netzbezug grösser 0
Die Wattzahl von der Netzeinspeisung wird nur angezeigt wenn größer 0
colorGrid() {
let consumption = this.receive - this.feed;
this.grid.classList.remove("pvvis-grid-feed", "pvvis-grid-consume", "grid-home");
if(consumption > 0 ) { this.grid.classList.add("pvvis-grid-consume"); this.shadowRoot.getElementById("pv-grid-txt").innerHTML = ""; } else { this.grid.classList.add("pvvis-grid-feed"); this.shadowRoot.getElementById("grid-home-txt").innerHTML = ""; }
}
Mit freundlichen Grüßen
@Shadow3561: vielen Dank fürs Testen und die Rückmeldung.
Zitat von: Shadow3561 am 08 Juli 2022, 19:17:16wenn du magst kannst du das "home-consume-txt" und "pv-produce-txt" ja noch variabel machen.
has-home-consume-txt=true/false"
has-pv-produce-txt="true/false"
Ich weiss nicht, die Texte optional ein und ausblenden zu können fänd ich als paramater nicht zielführend. Mir erschließt sich auch nicht, warum man das nicht sehen möchte (aber ich habe auch keinen Anwendungsfall und bin daher auf euch angewiesen).
Du kannst aber für dich im pvvis.component.css folgendes ergänzen:
.pvvis-home-text,
.pvvis-produce-txt {
display: none;
}Dadurch werden die Elemente ausgeblendet.
Zitat von: Shadow3561 am 09 Juli 2022, 16:26:40Leider haben der Hausverbrauch und PV-Home-Flow nicht immer die gleichen Werte (siehe Bild).
Ja, das liegt, wie mr_petz schon schreibt, an der Berechnung. Für die Berechnung nutze ich keine gerundeten Werte, aber zur Anzeige werden mittels
toFixed()) alle Nachkommastellen abgeschnitten.
Zitat von: Shadow3561 am 09 Juli 2022, 16:26:40Ich habe bei mir jetzt die Math.abs() durch Math.round() ersetzt. Jetzt scheint es zu stimmen.
Zitat von: mr_petz am 09 Juli 2022, 17:09:30yersinia hatte extra Math.abs() eingebaut, da andere Nutzer mit negativen Werten kamen und Math.abs() diese auf einen positiven Wert setzt für die weitere Berechnung.
Math.abs() ist nur dafür da und nicht zum runden.
Wenn dann könnte yersinia Bsp. Math.round(Math.abs(this.produce) - this.charge - this.feed) kombinieren.
Ich denke aber, dass der Hausverbrauch auch bei Math.round() unterschiedlich sein kann. Da brauch nur die Kommastelle einmal <0.5 und einmal >0.5 sein der Einspeisungen zum Hausverbrauch...
+1
Zitat von: Shadow3561 am 09 Juli 2022, 17:41:35Es liegt wohl am "Power" Reading. Dies ist immer einen Ganzzahl. Positiv bei Einspeisung und negatives Vorzeichen bei Bezug.
Das "AC_current_W" ist dagegen mit einer Nachkommastelle.
Edit:
Irgendetwas stimmt in der Berechnung, zumindest bei mir, nicht (siehe Screenshot)
Wenn ich es so einzeln definiere stimmt alles
[feed]="SE3500H:Momentanleistung_feed"
[receive]="SE3500H:Momentanleistung_Bezug"
Das kann ich nicht nachstellen. Wenn ich produce auf 788 und feed-receive auf -614 setze, dann zeigt der Hausverbrauch 1402 an. Die Anzeige des Bezugs (roter flow) zeigt 614 an.
Zitatfeed-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)
Wie sind denn deine Werte von Power in diesem Fall?
Zitat von: Shadow3561 am 09 Juli 2022, 18:19:08
Habe erst mal den genommen.
this.pvhomeval = Math.round(Math.abs(this.produce) - this.charge - this.feed);
Das kann zu weiteren Berechnungsfehlern führen da pvhomeval auch für houseConsume genutzt wird (pvhomeval + receive + discharge). Die round(0) pipe der readings finde ich daher wesentlich eleganter.
Zitat von: Shadow3561 am 10 Juli 2022, 14:03:17Die Wattzahl vom Netzbezug wird nur angezeigt wenn Netzbezug grösser 0
Die Wattzahl von der Netzeinspeisung wird nur angezeigt wenn größer 0
colorGrid() {
let consumption = this.receive - this.feed;
this.grid.classList.remove("pvvis-grid-feed", "pvvis-grid-consume", "grid-home");
if(consumption > 0 ) { this.grid.classList.add("pvvis-grid-consume"); this.shadowRoot.getElementById("pv-grid-txt").innerHTML = ""; } else { this.grid.classList.add("pvvis-grid-feed"); this.shadowRoot.getElementById("grid-home-txt").innerHTML = ""; }
}
Ist das ein Konsens hier, dass wenn die Werte = 0 sind die Texte dann ausgeblendet werden anstelle der Anzeige von 0? Dann könnte man dies konsequenter in der component einbauen...
Hallo zusammen,
anbei eine neue Testversion mit folgenden Änderungen:
-
die internen Werte zur Berechnung des Hausverbrauchs und des Verbrauchs PV->Home werden nun auf Ganzzahl gerundet (
vorher war nur die Anzeige ist Ganzzahlig)
@Shadow3561:
das wäre für dich sicher ganz gut - zumindest wenn man eine Anlage hat, die eigentlich alles praktischerweise in W anzeigt und Zahlwert bis 9999 zu erwarten sind. Wenn aber wie von habl
kW vorgeschlagen wird
Zitat von: habl am 08 Juli 2022, 16:28:38Mir ist es eigentlich egal, ob eine Einheit angehangen wird. Aber wenn, dann würde ich eher zu kW tendieren, damit der Text nicht zu lang wird.
und die Werte in kW angezeigt werden sollen, werden mit dieser Testversion aus 2,4kW "nur" 2kW; aus 3,6kW entsprechend 4kW. Demnach sollte die Pipe mit round(0) besser funktionieren, oder?
Edit: das runden sollte über pipe und round(0) laufen.
- es gibt zwei neue optionale Parameter für die Einheiten:
unit-soc für die Einheit des Akkustands, zB:
unit-soc="%"unit-value für die Einheit der Ent/Lade-Werte, zB:
unit-value="W"Sind die Werte nicht gesetzt wird auch keine Einheit gesetzt.
Ansonsten wäre es super, wenn ihr bei Anzeigefragen auch Werte der Readings mitliefern könntet - ansonsten ist es echt schwierig nachzustellen. Danke vorab.
Zitat von: yersinia am 10 Juli 2022, 16:32:31
Hallo zusammen,
anbei eine neue Testversion mit folgenden Änderungen:
- die internen Werte zur Berechnung des Hausverbrauchs und des Verbrauchs PV->Home werden nun auf Ganzzahl gerundet (vorher war nur die Anzeige Ganzzahlig) @Shadow3561: das wäre für dich sicher ganz gut - zumindest wenn man eine Anlage hat, die eigentlich alles praktischerweise in W anzeigt und Zahlwert bis 9999 zu erwarten sind. Wenn aber wie von habl kW vorgeschlagen wirdund die Werte in kW angezeigt werden sollen, werden mit dieser Testversion aus 2,4kW "nur" 2kW; aus 3,6kW entsprechend 4kW. Demnach sollte die Pipe mit round(0) besser funktionieren, oder?
- es gibt zwei neue optionale Parameter für die Einheiten:
unit-soc für die Einheit des Akkustands, zB:
unit-soc="%"
unit-value für die Einheit der Ent/Lade-Werte, zB:
unit-value="W"
Sind die Werte nicht gesetzt wird auch keine Einheit gesetzt.
Ansonsten wäre es super, wenn ihr bei Anzeigefragen auch Werte der Readings mitliefern könntet - ansonsten ist es echt schwierig nachzustellen. Danke vorab.
Moin yersinia,
vielen Dank nochmal für deine Mühe hier allen gerecht zu werden!
Ich hätte noch folgende Anmerkungen bzw. Wünsche:
- Ich bin der Meinung das die Ganze Rechnerei die du versuchts zu ermöglichen nicht in das Anzeigemodul reingehört, und lieber in FHEM direkt z.B. über userReadings erfolgen sollte.
Dann kann auch jeder die Werte beisteuern die er haben möchte (Ist aber nur eine persönliche Meinung).
- Könnten die Einheit kleiner angezeigt werdern? Ich habe die Einheit immer in der Hälfte der Größe des Wertes.
- Verglichen mit den anderen Symbolen (Sonne, Haus...) sieher der Pylon optisch nicht so optimal aus. Wäre es möglich diesen Fetter darzustellen?
Grüße
Olli
Die neue Version läuft bei mir nicht. Hier der Ausgabe der Konsole...
Zitat von: octek0815 am 10 Juli 2022, 17:41:53
Die neue Version läuft bei mir nicht. Hier der Ausgabe der Konsole...
Ja.
erste Zeile muss raus.
cat components/pvvis/pvvis.component.js
und das template stimmt auch nicht mehr...
transform muss wieder rein...
LG
Zitat von: octek0815 am 10 Juli 2022, 17:41:53
Die neue Version läuft bei mir nicht. Hier der Ausgabe der Konsole...
Ach verdammt, copy&paste fehler. :-X
Korrigierte Version hängt oben an.
Zitat von: mr_petz am 10 Juli 2022, 18:14:34
erste Zeile muss raus.
cat components/pvvis/pvvis.component.js
und das template stimmt auch nicht mehr...
transform muss wieder rein...
transform muss wieder rein? Müsste mit der css aus #57 (https://forum.fhem.de/index.php/topic,119440.msg1227262.html#msg1227262) (identisch mit der anhängenden) eigtl funktionieren. Wegen der Konsistenz habe ich alle Style-Anweisungen ins CSS gepackt.
Ja mit dieser css und js geht es wieder.
Hatte nicht mitbekommen, dass es eine neue css gibt. Habe immer nur das js überschrieben...
LG
Zitat von: octek0815 am 10 Juli 2022, 17:29:27vielen Dank nochmal für deine Mühe hier allen gerecht zu werden!
Dank dir für den Test und das konstrutive Feedback. :)
Zitat von: octek0815 am 10 Juli 2022, 17:29:27- Ich bin der Meinung das die Ganze Rechnerei die du versuchts zu ermöglichen nicht in das Anzeigemodul reingehört, und lieber in FHEM direkt z.B. über userReadings erfolgen sollte.
Dann kann auch jeder die Werte beisteuern die er haben möchte (Ist aber nur eine persönliche Meinung).
Das sehe ich ähnlich auch weil die Varianz der Werte als auch der verschiedenen Wünsche recht hoch ist. Ich hab das wieder ausgebaut. Interessant wird es allerdings wenn die User mit kW um die Ecke kommen und dann 2,345kW zu 2kW in der Anzeige werden. Da bin ich mal auf die Rückmeldungen gespannt, ob es diesen Fall überhaupt gibt.
Zitat von: octek0815 am 10 Juli 2022, 17:29:27- Könnten die Einheit kleiner angezeigt werdern? Ich habe die Einheit immer in der Hälfte der Größe des Wertes.
- Verglichen mit den anderen Symbolen (Sonne, Haus...) sieher der Pylon optisch nicht so optimal aus. Wäre es möglich diesen Fetter darzustellen?
Ich hab die Einheit auf 75% der Schriftgröße der Werte gesetzt - sieht etwas komisch aus wenn aus einem W visuell ein w wird.
Den Pylon hab ich etwas dicker dargestellt, es ist aber recht schwierig, da nicht viel Platz für einen nicht adipösen ;) Pylonen vorhanden ist.
Anbei ein Screenshot des Versuchs, passt das?
(Btw, wenn man ein Leerzeichen zwischen Wert und Einheit haben möchte muss man das explizit angeben:
unit-value=" W")
Zitat von: yersinia am 10 Juli 2022, 20:33:12
Dank dir für den Test und das konstrutive Feedback. :)
Das sehe ich ähnlich auch weil die Varianz der Werte als auch der verschiedenen Wünsche recht hoch ist. Ich hab das wieder ausgebaut. Interessant wird es allerdings wenn die User mit kW um die Ecke kommen und dann 2,345kW zu 2kW in der Anzeige werden. Da bin ich mal auf die Rückmeldungen gespannt, ob es diesen Fall überhaupt gibt.
Ich hab die Einheit auf 75% der Schriftgröße der Werte gesetzt - sieht etwas komisch aus wenn aus einem W visuell ein w wird.
Den Pylon hab ich etwas dicker dargestellt, es ist aber recht schwierig, da nicht viel Platz für einen nicht adipösen ;) Pylonen vorhanden ist.
Anbei ein Screenshot des Versuchs, passt das?
(Btw, wenn man ein Leerzeichen zwischen Wert und Einheit haben möchte muss man das explizit angeben:
unit-value=" W")
Hi,
hast du mal die neue pvvis.component.js parat, zwecks testen (in der eigene Oberfläche) ;-)
Wenn nur kW geliefert würde ich die Umrechnung in W ebenfalls nur in FHEM zulassen.
Wie bereits geschrieben, Berechnungen und Umrechnungen sollen in FHEM erfolgne und nicht in FTUI.
Danke und Grüße
Olli
Zitat von: octek0815 am 10 Juli 2022, 20:48:15hast du mal die neue pvvis.component.js parat, zwecks testen (in der eigene Oberfläche) ;-)
Jup. Aber sowohl die js als auch css müssen ersetzt werden.
Kleines Update:
- kleine Korrektur: einige classes wurden falsch zugeordnet
- Erweiterung: neuer experimenteller parameter do-not-show-zero: wenn gesetzt (Verwendung analog zu has-no-battery), werden alle gerundeten 0-Werte nicht angezeigt.
Nutzung weiterhin wie in #57 (https://forum.fhem.de/index.php/topic,119440.msg1227262.html#msg1227262) (und bezgl battstep das Update in #64 (https://forum.fhem.de/index.php/topic,119440.msg1227334.html#msg1227334) sowie von unit-soc und unit-value das Update in #82 (https://forum.fhem.de/index.php/topic,119440.msg1227572.html#msg1227572)) beschrieben.
Ich habe mal auf gefällt ;) mir geklickt für dein Arrangement hier, wenn es sonst keiner macht...
LG mr_petz
Zitat von: mr_petz am 11 Juli 2022, 17:39:18
Ich habe mal auf gefällt ;) mir geklickt für dein Arrangement hier, wenn es sonst keiner macht...
LG mr_petz
Recht hast du!
Ich bin bei ftui3 gerade auf Entdeckerreise und von dieser Komponente begeistert. Ganz tolle Arbeit! Beim Probieren ist mir bei meiner Anlage was aufgefallen (siehe Bild), was sehr wahrscheinlich auch andere Gründe haben könnte.
Wenn das Reading der Anlage sich verändert, reagiert die Anzeige von ftui-pvvis sehr verzögert und rechnet das Laden der Batterie dem Hausverbrauch zu.
Kurz mein Bild erklärt:
- PV liefert 923
- Haus benötigt 507
- Batterie läd mit 417 (wird aber nicht in SVG angezeigt)
- Einspeisung in das Netz 3 (Einspeisung wird bei mir neagtiv angezeigt)
Die Werte werden bei meinem S10 Device aller 10 Sekunden geladen (event-on-change-reading und event-on-update-reading haben den Wert ".*". Trotzdem zeigt er in regelmäßigen Abständen keine Batterieleistung an, sondern rechnet diese dem Hausverbrauch zu. Nach erneuter Änderung der Readings klappt es manchmal mit der Anzeige. Ich kann es nicht so richtig reproduzieren.
Was könnte die Ursache sein?
<ftui-pvvis
[pvmax]="8000"
[soc]="S10E:Batterieladezustand"
[feed-receive]="S10E:Netzleistung | multiply (-1)"
[charge-discharge]="S10E:Batterieleistung"
[produce]="S10E:Solarleistung"
grid-icon="pylon"
width="400px"
>
</ftui-pvvis>
Ich weiß, die Werte passen mit dem Bild nicht genau, aber das Grundproblem sollte verständlich sein.
Eine Frage fehlt mir noch ein. Kann man die aktuellen Werte auch ohne Berechnung anzeigen lassen?
Hi, ok als erstes die [] wegnehmen bei pvmax.
pvmax ist hier ein fester Wert und kein Reading.
@yersinia
Hier scheint was falsch zu sein im Code (denke ich zumindest):
case 'charge-discharge':
// one reading - negative when discharge; positive when charge
if(this.chargeDischarge < 0) {
this.discharge = Math.abs(this.chargeDischarge);
this.charge = 0;
} else if(this.feedReceive > 0) {
this.charge = this.chargeDischarge;
this.discharge = 0;
} else {
this.charge = 0;
this.discharge = 0;
}
break;
müsste:
case 'charge-discharge':
// one reading - negative when discharge; positive when charge
if(this.chargeDischarge < 0) {
this.discharge = Math.abs(this.chargeDischarge);
this.charge = 0;
} else if(this.chargeDischarge > 0) {
this.charge = this.chargeDischarge;
this.discharge = 0;
} else {
this.charge = 0;
this.discharge = 0;
}
break;
copy/paste?? ;D
LG
Zitat von: mr_petz am 15 Juli 2022, 13:33:27Hi, ok als erstes die [] wegnehmen bei pvmax.
pvmax ist hier ein fester Wert und kein Reading.
+1
Zitat von: mr_petz am 15 Juli 2022, 13:33:27 } else if(this.feedReceive > 0) {
müsste:
} else if(this.chargeDischarge > 0) {
copy/paste?? ;D
:o ::) *hust* Neeeeeiiiiin. Tausend mal geprüft und nicht gesehen. ::) Danke @h002 fürs melden! :)
Korrigierte Version anhängend.
Nutzung weiterhin wie in #57 (https://forum.fhem.de/index.php/topic,119440.msg1227262.html#msg1227262) (und bezgl
battstep das Update in #64 (https://forum.fhem.de/index.php/topic,119440.msg1227334.html#msg1227334) sowie von
unit-soc und
unit-value das Update in #82 (https://forum.fhem.de/index.php/topic,119440.msg1227572.html#msg1227572)) beschrieben.
Genau das war es. Hatte es auch im Code gesehen, dachte aber das feedReceive muss so sein, da ich ungeeignet bin die Gesamtlogik zu verstehen und mich nicht blamieren wollte. :-)
Für mich funktioniert es wie erwartet. :-)
Nochmals Danke für die prima Umsetzung! :D
Zitat von: h002 am 15 Juli 2022, 13:49:39Genau das war es. Hatte es auch im Code gesehen, dachte aber das feedReceive muss so sein, da ich ungeeignet bin die Gesamtlogik zu verstehen und mich nicht blamieren wollte. :-)
Neee, das ergibt ja keinen Sinn. feed-receive und charge-discharge dienen nur als Vehikel um dann intern feed, receive, charge und discharge zu definieren. Da hat bei charge-discharge feedReceive nüschts zu suchen.
Ansonsten kann man sich hier auch gerne in der Gruppe blamieren - zumindest ich kann nur Trockentesten mangels PV Anlage. Daher ist Feedback von euch sehr willkommen - insbesondere mit readings list.
Zitat von: yersinia am 15 Juli 2022, 13:46:20
...
:o ::) *hust* Neeeeeiiiiin. Tausend mal geprüft und nicht gesehen. ::)...
...
Keine Sorge... passiert auch den Besten. ;)
Aber hier sehen ja viele Augen hin. Nichts bleibt unaufgedeckt... ;D
LG
@h002
Zitat
event-on-change-reading und event-on-update-reading haben den Wert ".*"
Ist nicht zu empfehlen bzw. macht die Attribute wirkungslos ...
Zitat von: OdfFhem am 15 Juli 2022, 15:34:04
@h002
Ist nicht zu empfehlen bzw. macht die Attribute wirkungslos ...
Hi OdfFhem, lange nichts gehöhrt voneinander... :D
Ich denke event-on-change-reading macht schon sinn, wenn man es richtig anwendet.
im Bsp von @h002:
attr S10E event-on-change-reading Batt.*,Netzleistung,Solarleistung
so werden nur Event´s für FTUI,notify,log etc. erzeugt aus den 4 Readings wenn sie sich ändern.
Zur Not noch einen threshold einfügen wenn ein Wert minimal schwankt.
Die Systemlast wird dadurch auch reduziert.
Es sei denn er braucht mehr. Oder sehe ich das falsch??
https://wiki.fhem.de/wiki/Event-on-change-reading#Syntax
event-on-update-reading hingegen würde ich so auch nicht anwenden.
Höhere Systemlast.
Ist ja glaube automatisch in fhem, dass Events bei update erzeugt werden oder?
LG
@mr_petz
Hi, der nächste Herbst/Winter kommt bestimmt ;)
Es ging tatsächlich um die von h002 genannte Kombination:
- event-on-change-reading auf ".*" ... nur Wertänderung beim Reading führt zum Event
- event-on-update-reading auf ".*" ... jede Aktualisierung (auch ohne Wertänderung) beim Reading führt zum Event
==> entspricht exakt dem Standardverhalten ... die beiden Attribute könnte man also so auch weglassen
event-on-change-reading findet mit ".*" breites Interesse, da man damit massiv unnötige Events vermeidet - im Zweifel kombiniert mit Schwellwerten
event-on-update-reading verwendet man eigentlich nur für (eher einzelne) Readings, die auch mit demselben Wert eine Bedeutung haben ... z.B. leiser/lauter oder rauf/runter
Ich hatte event-on-update-reading für einen Test wegen dem o.g. Problem mit der Batterie eingetragen und später wieder entfernt. Bei event-on-change-reading habe ich produktiv spezifische Readings, damit u.a. das Statistik-Modul greift.
Vielen Dank trotzdem für den Hinweis.
Tolle Arbeit !!! Sieht sehr ansprechend aus . Ich bin auf der Suche nach genau so etwas und habe nicht schon gefreut endlich was gefunden zu haben.
Nun hab ich genauer hingesehen und bemerkt das sich dieses Widget wohl nur unter FTUI3 installieren lässt. Leider habe ich mein ganzes Projekt auf FTUI2 laufen.
Gibt es eine dafür Lösung außer das ich meine seehr umfangreiches UI umstelle was definitiv nicht in Frage kommt !
Zitat von: Skusi am 28 Juli 2022, 09:30:43Nun hab ich genauer hingesehen und bemerkt das sich dieses Widget wohl nur unter FTUI3 installieren lässt.
Jap, aber
Zitat von: Skusi am 28 Juli 2022, 09:30:43Leider habe ich mein ganzes Projekt auf FTUI2 laufen.
Gibt es eine dafür Lösung außer das ich meine seehr umfangreiches UI umstelle was definitiv nicht in Frage kommt !
=> post #3 (https://forum.fhem.de/index.php/topic,119440.msg1138919.html#msg1138919) (Grafik in #1 (https://forum.fhem.de/index.php/topic,119440.msg1138772.html#msg1138772))
POTZBLITZ !
Das hab ich echt überlesen. Naja, hab das mal gleich eingepflegt und mit readings gefüttert.
Das widget wird schonmal angezeigt und sieht echt cool aus. Aber....
Die benötigten Parameter kann ich so leider nicht alle liefern:
data-device - Gerät, das den Refresh triggert
Was genau ist mit "triggert" gemeint ? Bin mir nicht sicher welches Device ich da angeben soll.
data-get - Verbrauch Haus
OK ! aktueller Power Wert von meinem SML Lesekopf des Stromzählers
funktioniert, aktueller Bezug wird angezeigt.
data-feed - Einspeisungs in Netz
Das ist bei mir das selbe Reading wie oben (Bezug) allerdings al negativ Wert !
Wie soll ich das angeben ? Gibts die Möglichkeit wie in FTUI3 das auf ein einzelnes Reading zu legen ?
data-produce - Production PV-Anlage
OK Hab ich das Power Reading meiner PV Angeben, wird aber nicht angezeigt !?
data-charge - Ladung Akku
data-discharge - Entladung Akku
data-soc - Ladezustand Battery
Ich habe gar keine Akku ;-) kann man den irgendwie ausblenden ?
data-pv-max - Maxiamle Leistung PV
Hab ich angegeben .
So stehts im Code:
<div data-type="pvvis" data-device="Stromzaehler"
data-get="Stromzaehler:SML_Watt_Summe" data-feed="Stromzaehler:SML_Watt_Summe"
data-produce="MQTT2_AHOY_DTU:Summe_Leistung" data-pv-max="1800"
data-width="340" data-height="340" class="centered">
</div>
Und so sieht es aus
Bezgl der FTUI
2 Darstellung fragst du besser papa, welcher anscheinend auch eine aktuellere Version hat (siehe auch #58 (https://forum.fhem.de/index.php/topic,119440.msg1227271.html#msg1227271)).
Zitat von: Skusi am 28 Juli 2022, 20:54:48data-device - Gerät, das den Refresh triggert
Was genau ist mit "triggert" gemeint ? Bin mir nicht sicher welches Device ich da angeben soll.
So wie ich es verstehe, benötigst du hier ein Device, dass den Refresh des Widgets triggert - ich würde wahrscheinlich das Device nehmen, dass den Wert für PV-Produce enthält.
Zitat von: Skusi am 28 Juli 2022, 20:54:48data-feed - Einspeisungs in Netz
Das ist bei mir das selbe Reading wie oben (Bezug) allerdings al negativ Wert !
Wie soll ich das angeben ? Gibts die Möglichkeit wie in FTUI3 das auf ein einzelnes Reading zu legen ?
MWn gibt es dies in diesem Widget nicht. Du kannst aber ein userReading im FHEM Device erstellen, dass den Wert ins positive konvertiert.
Zitat von: Skusi am 28 Juli 2022, 20:54:48data-produce - Production PV-Anlage
OK Hab ich das Power Reading meiner PV Angeben, wird aber nicht angezeigt !?
Produce wird auch nicht direkt angezeigt sondern (ua) für Berechnungen benutzt - wie die opacity der Sonne oder für den Wert, der ins Haus eingespeist wird (produce - charge - feed).
Zitat von: Skusi am 28 Juli 2022, 20:54:48data-charge - Ladung Akku
data-discharge - Entladung Akku
data-soc - Ladezustand Battery
Ich habe gar keine Akku ;-) kann man den irgendwie ausblenden ?
Nicht das ich wüsste, zumindest meines Verständnis nach nicht in der Version aus #3. Du kannst die Readings aber mit 0 angeben - oder kommentierst den Code-Teil im Widget Code selbst aus.
Und noch ein Hinweis: FTUI2 ist EoL und wird nicht mehr aktiv unterstützt, hier noch guten support zu bekommen wird natürlich zunehmend schwieriger.
Hallo yersinia,
vielen Dank für die Tipps.
Nun habe ich stunden damit verbracht über Tasmota Scripts die richitgen Readings zu erzeugen, und nun will es trotzdem nicht funktionieren. Papa hab ich auch schon angeschrieben, aber der hat im Moment keine Zeit.
Mein Code sieht im Moment so aus:
<div data-type="pvvis" data-device="Stromzaehler"
data-get="Stromzaehler:SML_Watt_Bezug" data-feed="Stromzaehler:SML_Watt_Einspeisung"
data-produce="MQTT2_AHOY_DTU:SML_Watt_Summe" data-pv-max="1800"
data-charge="0" data-discharge="0" data-soc="0"
data-width="340" data-height="340" class="centered">
</div>
Alle Readings kommen als dezimal Werte mit einer Kommastelle nachweislich per Eventmonitor rein, aber trotzdem zeigt das widget nichts oder manchmal nur eine wile Leistung Richtung Haus an.
Event Monitor:
2022-08-01 13:57:09 MQTT2_DEVICE Stromzaehler SML_Watt_Einspeisung: 962
2022-08-01 13:57:11 MQTT2_DEVICE Stromzaehler SML_Watt_Summe: -962
2022-08-01 13:57:20 MQTT2_DEVICE MQTT2_AHOY_DTU Summe_Leistung: 1261.8
2022-08-01 13:57:20 MQTT2_DEVICE Stromzaehler SML_Watt_Bezug: 0
Die Werte sind ca vom Zeitpunkt des Screenshots
Auch fällt mir auf das die Werte im Widget sich nur nach einem Reload der Seite ändern.
welches Reading wird denn da vom trigger Device zum refresh erwartet ?
Naja, ich geb an dieser Stelle erstmal auf und warte bis Papa eine Sekunde für mich hat...
Zitat von: Skusi am 01 August 2022, 14:28:08Nun habe ich stunden damit verbracht über Tasmota Scripts die richitgen Readings zu erzeugen, und nun will es trotzdem nicht funktionieren.
Hab ich gesehen (https://forum.fhem.de/index.php/topic,111873.msg1229823.html#msg1229823) - das hättest du aber auch über ein FHEM userReading (https://wiki.fhem.de/wiki/UserReadings) geschafft. ;) Viele Wege führen nach Rom und für dich war es eine gute Gelegenheit in das Tasmota-Scripting einzusteigen. ;)
Ist das so richtig?
Zitat von: Skusi am 01 August 2022, 14:28:08data-produce="MQTT2_AHOY_DTU:SML_Watt_Summe"
obwohl
Zitat von: Skusi am 01 August 2022, 14:28:08Event Monitor:
2022-08-01 13:57:20 MQTT2_DEVICE MQTT2_AHOY_DTU Summe_Leistung: 1261.8
Ich hab meine FTUI2 Installation aus der Kiste gekramt und kann mit papas widget und meinem Testdummy keine Probleme feststellen - funktioniert. Die spezifische CSS aus #3 hast du auch eingebunden?
EDIT: wenn du folgendes in der CSS hinzufügst, wird der komplette Batteriestrang ausgeblendet:
svg > #battery,
svg > g > #bat-home,
svg > g > #pv-bat,
svg > g > #pv-bat-txt,
svg > g > #bat-home-txt {
display: none;
}Aber bekomm' erstmal das Widget ans laufen,
dann geht es mit der Optik weiter...
ZitatHab ich gesehen - das hättest du aber auch über ein FHEM userReading geschafft. ;) Viele Wege führen nach Rom und für dich war es eine gute Gelegenheit in das Tasmota-Scripting einzusteigen. ;)
Ja, du hast Recht. Ich hab auch zuerst überlegt das per User Reading zu machen, aber wie Du schon schreibst war es mir auch ein Bedürfnis mal mit Tasmota Scripts rum zu spielen. Außerdem wollte ich die Daten möglichst früh in der Kette verbiegen. Hat ja nun auch geklappt, und mal sehen wo ich das nochmal brauchen kann.
ZitatIst das so richtig?
Oh mann, natürlich ist das nicht richtig. Da hab ich mal wieder bei den ganzen Verzweiflungs copy Paste Orgien was falsches in der zwischenablege gehabt, und selber nicht geblickt. Irgendwann ist man aber auch blind und dann ist es gut wenn ein anderes Augenpaar drüber schaut. Danke !!!
Aber das alles war nicht der Grund warum das Widget nicht wollte. Mein Fehler war das ich das falsche Widget File aus dem Post #10 verwendet hatte. Ich hab beim überlesen das es sich dabei um eine "angepasste Version" von majestro84 handelte. Ich hab gedacht das es eine verbesserte Version von Papa´s letztem Stand war.
Nun hab ich die erste Fassung aus Post #3 installiert, und was soll ich sage... ES LÄUFT !
Man das hat mich aber auch viel Nerven und Zeit gekostet.
ZitatEDIT: wenn du folgendes in der CSS hinzufügst, wird der komplette Batteriestrang ausgeblendet:
Das habe ich dann auch gleich ausprobiert, und jetzt ist es wie ich es haben wollte !
Sehr herzlichen Dank für die Hilfe. So ist meine Viso wieder ein kleines Stückchen informatiever. Trotzdem werde ich wohl das Ganze bei zeiten auf FTUI3 umstricken müssen. Auch wenn ich das nicht wirklich will. Das macht ne Menge Arbeit. Aber der lange Winter kommt bestimmt...
Gruß Skusi
Schön, dass es läuft!
[OT]
Zitat von: Skusi am 03 August 2022, 12:42:30Sehr herzlichen Dank für die Hilfe. So ist meine Viso wieder ein kleines Stückchen informatiever. Trotzdem werde ich wohl das Ganze bei zeiten auf FTUI3 umstricken müssen. Auch wenn ich das nicht wirklich will. Das macht ne Menge Arbeit. Aber der lange Winter kommt bestimmt...
Das schöne an FTUI3 ist, dass du es parallel zu FTUI2 laufen lassen und dir somit soviel Zeit wie nötig mit der Umstellung lassen kannst.
[/OT]
Hallo zusammen, ich habe bei mir sowohl die FTUI2 Version von papa als auch die FTUI3 Version von yersinia zum laufen gebracht. Allerdings nutze ich bisher nur FTUI2 und würde nun auch gerne im widget das Symbol für grid bei Bezug aus dem Netz rot einfärben, bei Rückspeisung aus der PV-Anlage gelb und bei 0 grau.
Kann mir jemand helfen, dass im widget_pvvis.js von papa aus Beitrag #3 umzusetzen. Ich kenne mich mit JavaScript leider null aus. Ich denke aber, das müsste in etwa so aussehen:
// update grid symbol
var grid = elem.find("> svg > g#grid");
if( elem.getReading('feed').val < 0 ) {
grid.css( { fill: red } );
}
else {
grid.css( { fill: yellow } );
}
Danke schon mal für eure Hilfe...
Ist denn feed bei dir negativ wenn du beziehst oder dann einfach 0? Ansonsten ist dein Code schon nicht schlecht - nur füllst du das Symbol rot wenn du aus dem Netz beziehst und nicht grau. Du kannst zB in Zeile 132 (also vor // update battery symbol) folgendes einfügen:
// update grid symbol
var grid = elem.find("> svg > g#grid");
if( elem.getReading('feed').val <= 0 ) {
grid.css( { fill: 'red' } );
}
else {
grid.css( { fill: 'yellow' } );
}
Das Grid-Symbol wird bei kleiner/gleich 0 rot sonst gelb eingefärbt.
Danke yersinia, funktioniert ;D
Kannst du mir bitte noch erklären, wie ich auch noch das grid cable symbol gegen den pylon austauschen kann in der FTUI2 version?
Danke und Grüße
Hi tomhead,
tausche einfach das grid im Code:
<g id="grid" fill="gray" transform="translate(150,300),scale(4)"> \
<path d="M20,5V4c0-0.55-0.45-1-1-1h-2c-0.55,0-1,0.45-1,1v1h-1v4c0,0.55,0.45,1,1,1h1v7c0,1.1-0.9,2-2,2s-2-0.9-2-2V7 c0-2.21-1.79-4-4-4S5,4.79,5,7v7H4c-0.55,0-1,0.45-1,1v4h1v1c0,0.55,0.45,1,1,1h2c0.55,0,1-0.45,1-1v-1h1v-4c0-0.55-0.45-1-1-1H7 V7c0-1.1,0.9-2,2-2s2,0.9,2,2v10c0,2.21,1.79,4,4,4s4-1.79,4-4v-7h1c0.55,0,1-0.45,1-1V5H20z"/> \
</g> \
mit dem pylon von yersinia (Größe angepasst):
<g id="grid" fill="gray" transform="translate(155,305),scale(1.5)">
<path d="M50.651,10.354c0.12-0.86-0.858-1.239-1.187-1.364L34.677,3.347 c-0.749-0.285-1.852-1.082-2.356-1.705l-0.632-0.778C31.235,0.307,30.623,0,29.967,0c-0.688,0-1.335,0.348-1.778,0.95l-0.336,0.457 c-0.468,0.637-1.523,1.444-2.261,1.728L10.366,8.986C10.04,9.113,9.065,9.493,9.182,10.35c-0.001,0.025-0.015,0.046-0.015,0.072 v5.692c0,0.481,0.389,0.869,0.87,0.869s0.869-0.389,0.869-0.869v-4.823h13.485l-8.412,47.52c-0.084,0.473,0.232,0.924,0.706,1.006 c0.47,0.087,0.922-0.231,1.006-0.703l2.003-11.312h20.537l2.265,11.331c0.084,0.412,0.446,0.698,0.852,0.698 c0.057,0,0.114-0.005,0.171-0.018c0.471-0.094,0.777-0.551,0.684-1.021l-9.489-47.501h14.211v4.823c0,0.481,0.39,0.869,0.869,0.869 c0.482,0,0.871-0.389,0.871-0.869v-5.692C50.666,10.397,50.653,10.377,50.651,10.354z M23.59,25.801h4.238l-5.432,6.736 L23.59,25.801z M22.769,34.847l6.891-8.548l7.181,8.548H22.769z M34.925,36.585l-5.21,3.049l-5.437-3.049H34.925z M21.593,37.073 l6.383,3.578l-7.825,4.578L21.593,37.073z M22.174,46.061l7.559-4.424l7.888,4.424H22.174z M39.723,45.247l-8.251-4.627 l6.561-3.839L39.723,45.247z M37.19,32.56l-5.679-6.758h4.328L37.19,32.56z M35.492,24.062H23.897l2.144-12.112h7.032 L35.492,24.062z M13.74,9.553l12.475-4.796c1.043-0.4,2.379-1.421,3.04-2.321L29.59,1.98c0.225-0.308,0.512-0.309,0.75-0.018 l0.632,0.777c0.698,0.859,2.055,1.84,3.086,2.233l12.006,4.581H13.74z"/> \
</g> \
aus.
Vielleicht musst du die Größe noch einwenig anpassen...
LG mr_petz
Danke mr_petz, perfekt! Anbei mal die auf widget von papa basierende (Danke an dieser Stelle), angepasste widget_pvvis.js für FTUI2 für einen Fronius SYMO GEN24 WR falls es jemand brauchen kann.
Danke erst einmal für diese tolle Erweiterung.
Vielleicht habe ich auch nur eine Einstllungsoption übersehen, aber hier werden in der Produktion (Sonne) und Verbrauchsdarstellung (Haus) unterschieldiche Werte dargestellt - kann es sich um Rundungsdifferenzen handeln und wenn ja, wie bekomme ich die behoben?
In der Darstellung des Gerätes formatiere ich die Werte über
sprintf("%.0f",ReadingsVal($name,"eadingname",0))."
Wie mache ich das aber in FTUI3 bzw. hier im Modul?
Gruß
eurofinder
Nutze über die pipe die Funktion round(0) um Werte aus Readings ohne Nachkommastelle zu runden, Bsp:
[feed]="Device:Readingname | round(0)"
Für die Anzeige werden Nachkommstellen abgeschnitten bzw gerundet, das kann dann zu unterschiedlichen Werten führen.
Perfekt, danke.
eurofinder
Hier wie versprochen meine aktuelle Version für FTUI1 & FTUI2.
Mitterweile habe ich noch eine Wallbox angebunden. Diese wir per EVCC gesteuert und ist per MQTT an FHEM angebunden.
Optionen:
data-device - Gerät, das den Refresh triggert
data-get - Verbrauch Haus
data-feed - Einspeisungs in Netz - kann entfallen, dann -get
data-produce - Production PV-Anlage
data-charge - Ladung Akku - kann entfallen, dann -discharge
data-discharge - Entladung Akku - kann entfallen, dann -charge
data-soc - Ladezustand Battery
data-pv-max - Maxiamle Leistung PV
data-lp1 - Zustand des Steckers der Wallbox - 0 oder 1
data-lp1pow - Ladung des Auto
data-width - Breite des Widget
data-height - Höhe des Widget
Beispiel:
<div data-type="pvvis" data-device="eStat"
data-get="eStat:grid_pow" data-feed="eStat:feed_pow"
data-produce="eStat:pv_power" data-pv-max="7000"
data-soc="eStat:bat_soc" data-charge="eStat:bat_pow"
data-lp1="Wally:lp_1_Plug" data-lp1pow="Wally:lp_1_W"
data-width="450" data-height="450" class="centered">
</div>
eStat ist ein Dummy und wird mit Daten aus 2 Wechselrichtern und dem Stromzähler gefüllt.
Wally ist das MQTT-Device der Wallbox.
Zitat von: papa am 11 August 2022, 20:35:25
Hier wie versprochen meine aktuelle Version für FTUI1 & FTUI2.
Mitterweile habe ich noch eine Wallbox angebunden. Diese wir per EVCC gesteuert und ist per MQTT an FHEM angebunden.
Optionen:
data-device - Gerät, das den Refresh triggert
data-get - Verbrauch Haus
data-feed - Einspeisungs in Netz - kann entfallen, dann -get
data-produce - Production PV-Anlage
data-charge - Ladung Akku - kann entfallen, dann -discharge
data-discharge - Entladung Akku - kann entfallen, dann -charge
data-soc - Ladezustand Battery
data-pv-max - Maxiamle Leistung PV
data-lp1 - Zustand des Steckers der Wallbox - 0 oder 1
data-lp1pow - Ladung des Auto
data-width - Breite des Widget
data-height - Höhe des Widget
Beispiel:
<div data-type="pvvis" data-device="eStat"
data-get="eStat:grid_pow" data-feed="eStat:feed_pow"
data-produce="eStat:pv_power" data-pv-max="7000"
data-soc="eStat:bat_soc" data-charge="eStat:bat_pow"
data-lp1="Wally:lp_1_Plug" data-lp1pow="Wally:lp_1_W"
data-width="450" data-height="450" class="centered">
</div>
eStat ist ein Dummy und wird mit Daten aus 2 Wechselrichtern und dem Stromzähler gefüllt.
Wally ist das MQTT-Device der Wallbox.
Hi, vielen Dank fürs teilen der aktuellen Version.
Ich habe mir da ich noch keine Wallbox habe das Wallbox Icon ähnlich zur Batterie verblassen lassen.
Ich hänge die.js mal an.
VG Alex
@majestro84:
Zitat von: majestro84 am 12 August 2022, 10:29:27Ich habe mir da ich noch keine Wallbox habe das Wallbox Icon ähnlich zur Batterie verblassen lassen.
Alternativ kannst du dies auch über CSS machen (man muss ja eh eine zusätzliche CSS-Datei mit einbinden für papas FTUI2 Widget):
svg > #battery,
svg > #car,
svg > g > #bat-home,
svg > g > #pv-bat,
svg > g > #pv-bat-txt,
svg > g > #bat-home-txt,
svg > g > #home-car,
svg > g > #home-car-txt {
display: none; /* zum komplett ausblenden - Zeile loeschen wenn nur ausgegraut werden soll */
opacity: 0.2; /*zum ausgrauen */
fill: #090 !important; /*zum ausgrauen */
stroke: #090 !important; /*zum ausgrauen */
}
@papa: Danke, dass du zum Einen das FTUI2-Widget weiter entwickelst und zum Anderen deine neuere Version zur Verfügung stellst. :D
Zitat von: papa am 11 August 2022, 20:35:25Mitterweile habe ich noch eine Wallbox angebunden. Diese wir per EVCC gesteuert und ist per MQTT an FHEM angebunden.
Die Wallbox und die Darstellung ist echt cool! Ich denke, für
FTUI3 wäre dies auch sinnvoll - ich hab den Codeteil auch direkt
geklautübernommen.
Für diejenigen, die FTUI
3 nutzen anhängend die Version mit der Wallbox. Dafür gibt es zwei neue Attribute:
has-no-wallbox: wenn gesetzt, wird der Wallbox-Teil ausgblendet (analog zu
has-no-battery)
[wb-feed]: nimmt den Wert des derzeitigen Ladens des Autos auf (entspricht papas
data-lp1pow - Ladung des Auto). Ist der Wert <= 0 wird der Strang und das Auto ausgegraut. Ist der Wert > 0 wird das Auto grün und der flow gelb eingefärbt.
Ansonsten bleibt die Nutzung weiterhin wie in #57 (https://forum.fhem.de/index.php/topic,119440.msg1227262.html#msg1227262) (und bezgl
battstep das Update in #64 (https://forum.fhem.de/index.php/topic,119440.msg1227334.html#msg1227334) sowie von
unit-soc und
unit-value das Update in #82 (https://forum.fhem.de/index.php/topic,119440.msg1227572.html#msg1227572)) beschrieben.
Hab jetzt nochmal die SVG Grafiken und die Darstellung des Akkufüllstandes angepasst.
Das stand schon ewig auf meiner Wunschliste.
Ich würde auch noch gern den Akku per "Farbverlauf" anzeigen - also bei 100% -> grün, bei 50% -> gelb, bei 0% -> rot. Ist der Wert dazwischen, sollte entsprechend eine Mischfarbe berechnet werden. Es soll also je nach Wert von grün nach gelb und rot übergeblendet werden. Wenn jemand weiss, wie das einfach mit Javascript oder FTUI geht (ohne extra zusätzlichen Code einzubinden), wäre ich für nen Hinweis dankbar.
@papa
Ich stand mal vor dem gleichen Problem bei meinem Thermostat-Modul für FTUI3.
So kannst du einen Gradientverlauf definieren Bsp.:
<svg height="150" width="400">
<defs>
<linearGradient id="grad1" x1="0%" y1="0%" x2="0%" y2="100%">
<stop offset="0%" style="stop-color:rgb(255,0,0);stop-opacity:1" />
<stop offset="100%" style="stop-color:rgb(255,255,0);stop-opacity:1" />
</linearGradient>
</defs>
<ellipse cx="200" cy="70" rx="85" ry="55" fill="url(#grad1)" />
</svg>
Stammt von hier:
https://www.w3schools.com/graphics/svg_grad_linear.asp
Bei mir und bei setstate sieht es so aus:
@setstate´s:
https://github.com/knowthelist/ftui/blob/master/www/ftui/components/knob/knob.component.js#L77
und meins:
https://github.com/mr-petz/ftui/blob/thermostat/www/ftui/components/thermostat/thermostat.component.js#L70
Ich hoffe das es dir hilft. Ansonsten könnte ich dich unterstützen wenn du magst...
LG mr_petz
Edit:
Ein Beispiel unformatiert (ist schon spät):
<svg width="400" height="400" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">\
<g class="layer">
<title>Layer 1</title>
<defs>
<linearGradient id="grad1" x1="0%" x2="0%" y1="0%" y2="100%">
<stop offset="0%" stop-color="rgb(0,255,0)"/>
<stop offset="50%" stop-color="rgb(255,255,0)"/>
<stop offset="100%" stop-color="rgb(255,0,0)"/>
</linearGradient>
<linearGradient id="grad2" x1="100%" x2="0%" y1="0%" y2="0%">
<stop offset="0%" stop-color="rgb(0,255,0)"/>
<stop offset="50%" stop-color="rgb(255,255,0)"/>
<stop offset="100%" stop-color="rgb(255,0,0)"/>
</linearGradient>
</defs>
<g fill="url(#grad2)" id="battery" transform="translate(300,147),scale(.175,.145)">\
<path d="m0,176c0,-44.2 35.82,-80 80,-80l384,0c44.2,0 80,35.8 80,80l0,16c17.7,0 32,14.3 32,32l0,64c0,17.7 -14.3,32 -32,32l0,16c0,44.2 -35.8,80 -80,80l-384,0c-44.18,0 -80,-35.8 -80,-80l0,-160zm80,-16c-8.84,0 -16,7.2 -16,16l0,160c0,8.8 7.16,16 16,16l384,0c8.8,0 16,-7.2 16,-16l0,-160c0,-8.8 -7.2,-16 -16,-16l-384,0z" id="svg_3" transform="rotate(-90,300,300)"/>\
<rect fill="url(#grad1)" height="380" id="batxx" stroke-width="0px" width="155" x="178" y="135"/>\</g>
</g></svg>
grad1==Füllstand
grad2==Hülle
Sieht dann so aus wie im Anhang...
@papa: wenn du den Farbverlauf als Farbe in Abhängigkeit des Füllstandes anzeigen willst (und nicht als Farbverlauf der Batterie selbst), schau mal hier: https://jsfiddle.net/JeancarloFontalvo/1sco9Lpe/3/ (https://jsfiddle.net/JeancarloFontalvo/1sco9Lpe/3/)
Zitat von: yersinia am 15 August 2022, 07:40:44
@papa: wenn du den Farbverlauf als Farbe in Abhängigkeit des Füllstandes anzeigen willst (und nicht als Farbverlauf der Batterie selbst), schau mal hier: https://jsfiddle.net/JeancarloFontalvo/1sco9Lpe/3/ (https://jsfiddle.net/JeancarloFontalvo/1sco9Lpe/3/)
Genau das hier meinte ich. Danke
Zitat von: papa am 14 August 2022, 22:52:51
...
Ich würde auch noch gern den Akku per "Farbverlauf" anzeigen - also bei 100% -> grün, bei 50% -> gelb, bei 0% -> rot. Ist der Wert dazwischen, sollte entsprechend eine Mischfarbe berechnet werden. Es soll also je nach Wert von grün nach gelb und rot übergeblendet werden. Wenn jemand weiss, wie das einfach mit Javascript oder FTUI geht (ohne extra zusätzlichen Code einzubinden), wäre ich für nen Hinweis dankbar.
Ok ich hatte hier Farbverlauf gelesen und da für mich gradient die Lösung. Da könnte man von oben noch einen grauen Layer darüberlegen wenn der Füllstand geringer wird...
Die Lösung von @yersinia ist halt mit mehr css und js aber gut...
LG
Hach, so viele neue Impulse und Ideen. :) Da will ich in nichts nachstehen ;D - anbei ein Update der FTUI
3 component.
- die Nutzung bleibt weiterhin wie in #57 (https://forum.fhem.de/index.php/topic,119440.msg1227262.html#msg1227262) beschrieben
- bezgl
battstep siehe Update in #64 (https://forum.fhem.de/index.php/topic,119440.msg1227334.html#msg1227334)
- bezgl
unit-soc und
unit-value das Update in #82 (https://forum.fhem.de/index.php/topic,119440.msg1227572.html#msg1227572)
- Wallbox (Wiederholung von #122):
Zitat von: yersinia am 12 August 2022, 11:59:50has-no-wallbox: wenn gesetzt, wird der Wallbox-Teil ausgblendet (analog zu has-no-battery)
[wb-feed]: nimmt den Wert des derzeitigen Ladens des Autos auf (entspricht papas data-lp1pow - Ladung des Auto). Ist der Wert <= 0 wird der Strang und das Auto ausgegraut. Ist der Wert > 0 wird das Auto grün und der flow gelb eingefärbt.
-
sun-icon andere icons für die Sonne =>
sun2 entspricht der Sonne von papa aus #123 (https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479);
pvsun entspricht dem panel und der Sonne von Shadow3561 aus #24 (https://forum.fhem.de/index.php/topic,119440.msg1226092.html#msg1226092);
sun ist der Standardwert und muss nicht explizit gesetzt werden
-
grid-icon ist um einen weiteren pylon
pylon2 von papa aus #123 (https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479) erweitert worden; valide Werte sind nun:
pylon,
pylon2 oder
cable (Standard; muss nicht explizit gesetzt werden)
- der Batteriestand wird nun als Farbverlauf in Abhängigkeit des Ladezustands angezeigt - wenn der Akku leer ist färben sich die Balken rot und gehen bei Ladung bis voll sukzessive in grün über. Dabei ändern nur die Ladebalken die Farbe, die Batterie selbst zeigt immernoch an ob sie geladen (grün) oder entladen (rot) wird. Wer diesen Farbverlauf
nicht haben möchte, setzt
no-bat-gradient (analog zu
has-no-wallbox). (Wenn
battstep gesetzt ist, wird der erste Werte als untere Schwelle (leer) und der letzte Wert als obere Schwelle (voll) benutzt - bezgl
battstep siehe auch #64 (https://forum.fhem.de/index.php/topic,119440.msg1227334.html#msg1227334))
Vielen Dank an papa und Shadow3561 für die Vorlagen hier. :)
Wow.
Sieht gut aus.
Woran erkenne ich eigentlich ob ich die 2er oder 3er Version nutze?
Meine Oberfläche habe ich mit FUIP eingerichtet - ich weis so nicht bzw. finde nicht welches ftui genutzt wird dabei...
Danke
Carsten
Zitat von: stenny am 19 August 2022, 14:20:14Woran erkenne ich eigentlich ob ich die 2er oder 3er Version nutze?
Meine Oberfläche habe ich mit FUIP eingerichtet - ich weis so nicht bzw. finde nicht welches ftui genutzt wird dabei...
An der Art, wie der HTML Code aufgebaut ist. Und nach Thorsten basiert FUIP auf irgendwas wie FTUI2 (https://forum.fhem.de/index.php/topic,126606.msg1212099.html#msg1212099). Laut Wiki ist es auch FTUI2 (https://wiki.fhem.de/wiki/FHEM_User_Interface_Painter#Installation_und_Upgrade_in_FHEM):
ZitatFUIP verwendet FTUI (v2.x - es gibt inzwischen auch eine FTUI v3.x). D.h. man sollte zuerst einmal FTUI installieren, falls noch nicht passiert. Wie das geht steht bei FHEM Tablet UI (https://wiki.fhem.de/wiki/FHEM_Tablet_UI#Installation). Dabei reicht der erste Schritt aus, da lediglich die FTUI-Dateien von FUIP benötigt werden.
Danke erstmal für die schnelle Antwort.
Ich bin erstmal soweit auch davon ausgegangen das es die V2 ist.
Habe die zwei Dateien auch in die Verzeichnisse kopiert (www/tablet/js und css)
Nach dem definieren erhalte ich einen Fehler "Syntax Exrror: unexexapted token: Identififier"
Ist das jetzt ein Problem für hier oder eher im Bereich FUIP?
Guten morgen,
Danke für das tolle Widget. Ich nutze die FTUI3 Version.
Frage/Wunsch: ich nutze die FTUI3 Version. Ich betreibe eine Anlage welche die Batterie sowohl via Netz als auch via PV laden kann, aber nicht ins Netz einspeisen kann.
Daher die Frage ob man optional den Pfad PV-> Netz per Attribut ausblendbar machen Könnte und weiterhin per weiterem Attribut einen Pfad Netz-> Batterie einblendbar machen könnte (den man dann natürlich auch mit einem Leistungswert versehen können sollte).
Letzter Finish-Wunsch wäre noch das Haussymbol austauschbar zu machen gegen ein Steckdosen-Symbol, denn zumindest bei mir versorgt die Anlage nicht das ganze Haus sondern dient als Backup/USV für einige wichtige Verbraucher und da passt das mit dem Haus nur bedingt.
Wenn gewünscht kann ich mich aber auch selber versuchen und das Ergebnis falls ich es schaffe zur Verfügung stellen.
Könnte mir schon vorstellen, dass mehrere Leute gibt die sowas nutzen könnten.
Grüße
Markus
Zitat von: Grisu1079 am 24 August 2022, 07:52:14Frage/Wunsch: ich nutze die FTUI3 Version. Ich betreibe eine Anlage welche die Batterie sowohl via Netz als auch via PV laden kann, aber nicht ins Netz einspeisen kann.
Daher die Frage ob man optional den Pfad PV-> Netz per Attribut ausblendbar machen Könnte und weiterhin per weiterem Attribut einen Pfad Netz-> Batterie einblendbar machen könnte (den man dann natürlich auch mit einem Leistungswert versehen können sollte).
Letzter Finish-Wunsch wäre noch das Haussymbol austauschbar zu machen gegen ein Steckdosen-Symbol, denn zumindest bei mir versorgt die Anlage nicht das ganze Haus sondern dient als Backup/USV für einige wichtige Verbraucher und da passt das mit dem Haus nur bedingt.
Puh, das klingt für mich nach einem
sehr speziellen Anwendungsfall - ich weiss nicht, ob das (auch noch) in einer generellen component vorkommen sollte. Für mich klingt das derzeit danach, als würdest nur du dies benötigen - sofern es keine weiteren Befürworter(m/w/d)/Bedarf gibt, sehe ich noch keinen Nutzen für 'meine' FTUI3 Version.
Aber es steht dir frei die component entsprechend für dich anzupassen. ;)
Das sieht schon sehr gut aus :)
In dieselbe Richtung geht auch diese Visualisierung hier: https://forum.fhem.de/index.php/topic,75456.msg988539.html#msg988539
Gibt es ein HTML Ftui Beispiel auf das ich aufsetzen könnte? Ich habe keinen Sonnenbatterie sondern einen Solax X1 WR und mehrere Micro-WR. Kann man die anderslautenden Readings dem Modul als Parameter mitgeben?
Ja, die Bezeichnung mit Sonnenbatterie ist eigentlich mittlerweile irreführend. Hier geht es viel mehr um die Darstellung einer PV-Anlage und deren Einspeisung mit Batterie, Netzbezug, BEV-Ladung usw. Wenn du die entsprechenden Werte aus Devices:Reading bekommst, kannst dies entsprechend nutzen.
Für FTUI2 siehe papas post (#120) => https://forum.fhem.de/index.php/topic,119440.msg1231146.html#msg1231146
Für FTUI3 siehe meinen post (#14) => https://forum.fhem.de/index.php/topic,119440.msg1225904.html#msg1225904
und dazu das letzte Update unter #128 (https://forum.fhem.de/index.php/topic,119440.msg1231548.html#msg1231548) (und die verlinkten posts dort). Hilfreich ist, wenn du dich mit der FTUI3 Nomenklatur schon etwas auskennst. Ansonsten hilft es wenn du ein List und weitere Erklärungen deines Setups teilen würdest.
perfekt, danke :)
Ich nutze noch FTUI2.x da die Charts in der 3er Version noch nicht den Stand haben den ich benötige (->WAF)
Zitat von: yersinia am 24 August 2022, 09:40:47
Puh, das klingt für mich nach einem sehr speziellen Anwendungsfall - ich weiss nicht, ob das (auch noch) in einer generellen component vorkommen sollte. Für mich klingt das derzeit danach, als würdest nur du dies benötigen - sofern es keine weiteren Befürworter(m/w/d)/Bedarf gibt, sehe ich noch keinen Nutzen für 'meine' FTUI3 Version.
Aber es steht dir frei die component entsprechend für dich anzupassen. ;)
Alles klar, ich passe mir das selber an. Ist vermutlich eh besser, da ich dann direkt die zwei PV Anlagen in einer Compenent für mich verheiraten kann. Werde ich dann mal zeigen wenn fertig.
Allerdings halt ich das trotzdem für keine Sonderfall gerade aktuell installieren viele Leute ne Art Halb-Inselanlagen welche nicht ins Netz zurückspeisen können, aber von dort aus sehr wohl die Batterie aufladen können als Backup Option als auch den Verbraucher direkt über einen Bypass betreiben können.
Grüße
Markus
Zitat von: Grisu1079 am 26 August 2022, 00:05:34Allerdings halt ich das trotzdem für keine Sonderfall gerade aktuell installieren viele Leute ne Art Halb-Inselanlagen welche nicht ins Netz zurückspeisen können, aber von dort aus sehr wohl die Batterie aufladen können als Backup Option als auch den Verbraucher direkt über einen Bypass betreiben können.
Ich möchte noch anmerken, dass ich keine PV Anlage besitze und die Anforderungen dadurch nur schwer nachvollziehen kann. Daher erschließt sich mir (noch?) nicht warum ein Anwender einen (PV-)Akku (teuer) aus dem Netz laden (können) sollte? (und ich meine keine USV oder ähnliches) Ist es nicht eher so, dass der Akku per PV geladen wird und ich diese Energie
anstelle des bzw. bei geringerem Netzbezugs entnehme?
Ich will hier keine Grundsatzdiskussion starten - aber verstehen würde ich es gern.
Aber mach' mal nen Vorschlag und wenn dieser gut ankommt und weiteren Bedarf zeigt, kann man das dann
klauenübernehmen. :)
Moin,
zurück laden einer Batterie aus dem Netz wäre m.M. nur sinnvoll, wenn die ganze Anlage immer auch als Notstrom funktionieren können soll, auch wenn länger mal nur wenig Strom aus der PV geliefert werden kann - wobei die Anforderungen und Kosten dann insbes. an Steuerung und Akkus doch schon recht hoch liegen dürften ... das würden dann zur Zeit wohl sehr wenige Häuslebesitzer entsprechend machen
Gruß, Christoph
Oder aus Kostengründen zum Beispiel im Winter, wenn die PV Anlage nicht mehr genügend Saft den Tag über liefert, um Haus/Heizung zu versorgen und den Akku voll zu bekommen. Sofern man einen smarten Tarif hat, könnte dann z.B. in Zeiten besonders günstigen Netzstroms, der Akku voll geladen werden.
Ich kann mir das immer noch schwer vorstellen, dass sich das bei all den Verlusten dann überhaupt noch (finanziell) lohnt. Zumindest wenn die Notstromoption nicht relevant ist. Solle Notstrom eine relevante Funktion sein, kann ich das voll und ganz nachvollziehen, analog zu caldir65.
Basierend auf den Rückmeldungen anbei ein FTUI3-Update zum Testen (die Version ist als Beta zu betrachten). Wer nicht Testen möchte, bleibt derzeit besser bei der letzten Version (2022-08-15) (https://forum.fhem.de/index.php/topic,119440.msg1231548.html#msg1231548).
Was ist neu?
- das Haus-Icon lässt sich ersetzen; dafür gibt es den neuen Parameter home-icon mit folgenden potentiellen Werten: house (Standard; muss nicht explizit gesetzt werden), plug (Stecker) oder socket (Steckdose)
- die Netzeinspeisung kann durch setzen von has-no-grid-feed ausgeblendet werden
- Laden des Akkus vom Netz kann mit has-grid-charge aktiviert und entsprechende Werte mittels [grid-charge]="DEVICE:READING" übergeben werden.
Verwendung ansonsten wie bisher. Es sollte keine Auswirkungen auf bestehende FTUI3-Konfiguration geben, wenn diese Version benutzt wird.
Danke @yersinia für die tolle PV Darstellung in FTUI3!
Eben bei mir umgesetzt und nun die Wallboxladung getestet. Leider rechnet das component hier falsch, weil es davon ausgeht, dass die Wallboxleistung auch im Hausverbrauch auftaucht.
Meine PV ist aktuell so konfiguriert, dass die Wallbox keinen Strom aus dem Speicherakku zieht, also kommt dieser Strom komplett aus dem Netz.
Bild "PV1" zeigt das FTUI3 component, "PV2" die tatsächlichen Werte.
Hier noch mein Code, falls ich was falsch konfiguriert habe und es daran liegt:
<ftui-pvvis
[charge-discharge]="E3DC_S10E:Batterieleistung"
[soc]="E3DC_S10E:Batterieladezustand"
[produce]="E3DC_S10E:Solarleistung"
[wb-feed]="E3DC_S10E:Wallboxleistung"
pvmax="12580"
[feed-receive]="Stromzaehler:Itron_Power_cur"
sun-icon="sun"
grid-icon="pylon2"
unitSoc="%"
unitValue="W"
width="400px">
</ftui-pvvis>
Edit:
Hier noch die Werte in Zahlen (ich habe in Bild "PV2" die Vorzeichen per pipe angepasst)
Batterieleistung -> -276 W
Solarleistung -> 726 W
Hausleistung -> 1065 W
Wallboxleistung -> 4897 W
Itron_Power_cur -> 4922 W
Das Haus braucht 1065W, davon kommen 726W per PV und 276W aus dem Akku.
Das Auto lädt mit 4897W, aus dem Stromnetz kommen 4922W.
Sorry, ich muss gleich diese Antwort hinterher schicken, weil mir eben mein gravierender Fehler selbst aufgefallen ist. Mein FHEM Stromzähler Device gibt bei Bezug positive Werte und bei Einspeisung negative Werte zurück. Das FTUI3 component erwartet das aber mit umgekehrten Vorzeichen! Jetzt sieht die Grafik auch bei Benutzung der Wallbox viel logischer aus.
Ich persönlich sehe Stromverbrauch von Haus und Wallbox getrennt. Von daher wäre es cool, wenn man die Hausverbrauchsanzeige konfigurieren könnte, ob der Wallboxverbrauch mit drin ist, oder nicht.
Ich habe das bei mir mal mit in die "pvvis.component.js" eingebaut.
static get properties() {
return {
battstep: '',
charge: 0,
chargeDischarge: 0,
discharge: 0,
doNotShowZero: false,
feed: 0,
feedReceive: 0,
gridIcon: 'cable',
hasNoBattery: false,
hasNoWallbox: false,
noBatGradient: false,
produce: 0,
pvhomeval: 0,
pvmax: 0,
receive: 0,
soc: 0,
sunIcon: 'sun',
unitSoc: '',
unitValue: '',
wbFeed: 0,
noWallboxvalInHomeval: false,
width: '200px',
};
}
calcHouseConsume() {
let houseConsume;
if (this.noWallboxvalInHomeval) {
houseConsume = this.pvhomeval + this.discharge + this.receive - this.wbFeed;
} else {
houseConsume = this.pvhomeval + this.discharge + this.receive;
}
if((this.doNotShowZero) && (houseConsume.toFixed() == 0)) {
this.shadowRoot.getElementById("home-consume-txt").innerHTML = '';
} else {
this.shadowRoot.getElementById("home-consume-txt").innerHTML = houseConsume.toFixed();
if(this.unitValue) { this.shadowRoot.getElementById("home-consume-txt").innerHTML += '<tspan class="pvvis-txt-unit-value">' + this.unitValue + '</tspan>'; }
}
}
<ftui-pvvis
[charge-discharge]="E3DC_S10E:Batterieleistung"
[soc]="E3DC_S10E:Batterieladezustand"
[produce]="E3DC_S10E:Solarleistung"
[wb-feed]="E3DC_S10E:Wallboxleistung"
pvmax="12580"
[feed-receive]="Stromzaehler:Itron_Power_cur | multiply(-1)"
no-wallboxval-in-homeval="1"
sun-icon="sun"
grid-icon="pylon2"
unit-soc="%"
unit-value="W"
width="400px">
</ftui-pvvis>
Vielleicht kann das ja in den Code mit rein. Über die Bezeichnung "no-wallboxval-in-homeval" kann man gerne noch diskutieren. ;)
Zitat von: docolli am 05 November 2022, 15:36:43
...
Meine PV ist aktuell so konfiguriert, dass die Wallbox keinen Strom aus dem Speicherakku zieht, also kommt dieser Strom komplett aus dem Netz.
...
Hi @docolli,
Eine Frage die @yersinia bestimmt beantwortet braucht (denke ich zumindest).
Ist diese Konfiguration dynamisch oder kommt es immer komplett aus dem Netz?
LG mr_petz
Zitat von: mr_petz am 05 November 2022, 16:57:42
Hi @docolli,
Eine Frage die @yersinia bestimmt beantwortet braucht (denke ich zumindest).
Ist diese Konfiguration dynamisch oder kommt es immer komplett aus dem Netz?
LG mr_petz
Die Konfiguration ist dynamisch, dass kann ich am Hauskraftwerk (Wechselrichter+Akkuspeicher) einstellen, ob die Wallbox den Akku entleeren darf oder nicht. Aktuell habe ich das deaktiviert, die PV Leistung reicht ja gerade so fürs Laden des Speichers für den Hausverbrauch (oder so wie heute nicht mal dafür).
Zusätzlich kann ich an der Wallbox noch wählen, ob sie nur mit PV Überschußstrom lädt, oder Strom aus dem Netz (oder auch zuerst aus dem Akku, wenn erlaubt) zieht.
Dann bräuchte die Wallbox ja eigene Strangberechnungen wie das Haus?
Oder woher kann der View das sehen von wo die Wallbox gerade Strom bezieht bzw. beziehen darf?
Ist nur für die Umsetzung zu überlegen.
LG mr_petz
Edit:
Es muss natürlich der Hausverbrauch mit einbezogen werden in den Berechnungen...
Ja, grundsätzlich hast du Recht. Der Strom der Wallbox kann (wie der Strom fürs Haus) von der PV, vom Akku oder aus dem Netz kommen. Für die Darstellung hier im FTUI3 war es mir nur wichtig (und logisch), den Hausverbrauch ohne den Wallboxverbrauch darstellen zu können.
Ich hätte vom Hauskraftwerk/Wallbox noch die Werte "WallboxGesamtstrom" und "WallboxSolarstrom". Die Differenz ist aber leider nicht nur der WallboxNetzstrom, sondern das kann (wenn erlaubt) nur Akkustrom sein, Akku+Netzstrom gemischt oder nur Netzstrom. Die Strangberechnung für die Wallbox wäre ganz schön kompliziert, ich habe mich schon daran in FHEM per userreading versucht. Bin aber noch nicht ganz zufrieden, da es Situationen gibt, bei denen die Wallbox faktisch nur Netzstrom zieht, er aber sowas wie Akkustrom = -81W und PVStrom = +81W berechnet.
Für mich ist eben Akkustrom auch Solarstrom und mich interessiert, wieviel Strom die Wallbox tatsächlich aus dem Netz genommen hat. Leider ist das mit den Werten, die mein PV System liefert nicht so leicht auszurechnen.
Kannst du diese Einstellungen was gerade erlaubt ist auch auslesen?
Ich habe mir eben noch erlaubt für die Batterie neben Laden=Grün, Entladen=Rot noch einen dritten Status Neutral=Grau einzuführen. Wenn die Batterie ganz leer oder ganz voll ist, erfolgt keine Ladung mehr und die Batterie ist nur noch passiv, da wäre Grau meiner Meinung nach passender, als wie bisher Grün.
Hinzugefügt in pvvis.component.css:
.pvvis-battery-neutral {
fill: var(--pvvis-color-grey, grey);
stroke: var(--pvvis-color-grey, grey);
}
Änderung in pvvis.component.js:
colorBat() {
let chargeval = this.charge - this.discharge;
this.battery.classList.remove("pvvis-battery-charge", "pvvis-battery-discharge", "pvvis-battery-neutral");
if(chargeval < 0) {
this.battery.classList.add("pvvis-battery-discharge");
} else if (chargeval > 0) {
this.battery.classList.add("pvvis-battery-charge");
} else {
this.battery.classList.add("pvvis-battery-neutral");
}
}
Zitat von: mr_petz am 05 November 2022, 18:29:41
Kannst du diese Einstellungen was gerade erlaubt ist auch auslesen?
Werden wir mal konkreter: Ich habe ein S10E Hauskraftwerk von E3DC und hole mir aktuell die Werte per Modbus in FHEM. Ein Wert, der mir diese Info liefert ist mir noch nicht aufgefallen. Es gibt zwar einen Wallboxstatus, der liefert aber nur die Info, ob die Leistung der Wallbox maximal der PV Überschußleistung entspricht, oder ob die Wallbox mit der eingestellten Leistung lädt, egal woher der Strom kommt (PV/Akku/Netz).
Ob der Akku "mithelfen" darf, ist eine Einstellung des Hauskraftwerks und da habe ich leider noch keinen per SW auslesbaren Wert gefunden. Wenn ich Zeit habe, kann ich ja mal bei E3DC nachfragen, ob es den gibt.
Laut der Doku sollte es gehen:
https://community.symcon.de/uploads/short-url/z6Yc7LiO6m9lJt8r5Aif539GbHI.pdf
Ab Kapitel 3.1.3. wenn ich richtig liege...
Zitat von: mr_petz am 05 November 2022, 19:03:07
Laut der Doku sollte es gehen:
https://community.symcon.de/uploads/short-url/z6Yc7LiO6m9lJt8r5Aif539GbHI.pdf
Ab Kapitel 3.1.3. wenn ich richtig liege...
Nee, damit ich kann steuern, ob der Akku ÜBERHAUPT (also auch vom Haus aus) entladen werden darf. ;) Da kann man auch Zeiten im System hinterlegen.
Diese Einstellung, die hier relevant ist, gilt aber nur für die Wallbox.
Siehe https://www.memodo.de/media/pdf/30/da/84/memodo_e3dc_wallbox_easy_connect_betriebsanleitung_44e38bcede452f446818f838f872d0b0.pdf
-> Kapitel 9.7.2.
Ok. Ich denke da muss man mehr machen bzgl Daten sammeln deiner Wallbox. Siehe hier:
https://forum.iobroker.net/topic/32976/e3dc-hauskraftwerk-steuern/1131?lang=en-GB
Sehr langer Thread. Die Register sind in Bits unterteilt die man per script zerpflücken muss. So habe ich es verstanden...
LG
Ja, da geht es dann in Richtung RSCP Anbindung an FHEM, damit möchte ich mich aktuell nicht beschäftigen. Modbus Werte reichen mir aus. Wir werden aber inzwischen ganz schön OT ::)
Zurück zur FTUI3 component: Ich habe noch einige weitere Anpassungen für mich vorgenommen, so z.B. wird nun auch das grid-Icon grau, wenn kein Strom aus dem bzw. ins Netz fliest. Das Ganze ist auch noch über ein weiteres Attribut konfigurierbar ab welchem Schwellwert (ich habe 10W genommen) das Netz als inaktiv dargestellt wird und auch die Energieflüsse inaktiv bleiben.
Ich mach jetzt mal meine Anpassungen, dann poste ich hier mein Ergebniss, samt kleiner Anleitung. Dann kann ich mich mit @yersinia austauschen, ob wir die beiden Codes mergen. Einen eigenen Fork möchte ich nicht pflegen.
Mir würde noch eine zweite Batterie neben dem Auto gefallen. Den Füllstand der Autobatterie habe ich als Wert. Auch eine geschätze Zeit bis zur vollen Ladung/Entladung der Hausbatterie. Auch alles konfigurierbar, ob es angezeigt werden soll, oder nicht.
Ich habe versucht den SVG Code in Inkscape zu nehmen und damit das SVG zu erweitern. Bei mir klappt das aber nicht so wie gedacht, einige Objekte haben z.B. eine sehr dicke Linienstärke. Wie bearbeitet ihr den SVG Code?
Danke fürs Feedback und zusätzlichen Code (https://forum.fhem.de/index.php/topic,119440.msg1243563.html#msg1243563) docolli. Den Code für den ausgegrauten Akku habe ich übernommen - das funktioniert für den Ladestand imho nur wenn
no-bat-gradient gesetzt ist.
Ansonsten kann ich deine Anforderung der visuellen Trennung der Wallbox verstehen (@mr_petz: danke fürs Anmoderieren btw), sehe dies aber in deinem Fall nicht als Teil der PV Darstellung. Dein PV-Strom geht ja nicht in die Wallbox, also warum sollte man dies hier darstellen? Und wenn die Wallbox durch den Netzbezug gespeist wird, dann entspricht dies mMn auch dem Hausverbrauch. Oder hat die Wallbox einen eigenen elektrischen Anschluß inklusive Zähler seitens Netzbetreibers?
Zitat von: docolli am 06 November 2022, 12:33:32Mir würde noch eine zweite Batterie neben dem Auto gefallen. Den Füllstand der Autobatterie habe ich als Wert. Auch eine geschätze Zeit bis zur vollen Ladung/Entladung der Hausbatterie. Auch alles konfigurierbar, ob es angezeigt werden soll, oder nicht.
Auch im Hinblick auf den zur Verfügung stehenden Platz sehe ich weitere Erweiterungen eher kritisch. Da sehe ich in deinem speziellen Fall auch eher einen fork, welche die PV Anlage dann komplett raus nimmt und sich allein auf die Wallbox und Ladestand des eAutos fokussiert.
Der Ladestand lässt sich analog zum Akkustand als Text bestimmt noch unterm Auto darstellen.
Zitat von: docolli am 06 November 2022, 12:33:32Ich mach jetzt mal meine Anpassungen, dann poste ich hier mein Ergebniss, samt kleiner Anleitung. Dann kann ich mich mit @yersinia austauschen, ob wir die beiden Codes mergen. Einen eigenen Fork möchte ich nicht pflegen.
Sehr gerne. :)
Zitat von: docolli am 06 November 2022, 12:33:32Wie bearbeitet ihr den SVG Code?
vim 8)
Zitat von: yersinia am 06 November 2022, 14:52:21
Ansonsten kann ich deine Anforderung der visuellen Trennung der Wallbox verstehen (@mr_petz: danke fürs Anmoderieren btw), sehe dies aber in deinem Fall nicht als Teil der PV Darstellung. Dein PV-Strom geht ja nicht in die Wallbox, also warum sollte man dies hier darstellen? Und wenn die Wallbox durch den Netzbezug gespeist wird, dann entspricht dies mMn auch dem Hausverbrauch. Oder hat die Wallbox einen eigenen elektrischen Anschluß inklusive Zähler seitens Netzbetreibers?
Technisch gesehen hast du Recht, die Wallbox hängt einfach an der Unterverteilung wie alle anderen Hausverbraucher auch und läuft über den Hausanschlußzähler. Aber die Wallbox kommuniziert mit dem Hauskraftwerk und die Leistung, die durch die Wallbox läuft, kann gesteuert werden.
Mein PV-Strom geht selbstverständlich in die Wallbox! :) Habe ich z.B. 8000W PV Produktion, das Haus braucht 500W, mein Akku lädt mit 2500W, so bleiben noch 5000W für die Wallbox. Nur was weder von Haus, noch vom Hausakku oder der Wallbox verbraucht wird, geht ins Netz. Stelle ich die Wallbox so ein, dass sie nur 3000W ins Auto lädt, dann gehen im vorigen Fall 2000W ins Netz.
Dadurch dass man die Wallbox einfach als weiteren Hausverbraucher sehen kann, kann man es natürlich auch so sehen, dass damit der Hausverbrauch auch um diesen Betrag höher ist. Ich persönlich (vielleicht auch andere), möchte aber nur den reinen Hausverbrauch sehen und die Wallboxleistung als extra Wert haben.
Zitat
Auch im Hinblick auf den zur Verfügung stehenden Platz sehe ich weitere Erweiterungen eher kritisch. Da sehe ich in deinem speziellen Fall auch eher einen fork, welche die PV Anlage dann komplett raus nimmt und sich allein auf die Wallbox und Ladestand des eAutos fokussiert.
Der Ladestand lässt sich analog zum Akkustand als Text bestimmt noch unterm Auto darstellen.
Auch darüber habe ich nochmals nachgedacht und der Platz ist schon begrenzt. Da müsste man dann eher das Haus nach oben versetzen und das Auto auch etwas hochschieben, sodass eine Art T-förmige Energieflusssdarstellung entsteht. Ist alles zu aufwendig. Aber eine kleine Darstellung des Akkustandes als Text ist eine gute Idee!
An der Wallbox kann ja durchaus auch mal ein anderes Auto geladen wird, oder das eigene Auto wird woanders geladen. Da passen dann Wallboxleistung und Auto Akkustand nicht zusammen. Somit bin ich mir jetzt auch nicht mehr so sicher, ob das in die PV Anzeige rein sollte.
Zitat
Sehr gerne. :)
vim 8)
Ähhhh, du editierst SVG im Texteditor ohne visuelles Feedback? Respekt! :o
Kannst du dir im Kopf die Form und Position vorstellen? Oder nimmst du vim, um die SVG Schnipsel zusammenzubauen? ;)
Anbei eine neue Version, welche deine Vorschläge partiell übernimmt:
- der Akku wird ausgegraut, wenn keine Ent/Ladung geschieht
- genauso das Netzicon, wenn es weder Bezug oder Einspeisung gibt; ein Schwellenwert habe ich nicht definiert, da selbst zB 10w imho kein Nichtebzug sind.
Weiterhin finde ich die Trennung zwischen Hausverbrauch und Wallboxverbrauch nach deiner Beschreibung sinnvoll. Es kann visuell schon ein Unterschied machen, den Verbrauch der Wallbox nicht dem Haus zuzuordnen. Ich habe deinen Code-Vorschlag (https://forum.fhem.de/index.php/topic,119440.msg1243524.html#msg1243524) adaptiert übernommen: der Parameter um den Wallboxverbrauch aus dem Hausverbauch herauszurechnen ist
no-wb-in-home.
<ftui-pvvis
[charge-discharge]="E3DC_S10E:Batterieleistung"
[soc]="E3DC_S10E:Batterieladezustand"
[produce]="E3DC_S10E:Solarleistung"
[wb-feed]="E3DC_S10E:Wallboxleistung"
pvmax="12580"
[feed-receive]="Stromzaehler:Itron_Power_cur | multiply(-1)"
no-wb-in-home
sun-icon="sun"
grid-icon="pylon2"
unit-soc="%"
unit-value="W"
width="400px">
</ftui-pvvis>Zitat von: docolli am 06 November 2022, 20:38:36Ähhhh, du editierst SVG im Texteditor ohne visuelles Feedback? Respekt! :o
Kannst du dir im Kopf die Form und Position vorstellen? Oder nimmst du vim, um die SVG Schnipsel zusammenzubauen? ;)
Naja, man muss dazu sagen, dass ich (hier) viel SVG code einfach von papa, Shadow3561 und mr_petz übernommen und bei Bedarf adaptiert habe. Dafür reicht vim, ich zeichne ja nicht komplett neu. Zur Anzeige nutze ich FF mit den WebDeveloper tools, das reicht für meine Bedürfnisse.
Und ja, ich hab natürlich vorher eine grobe Vorstellung, wie man etwas realisieren könnte - daher stell' ich mir die Akkustanderweiterung für das eAuto oder einen (optionalen) flow Netz=>Wallbox schwierig vor; weniger von der Realisierung sondern eher von der daraus resultierenden visuellen Überfrachtung.
Davon abgesehen hat diese component jetzt schon verdammt viele Parameter und Einstellmöglichkeiten:
Zitatpvmax: maximale Leistung der PV Anlage - dies ist ein fester Wert
[produce]: reading; Produktion der PV Anlage (der Wert wird zu einem positiven Wert konvertiert)
[soc]: reading; Ladestand des Akkus (kann % aber auch Wh annehmen)
[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)
battstep: optional; Grenzwerte für die Ladestandsanzeige des Akkus:
battstep="21,35,51,75,95"
Dabei ist 21 der untere Schwellenwert unter dem der Akku grau bleibt. Diese Definition entspricht:
0 bis 21 - Batterie ist ausgegraut
21 bis 35 - kein Balken
35 bis 51 - ein Balken
51 bis 75 - zwei Balken
75 bis 95 - drei Balken
ab 95 - vier Balken
Vorgegebener Standard ist
battstep="1,24,49,74,95"
no-bat-gradient: optional; der Batteriestand wird als Farbverlauf in Abhängigkeit des Ladezustands angezeigt - wenn der Akku leer ist färben sich die Balken rot und gehen bei Ladung bis voll sukzessive in grün über. Dabei ändern nur die Ladebalken die Farbe, die Batterie selbst zeigt immer noch an ob sie geladen (grün) oder entladen (rot) wird (grau wenn weder ge/entladen wird). Wer diesen Farbverlauf nicht haben möchte, setzt no-bat-gradient. Der Farbverlauf basiert auf den battstep-Schwelelnwerte.
has-no-battery: optional; wenn gesetzt wird der Akkustrang rechts ausgeblendet
grid-icon: optional; ersetzt das Kabel-Netzicon; valide Werte sind: pylon, pylon2 (von papa aus #123 (https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479) ) oder cable (Standard; muss nicht explizit gesetzt werden)
home-icon: optional; das Haus-Icon lässt sich ersetzen durch folgende potentielle Werte: house (Standard; muss nicht explizit gesetzt werden), plug (Stecker) oder socket (Steckdose)
has-no-grid-feed: optional; blendet die Netzeinspeisung (PV=>Netz) aus
has-grid-charge: optional; aktiviert das Laden des Akkus vom Netz und entsprechende Werte können mittels [grid-charge]="DEVICE:READING" übergeben werden.
[grid-charge]: reading, optional; übernimmt die Werte der Ladeleistung des Akkus aus dem Netz; muss gesetzt werden wenn has-grid-charge genutzt wird
has-no-wallbox: optional; wenn gesetzt, wird der Wallbox-Teil ausgblendet
[wb-feed]: reading, optional; nimmt den Wert des derzeitigen Ladens des Autos auf (entspricht papas data-lp1pow - Ladung des Auto). Ist der Wert <= 0 wird der Strang und das Auto ausgegraut. Ist der Wert > 0 wird das Auto grün und der flow gelb eingefärbt. Muss nicht gesetzt werden wenn has-no-wallbox gesetzt ist.
no-wb-in-home: optional; zieht den Wallboxverbrauch vom Hausverbrauch ab
sun-icon: optional; andere icons für die Sonne => sun2 entspricht der Sonne von papa aus #123 (https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479); pvsun entspricht dem panel und der Sonne von Shadow3561 aus #24 (https://forum.fhem.de/index.php/topic,119440.msg1226092.html#msg1226092); sun ist der Standardwert und muss nicht explizit gesetzt werden
unit-soc optional; für die Einheit des Akkustands, zB:
unit-soc="%"
Wenn nicht gesetzt wird auch keine Einheit gesetzt.
unit-value optional; für die Einheit der Ent/Lade-Werte, zB:
unit-value="W"
Wenn nicht gesetzt wird auch keine Einheit gesetzt.
width: optional; Breite der Grafik (Standard ist 200px)
Vielen Dank für die Integration! Das mit den Schwellwerten wurde hier ja schon mal diskutiert und dann mit einer Helperfunktion gelöst, die per pipe das Reading oberhalb eines individuellen Schwellwerts auf Null setzt. Das habe ich heute mal implementiert, muss aber sagen, dass mir meine Lösung im Code besser gefällt, da diese nur die farbige Hervorhebung des Energiestrangs unterdrückt, aber den geringen Energieverbrauch dennoch als Wert anzeigt. Mich persönlich hat nur gestört, dass ein geringer Energiefluss optisch die gleiche "Aufmerksamkeit" bekommt, wie ein hoher (siehe Bild, bei meiner Umsetzung verschwinden die 3W aus dem Netz optisch, der Wert ist aber zu lesen / es kommt relevante Energie nur aus dem Akku).
Damit du besser verstehst was ich mache hier der Code dazu:
colorGrid() {
let consumption = this.receive - this.feed;
this.grid.classList.remove("pvvis-grid-feed", "pvvis-grid-consume", "pvvis-grid-neutral");
if(consumption > this.flowThreshold ) {
this.grid.classList.add("pvvis-grid-consume");
} else if(consumption < -this.flowThreshold ) {
this.grid.classList.add("pvvis-grid-feed");
} else {
this.grid.classList.add("pvvis-grid-neutral");
}
}
bzw.
flowValue(src, obj) {
const loadOneThird = Math.round(this.pvmax * (1/3));
const loadTwoThirds = Math.round(this.pvmax * (2/3));
this.shadowRoot.getElementById(obj).classList.remove("pvvis-active1", "pvvis-active2", "pvvis-active3", "pvvis-inactive");
if(!isNaN(src)) { src = parseInt(src); }
if(src > loadTwoThirds) {
this.shadowRoot.getElementById(obj).classList.add("pvvis-active1");
} else if(src > loadOneThird) {
this.shadowRoot.getElementById(obj).classList.add("pvvis-active2");
} else if(src > this.flowThreshold ) {
this.shadowRoot.getElementById(obj).classList.add("pvvis-active3");
} else {
this.shadowRoot.getElementById(obj).classList.add("pvvis-inactive");
}
if((this.doNotShowZero) && (Math.round(src) == 0)) {
this.shadowRoot.getElementById(obj+"-txt").innerHTML = '';
} else {
this.shadowRoot.getElementById(obj+"-txt").innerHTML = src.toFixed();
if(this.unitValue) { this.shadowRoot.getElementById(obj+"-txt").innerHTML += '<tspan class="pvvis-txt-unit-value">' + this.unitValue + '</tspan>'; }
}
}
Ich habe (sorry, noch ein Parameter mehr ::)) dafür "flow-threshold" eingeführt. Der Einfachheit halber nutze ich den sowohl, um die Farbe des grid-Icon zu steuern, als auch die flow Darstellung der Energieflüsse zu starten.
Das mit dem SVG habe ich jetzt verstanden, als ich mir die CSS Auszeichnung mit transform/translate/scale angesehen habe. Cool, so geht das mit Editor und FF im Entwicklungsmodus. 8)
Was ich mit dem Auto und seinen Werten mache, muss ich mir noch selber klar werden. Im Bild siehst du den Stand, wo ich Akkustand drunter und Innentemperatur innen rein gesetzt habe... ;D
Was mir eben noch auffällt: Es kann bei meinem Hauskraftwerk durchaus vorkommen, dass der Wechselrichter aus dem Akku kurzfristig zuviel Strom erzeugt und dieser dann ins Netz eingespeist wird. Sind nur wenige Watt (<10W), aber dadurch rechnet er eine negative PV-Produktion. Und der Strom, der ins Netz geht, kommt nicht wirklich von der PV, steht also auch am falschen Strang. Irgendeine Idee, wie man das verbessern könnte?
Zitat von: docolli am 07 November 2022, 17:41:35Vielen Dank für die Integration!
Vielen Dank für den Code-Input. :)
Zitat von: docolli am 07 November 2022, 17:41:35Das mit den Schwellwerten wurde hier ja schon mal diskutiert und dann mit einer Helperfunktion gelöst, die per pipe das Reading oberhalb eines individuellen Schwellwerts auf Null setzt. Das habe ich heute mal implementiert, muss aber sagen, dass mir meine Lösung im Code besser gefällt, da diese nur die farbige Hervorhebung des Energiestrangs unterdrückt, aber den geringen Energieverbrauch dennoch als Wert anzeigt. Mich persönlich hat nur gestört, dass ein geringer Energiefluss optisch die gleiche "Aufmerksamkeit" bekommt, wie ein hoher (siehe Bild, bei meiner Umsetzung verschwinden die 3W aus dem Netz optisch, der Wert ist aber zu lesen / es kommt relevante Energie nur aus dem Akku).
Ja, ganz oder gar nicht - entweder man möchte die Werte sehen oder eben nicht. Wenn die unter dem via pipe selbstgewählten Schwellwert fallen, dann sollten mMn sowohl Werte als auch flows ausgeblendet/genullt werden. Die flows auszublenden um dann nur 3W anzuzeigen finde ich nicht zielführend. Aber wenn es hier noch mehr Bedarf dafür gibt, dann bau' ich das mit ein.
Zitat von: docolli am 07 November 2022, 18:47:36Und der Strom, der ins Netz geht, kommt nicht wirklich von der PV, steht also auch am falschen Strang. Irgendeine Idee, wie man das verbessern könnte?
Eine negative PV produktion kann es eigtl nicht geben - von daher würde ich negative Werte verwerfen:
calcProduce() {
this.pvhomeval = Math.abs(this.produce) - this.charge - this.feed;
if(this.pvhomeval < 0) { this.pvhomeval = 0; }
this.flowValue(this.pvhomeval, "pv-home");
this.calcHouseConsume();
}
Gerade den Thread entdeckt. Ich nutze FTUI2 und das Widget von Papa aus Beitrag 120 und folgende Änderungen.
Was mir noch gefehlt hatte:
- Gesamtverbrauch momentan vom Haus
- Gesamtproduktion momentan von der PV-Anlage
Also Gesamtverbrauch vom Haus als Zahl beim "Haus"-Icon, sowie Gesamtproduktion als Zahl beim "Sonnen"-Icon?
dazu habe ich in die config noch die Variable "verbrauch" eingebaut und dann "verbrauch" und "produce" (dieser Wert war schon enthalten, wurde nur nicht angezeigt) im Widget mit eingefügt.
das sind nun die aktuell möglichen Werte:
data-device - Gerät, das den Refresh triggert
data-get - Bezug aus dem Netz
data-feed - Einspeisungs in Netz
data-produce - Production PV-Anlage momentan
data-verbrauch - Verbrauch Haus momentan
data-charge - Ladung Akku
data-discharge - Entladung Akku
data-soc - Ladezustand Battery
data-pv-max - Maxiamle Leistung PV
data-lp1 - Zustand des Steckers der Wallbox - 0 oder 1
data-lp1pow - Ladung des Auto
data-width - Breite des Widget
data-height - Höhe des Widget
so sieht die config aus:
<div data-type="pvvis" data-device="symogen24"
data-get="usr_Netz_Bezug" data-feed="usr_Netz_Einspeisung"
data-produce="usr_Photovoltaik" data-charge="usr_Batt_Einspeisung"
data-verbrauch="usr_Verbrauch" data-discharge="usr_Batt_Bezug" data-soc="usr_Batt_Prozent"
data-pv-max="11000"
data-width="370" data-height="370" class="centered">
</div>
und so sieht es aus:
Zitat von: mr_petz am 05 November 2022, 17:25:42
Dann bräuchte die Wallbox ja eigene Strangberechnungen wie das Haus?
Oder woher kann der View das sehen von wo die Wallbox gerade Strom bezieht bzw. beziehen darf?
Ist nur für die Umsetzung zu überlegen.
LG mr_petz
Edit:
Es muss natürlich der Hausverbrauch mit einbezogen werden in den Berechnungen...
Hier mal für Euch ein nettes Beispiel aus der Praxis (siehe Bild), damit man sieht, dass die Idee mit der Strangberechnung für die Wallbox gar nicht so trivial ist.
Ich habe die Wallbox fest auf 10A eingestellt, so zieht das Auto 2248W. Von der PV kommen 2243W, das Haus braucht 576W und aus dem Netz kommen 581W.
So, hat nun die Wallbox reinen PV Strom und wird das Haus komplett aus dem Netz versorgt? Oder wird das Haus mit 576W komplett von der PV versorgt und der Überschuss (1667W) gehen in die Wallbox und den Rest (581W) zieht die sich aus dem Netz? ::)
Es ist ja eher so, dass das Haus (samt Wallbox) mit Mischstrom aus PV und Netz versorgt wird, der PV Anteil ist 2243/2824=79,4%, der Netzanteil somit 20,6%. Wenn man (was aus meiner Sicht an dieser Stelle nicht notwendig ist) eine Strangberechung für Wallbox samt extra Stränge darzustellen machen will, dann nur mit prozentualen Werten und drüber dann die "W" der einzelnen Wallboxstränge berechnen.
ah. das ist interessant. Wie bekomme ich denn im Widget noch ein "w" hinter die Werte?
an welcher Stelle muss das rein? Ich bin zugegeben nicht so fit was javascript anbetrifft.
Die anderen Dinge konnte ich anhand der anderen Werte im Widget ableiten und hinzufügen.
Aber einen String (w) an die Werte hängen, da fehlt mir der Ansatz.
Zitat von: fred_feuerstein am 08 November 2022, 15:17:39Aber einen String (w) an die Werte hängen, da fehlt mir der Ansatz.
Analog zu Zeile 237 in deiner Version (welches ein % an den Ladestand hängt):
batsoctxt.text(doround(soc)+"%");kannst du ab Zeile 227 folgendes ergänzen:
var unit = "W"; //<--
gridhometxt.text(doround(consume) + unit); //<--
gridhometxt.attr("class", flowstyle(consume));
pvgridtxt.text(doround(feed) + unit); //<--
pvgridtxt.attr("class", flowstyle(feed));
pvhometxt.text(pvhomeval + unit); //<--
pvhometxt.attr("class", flowstyle(pvhomeval));
pvbattxt.text(doround(charge) + unit); //<--
pvbattxt.attr("class", flowstyle(charge));
bathometxt.text(doround(discharge) + unit); //<--
bathometxt.attr("class", flowstyle(discharge));
batsoctxt.text(doround(soc)+"%");
homecartxt.text(doround(lp1pow) + unit); //<--
homecartxt.attr("class", flowstyle(lp1pow));
producetxt.text(doround(produce) + unit); //<--
verbrauchtxt.text(doround(verbrauch) + unit); //<--(die
//<-- sind Marker für die Zeilen mit Änderungen und nicht notwendig)
(FTUI2)
Super! Vielen Dank.
wieder was gelernt :)
Jetzt gefällt es mir.
Anbei die aktuelle Version.
//edit: nochmal neue Version angehängt. Habe noch abgefangen, dass der berechnete Wert "pvhomeval" auch mal kleiner 0 sein kann. Falls dem so ist wird er als 0 angezeigt.
Diese Konstellation kommt bei mir manchmal vor, wenn es bei wenig Produktion, Wechsel von Batterie- zu Netzstrom oder umgekehrt gibt.
Passt also.
Hallo,
eine Superdarstellung für die PV-Anlage. Vielen Dank.
Wie kann man die Schriftgröße anpassen? Zum Lesen muss man an mein Tablet schon sehr nah rangehen.
size="XXX" hatte ich schon ohne Effekt probiert.
Torsten
Welche Version nutzt du? Beim FTUI2 geht es so:
Die einzelnen Textvariablen kannst du hier verändern :
<text id="pv-home-txt" x="210" y="230" style="fill: #ccc; font-size: 38px; text-anchor: end;">0</text> \
<text id="grid-home-txt" x="210" y="400" style="fill: #ccc; font-size: 38px; text-anchor: end;">0</text> \
<text id="pv-bat-txt" x="390" y="230" style="fill: #ccc; font-size: 38px; text-anchor: start;">0</text> \
<text id="bat-home-txt" x="390" y="355" style="fill: #ccc; font-size: 38px; text-anchor: start;">0</text> \
<text id="bat-soc-txt" x="595" y="425" style="fill: #ccc; font-size: 38px; text-anchor: middle;">%</text> \
<text id="pv-grid-txt" x="330" y="451" style="fill: #ccc; font-size: 38px; text-anchor: start;">0</text> \
<text id="home-car-txt" x="25" y="471" style="fill: #ccc; font-size: 38px; text-anchor: start;">0</text> \
<text id="produce-txt" x="390" y="6" style="fill: #ccc; font-size: 38px; text-anchor: start;">0</text> \
<text id="verbrauch-txt" x="0" y="190" style="fill: #ccc; font-size: 38px; text-anchor: middle;">0</text> \
Jeweils den Wert font-size
Die komplette Grösse der Anzeige Grafik und somit auch der Texte stellst Du im ftui device ein.
Achtung. Hier sollte jeder seine verwendete Version für FTUI2 oder FTUI3 dazu schreiben!
In diesen Thread werden beide Versionen supportet...
LG
Stimmt. Habe es bei meiner Antwort ergänzt.
ich nutze ja FTUI2
@fred_feuerstein: Danke.
Ich nutze zwar FTUI3, aber mit den IDs habe ich die entsprechenden Stellen in der CSS-Datei gefunden.
@yersinia
Nur ein Vorschlag.
Du könntest bezüglich der Anfrage zur Textgröße von @iron.eagle alle <text> Tags aus den <g> Tags rausholen, die x und y der Textposition anpassen und in den Klassen die font-size´s löschen.
Damit kann man dann mit den FTUI3 Klassen Bsp.: class="size-2" die Größe für alle Texte mitgeben...
Die font-size: 75%; in .pvvis-txt-unit-value könntest du beibehalten.
Wenn du dafür Hilfe benötigst sage einfach Bescheid...
LG mr_petz
@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:
.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.
@mr_petz
mir ist noch nicht klar, wie ich einen default vorgeben kann, welcher bei Bedarf überschrieben werden kann. Man kann stand heute durchaus class="size-2" setzen nur ignoriert die css Hierarchie dies. Wenn ich font-size aus den Klassen rausnehme (bzw auf % setze), muss mMn immer class="size-n" gesetzt werden.
Zitat von: yersinia am 12 November 2022, 14:30:36
.....
@mr_petz
mir ist noch nicht klar, wie ich einen default vorgeben kann, welcher bei Bedarf überschrieben werden kann. Man kann stand heute durchaus class="size-2" setzen nur ignoriert die css Hierarchie dies. Wenn ich font-size aus den Klassen rausnehme (bzw auf % setze), muss mMn immer class="size-n" gesetzt werden.
@yersinia
Ich meinte so wie im Anhang.
Entweder mit --text-size oder size="1.5" oder class="size"
(einwenig vom label abgekupfert...)
Standard ist hier 1.5rem.
Alle Texttags ins svg geschoben und x, y angepasst...
Schau es dir an. ;)
LG mr_petz
EDit: irgendwann ist natürlich alles oversized...
Anhang entfernt...
charmante Lösung @mr_petz. ich frage mich, nur ob man es so kompliziert machen muss - FTUI bringt ja ein font-size (https://github.com/knowthelist/ftui/blob/master/www/ftui/themes/ftui-theme.css#L119) mit und CSS vererbt es entsprechend - und man kann es mit class="size-xx" entsprechend für pvvis übersteuern. Möglichereise ist der Weg via max() und relativen Angaben eleganter:
font-size: max(20px, 100%);
Anbei eine Version, die alle font-sizes derart definiert.
@iron.eagle: jetzt kannst du entsprechend der gewünschten Textgröße (https://github.com/knowthelist/ftui/blob/master/www/ftui/ftui.css#L228) die class setzen, zB
class="size-4"
OK. Bei deiner Version werden in erster Linie nur Sonne und Haus vergrößert.
Hier mit size-7 getestet...
Deswegen habe ich die <text> aus den <g> geholt, sonst ziehen die class="size-x" nicht für alle Elemente.
Übergröße ist weiterhin möglich. Ich schau mal was man noch machen kann...
LG mr_petz
@yersinia
Neuer Versuch/Vorschlag :)
Die <text> bleiben wo sie sind und die Fontsize´s werden mit calc() in der css gesetzt/berechnet.
Hinzugekommen ist text-size als Attribute.
Wenn nix angegeben wird der Standard gesetzt.
Wenn text-size>35 angegeben dann wird auf Standard gesetzt, ansonsten die Größe berechnet.
Bsp:
text-size="30px"
Damit hebelst du ein stylen und die Sizeklassen aus. Eine Übergröße ist nicht möglich.
LG mr_petz
Edit: Ich habe gerade clamp() entdeckt.
Da hast du als erstes ein min, danach den soll/variabler/wunsch Wert und als letztes den max Wert.
Das wird dir denke ich eher gefallen...
Das könntest du dann z.Bsp. so gestalten in der css:
font-size: clamp(1.25rem, var(--text-size), 2rem);
wenn du es so machst:
font-size: clamp(1.25rem, 20px, 2rem);
dann hilft das aber nix. die 20px müssen ansprechbar sein...
Musst du aber für alle font-size einen eigenen var definieren...
Es sei denn du holst die <text> aus den <g>... (was einfacher wäre und funktioniert...)
und wenn du die font-size (size-x) der class mitbenutzen möchtest könntest du sie so auslesen:
window.getComputedStyle(this, null).getPropertyValue('font-size');
oder mit FTUI3 mitteln:
getStylePropertyValue('font-size', this);
dafür musst du aber noch das importieren:
import { getStylePropertyValue } from '../../modules/ftui/ftui.helper.js';
Du musst nur aufpassen... es wird in px ausgelesen...
Da könnte ich noch eine Version bauen...
clamp() Version angehangen...
Mit class="size-x" die Größe angeben...
Anhang entfernt...
Auf Anregung von @yersinia möchte ich hier eine Erweiterung seiner Darstellung, basierend auf dem Code vom 06-11-2022 vorstellen.
Ich habe vom eAuto als FHEM Reading sowohl Akkuladestand als auch Innentemperatur, diese können beim Auto-Symbol mit angezeigt werden. Dazu gibt es zwei neue Parameter
Zitat[carsoc]: reading, optional; Ladestand des Akku vom eAuto (kann % aber auch Wh annehmen, siehe unit-soc)
[cartemp]: reading, optional; Innentemperatur des eAuto in °C
Der Hausakku zeigt nun die Zeitdauer (max. 99,9h) bis zur vollständigen Füllung bzw. kompletter Entleerung, basierend auf der
aktuellen Akku-Entnahme, an. Die Zeit bis der Akku voll ist steht bei Beladung oben, bis er leer ist bei Entladung unten, ansonsten ist die Zeit ausgeblendet. Dazu muss die Kapazität des Hausakku in kWh übergeben werden.
Ich finde das ganz hilfreich, um Abends planen zu können, ob noch genügend Strom im Hausakku für z.B. einen Spülmaschinenlauf ist. Reicht die Zeit bis zum nächsten Morgen locker, bis die PV wieder produziert, dann kann man auch den Verbraucher starten, ohne Nachts dann in Netzbezug zu kommen und am nächsten Tag aber dann Überschuß ins Netz zu speisen.
Zitat[batmax]: reading, optional; Hausakkukapazität in Wh
Der untere Schwellwert, ab dem der Energiefluss durch Animation und leuchtender Farbe visualisiert wird, kann selbst gewählt werden. Gefällt mir persönlich besser, als das reading durch eine Schwellwertfunktion auf "0" zu setzen, da man damit den geringen Wert angezeigt bekommt, er aber nicht visuell gleichberechtigt mit viel größeren Energieflüssen dargestellt wird.
Zitatflow-threshold: optional; Schwellwert in W, ab dem der Energiefluss durch Animation und leuchtender Farbe visualisiert wird
Wenn in FHEM per userreading und integral Funktion die Tagessummen von PV-Produktion, Hausverbrauch, Netzentnahme und Netzeinspeisung berechnet werden, so können diese nun auch dargestellt werden.
Zur besseren Planung des Tages, ob man voraussichtlich genug Überschußstrom hat, um z.B. Waschmaschine, Trocker oder Geschirrspüler laufen zu lassen, hole ich mir von Proplanta die Einstrahlung und rechne über die qm PV Fläche und Leistung pro qm und einen Faktor den voraussichtlichen Ertrag aus:
ReadingsVal ("WetterProplanta","fc0_rad",0)*63.2*0.198*0.80.
Zitat[pvproducedtoday]: reading, optional; heutiger PV-Ertrag in kWh
[pvforecast]: reading, optional; voraussichtlicher heutiger PV-Ertrag in kWh
[homeconsumedtoday] reading, optional; bisheriger Tages-Stromverbrauch in kWh
[gridintoday] reading, optional; bisherige Einspeisung ins Stromnetz in kWh
[gridouttoday] reading, optional; bisherige Entnahme aus dem Stromnetz in kWh
Ich stelle nur mal den Screenshot zur Diskussion, wenn Interesse besteht, poste ich auch den Code dazu.
[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.
@mr_petz: clamp (https://developer.mozilla.org/en-US/docs/Web/CSS/clamp) ist, glaube ich, genau das, was ich gesucht habe - so kann ich bei den vier Textarten (Loadflows, Ladestand Batterie, Produce & Home) Mindest- und Maximalgrößen übergeben und der User kann noch mit class="size-xx" begrenzt darauf einwirken.
Danke auch für die Vorarbeit des Rauslösens der <text> aus den groups - das macht es doch einfacher und einheitlicher. Vor allem wird jetzt die font-size auch besser vererbt imho.
Zitat von: yersinia am 14 November 2022, 10:28:00
@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.
zeige Interesse 8)
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
{"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?
Zitat von: Adimarantis am 14 November 2022, 11:13:20Das JSON schaut so aus
Wie sind denn die readings des FHEM-Devices (und was bedeuten sie)?
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:
[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.
Schau mal in #157 (https://forum.fhem.de/index.php/topic,119440.msg1243844.html#msg1243844):
Zitat[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.
[soc]="Sonnenbatterie:USOC"scheint falsch zu sein - ist der Ladestand des Akkus wirklich 0%? Oder sollte es eher
[soc]="Sonnenbatterie:Ubat"sein?
In deinem Auszug wird ja die Batterie weder ge- noch entladen, oder?
"BatteryCharging":false,"BatteryDischarging":falseSpannend wären die Werte, wenn der Akku ge/entladen wird.
Wenn ich dein JSON richtig verstehe, dann ist das multiply(-1) hier falsch
[feed-receive]="Sonnenbatterie:GridFeedIn_W | multiply(-1)"und kannst du eigtl weglassen, weil
"GridFeedIn_W":-3271-> entspricht meines Verständnisses eines Bezugs aus dem Netz (GrdiFeed wäre imho positiv wenn du ins Netz einspeist).
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.
Zitat von: Adimarantis am 14 November 2022, 13:26:43Erst 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?
Apparent_output":232
Bestimmt 232V
Zitat von: yersinia am 14 November 2022, 10:28:00
[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!
Zitat von: yersinia am 12 November 2022, 14:30:36
@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:
.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 :-\
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.
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. :)
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:
<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.
Zitat von: docolli am 17 November 2022, 18:44:12
...
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:
<text id="home-car-txt" x="70" y="295" class="pvvis-text" style="text-anchor: start;"></text>
....
Das geht auf meine Kappe ;D
Sorry
LG
@ mr_petz: kein Problem ;D
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!
<?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.
[FTUI3]
Man, man, man - so schnell komm ich gar nicht nach mit frickeln so wie die Ideen hier sprudeln. :D
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:
Zitat[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 (https://forum.fhem.de/index.php/topic,119440.msg1243844.html#msg1243844)
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!
Vielen Dank für die rasche und umfassende Umsetzung der Ideen in deinen Zweig!
Ich muss damit auch Tester der ersten Stunde sein. 8) Sieht prima aus, gerade die Idee mit dem roten Strich und Pfeil zur Darstellung des exakten Ladezustands ist super!
Leider schaffe ich es nicht die Summenwerte und car-temp und car-soc darstellen zu lassen. Die kommen bei mir nicht.
<ftui-pvvis
[charge-discharge]="E3DC_S10E:Batterieleistung"
[soc]="E3DC_S10E:Batterieladezustand"
[produce]="E3DC_S10E:Solarleistung"
[wb-feed]="E3DC_S10E:Wallboxleistung"
[pv-forecast]="E3DC_S10E:Ertragsprognose | fix(1)"
[pv-prod-tdy]="E3DC_S10E:Solarleistung_today | multiply(0.001) | round(1) | fix(1)"
[home-consume-tdy]="E3DC_S10E:Hausleistung_today | multiply (0.001) | round(1) | fix(1)"
[grid-feed-tdy]="Stromzaehler:Einspeisung_today | fix(3)"
[grid-consume-tdy]="Stromzaehler:Netzbezug_today | fix(3)"
pvmax="10000"
battmax="13000"
calc-bat-remain-time="1"
[feed-receive]="Stromzaehler:Itron_Power_cur | multiply(-1)"
[car-soc]="NissanZE1:BatterySOC | part(1)"
[car-temp]="NissanZE1:CabinTemp | fix(1)"
unit-car-soc="%"
no-wb-in-home="1"
sun-icon="sun"
grid-icon="pylon2"
flow-threshold="10"
unit-soc="%"
unit-sum="kWh"
unit-value="W"
width="290px"
margin="3px 0 0 0"
class="size-3">
</ftui-pvvis>
Edit: definiere ich z.B. pv-forecast="10.5", so wird ein Wert angezeigt.
Unterhalb des Akkus schaffe ich es auch nicht, die Restladung in kWh anzeigen zu lassen, wenn ich soc in % übergebe. Vielleicht sollten wir calc-bat-remain-soc-not-percent umbenennen in soc-not-percent. Somit könnte man die Info, dass der soc in % übergeben wurde nicht nur für die bat-remain Berechnung benutzen, sondern auch für die Anzeige unterhalb der Batterie. Ist unit-soc="kWh" (also die Einheit, die unterhalb der Batterie angezeigt werden soll) und soc-not-percent=false, so wird der angezeigte Wert aus battmax und soc errechnet (in kWh). Oder wir definieren noch einen Parameter unit-bat und der wird dann als Kriterium zur evetuell notwendigen soc Umrechung herangezogen.
Zitat von: docolli am 18 November 2022, 15:57:09Leider schaffe ich es nicht die Summenwerte darstellen zu lassen. Die kommen bei mir nicht.
Kommentiere mal testhalber Zeile 391 diese Prüfung aus:
// if(!isNaN(val)) { val = parseFloat(val); }Ich denke, dass die hier nicht (mehr) benötigt wird.
Zitat von: docolli am 18 November 2022, 15:57:09Unterhalb des Akkus schaffe ich es auch nicht, die Restladung in kWh anzeigen zu lassen, wenn ich soc in % übergebe.
Das ist so auch nicht vorgesehen. soc nimmt
jeden Wert an; kann also % (0-100) oder irgendein (k)Wh Wert sein (>= 0). Setzt du soc auf was anderes als %, musst du battstep entsprechend anpassen, da die Schwellwerte alle < 100 sind.
Zitat von: docolli am 18 November 2022, 15:57:09Vielleicht sollten wir calc-bat-remain-soc-not-percent umbenennen in soc-not-percent. Somit könnte man die Info, dass der soc in % übergeben wurde nicht nur für die bat-remain Berechnung benutzen, sondern auch für die Anzeige unterhalb der Batterie. Ist unit-soc="kWh" (also die Einheit, die unterhalb der Batterie angezeigt werden soll) und soc-not-percent=false, so wird der angezeigte Wert aus battmax und soc errechnet (in kWh). Oder wir definieren noch einen Parameter unit-bat und der wird dann als Kriterium zur evetuell notwendigen soc Umrechung herangezogen.
Bin ich noch nicht überzeugt. Wenn man den Ladestand in zB Wh darstellen möchte, dann sollte dies auch so an soc aus FHEM heraus übergeben werden.
calc-bat-remain-soc-not-percent brauche ich nur, weil ich auf component-seite nicht
sicher zwischen % und zB kWh unterscheiden kann und dann die Berechnung für
calc-bat-remain-time unschlüssig wird.
Also entweder beispielsweise
[soc]="E3DC_S10E:Batterieladezustand" <!-- zB 12% -->
unit-soc="%"
calc-bat-remain-timeoder
[soc]="E3DC_S10E:Batterieladezustand" <!-- zB 7823Wh -->
unit-soc="Wh"
battstep="21,35,51,75,95"
calc-bat-remain-time
calc-bat-remain-soc-not-percentoder
[soc]="E3DC_S10E:Batterieladezustand" <!-- zB 7.8kWh -->
unit-soc="kWh"
battstep="0.5,2,5,8,12"
calc-bat-remain-time
calc-bat-remain-soc-not-percentOder möchtest du einen prozentualen Wert übergeben und pvvis soll dann selbstständig den Ladestand ausrechnen? Das sollte imho aus dem FHEM-Device kommen....
Btw, du kannst dir die ="1" Zuweisungen bei den Parametern sparen - die sind wahr wenn gesetzt:
<ftui-pvvis
[charge-discharge]="E3DC_S10E:Batterieleistung"
[soc]="E3DC_S10E:Batterieladezustand"
[produce]="E3DC_S10E:Solarleistung"
[wb-feed]="E3DC_S10E:Wallboxleistung"
[pv-forecast]="E3DC_S10E:Ertragsprognose | fix(1)"
[pv-prod-tdy]="E3DC_S10E:Solarleistung_today | multiply(0.001) | round(1) | fix(1)"
[home-consume-tdy]="E3DC_S10E:Hausleistung_today | multiply (0.001) | round(1) | fix(1)"
[grid-feed-tdy]="Stromzaehler:Einspeisung_today | fix(3)"
[grid-consume-tdy]="Stromzaehler:Netzbezug_today | fix(3)"
pvmax="10000"
battmax="13000"
calc-bat-remain-time
[feed-receive]="Stromzaehler:Itron_Power_cur | multiply(-1)"
[car-soc]="NissanZE1:BatterySOC | part(1)"
[car-temp]="NissanZE1:CabinTemp | fix(1)"
unit-car-soc="%"
no-wb-in-home
sun-icon="sun"
grid-icon="pylon2"
flow-threshold="10"
unit-soc="%"
unit-sum="kWh"
unit-value="W"
width="290px"
margin="3px 0 0 0"
class="size-3">
</ftui-pvvis>
Zitat von: yersinia am 18 November 2022, 16:23:20
Kommentiere mal testhalber Zeile 391 diese Prüfung aus:
// if(!isNaN(val)) { val = parseFloat(val); }
Ich denke, dass die hier nicht (mehr) benötigt wird.
Hilft leider auch nicht...
Zitat von: yersinia am 18 November 2022, 16:23:20
Oder möchtest du einen prozentualen Wert übergeben und pvvis soll dann selbstständig den Ladestand ausrechnen? Das sollte imho aus dem FHEM-Device kommen....
Okay, ich packs als user-reading ins FHEM-Device.
Zitat von: yersinia am 18 November 2022, 16:23:20
Btw, du kannst dir die ="1" Zuweisungen bei den Parametern sparen - die sind wahr wenn gesetzt:
Ahh, wieder was gelernt!
Zitat von: docolli am 18 November 2022, 16:31:28Hilft leider auch nicht...
Dann liegt es vermutlich an der späten Werte-Verfügbarkeit. Setz in der js unter get properties() die Werte auf 0:
gridConsumeTdy: -1,
gridFeedTdy: -1,
homeConsumeTdy: -1,
pvForecast: -1,
pvProdTdy: -1,Möglicherweise werden die Texte bereits frühzeitig ausgeblendet bevor überhaupt überschrieben werden können.
Weiterhin kannst du in Zeile 391 folgendes anfügen:
this.shadowRoot.getElementById(obj).style.display = "unset";Wenn das nicht hilft brauch ich die Werte nach den pipes und einen Auszug der Web-Developer-Analyze Funktion.
Zitat von: yersinia am 18 November 2022, 16:37:29
Dann liegt es vermutlich an der späten Werte-Verfügbarkeit. Setz in der js unter get properties() die Werte auf 0:
gridConsumeTdy: -1,
gridFeedTdy: -1,
homeConsumeTdy: -1,
pvForecast: -1,
pvProdTdy: -1,
Möglicherweise werden die Texte bereits frühzeitig ausgeblendet bevor überhaupt überschrieben werden können.
Auf 0 setzen hat geholfen!
carTemp kann ich aber nicht auf 0 setzen, das kann im Winter ein gültiger Wert sein.
Zitat von: docolli am 18 November 2022, 16:48:10Auf 0 setzen hat geholfen!
Gut zu wissen. Danke fürs testen.
Kannst du noch testen, wenn du diese Werte wieder auf -1 setzt und dafür
Zitat von: yersinia am 18 November 2022, 16:37:29Weiterhin kannst du in Zeile 391 folgendes anfügen:
this.shadowRoot.getElementById(obj).style.display = "unset";
setzt?
Zitat von: yersinia am 18 November 2022, 16:49:37
Gut zu wissen. Danke fürs testen.
Kannst du noch testen, wenn du diese Werte wieder auf -1 setzt und dafürsetzt?
powerVals(val, obj, preHtml) {
// if(!isNaN(val)) { val = parseFloat(val); }
this.shadowRoot.getElementById(obj).style.display = "unset";
this.shadowRoot.getElementById(obj).innerHTML = preHtml + val;
if(this.unitSum) { this.shadowRoot.getElementById(obj).innerHTML += '<tspan class="pvvis-txt-unit-power">' + this.unitSum + '</tspan>'; }
}
Setze ich carSoc zurück auf "-1", ist die Anzeige wieder weg.
Das ist interessant. ich schau es mir mal an. Danke für die Rückmeldung.
Übergebe ich den soc jetzt als kWh und definiere ich battstep, so stimmt die rote Linie und remain time noch nicht!
Ich habe in meinem Code den kleinsten und größten Wert aus dem battstep Array ermittelt und normiere darauf.
const batStepRange = Math.max.apply(null, arrStep) - Math.min.apply(null, arrStep);
const batFillPercent = (this.soc - Math.min.apply(null, arrStep))/batStepRange;
Andere Unschönheiten siehe Bild ;)
Beim Entladen blinkt kein Segment der Batterie, wenn ich soc in Wh übergebe.
Edit: -> Ursache battstep definiert in kWh, nun übergebe ich aber Wh (!), muss also battstep="500,2000,5000,8000,12000" sein.Edit: Problem ist vermutlich, dass battmax in "Wh" übergeben wird. Ich aber die Batteriekapazität mittels unit-soc="kWh" in kWh haben will. Da passt dann die Berechnung nicht.
-> Getestet mit soc in Wh -> Stimmt! Dann ist die Anzeige in Ordnung. Ich kann mit Wh unterhalb der Batterie leben.Hmm, wie lösen wir das nun wieder? Die Einheiten von batmax und soc müssen aktuell übereinstimmen. Da die anderen Flusswerte auch in W sind, sollten wir hier auch Wh als Übergabewert fordern. Oder unit-value muss gesetzt sein, sowie unit-soc und wenn einer "W" und der andere "kWh" ist, muss letzterer intern in Wh umgerechnet werden, aber in "kWh" angezeigt.
Edit2: Ja, das Problem habe ich verursacht als ich angefangen habe mit den Werten zu rechnen. Vorher war die Einheit von soc und den anderen Werten egal, die wurden nur an passender Stelle mit oder ohne Einheit dargestellt. Sobald man rechnet, wird aber die Einheit der übergebenen Werte wichtig. Ist wie früher im Physikunterricht: Die korrekten Einheiten sind wichtiger als die Zahlen...
- Wir definieren interne Standardeinheiten für die Werte (z.B. W, Wh oder %).
- Für die Wertegruppen muss man die Einheit des übergebenen Wertes definieren (gerade bei der Übergabe des soc als relativer Wert in % oder Wh/kWh wichtig)
- Es gibt eine Funktion, welche die übergebenen Werte in die internen Standardeinheiten umrechnet.
- Man kann noch definieren, welche Ausgabeeinheit man haben will. Dann wird wieder passend umgerechnet. Hier sollte für den soc (wenn battmax definiert) auch von % in Wh/kWh bzw. von Wh/kWh in % möglich sein.
Man kann die ganze Rechnerei aber auch ganz pragmatisch ins FHEM-Device verweisen und pvvis stellt nur die Ergebnisse grafisch passend dar. ;)
Wenn ich die Parameter fix definiere, so passt die Darstellung (links). Kommen die Werte jedoch aus einem FHEM-Device, so funktioniert einiges nicht mehr wie gewünscht. Hier z.B. das "Hochschubsen" des Hausverbrauchs.
Ich habe zusätzlich in der CSS kleine Änderungen vorgenommen, mir waren die Summenwerte einfach zu groß in Relation zu den aktuellen Werten.
.pvvis-text2 {
text-anchor: start;
font-size: clamp(14px, 100%, 0.8rem);
fill: var(--pvvis-color-grey, grey);
}
Auch der Batteriewert des Autos sollte gleich groß sein, wie der Batteriewert vom Haus
#bat-val-txt,
#pvvis-car-bat-val-txt {
text-anchor: middle;
font-size: clamp(12px, 100%, 1rem);
fill: var(--pvvis-color-grey, #ccc) !important;
#pvvis-car-temp-val-txt {
text-anchor: middle;
font-size: clamp(12px, 100%, 0.8rem);
fill: var(--pvvis-color-grey, #ccc) !important;
}
Meine letzte Anregung für heute ::)
Den Füllstand des Autos farbig innerhalb des Autos anzuzeigen finde ich super cool. Nur die Farben gefallen mir noch nicht.
Könnte man den farbigen Gradienten, wie bei der Hausbatterie auch, auf den gefüllten Teil des Autos übertragen?
Wenn geladen wird, dann könnte der obere (noch nicht geladene) Teil des Autos blinken, wie bei der Hausbatterie auch.
.pvvis-batbar-blink,
.pvvis-batcar-blink {
-webkit-animation: pvvis-blink 2s infinite both;
animation: pvvis-blink 2s infinite both;
}
colorCar() {
if(this.carSoc > -1) { //add wbFeed
this.shadowRoot.getElementById("pvvis-car-bat-val-txt").innerHTML = this.carSoc.toFixed();
if(this.unitCarSoc) { this.shadowRoot.getElementById("pvvis-car-bat-val-txt").innerHTML += '<tspan class="pvvis-txt-unit-car">' + this.unitCarSoc + '</tspan>'; }
this.shadowRoot.getElementById("pvvis-car-fill-bottom").style.display = 'unset';
this.shadowRoot.getElementById("pvvis-car-fill-bottom").setAttribute("y", ("" + (100 - this.carSoc) + "%"));
this.shadowRoot.getElementById("pvvis-car-fill-top").classList.add("pvvis-batcar-blink");
}
if((this.carSoc > -1) && (this.wbFeed <= 0)) {
this.shadowRoot.getElementById("pvvis-car-fill-bottom").style.fill = 'var(--pvvis-color-yellow, #436c3a)';
this.shadowRoot.getElementById("pvvis-car-fill-top").classList.remove("pvvis-batcar-blink");
}
if((this.carSoc < 0) && (this.wbFeed > 0)) {
this.shadowRoot.getElementById("pvvis-car-fill-top").style.fill = 'var(--pvvis-color-green, #090)';
}
}
Zitat von: docolli am 18 November 2022, 17:09:49Edit2: Ja, das Problem habe ich verursacht als ich angefangen habe mit den Werten zu rechnen. Vorher war die Einheit von soc und den anderen Werten egal, die wurden nur an passender Stelle mit oder ohne Einheit dargestellt. Sobald man rechnet, wird aber die Einheit der übergebenen Werte wichtig. Ist wie früher im Physikunterricht: Die korrekten Einheiten sind wichtiger als die Zahlen...
- Wir definieren interne Standardeinheiten für die Werte (z.B. W, Wh oder %).
- Für die Wertegruppen muss man die Einheit des übergebenen Wertes definieren (gerade bei der Übergabe des soc als relativer Wert in % oder Wh/kWh wichtig)
- Es gibt eine Funktion, welche die übergebenen Werte in die internen Standardeinheiten umrechnet.
- Man kann noch definieren, welche Ausgabeeinheit man haben will. Dann wird wieder passend umgerechnet. Hier sollte für den soc (wenn battmax definiert) auch von % in Wh/kWh bzw. von Wh/kWh in % möglich sein.
Man kann die ganze Rechnerei aber auch ganz pragmatisch ins FHEM-Device verweisen und pvvis stellt nur die Ergebnisse grafisch passend dar. ;)
Ich möchte eigentlich nicht auf pvvis-Seite noch großartig umrechnen - ich weiss nicht, welche Anlagen die User haben. Von daher sollte es, wenn pvvis rechnet, einheitliche Einheiten sein: soc, battstep und battmax müssen gleich sein wenn alle Wh nutzen; egal ob mWh, kWh oder GWh. soc und battstep haben eine direkte Beziehung zur Anzeige des Füllstands - beide brauche gleiche Einheiten, egal ob % oder xWh oder nüsse oder broteinheiten. battmax bezieht sich auf die Rechnung - also auch des ladeparameters [charge-discharge]: wenn du in Wh lädst, muss battmax auch in Wh angegeben werden.
Die loadfloaws und alle Anzeige dazu müssen mit pvmax harmonieren. Bisher ging ich von Wh aus (oder sowas ähnliches), demnach muss auch dies alles in einer Einheit geführt werden.
Die Summenwerte werden nur angezeigt, also weitergereicht.
car-soc ist ebenso nur ein Prozentwert.
pvvis zeigt ja nur an, also ja, die Werte entsprechend in FHEM oder via pipe vorbereiten.
Zitat von: docolli am 19 November 2022, 09:32:31Wenn ich die Parameter fix definiere, so passt die Darstellung (links). Kommen die Werte jedoch aus einem FHEM-Device, so funktioniert einiges nicht mehr wie gewünscht. Hier z.B. das "Hochschubsen" des Hausverbrauchs.
Ich denke, ich hab es etwas zu kompliziert versucht. Ich wollte auch alle nicht benötigten Texte ausblenden, dies ist aber wohlmöglich nicht nötig.
Zitat von: docolli am 19 November 2022, 09:32:31Ich habe zusätzlich in der CSS kleine Änderungen vorgenommen, mir waren die Summenwerte einfach zu groß in Relation zu den aktuellen Werten.
Auch der Batteriewert des Autos sollte gleich groß sein, wie der Batteriewert vom Haus
Danke, an vernünftige Textgrößen müssen wir uns erst noch rantesten, insbesondere weiss ich nicht, was für Werte zu erwarten sind.
Zitat von: docolli am 19 November 2022, 10:04:50Meine letzte Anregung für heute ::)
Sicher? ;D
Zitat von: docolli am 19 November 2022, 10:04:50Den Füllstand des Autos farbig innerhalb des Autos anzuzeigen finde ich super cool. Nur die Farben gefallen mir noch nicht.
Könnte man den farbigen Gradienten, wie bei der Hausbatterie auch, auf den gefüllten Teil des Autos übertragen?
Keine schlechte Idee - aber den Teil dann grau blinken lassen? ich weiss nicht, dann doch lieber grün?
Insgesamt war das eine Spielerei mit dem Auto und dem Füllstand. Mir ist das aber noch nicht genau genug. Bei 75% ist das Auto fast ausgefüllt, das ist visuell irgendwie komisch. Das liegt aber an der Art und Weise, wie die rechtecke drübergelegt werden.
Mal schauen, vielleicht fällt mir noch was dazu ein. Oder dir. ;D
Anbei ein neuer Wurf mit deinen Änderungen (nochmals VIELEN DANK fürs Testen und das konstruktive Feedback!).
Nachdem wir wirklich nicht wissen können, welche Einheiten die user anliefern, wird das mit dem Umrechnen in pvvis nichts. Das sehe ich ein. Sowas muss dann ins FHEM-Device / pipe ausgelagert werden. Wichtig für die Doku von pvvis ist, das diese Zusammenhänge klar kommuniziert werden, also welche Werte in identischen Einheiten übergeben werden müssen.
Ich werde deine neue Version nachher noch testen. Mir ist auch aufgefallen, dass der Füllstand des Autos sich komisch verhält. Ich hätte da einen Vorschlag ::)
Das Auto im SVG Code besser auf x=0/y=0 positionieren.
<defs>
<clipPath id="pvvis-car-template">
<path d="m501.4 112h-60l-17-42c-17-43-58-70-104-70h-127c-46 0-87 28-104 70l-17 42h-60c-7.8 0-14 7.3-12 15l6 24c1.3 5.3 6.1 9.1 12 9.1h20c-13 12-22 29-22 48v48c0 16 6.2 31 16 42v54c0 18 14 32 32 32h32c18 0 32-14 32-32v-32h256v32c0 18 14 32 32 32h32c18 0 32-14 32-32v-54c9.8-11 16-26 16-42v-48c0-19-8.6-36-22-48h20c5.5 0 10-3.8 12-9.1l6-24c1.9-7.6-3.8-15-12-15zm-352-18c7.3-18 25-30 45-30h127c20 0 37 12 45 30l20 50h-256zm-52 162c-19 0-32-13-32-32s13-32 32-32c19 0 48 29 48 48s-29 16-48 16zm320 0c-19 0-48 3.2-48-16s29-48 48-48 32 13 32 32-13 32-32 32z"/>
</clipPath>
</defs>
Es muss dadurch etwas anders positioniert werden
.pvvis-car {
transform: translate(6px, 316px) scale(0.16);
}
Trotzdem sind es von unten bis ganz oben gefüllt nur 95% und nicht 100%. Somit muss der Code, der den Füllstand aus carSoc berechnet etwas angepasst werden. Zusätzlich habe ich eine etwas andere Füllfarbe gewählt, das ist aber Geschmackssache.
colorCar() {
if(this.carSoc > -1) { //add wbFeed
this.shadowRoot.getElementById("pvvis-car-bat-val-txt").innerHTML = this.carSoc.toFixed();
if(this.unitCarSoc) { this.shadowRoot.getElementById("pvvis-car-bat-val-txt").innerHTML += '<tspan class="pvvis-txt-unit-car">' + this.unitCarSoc + '</tspan>'; }
this.shadowRoot.getElementById("pvvis-car-fill-bottom").style.display = 'unset';
this.shadowRoot.getElementById("pvvis-car-fill-bottom").setAttribute("y", ("" + (95 - this.carSoc*0.95) + "%"));
this.shadowRoot.getElementById("pvvis-car-fill-top").classList.add("pvvis-batcar-blink");
}
if((this.carSoc > -1) && (this.wbFeed <= 0)) {
this.shadowRoot.getElementById("pvvis-car-fill-bottom").style.fill = 'var(--pvvis-color-yellow, #436c3a)';
this.shadowRoot.getElementById("pvvis-car-fill-top").classList.remove("pvvis-batcar-blink");
}
if((this.carSoc < 0) && (this.wbFeed > 0)) {
this.shadowRoot.getElementById("pvvis-car-fill-top").style.fill = 'var(--pvvis-color-green, #090)';
}
}
So, jetzt hoffe ich ich habe Dir alle relevanten Änderungen mitgeteilt. Du siehst im Bild, das bei 2% grad so die Reifen grün werden und bei 98% nur noch ein bisschen Dach grau bleibt.
Aber du hast Recht, das sollte dann auch hell/dunkegrün blinken. Konsequenterweise müsste man sich an der anderen Batterie orientieren. Eigentlich müsste ums Auto auch ein Rahmen, der grau oder grün wird, aber ich bin ja schon still.... :-X ;D
Hi @yersinia,
hier für Dich mal realistische Werte für die einzelnen PV Parameter.
Hausanlage
ich habe 12,5kWp auf dem Dach, verteilt in SO und NW Ausrichtung, somit erzeuge ich Mittags nicht so brutal viel Überschusstrom, sondern die Erzeugung verteilt sich breiter über den Tag. Zusätzlich steht ein guter 10kWh Speicher im Keller, der auch ordentlich Leistung aufnehmen und abgeben kann.
Hier mal typische Werte für einen Sonnentag:
produce = max. 9000W, kurze Spitzen bis 12000W möglich (also bis zu 5stellig)
charge/discharge = max. 4500W (der Akku hat ordentlich Leistung) (max. 4stellig)
soc = 0-100% bzw. 0 bis 13000Wh (Vollausbau Akkuspeicher) (bis zu 5 stellig)
wb-feed = max. 11000W (Standard 3phasige Wallbox), es gibt aber auch welche mit 22000W für Zuhause (bis zu 5 stellig)
feed-receive = [Hausverbrauch] (4-5 stellig) + [wb-feed] (bis zu 5 stellig)
pv-prod-tdy = bis zu 80 kWh an einem sehr sonnigen, langen Tag (1 Nachkommastelle reicht)
pv-forecast = bis zu 80 kWh an einem sehr sonnigen, langen Tag (1 Nachkommastelle reicht)
home-consume-tdy = typ. 10-15kWh, aber wenn E-Auto lädt (und jemach noch eine WP hat), dann kann es durchaus ~100kWh sein
grid-consume-tdy = kann bis zu max. home-consume-tdy sein, also 100kWh (3 Nachkommastellen, da es sein kann, man bezieht nur wenig [z.B. 20W] pro Tag)
grid-feed-tdy = kann bis zu max. pv-prod-tdy, also 80kWh (3 Nachkommastellen, da es sein kann, man speist nur wenig [z.B. 20W] pro Tag ein)
Industrieanlage
Unsere Firma hat das komplette Hallendach voll PV, da geht schon was anderes, zusätzlich verbrauchen die Maschinen viel.
produce = bis zu 5stellig
charge/discharge = max. 7500W (3x Akku á 2500W) (max. 4stellig)
soc = 0-100% bzw. 0 bis 30000Wh (bis zu 5 stellig)
feed-receive = [Hausverbrauch] (4-5 stellig)
pv-prod-tdy = bis zu 500 kWh an einem sehr sonnigen, langen Tag (1 Nachkommastelle reicht)
pv-forecast = bis zu 500 kWh an einem sehr sonnigen, langen Tag (1 Nachkommastelle reicht)
home-consume-tdy = typ. 300-600kWh,
grid-consume-tdy =kann bis zu max. home-consume-tdy sein, also 600kWh (3 Nachkommastellen, da es sein kann, man bezieht nur wenig [z.B. 20W] pro Tag)
grid-feed-tdy = kann bis zu max. pv-prod-tdy sein, also 5stellig (3 Nachkommastellen, da es sein kann, man speist nur wenig [z.B. 20W] pro Tag ein)
Ich habe noch einen Fehler gefunden. Der geht vermutlich auf meine Kappe, das hatte ich meinem Code auch schon mal verwechselt und vermutlich hier so veröffentlicht. ::)
Die Werte für gridFeedTdy und gridConsumeTdy sind vertauscht und passen nicht zur Logik der Pfeile. Bitte abändern:
case 'grid-feed-tdy':
this.powerVals(this.gridFeedTdy.toFixed(3), "pvvis-grid-out-today-txt", "⟸ ∑ ");
break;
case 'grid-consume-tdy':
this.powerVals(this.gridConsumeTdy.toFixed(3), "pvvis-grid-in-today-txt", "⟹ ∑ ");
break;
Moin,
test gerade euere neuen Versionen.
Was muss ich als Parameter außer "calc-bat-remain-time" noch angeben damit bei der Batterie nich 0.0h steht.
Grüße
Olli
Servus!
du musst battmax (=Kapazität deiner Batterie) angeben. Bitte in der gleichen Grundeinheit wie die Leistungen. In deinem Fall in Wh.
Dann sollte es passen. Wenn nicht, bitte pvvis Definition hier reinstellen.
Grüße,
Olli
Ist so angegeben...
<ftui-pvvis
[feed]="Energie_PV_WR1:urPVEinspeisungAktuellInWatt"
[produce]="Energie_PV_WR1:urP_PV"
[receive]="Energie_PV_WR1:urStrombezugAktuellInWatt"
[soc]="Energie_PV_WR1:Storage_0_Controller_StateOfCharge_Relative"
[charge-discharge]="Energie_PV_WR1:urP_Akku_reverse"
[pv-prod-tdy]="Energie_PV_Erzeugung:Tag"
[home-consume-tdy]="Energie_Stromgesamtverbrauch:Tag"
[grid-feed-tdy]="Energie_Stromeinspeisung:Tag"
[grid-consume-tdy]="Energie_Strombezug:Tag"
has-no-wallbox
do-not-show-zero
calc-bat-remain-time
batmax="11059"
pvmax="19050"
sun-icon="sun"
unit-soc="%"
unit-value="W"
unit-sum="kWh"
grid-icon="pylon2"
width="49vh"
class="size-3">
</ftui-pvvis>
Sollte so von der Definition her passen. Muss was im Code sein. Ich kann es nachstellen, sehe aber den Grund noch nicht.
Melde mich später nochmals!
Zitat von: docolli am 20 November 2022, 12:36:46
Sollte so von der Definition her passen. Muss was im Code sein. Ich kann es nachstellen, sehe aber den Grund noch nicht.
Melde mich später nochmals!
Alles klar, danke!
Tippfehler Deinerseits! ;D
battmax, nicht batmax...
@yersinia: Vielleicht sollten wir den Namen battmax nochmals überdenken.
Zitat von: docolli am 20 November 2022, 13:43:17
Tippfehler Deinerseits! ;D
battmax, nicht batmax...
Oh ja, hast recht, sorry dafür.
Aber sollte dann der Parameter "calc-bat-remain-time" nicht auch dann in "calc-batt-remain-time" umbenannt werden, damit das einheitlich wird?
LG
Yep. Siehe mein Edit im vorigen Post. Müssen wir wirklich einheitlich gestalten.
Danke!
Zitat von: docolli am 20 November 2022, 13:50:27
Yep. Siehe mein Edit im vorigen Post. Müssen wir wirklich einheitlich gestalten.
Danke!
Ich möchte nochmal ein Lob hier aussprechen, eine super Arbeit die Ihr hier leistet!
Danke dafür.
LG
Olli
Könnte noch die Möglichkeit eingebaut werden, die Tagessummen für PV und Hausverbrauch auch mit drei Nachkommastellen wie bei Netz-Bezug und Netz-Einspeisung einzustellen?
Funktioniert irgendwie nicht mit | fix(3)
Die Zahl der Nachkommastellen ist aktuell fix im Code hinterlegt.
Brauchst du die Werte wirklich bis auf Wh genau? ::)
Bei Einspeisung/Bezug habe ich mich für 3 Stellen entschieden, da man im Sommer/Winter ja wirklich nur wenige Wattstunden haben kann. Bei den anderen ist 1 Nachkommastelle 100Wh. So genau muss man erstmal aufsummieren können. ;D
@yersinia: Ich habe mir mal den Code für die label component angesehen und bemerkt, dass dort noch value beim Aufruf benutzt wird.
Wir sollten den Code für "onAttributeChanged" daher folgendermaßen umbauen, hier mal als Beispiel für das ein case statement:
onAttributeChanged(name, value) {
switch (name) {
case 'car-temp':
this.shadowRoot.getElementById("pvvis-car-temp-val-txt").style.display = "unset";
this.shadowRoot.getElementById("pvvis-car-temp-val-txt").innerHTML = value + '<tspan class="pvvis-txt-unit">°C</tspan>';
break;
.....
case 'grid-feed-tdy':
this.powerVals(value, "pvvis-grid-out-today-txt", "⟸ ∑ ");
break;
case 'grid-consume-tdy':
this.powerVals(value, "pvvis-grid-in-today-txt", "⟹ ∑ ");
break;
case 'home-consume-tdy':
if(!this.hasNoWallbox) {
this.shadowRoot.getElementById("home-consume-txt").setAttribute("y", "130");
}
this.powerVals(value, "pvvis-home-consumedtoday-txt", "∑ ");
break;
case 'produce':
this.calcProduce();
this.calcSunOpacity();
break;
case 'pv-forecast':
this.powerVals(value, "pvvis-pv-forecast-txt", "↗ ");
break;
case 'pv-prod-tdy':
this.powerVals(value, "pvvis-pv-producedtoday-txt", "∑ ");
break;
.....
Überall, wo this.carTemp im ersten case Verwendung findet, muss man einfach value verwenden. Dann klappt es auch mit der Formatierung.
Vermutlich wäre es auch besser in jedem case das value in der aufgerufenen Funktion zu übergeben anstatt in der Funktion per this.xxx darauf zuzugreifen. Ich bin aber beileibe kein Javascript Experte. ;)
Das sollte so wirklich klappen. Siehe Bild, das sind zwei pvvis Definitionen nebeneinander mit unterschiedlichen fix()-Werten in den pipes. Geht sogar bei der Auto-Temperatur 8)
onAttributeChanged(name, value) {
switch (name) {
case 'car-soc':
this.shadowRoot.getElementById("pvvis-car-bat-val-txt").style.display = "unset";
this.colorCar();
break;
case 'car-temp':
this.shadowRoot.getElementById("pvvis-car-temp-val-txt").style.display = "unset";
this.shadowRoot.getElementById("pvvis-car-temp-val-txt").innerHTML = value + '<tspan class="pvvis-txt-unit">°C</tspan>';
break;
case 'charge':
this.flowValue(value, "pv-bat");
this.socValue();
this.calcProduce();
this.colorBat();
break;
case 'charge-discharge':
// one reading - negative when discharge; positive when charge
if(value < 0) {
this.discharge = Math.abs(value);
this.charge = 0;
} else if(value > 0) {
this.charge = value;
this.discharge = 0;
} else {
this.charge = 0;
this.discharge = 0;
}
break;
case 'discharge':
this.flowValue(value, "bat-home");
this.socValue();
this.colorBat();
this.calcHouseConsume();
break;
case 'feed':
this.flowValue(value, "pv-grid");
this.calcProduce();
this.colorGrid();
break;
case 'feed-receive':
// one reading - negative when consume; positive when feed
if(value > 0) {
this.feed = value;
this.receive = 0;
} else if(value < 0) {
this.receive = Math.abs(value);
this.feed = 0;
} else {
this.feed = 0;
this.receive = 0;
}
break;
case 'grid-charge':
this.flowValue(value, "grid-bat");
this.socValue();
this.calcProduce();
this.colorBat();
break;
case 'grid-feed-tdy':
this.powerVals(value, "pvvis-grid-out-today-txt", "⟸ ∑ ");
break;
case 'grid-consume-tdy':
this.powerVals(value, "pvvis-grid-in-today-txt", "⟹ ∑ ");
break;
case 'home-consume-tdy':
if(!this.hasNoWallbox) {
this.shadowRoot.getElementById("home-consume-txt").setAttribute("y", "130");
}
this.powerVals(value, "pvvis-home-consumedtoday-txt", "∑ ");
break;
case 'produce':
this.calcProduce();
this.calcSunOpacity();
break;
case 'pv-forecast':
this.powerVals(value, "pvvis-pv-forecast-txt", "↗ ");
break;
case 'pv-prod-tdy':
this.powerVals(value, "pvvis-pv-producedtoday-txt", "∑ ");
break;
case 'receive':
this.flowValue(value, "grid-home");
this.colorGrid();
this.calcHouseConsume();
break;
case 'soc':
this.socValue();
this.colorBat();
break;
case 'wb-feed':
this.flowValue(value, "home-car");
this.colorCar();
break;
}
}
Danke docolli für die ganze Vorarbeit und Recherche - ich habe eigtl alles an Code so übernommen. Und in diesem Zuge auch battmax zu batmax sowie battstep zu batstep umbenannt; das folgt eher der Battery Abkürzung.
Weiterhin habe ich die toFixed() aus der Übergabe im Zuge der Umstellung auf value rausgenommen. Die Nachkommstellen usw sollen via reading/pipe kommen, das soll und kann der user selbst entscheiden.
Neue Version anhängend.
Danke, hab ich gerne gemacht! Ich wäre auch auf "bat" anstatt "batt" gegangen, das wollte ich aber Dir überlassen. Sind wir uns also einig. 8)
Bin schon am testen, dabei fälllt mir noch folgendes auf.
1) Hier muss noch mehr mit "value" ersetzt werden (habe ich hier schon gemacht):
case 'charge-discharge':
// one reading - negative when discharge; positive when charge
if(value < 0) {
this.discharge = Math.abs(value);
this.charge = 0;
} else if(value > 0) {
this.charge = value;
this.discharge = 0;
} else {
this.charge = 0;
this.discharge = 0;
}
break;
case 'feed-receive':
// one reading - negative when consume; positive when feed
if(this.value > 0) {
this.feed = value;
this.receive = 0;
} else if(value < 0) {
this.receive = Math.abs(value);
this.feed = 0;
} else {
this.feed = 0;
this.receive = 0;
}
break;
2) Hier muss noch eine Zeile rein, damit der Wagen (pvvis-car-fill-bottom) beim Laden auch grün wird.
colorCar() {
if(this.carSoc >= 0) {
this.shadowRoot.getElementById("pvvis-car-bat-val-txt").innerHTML = this.carSoc.toFixed();
if(this.unitCarSoc) { this.shadowRoot.getElementById("pvvis-car-bat-val-txt").innerHTML += '<tspan class="pvvis-txt-unit-car">' + this.unitCarSoc + '</tspan>'; }
this.shadowRoot.getElementById("pvvis-car-fill-bottom").style.display = 'unset';
this.shadowRoot.getElementById("pvvis-car-fill-bottom").setAttribute("y", ("" + (95 - this.carSoc*0.95) + "%"));
this.shadowRoot.getElementById("pvvis-car-fill-bottom").style.fill = 'var(--pvvis-color-green, #090)';
this.shadowRoot.getElementById("pvvis-car-fill-top").style.fill = 'var(--pvvis-color-green, #090)';
this.shadowRoot.getElementById("pvvis-car-fill-top").classList.add("pvvis-batcar-blink");
}
if((this.carSoc > -1) && (this.wbFeed <= 0)) {
this.shadowRoot.getElementById("pvvis-car-fill-bottom").style.fill = 'var(--pvvis-color-yellow, yellow)';
this.shadowRoot.getElementById("pvvis-car-fill-top").style.fill = 'var(--pvvis-color-grey, grey)';
this.shadowRoot.getElementById("pvvis-car-fill-top").classList.remove("pvvis-batcar-blink");
}
if((this.carSoc < 0) && (this.wbFeed > 0)) {
this.shadowRoot.getElementById("pvvis-car-fill-top").style.fill = 'var(--pvvis-color-green, #090)';
}
}
Zitat von: docolli am 20 November 2022, 21:09:15Danke, hab ich gerne gemacht! Ich wäre auch auf "bat" anstatt "batt" gegangen, das wollte ich aber Dir überlassen. Sind wir uns also einig. 8)
8)
Zitat von: docolli am 20 November 2022, 21:09:15Bin schon am testen, dabei fälllt mir noch folgendes auf.
Das hab ich glatt übersehen, neue Version hängt dann an. Ich lass value für den numerischen Vergleich aber vorher noch in float umwandeln, sicher ist sicher.
Zitat von: docolli am 20 November 2022, 21:09:152) Hier muss noch eine Zeile rein, damit der Wagen (pvvis-car-fill-bottom) beim Laden auch grün wird.
Das müsste aus der css via
#pvvis-car-fill-bottom schon kommen.
#pvvis-car-fill-bottom {
fill: var(--pvvis-color-green, #090);
display: none;
}
Zitat von: yersinia am 20 November 2022, 21:25:56
Das müsste aus der css via #pvvis-car-fill-bottom schon kommen.
#pvvis-car-fill-bottom {
fill: var(--pvvis-color-green, #090);
display: none;
}
Ja, aber wenn das Auto gelb ist und ich zu laden anfange, ist es bei mir heute unten gelb geblieben und hat oben grün geblinkt.
Ich kann es grad nicht mehr testen. Morgen mehr!
Zitat von: docolli am 20 November 2022, 21:34:42Ja, aber wenn das Auto gelb ist und ich zu laden anfange, ist es bei mir heute unten gelb geblieben und hat oben grün geblinkt.
Guter Punkt, das kann durchaus sein. Der style wird ja nicht mehr überschrieben; und inline-CSS überschreibt id/class css. Hab das in #222 (https://forum.fhem.de/index.php/topic,119440.msg1246690.html#msg1246690) aktualisiert.
Zitat von: yersinia am 20 November 2022, 20:07:38
Danke docolli für die ganze Vorarbeit und Recherche - ich habe eigtl alles an Code so übernommen. Und in diesem Zuge auch battmax zu batmax sowie battstep[/b] zu batstep umbenannt; das folgt eher der Battery Abkürzung.
Weiterhin habe ich die toFixed() aus der Übergabe im Zuge der Umstellung auf value rausgenommen. Die Nachkommstellen usw sollen via reading/pipe kommen, das soll und kann der user selbst entscheiden.
Neue Version anhängend.
Hallo yersinia,
ich versuche die schöne Ansicht mit meiner TESLA Powerwall in Betrieb zu nehmen. Aber leider ist [charge-discharge] Wert bei mir genau anderes rum. Positiv wenn die Batterie entladen wird und negativ wenn geladen wird.
Kann ich das irgendwie anpassen?
vg
Tim
Zitat von: HoTi am 21 November 2022, 15:47:04Aber leider ist [charge-discharge] Wert bei mir genau anderes rum. Positiv wenn die Batterie entladen wird und negativ wenn geladen wird.
Kann ich das irgendwie anpassen?
Ja, mit der multiply(-1) pipe
[charge-discharge]="DEVICE:READING | multiply(-1)"oder userReading in FHEM.
Das hier passt meiner Meinung nach noch nicht. grid-consume ist das was man aus dem Netz holt. Das sollte doch auf das Textfeld pvvis-grid-in-today-txt und mit einem Pfeil nach rechts versehen werden. Und umgekehrt.
case 'grid-consume-tdy':
this.powerVals(value, "pvvis-grid-out-today-txt", "⟹ ∑ ");
break;
case 'grid-feed-tdy':
this.powerVals(value, "pvvis-grid-in-today-txt", "⟸ ∑ ");
break;
Hier mein Code Vorschlag
case 'grid-consume-tdy':
this.powerVals(value, "pvvis-grid-in-today-txt", "⟹ ∑ ");
break;
case 'grid-feed-tdy':
this.powerVals(value, "pvvis-grid-out-today-txt", "⟸ ∑ ");
break;
Auto Icon kann ich nicht testen. Das Auto ist unterwegs...
Hi zusammen,
könnte man (siehe Bild) die Schrift hier nochmal zentrieren?
Vermutlich liegt es am SVG Icon.
Ansonsten ist die Komponente schon ziemlich perfekt für mich.
Nochmals tolle Arbeit von euch hier!
LG
Olli
Im SVG auf x=50 setzen:
<text id="pvvis-home-consumedtoday-txt" x="50" y="153" class="pvvis-text2"></text>
Im CSS zentriert:
#pvvis-home-consumedtoday-txt{
text-anchor: middle;
}
Zitat von: docolli am 21 November 2022, 20:31:38
Im SVG auf x=50 setzen:
<text id="pvvis-home-consumedtoday-txt" x="50" y="153" class="pvvis-text2"></text>
Im CSS zentriert:
#pvvis-home-consumedtoday-txt{
text-anchor: middle;
}
Moin,
die CSS Anpassung haut nicht hin (wird komplett nach links versetzt), aber die x= Anpassung mit js klappt.
Danke für Deine schnelle Antwort!
Musst ja auch beides machen ;D ;D
CSS macht es zentriert, damit muss x im SVG auf die Mitte vom Haus verschoben werden.
Ah ja, der Feinschliff. Danke für die Rückmeldungen und Vorschläge - ich hab das weitestgehend übernommen.
Zitat von: docolli am 21 November 2022, 18:53:57Das hier passt meiner Meinung nach noch nicht. grid-consume ist das was man aus dem Netz holt. Das sollte doch auf das Textfeld pvvis-grid-in-today-txt und mit einem Pfeil nach rechts versehen werden. Und umgekehrt.
Ja, irgendwie hab ich das vertauscht. Ich fand das auch visuell noch Verbesserungswürdig. Anbei ein Vorschlag und die Textfelder sind getauscht - feed nach unten und consume nach oben. Zudem fand ich andere Pfeile und koloriert einfach intuitiver. Meinung? Zu verspielt?
Zitat von: yersinia am 22 November 2022, 08:16:30
Ah ja, der Feinschliff. Danke für die Rückmeldungen und Vorschläge - ich hab das weitestgehend übernommen.
Ja, irgendwie hab ich das vertauscht. Ich fand das auch visuell noch Verbesserungswürdig. Anbei ein Vorschlag und die Textfelder sind getauscht - feed nach unten und consume nach oben. Zudem fand ich andere Pfeile und koloriert einfach intuitiver. Meinung? Zu verspielt?
Moin,
ich fand die Pfeile wie sie vorher waren besser (also Richtung Pylon bzw. vom Pylon weg).
Hoch/Runter gefällt mir nicht so.
Die Farben können von mir aus rot und grün sein, bräuchte ich aber nicht umbeding.
LG
Olli
Ja, hurra, wenn wir uns nur noch um solche Kleinigkeiten kümmern müssen, sind wir weit gekommen! 8)
Ich fand auch die Pfeile von und zum Pylon hin intuitiver. ;)
Farbe habe ich mir auch schon überlegt, das gefällt mir.
Ich würde aber, wenn Farbe, die Einspeisung grün machen und den Bezug rot.
Mir persönlich ist die Einspeisung wichtiger als Bezug, darum habe ich Einspeisung oben und Bezug unten gewählt.
Aber auch hier gerne andere Meinungen.
Mmh, also ist Pfeil zum Pylon (nach links) automatisch feed; vom Pylon weg (nach rechts) consume? Ist das intuitiv genug?
Nach oben/unten würde dem flow folgen.
So gefällt es mir. Aber andere Meinung ist willkommen.
Wenn wir schon an den Kleinigkeiten sind: Die gelbe Autofarbe, die den Füllstand anzeigt, wenn keine Ladung erfolgt, ist mir optisch zu "mächtig". Das Auto zieht so die gesamten visuelle Aufmerksamkeit auf sich. Aber das Auto ist doch nicht der Star von pvvis, sondern der Flow.
Ok. :)
Zitat von: docolli am 22 November 2022, 08:42:35Die gelbe Autofarbe, die den Füllstand anzeigt, wenn keine Ladung erfolgt, ist mir optisch zu "mächtig". Das Auto zieht so die gesamten visuelle Aufmerksamkeit auf sich.
Was schwebt dir denn vor? Die opacity/Deckkraft reduzieren? Eine andere Farbe (https://htmlcolorcodes.com/)?
Edit: ich denke ein
opacity: 0.6;könnte das Gelb etwas entschärfen.
Ich denke einfach eine andere Farbe: #aa0
Edit: Grundsätzlich sollte es so "stumpf" sein, wie das Rot der Batterie. Die springt einem auch nicht so ins Auge. Klar, auch weil der Rand so dünn ist im Gegensatz zum massiv gefüllten Auto.
Bei Opacity kommt halt die andere Farbe im Hintergrund (in dem Fall das Grau des Autos) mit ins Spiel. Hier würde ich dann sogar auf 0.5 bis 0.4 runter gehen.
Im ersten Fall hätte man die Farbe absolut definiert.
Zitat von: yersinia am 22 November 2022, 08:37:26
Mmh, also ist Pfeil zum Pylon (nach links) automatisch feed; vom Pylon weg (nach rechts) consume? Ist das intuitiv genug?
Nach oben/unten würde dem flow folgen.
Finde ich gut so.
VG
Zitat von: docolli am 22 November 2022, 09:04:53Grundsätzlich sollte es so "stumpf" sein, wie das Rot der Batterie. Die springt einem auch nicht so ins Auge. Klar, auch weil der Rand so dünn ist im Gegensatz zum massiv gefüllten Auto.
Bei Opacity kommt halt die andere Farbe im Hintergrund (in dem Fall das Grau des Autos) mit ins Spiel. Hier würde ich dann sogar auf 0.5 bis 0.4 runter gehen.
Im ersten Fall hätte man die Farbe absolut definiert.
Als Vorschlag belassen wir es bei yellow, nehmen aber eine Deckung von 0.5. In diesem Zug habe ich größtenteils von inline-CSS auf class umgestellt; soweit ich das Testen konnte, passt dies.
Die Pfeile habe ich auch zurückgedreht und eingefärbt. Die Positionierungskorrekturen sind auch eingepflegt.
Aktualisierte Version in #222 (https://forum.fhem.de/index.php/topic,119440.msg1246690.html#msg1246690).
Zitat von: yersinia am 22 November 2022, 10:06:10
Als Vorschlag belassen wir es bei yellow, nehmen aber eine Deckung von 0.5. In diesem Zug habe ich größtenteils von inline-CSS auf class umgestellt; soweit ich das Testen konnte, passt dies.
Die Pfeile habe ich auch zurückgedreht und eingefärbt. Die Positionierungskorrekturen sind auch eingepflegt.
Aktualisierte Version in #222 (https://forum.fhem.de/index.php/topic,119440.msg1246690.html#msg1246690).
Sieht soweit gut aus.
Ich würde lediglich noch x="47" bei "home-consume-txt" in der js anpssen.
Ist meiner Meinung nach mit 50 nicht ganz mittig unter dem Häuschen.
Zitat von: octek0815 am 22 November 2022, 10:17:52
Sieht soweit gut aus.
Ich würde lediglich noch x="47" bei "home-consume-txt" in der js anpssen.
Ist meiner Meinung nach mit 50 nicht ganz mittig unter dem Häuschen.
Stimme zu, habe mich an der Ausrichtung am Hausverbrauchstextfeld mit x=50 orientiert, aber wenn man genau schaut, ist auch der nicht ganz 100%ig mittig zum Haus.
Also auch "home-consume-txt" ändern, ich würde aber x=48 vorschlagen. ::)
Siehe Bild, y habe ich testweise so gesetzt, dass man besser mit dem Haus vergleichen kann.
Ansonsten: Klasse und vielen Dank ;D
Ich hab die Werte für alle Texte in der Spalte (home-consume, home-consume-tdy, car-soc und car-temp) auf 48 gesetzt. Kommt mit dem nächstem update.
Ich sags ja, Feinschliff :)
Mit dem nächsten Feinschliff bitte car-soc y-Wert auch etwas anpassen (Abstand zum Auto wie soc-Wert Abstand zur Hausbatterie):
<text id="pvvis-car-bat-val-txt" y="383" x="48">
Edit: Aha ja, wenn has-no-wallbox gesetzt ist, sollten die car-temp und car-soc Werte auch ausgeblendet werden. Klar, dann sollte man car-soc und car-temp auch nicht definert haben, aber... ::)
Wenn der Akku neutral ist, dann bitte die Restzeit ausblenden.
Zitat von: docolli am 23 November 2022, 07:42:59
Wenn der Akku neutral ist, dann bitte die Restzeit ausblenden.
Moin,
hätte auch noch was...
Könnte bitte der Abstand Restkapazität (% / Wh) gleich gesetzt werden wie beim Hausverbrauch (siehe Bild).
Danke und Grüße
Olli
Zitat von: docolli am 23 November 2022, 07:42:59Wenn der Akku neutral ist, dann bitte die Restzeit ausblenden.
Kommt mit dem nächsten Update.
Zitat von: octek0815 am 23 November 2022, 07:48:32Könnte bitte der Abstand Restkapazität (% / Wh) gleich gesetzt werden wie beim Hausverbrauch (siehe Bild).
Finde ich schwierig, da sich die Abstände mit veränderbarer Schriftgröße dynamisch ändern. Ich könnte den bat-val-txt auf y=256 setzen, das würde diesen text
etwas nach unten schieben.
Edit: aktualisierte Version in #222 (https://forum.fhem.de/index.php/topic,119440.msg1246690.html#msg1246690).
Von meinem PV-System her kenne ich die Begriffe (und Werte) von Eigenverbrauch und Autarkie. Wenn die Tagessummen übergeben werden, könnten diese Kennzahlen leicht berechnet und dargestellt werden.
Eigenverbrauch:
Das ist der Anteil des produzierten Stroms, der bislang selber verbraucht (direkt oder in den Akku gespeichert) wurde. Bei einem Eigenverbrauch von 100% wurde nichts ins Netz eingespeist.
Autarkie:
Das ist der Anteil des verbrauchten Stroms (Haus und Wallbox), der bislang nicht aus dem Netz bezogen werden musste, also entweder von der PV oder dem Akku kam. Bei einer Autarkie von 100% wurde nichts aus dem Netz bezogen.
Hätte noch jemand Interesse, dass pvvis diese Kennzahlen aus den vorhandenen Werten berechnet und darstellt?
Zitat von: docolli am 24 November 2022, 18:42:18
Von meinem PV-System her kenne ich die Begriffe (und Werte) von Eigenverbrauch und Autarkie. Wenn die Tagessummen übergeben werden, könnten diese Kennzahlen leicht berechnet und dargestellt werden.
Eigenverbrauch:
Das ist der Anteil des produzierten Stroms, der bislang selber verbraucht (direkt oder in den Akku gespeichert) wurde. Bei einem Eigenverbrauch von 100% wurde nichts ins Netz eingespeist.
Autarkie:
Das ist der Anteil des verbrauchten Stroms (Haus und Wallbox), der bislang nicht aus dem Netz bezogen werden musste, also entweder von der PV oder dem Akku kam. Bei einer Autarkie von 100% wurde nichts aus dem Netz bezogen.
Hätte noch jemand Interesse, dass pvvis diese Kennzahlen aus den vorhandenen Werten berechnet und darstellt?
Immer her damit..
Zitat von: docolli am 24 November 2022, 18:42:18Eigenverbrauch:
Das ist der Anteil des produzierten Stroms, der bislang selber verbraucht (direkt oder in den Akku gespeichert) wurde. Bei einem Eigenverbrauch von 100% wurde nichts ins Netz eingespeist.
Autarkie:
Das ist der Anteil des verbrauchten Stroms (Haus und Wallbox), der bislang nicht aus dem Netz bezogen werden musste, also entweder von der PV oder dem Akku kam. Bei einer Autarkie von 100% wurde nichts aus dem Netz bezogen.
...dies kann man aber bereits jetzt schon aus den gegebenen Werten/Darstellung ab/herleiten: die Einspeisung im Netz wird bereits angezeigt, wenn dieser 0 ist, ist wohl der Eigenverbrauch sehr nah bei 100%. Analog zum Bezug aus dem Netz: ist dieser nahe 0, ist die Autarkie wohl ebenso nahe 100%. Zumindest interpretiere ich dies so.
Bedarf es denn hier überhaupt zwei weiterer Anzeigen, die das dann auch noch optional in % ausdrücken? Zumal pvvis ja nur basierend auf den überlieferten Ist-Werten rechnen und anzeigen könnte.
Zitat von: yersinia am 25 November 2022, 07:25:16
...dies kann man aber bereits jetzt schon aus den gegebenen Werten/Darstellung ab/herleiten: die Einspeisung im Netz wird bereits angezeigt, wenn dieser 0 ist, ist wohl der Eigenverbrauch sehr nah bei 100%. Analog zum Bezug aus dem Netz: ist dieser nahe 0, ist die Autarkie wohl ebenso nahe 100%. Zumindest interpretiere ich dies so.
Bedarf es denn hier überhaupt zwei weiterer Anzeigen, die das dann auch noch optional in % ausdrücken? Zumal pvvis ja nur basierend auf den überlieferten Ist-Werten rechnen und anzeigen könnte.
Hast Recht, und zu sehr aufblähen muss man die Komponente ja auch nicht.
Eigentich ist es jetzt super wie es ist.
Ja klar, ich möchte pvvis auch nicht mit unnötigen Werten vollballern. Darum diskutieren wir hier ja ;)
Die Anzeige im Web/App von E3DC zeigt diese Werte sehr prominent an und ich kann diese, auch ohne in FHEM/pvvis rechnen zu müssen aus der Anlage auslesen. Jetzt habe ich mich mit den Hintergründen dieser Werte beschäftigt und du hast Recht, eigentlich sieht man die aktuelle Lage aus den Werten Netzeinspeisung/bezug ohne rechnen zu müssen.
Das Ganze macht auch mit den aktuellen Werten wenig Sinn, eher mit den Tagessummen. Somit sieht man wie es an diesem Tag vom Eigenverbrauch/Autarkie her ausgesehen hat, aber auch hier genügt eigentlich ein Blick auf die Werte neben dem Pylon.
Ich baue das jetzt aber dennoch in meine pvvis ein, damit ich meine Berechung mit der der von E3DC vergleichen kann. Wobei mir eben auffällt, dass E3DC hier einen Bug haben muss. Rufe ich die Anzeige auf ist Eigenstrom auf 0%, wandert aber dann so langsam bis auf 100% hoch? Obwohl sich nichts ändert, kaum Netzbezug, alles aus dem Akku??? :o Das Ganze kann auch umgekehrt sein, startet bei 100% und wandert dann runter auf 0%...
Danke für eure Meinung dazu, ich berichte weiter. :D
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?
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.
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
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.
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.
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.
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.
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!
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.
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.
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 (https://forum.fhem.de/index.php/topic,119440.msg1245255.html#msg1245255) schon abgefahren ist? Ansonsten dacor.
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.
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...
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
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)
Zitat von: docolli am 29 November 2022, 13:03:02Liegt 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.
Das ist ja nichts, was man nicht hinbekommen würde; aber ja, der Platz ist begrenzt, ausgereizt und irgendwie wollen AU und EV nirgends so richtig Platz finden.
Zitat von: docolli am 29 November 2022, 13:03:02Was 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.
Da geht ne Menge; alles was JavaScript kann. ;) Du kannst auch eigene Funktionen aufrufen usw.
Zitat von: docolli am 29 November 2022, 13:03:02Gibt es dazu eine Doku? 8)
Ja, gibt es. ;) (https://forum.fhem.de/index.php/topic,115259.0.html); insbesondere mr_petz und OdfFhem haben hier wirklich viel gezeigt.
Edit: man könnte auch mit Kreisen arbeiten, sind ggf etwas dezenter als Ladebalken. Siehe zweites Bild.Edit II: anbei eine Version, welche Autarkie und Eigenverbrauch als Kreise (circle) oder Ladebalken (flow) darstellt - die Prozentwerte (0-100) kommen aus einem FHEM-Device.
Zitat von: docolli am 29 November 2022, 13:03:02
@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.
Google "html div overlay" sagt z.B. https://stackoverflow.com/questions/2941189/how-to-overlay-one-div-over-another-div
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!
Wird so nicht funktionieren, da unit-value für ALLE Werte gilt, du aber mit der pipe jeden einzelnen Wert in W oder kWh umrechnest.
Damit es geht müsste man definieren, in welcher Einheit die Werte an pvvis übergeben werden müssen (z.B. in W), dann kann das in pvvis sauber umgerechnet werden.
Somit könnte man sich aber die Übergabe der unit sparen.
Nochmals danke für den Tipp mit DIV-Overlay. Damit komme ich deutlich weiter und muss mich nicht in pvvis einmischen 😁🤣.
Dank des Tips von @papa konnte ich nun Eigenverbrauch und Autarkie im Dashboard unserer Firma mit Hilfe von label und slider folgendermaßen darstellen (siehe Bild).
Werte werden jetzt alle als userreading im FHEM device berechnet.
Aus bestimmten Gründen nutze ich hier nicht die in pvvis intergrierte Darstellung der Summernwerte. Wir wollen auch den Vergleich zum Vortag haben.
Bei Interesse teile ich gerne die userreadings bzw. das div-Konstrukt, damit auch jemand anderes eine Basis für eigene Overlays hat.
Zitat von: docolli am 08 Dezember 2022, 08:25:35
Dank des Tips von @papa konnte ich nun Eigenverbrauch und Autarkie im Dashboard unserer Firma mit Hilfe von label und slider folgendermaßen darstellen (siehe Bild).
Werte werden jetzt alle als userreading im FHEM device berechnet.
Aus bestimmten Gründen nutze ich hier nicht die in pvvis intergrierte Darstellung der Summernwerte. Wir wollen auch den Vergleich zum Vortag haben.
Bei Interesse teile ich gerne die userreadings bzw. das div-Konstrukt, damit auch jemand anderes eine Basis für eigene Overlays hat.
Moin,
kannst Du den Code dafür zeigen, sieht gut aus. Auch das mit den Vortagswerten ist super.
Grüße
Olli
Ich habe folgende userreadings, der besseren Lesbarkeit wegen mit extra Zeilen getrennt:
Haus-Stromverbrauch_tag integral { ReadingsVal($NAME,"Haus-Stromverbrauch",0)/3600 },
PV-Erzeugung_tag integral { ReadingsVal($NAME,"PV-Erzeugung",0)/3600 },
AKKU_tag integral { ReadingsVal($NAME,"AKKU-Entnahme",0)/3600 },
Netz-Einspeisung_1 { min(ReadingsVal($NAME,"Netz-Einspeisung",0),0)*-1 },
Netz-Bezug_1 { max(ReadingsVal($NAME,"Netz-Einspeisung",0),0) },
Netz-Einspeisung_tag integral { ReadingsVal($NAME,"Netz-Einspeisung_1",0)/3600 },
Netz-Bezug_tag integral { ReadingsVal($NAME,"Netz-Bezug_1",0)/3600 },
Autarkie { ( 1 - ReadingsVal($NAME,"Netz-Bezug_tag",0) / ReadingsVal($NAME,"Haus-Stromverbrauch_tag",0) ) *100 },
Eigenverbrauch { ( (ReadingsVal($NAME,"PV-Erzeugung_tag",0) - ReadingsVal($NAME,"Netz-Einspeisung_tag",0)) / ReadingsVal($NAME,"PV-Erzeugung_tag",0) ) *100 }
Mit den ersten drei integriere ich die Werte von Haus/PV/Akku-Entnahme auf.
Da das Senec System mir den Netzbezug/Einspeisung als einen Wert, aber positiv/negativ gibt, splitte ich den Wert in zwei temporäre readings per min/max Funktion auf. Dann kann ich wieder getrennt darüber integrieren.
Autarkie und Eigenverbrauch Berechnung ist nur mal so formuliert, da ist noch kein DivisionByZero abgefangen... ::)
Zusätzlich haben ich noch ein AT Device, dass mir um 23:59:59 die Werte von "*_tag" auf "*_gestern" per setreading Befehl kopiert und dann "'_tag" auf Null setzt. Beispiel:
fhem('setreading DEVICE AKKU_gestern [DEVICE :AKKU_tag]'),
fhem('setreading DEVICE AKKU_tag 0'),
Anmerkung:
DEVICE=<eigener Device Name>
Dazu kommt noch die <div> Magie, um (ftui)-Elemente über dem pvvis Element zu platzieren.
<div style="position: relative;">
<ftui-pvvis
....
width="500px"
margin="50px 50px 50px 50px">
</ftui-pvvis>
<div style="position: absolute; top: 0%; transform: translate(313px, 85px);">
<ftui-label [text]="DEVICE:PV-Erzeugung_tag | multiply(0.001) | round (1) | fix(1)" unit=" kWh" size="1">Heute </ftui-label>
</div>
<div style="position: absolute; top: 0%; transform: translate(313px, 100px);">
<ftui-label [text]="DEVICE:PV-Erzeugung_gestern | multiply(0.001) | round (1) | fix(1)" unit=" kWh" size="1">Gestern </ftui-label>
</div>
.....
<div style="position: absolute; top: 0%; transform: translate(3px, 20px); width: 180px;">
<ftui-label [text]="DEVICE:Autarkie | round(0)" unit="%" size="1">Autarkie: </ftui-label>
<ftui-slider [value]="DEVICE:Autarkie" readonly min="0" max="100" handle="none" tick="25" has-ruler margin="5px 0px 0px 0px"></ftui-slider>
</div>
<div style="position: absolute; top: 0%; transform: translate(3px, 80px); width: 180px;">
<ftui-label [text]="DEVICE:Eigenverbrauch | round(0)" unit="%" size="1">Eigenverbrauch: </ftui-label>
<ftui-slider [value]="DEVICE:Eigenverbrauch" readonly min="0" max="100" handle="none" tick="25" has-ruler margin="5px 0px 0px 0px"></ftui-slider>
</div>
</div>
Mein pvvis ist 500px breit mit dem angebenen Rand. Das muss man anpassen, genauso die Position der einzelnen div Elemente. Nur mal zum zeigen, wie es gehen kann. Der Einfachheit halber habe ich nicht mit CSS Klassen gearbeitet, sondern das style attribut direkt ins div Tag geschrieben.
Jetzt kommt doch noch ein Problem, wenn ich das in mein FTUI Zuhause einbauen will.
Hier ist mein pvvis nur 290px breit. Um also die zwei Slider oben links zu positionieren, muss ich diese (samt Schrift) verkleinern.
Ich habe das per scale auf 70% versucht, aber dann stimmt die Skalierung des Sliders nicht mehr. 99% sind nicht ganz rechts.
Siehe Bild.
Irgendjemand eine Idee was ich da machen kann?
<div style="position: absolute; top: 0%; transform: scale(0.7) translate(-40px,58px); width:180px;">
<ftui-label [text]="E3DC_S10E:Autarkie | round(0)" unit="%" size="1">Autarkie: </ftui-label>
<ftui-slider [value]="E3DC_S10E:Autarkie" readonly min="0" max="100" handle="none" tick="25" has-ruler margin="5px 0px 0px 0px"></ftui-slider>
</div>
<div style="position: absolute; top: 0%; transform: scale(0.7) translate(-40px,3px); width: 180px;">
<ftui-label [text]="E3DC_S10E:Eigenverbrauch | round(0)" unit="%" size="1">Eigenverbrauch: </ftui-label>
<ftui-slider [value]="E3DC_S10E:Eigenverbrauch" readonly min="0" max="100" handle="none" tick="25" has-ruler margin="5px 0px 0px 0px"></ftui-slider>
</div>
@docolli
Kannst es so mal testen:
<div style="position: relative;">
<ftui-pvvis
...
width="290px">
</ftui-pvvis>
<ftui-cell style="position: absolute; top: 0; left:-40px; width:47%;">
<ftui-label [text]="E3DC_S10E:Autarkie | round(0)" unit="%" size="1" width="100%">Autarkie: </ftui-label>
<ftui-slider [value]="E3DC_S10E:Autarkie" readonly min="0" max="100" handle="none" tick="25" has-ruler margin="5px 0 25px 0" style="width: 100%;"></ftui-slider>
<ftui-label [text]="E3DC_S10E:Eigenverbrauch | round(0)" unit="%" size="1" width="100%">Eigenverbrauch: </ftui-label>
<ftui-slider [value]="E3DC_S10E:Eigenverbrauch" readonly min="0" max="100" handle="none" tick="25" has-ruler margin="5px 0 0 0" style="width: 100%;"></ftui-slider>
</ftui-cell>
</div>
Habe die slider und dazugehörigen label in eine ftui-cell gepackt.
Bei mir wird alles richtig gesetzt im slider...
Die passende Größe musst du halt noch anpassen im ftui-cell style. Left dann auch. Mehr brauchst du da eigentlich nicht...
LG mr_petz
Edit:
hier noch reduzierter:
<ftui-cell style="position: absolute; top: 0; left:5px; width:30%;">
<ftui-label [text]="E3DC_S10E:Autarkie | round(0)" unit="%" class="size--1" width="100%">Autarkie: </ftui-label>
<ftui-slider [value]="E3DC_S10E:Autarkie" readonly min="0" max="100" class="size--1" handle="none" tick="25" has-ruler margin="5px 0 25px 0" style="width: 100%;"></ftui-slider>
<ftui-label [text]="E3DC_S10E:Eigenverbrauch | round(0)" unit="%" class="size--1" width="100%">Eigenverbrauch: </ftui-label>
<ftui-slider [value]="E3DC_S10E:Eigenverbrauch" readonly min="0" class="size--1" max="100" handle="none" tick="25" has-ruler margin="5px 0 0 0" style="width: 100%;"></ftui-slider>
</ftui-cell>
Danke, hab's gleich ausprobiert, leider nicht mit dem gewünschten Ergebnis.
<ftui-cell style="position: absolute; top: 0%; transform: scale(0.7) translate(-80px,3px); width: 180px;">
<ftui-label [text]="E3DC_S10E:Eigenverbrauch | round(0)" unit="%" size="1">Eigenverbrauch: </ftui-label>
<ftui-slider [value]="E3DC_S10E:Eigenverbrauch" readonly min="0" max="100" handle="none" tick="25" has-ruler margin="5px 0px 0px 0px"></ftui-slider>
</ftui-cell>
<ftui-cell style="position: absolute; top: 0%; transform: translate(-20px,38px); width: 45%;">
<ftui-label [text]="E3DC_S10E:Eigenverbrauch | round(0)" unit="%" size="1">Eigenverbrauch: </ftui-label>
<ftui-slider [value]="E3DC_S10E:Eigenverbrauch" readonly min="0" max="100" handle="none" tick="25" has-ruler margin="5px 0px 0px 0px"></ftui-slider>
</ftui-cell>
Der untere Slider ist nicht skaliert, sondern in der Breite so angepasst, wie du vorgeschlagen hast. Damit stimmt zwar dann die Werteanzeige im Balken, aber die Schriften (und der Rest) werden damit nicht runter skaliert. Ich hätte gerne den Slider samt Beschriftung in einer Box, den kompletten Inhalt aber passend auf 70% runter skaliert. Dann passt das gut links oben hin und drängt sich auch nicht so auf.
Nimm doch das 2.Beispiel und nur eine cell!
Durch die %Angabe scaliert es doch...
Sorry, dachte ich hätte grundsätzlich verstanden woran es bei mir gelegen hat.
Offensichtlich nicht! ::)
Danke für den Hinweis.
Moin,
auch auf die Gefahr das ich erschlagen werde....
Welche Dateien sind jetzt die Aktuellen für die FTUI2.
Gruß
Carsten
@stenny
Diese hier sollten es sein:
von @papa
https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479
von @fred_feuerstein
https://forum.fhem.de/index.php/topic,119440.msg1244211.html#msg1244211
LG
Danke
Danke
Und für FTUI3?
Zitat von: Stonemuc am 18 Januar 2023, 01:03:34
Und für FTUI3?
Hier das Modul für FTUI3:
https://forum.fhem.de/index.php/topic,119440.msg1248379.html#msg1248379
und hier die Beschreibung mit älteren Modul für FTUI3:
https://forum.fhem.de/index.php/topic,119440.msg1246690.html#msg1246690
LG
Danke ;D
Zitat von: mr_petz am 18 Januar 2023, 08:25:32Hier das Modul für FTUI3:
https://forum.fhem.de/index.php/topic,119440.msg1248379.html#msg1248379
und hier die Beschreibung mit älteren Modul für FTUI3:
https://forum.fhem.de/index.php/topic,119440.msg1246690.html#msg1246690
Dank mr_petz ist die pvvis FTUI3 Version nun auch über die Regulären FHEM Update Menchanismen aktualisierbar: https://github.com/mr-petz/ftui/tree/addons (https://github.com/mr-petz/ftui/tree/addons)
Thx @mr_petz und @OdfFhem für das repo
die
aktuelle FTUI3-pvvis Version gibt es nur noch über das FTUI3 addons repo (https://github.com/mr-petz/ftui/tree/addons). Alle derzeit verfügbaren Parameter der component sind:
Zitat~~~ EINSTELLUNG PV-ANLAGE/ALLGEMEIN ~~~
pvmax: maximale Leistung der PV Anlage - dies ist ein fester Wert
[produce]: reading; Produktion der PV Anlage (der Wert wird zu einem positiven Wert konvertiert)
[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)
unit-value optional; für die Einheit der Ent/Lade-Werte, zB:
unit-value="W"
Wenn nicht gesetzt wird auch keine Einheit gesetzt.
width: optional; Breite der Grafik (Standard ist 200px)
sun-icon: optional; andere icons für die Sonne => sun2 entspricht der Sonne von papa aus #123 (https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479); pvsun entspricht dem panel und der Sonne von Shadow3561 aus #24 (https://forum.fhem.de/index.php/topic,119440.msg1226092.html#msg1226092); sun ist der Standardwert und muss nicht explizit gesetzt werden
[pv-prod-tdy]: reading, optional; heutiger PV-Ertrag (in kWh)
[pv-forecast]: reading, optional; voraussichtlicher heutiger PV-Ertrag (in kWh)
unit-sum: fester Wert, optional; setzt die Einheit für die Summen (zB kWh)
flow-threshold: fester Wert, optional; Schwellwert, ab dem der Energiefluss durch Animation und leuchtender Farbe visualisiert wird
[autarky]: reading, optional; Grad der Autarkie in % (Werte; 0 bis 100); wird dem AU-Wert zugeschrieben
[own-consumption]: reading, optional; Grad des Eigenverbrauchs in % (Werte; 0 bis 100); wird dem OC-Wert zugeschrieben
au-oc-type: optional; definiert die Anzeige von AU (autarky/Autarkie) und OC (own consumption/Eigenverbrauch) als circle (Kreise) (Standard; muss nicht explizit gesetzt werden) oder flow (Ladebalken)
~~~ EINSTELLUNGEN AKKU ~~~
has-no-battery: optional; wenn gesetzt wird der Akkustrang rechts ausgeblendet
[soc]: reading; Ladestand des Akkus (kann % aber auch Wh annehmen)
unit-soc optional; für die Einheit des Akkustands, zB:
unit-soc="%"
Wenn nicht gesetzt wird auch keine Einheit gesetzt.
batstep: optional; Grenzwerte für die Ladestandsanzeige des Akkus:
batstep="21,35,51,75,95"
Dabei ist 21 der untere Schwellenwert unter dem der Akku grau bleibt. Diese Definition entspricht:
0 bis 21 - Batterie ist ausgegraut
21 bis 35 - kein Balken
35 bis 51 - ein Balken
51 bis 75 - zwei Balken
75 bis 95 - drei Balken
ab 95 - vier Balken
Vorgegebener Standard ist
batstep="1,24,49,74,95"
Hinweis: die Darstellung bezieht sich auf soc werte mit %; wenn soc nicht als % vorliegt, muss batstep auch entsprechend angepasst werden, dies kann zB (in Wh oder kWh) so aussehen
batstep="400,1200,2500,3800,5600"
batstep="0.4,1.2,2.5,3.8,5.6"
batmax: fester Wert, optional; Hausakkukapazität in Wh (muss gesetzt werden wenn Ent/Ladezeitschätzung angezeigt werden soll -> siehe calc-bat-remain-time); batmax sollte die gleiche Einheit haben wie produce; man sollte Einheitenmischung Wh vs kWh vermeiden
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 batmax 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.
no-bat-gradient: optional; der Batteriestand wird als Farbverlauf in Abhängigkeit des Ladezustands angezeigt - wenn der Akku leer ist färben sich die Balken rot und gehen bei Ladung bis voll sukzessive in grün über. Dabei ändern nur die Ladebalken die Farbe, die Batterie selbst zeigt immer noch an ob sie geladen (grün) oder entladen (rot) wird (grau wenn weder ge/entladen wird). Wer diesen Farbverlauf nicht haben möchte, setzt no-bat-gradient. Der Farbverlauf basiert auf den battstep-Schwelelnwerte.
has-grid-charge: optional; aktiviert das Laden des Akkus vom Netz und entsprechende Werte können mittels [grid-charge]="DEVICE:READING" übergeben werden.
[grid-charge]: reading, optional; übernimmt die Werte der Ladeleistung des Akkus aus dem Netz; muss gesetzt werden wenn has-grid-charge genutzt wird
~~~ EINSTELLUNGEN GRID/NETZ ~~~
grid-icon: optional; ersetzt das Kabel-Netzicon; valide Werte sind: pylon, pylon2 (von papa aus #123 (https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479) ) oder cable (Standard; muss nicht explizit gesetzt werden)
has-no-grid-feed: optional; blendet die Netzeinspeisung (PV=>Netz) aus
[grid-feed-tdy]: reading, optional; bisherige/heutige Einspeisung ins Stromnetz
[grid-consume-tdy]: reading, optional; bisherige/heutige Entnahme aus dem Stromnetz
~~~ EINSTELLUNGEN HAUS/EIGENVERBRAUCH ~~~
home-icon: optional; das Haus-Icon lässt sich ersetzen durch folgende potentielle Werte: house (Standard; muss nicht explizit gesetzt werden), plug (Stecker) oder socket (Steckdose)
no-wb-in-home: optional; zieht den Wallboxverbrauch vom Hausverbrauch ab
[home-consume-tdy]: reading, optional; bisheriger Tages-Stromverbrauch
~~~ EINSTELLUNGEN WALLBOX ~~~
has-no-wallbox: optional; wenn gesetzt, wird der Wallbox-Teil ausgblendet
[wb-feed]: reading, optional; nimmt den Wert des derzeitigen Ladens des Autos auf (entspricht papas data-lp1pow - Ladung des Auto). Ist der Wert <= 0 wird der Strang und das Auto ausgegraut. Ist der Wert > 0 wird das Auto grün und der flow gelb eingefärbt. Muss nicht gesetzt werden wenn has-no-wallbox gesetzt ist.
[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
die
FTUI2 widget Versionen finden sich in diesen Beiträgen:
Zitat von: mr_petz am 07 Januar 2023, 11:29:53von @papa
https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479 (https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479)
von @fred_feuerstein
https://forum.fhem.de/index.php/topic,119440.msg1244211.html#msg1244211 (https://forum.fhem.de/index.php/topic,119440.msg1244211.html#msg1244211)
Hallo, hat sich nochmal jemand die Mühe gemacht, die vielen tollen Änderungen aus der FTUI3 Version in die FTUI2 Version zu übernehmen?
Speziell die Restzeitanzeige bis zur vollständigen Ladung / Entladung des Speichers würde mich interessieren.
Danke und Grüße
Ich habe jetzt mal angefangen, die Rest-Lade oder Entladezeit des Speichers in der FTUI2 Version einzubauen. Dazu habe ich die Speichergröße über batt-max definiert. Funktioniert erst mal grundsätzlich, aber ich hänge gerade noch an 2 Dingen:
1. wie kann ich die Einheit "h" für die Restzeit bzw % für den SOC in der Anzeige ergänzen? Dachte, das geht, wenn ich in den Zeilen
<text id="bat-soc-txt" x="570" y="415" style="fill: #ccc; font-size: 38px; text-anchor: start;">0</text> \
<text id="bat-remain-txt" x="590" y="200" style="fill: #ccc; font-size: 38px; text-anchor: middle;">0</text> \
die 0 am Ende durch die Einheit h oder % ersetze. Klappt aber nicht :-(
2. wie kann ich die Zeit immer auf eine halbe Stunde runden? Dachte, das geht über Math.round und dann *10 und /10, aber das funktioniert nicht.
Wäre toll, wenn jemand helfen könnte. Bin da nicht so der Profi ;-)
Im Anhang die erweiterte Version.
Danke und Grüße
Edit: hat sich erledigt, ich hab rausgefunden wie es geht.
Erst mal Danke an alle Beteiligten für dieses tolle Modul und die vielen Ideen die hier eingeflossen sind.
Da ich (noch) FTUI2 nutze und einen Fronius GEN24 Wechselrichter sowie einen Fronius Wattpiloten zum Laden meines E-Autos habe, habe ich das Modul nun etwas an meine Bedürfnisse angepasst. Der Fronius liefert z.B. nur einen Wert für die HVS-Ladeleistung, die entweder positiv oder negativ ist. Basis waren die Version von papa, maestro84 und Fred_feuerstein.
Vielleicht mag sie ja jemand auch noch verwenden, der ebenso die o.g. Fronius Komponenten nutzt. Die Anbindung des Wattpiloten habe ich über ioBroker zu FHEM gemacht, da es leider für FHEM noch kein passendes Modul dafür gibt. Den Ladezustand meines BMW i3 lese ich auch über das BMW ioBroker Modul aus.
Wenn der i3 über den Wattpiloten angesteckt ist (und z.B. auf Überschussladen wartet), erscheint das Ladekabel in der Anzeige und das Fzg.symbol wechselt von grau auf grün. Wenn der Ladevorgang startet, wechselt das Fzg.symbol auf blau.
Der FTUI Code sieht so aus:
<div data-type="pvvis" data-device="Fronius_Wechselrichter"
data-get="Stromzaehler_Modbus:power"
data-feed="Stromzaehler_Modbus:power"
data-lp1="fronius_wattpilot.0.carConnected:Statenum"
data-lp1pow="fronius_wattpilot.0.power:state"
data-carsoc="bmw.0.WBYxxxxx.properties.chargingState.chargePercentage:state"
data-carrange="bmw.0.WBYxxxxx.properties.electricRange.distance.value:state"
data-produce="PV_Gesamt_Leistung:PV_Leistung"
data-sumproduceday="FroniusWEB:statKW_PV_ENERGYACTIVE_GesamtDay"
data-sumgridday="Stromzaehler_Modbus:statKW_total_consumptionDay"
data-sumfeedday="Stromzaehler_Modbus:statKW_total_feedDay"
data-soc="Fronius_Wechselrichter:PowerFlow_Inverters_1_SOC"
data-chargedischarge="Fronius_Wechselrichter:PowerFlow_Site_P_Akku"
data-pv-max="6000"
data-batt-max="10240"
data-autarky="Fronius_Wechselrichter:Autarkiegrad_heute"
data-pvhome="Fronius_Wechselrichter:PowerFlow_Site_P_Load"
data-width="240" data-height="240" class="centered">
</div>
Viele Grüße
Zitat von: yersinia am 29 Januar 2023, 22:10:40
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)
Gibt es auch ein
[receive-feed]?
Mein Zähler liefert:
Wert > 0 (positiv) => bei Verbrauch aus Stromnetz/von EVU
Wert < 0 (negativ) => bei Einspeisung ins Stromnetz/an EVU
Oder muss ich mir ein userreading mit (Wert * -1) bauen?
Edit: Konnte ich schon selbst lösen. [feed-receive]="reading | multiply(-1)"
Gruß LuGu
Wie berechnet ihr [autarky] und [own-consumption]?
Ich habe mir eine ReadingsGroup angelegt, die die Daten von den einzelnen Zählern einsammelt.
einspeiseZaehler:EnergyDay 0.010 2023-03-13 14:45:14
solarZaehler:EnergyDay 0.790 2023-03-13 17:53:10
stromZaehler:EnergyDay 8.844 2023-03-13 21:02:56
In der ReadingsGroup habe ich mir ein userreading angelegt, dass own-consumption rechnen soll.
attr LeistungenTag userReadings ownConsumption {(ReadingsNum("solarZaehler","EnergyDay",0) - ReadingsNum("einspeiseZaehler","EnergyDay",0)) * 100 / ReadingsNum("solarZaehler","EnergyDay",0)}
Das funktioniert aber nicht. Es wird kein userReadings angelegt.
Ist ein userReadings in einer ReadingsGroup nicht möglich?
Hat jemand einen Tipp für mich?
Gruß LuGu
Hi LuGu,
für eine Berechnung in/aus einer readingsgroup ab hier mal lesen:
https://forum.fhem.de/index.php/topic,42742.msg348503.html#msg348503
LG mr_petz
Hallo LuGu,
ich habe das zwar nicht über eine readings group gelöst, aber ich habe im Device des Wechselrichters ein user reading angelegt, dass sich die notwendigen readings (auch aus einem anderen Device) zusammensucht und die Autarkie berechnet:
Autarkiegrad_heute:statPowerFlow_Inverters_1_E_TotalDay.* {(ReadingsVal("Fronius_Wechselrichter","statPowerFlow_Inverters_1_E_TotalDay",0)/1000)/(ReadingsVal("Fronius_Wechselrichter","statPowerFlow_Inverters_1_E_TotalDay",0)/1000+ReadingsVal("Stromzaehler_Modbus","statKW_total_consumptionDay",0))*100;;}
Vielleicht hilft dir ja das weiter.
VG
Danke tomhead
Zitat von: tomhead am 14 März 2023, 22:37:58
ich habe das zwar nicht über eine readings group gelöst, aber ich habe im Device des Wechselrichters ein user reading angelegt, dass sich die notwendigen readings (auch aus einem anderen Device) zusammensucht und die Autarkie berechnet:
Ich dachte userreading kann nur mit readings aus dem eingenen device rechnen.
Ich werde es noch mal versuchen.
Edit: Ja, hat funktioniert. Danke noch mal.
Gruß LuGu
Hallo,
Nutzt hier einer die Readings aus dem SolarForecast Modul?
Kriege da immer Fehler im Browser angezeigt.
Gruß
Eisix
Moin mr_petz
Zitat von: mr_petz am 14 März 2023, 22:03:30
Hi LuGu,
für eine Berechnung in/aus einer readingsgroup ab hier mal lesen:
https://forum.fhem.de/index.php/topic,42742.msg348503.html#msg348503
LG mr_petz
Leider bin ich da nicht fündig geworden, auch nicht, wenn ich alle Links der Links verfolgen.
Ich habe gelernt, wie ich in ReadingsGroups rechnen kann z.B. Summen in eine neue Zeile schreiben, aber nicht wie es mit userReadings in ReadingsGroups funktioniert.
Aber danke, konnte das Problem ja anders lösen.
Gruß LuGu
Ok LuGu.
Das war von mir auch nur als Hinweis/Lösungsansatz gedacht.
Aber du hast es ja jetzt hinbekommen. :D
LG mr_petz
Zitat von: yersinia am 29 November 2022, 13:33:35
Edit II: anbei eine Version, welche Autarkie und Eigenverbrauch als Kreise (circle) oder Ladebalken (flow) darstellt - die Prozentwerte (0-100) kommen aus einem FHEM-Device.
Hallo yersinia,
ersteinmal vielen Dank für die tolle und sehr komplexe Componente.
Ich könnte mal ein Denkanstoß gebrauchen. Meine Visu sieht noch nicht so "optimal" aus.
<ftui-grid-tile row="9" col="5" height="8" width="9" shape="round">
<header>Versorgung</header>
<ftui-pvvis
pvmax="600"
[produce]="dr_BKWPow:ENERGY_Power0"
sun-icon="sun"
[pv-prod-tdy]="solarZaehler:EnergyDay"
[feed-receive]="kg_EasyMeter:SML_Power_curr | multiply(-1)"
[grid-consume-tdy]="stromZaehler:EnergyDay"
[autarky]="stromZaehler:autarky"
[own-consumption]="stromZaehler:ownConsumption"
grid-icon="pylon"
au-oc-type="flow"
has-no-battery
has-no-wallbox
unit-value="W"
unit-sum="kWh"
width="30vh"
class="size-4"
></ftui-pvvis>
</ftui-grid-tile>
Autarkie und Eigenverbrauch bekomme ich nicht hin. Wo kann ich angreifen?
Gruß LuGu
Hi@LuGu
Ich gehe mal davon aus du hast die letzte Version.
Scheint an dem fill in der css zuliegen?:
https://github.com/mr-petz/ftui/blob/addons/www/ftui/components/pvvis/pvvis.component.css#L316
Wenn ich die aus mache wird der Kreis bei mir auch schwarz.
Könntest an der oben genannten Stelle mal mit:
fill: transparent;
oder mit:
fill: var(--grid-background-color);
testen und Browsercache leeren nicht vergessen...
Welchen Browser benutzt du?
Hast du irgendwo in einer user.css etwas mit fill für svg oä. stehen?
LG mr_petz
Edit:
alternativ nach oben genannter Zeile noch das:
fill-opacity: 0;
mit eintragen.
Zitat von: mr_petz am 17 März 2023, 21:09:45
Hi@LuGu
Ich gehe mal davon aus du hast die letzte Version.
Danke, dein Tipp war mal wieder richtig. Kaum macht man's richtig schon funktioniert es.
Ich hatte die aktuelle *.js, aber leider nicht die aktuelle *.css.
Jetzt ist alles wie es soll.
Gruß LuGu
Hi,
ich verwende auf meinem Hannspree Titan3 Tablet den Fully Browser um meine FTUI3 Seiten anzuzeigen.
Bei Animationen im Zusammenhang mit einem Kamerabild, welches sich regelmässig aktualiert, gibt es immer wieder ein Geflackere von einzelnen Komponenten.
Jetzt ist mir aufgefallen, das meine Sonnenbatteriedarstellung auch hin- und wieder flackert (und auf der Seite ist sonst nichts animiert).
Hat sonst noch jemand so ein Problem?
EDIT: Zur Klarstellung, das Problem sehe ich nur mit Fully - selbst auf dem Tablet flackert mit Chrome nichts.
Danke,
Jörg
Klingt als wäre es ein Problem von Fully.
Die pvvis aktualisiert ja laufend die Ansicht immer wenn sich entsprechende Werte ändern - und CSS Animationen gibt es auch: die Flows, Ladestandsanzeige des Akkus, das eAuto wenn es geladen wird usw.
Da wird die Aktualisierungsrate nicht reichen. Hast du die Möglichkeit einen anderen Browser zu testen?
Darüberhinaus ist das eigtl auch kein Thema für diesen Thread...
Sorry dieser Thread hier bemühen.
Diese Darstellung ist bei mir halt ein ziemlich guter Reproducer und ich wollte die Fully Leute damit konfrontieren.
Wenn noch mehr das nachvollziehen können, hätte das eben mehr Gewicht, als wenn es nur mein Tablet ist.
Ganz allein das Tablet ist es zumindest nicht, denn mit Chrome flackert nichts.
Zitat von: Adimarantis am 18 April 2023, 09:17:02EDIT: Zur Klarstellung, das Problem sehe ich nur mit Fully - selbst auf dem Tablet flackert mit Chrome nichts.
Hier
Hallo zusammen
Ein sehr schönes und sehr übersichtliches Widget. Danke für die Arbeit!
Wir verfügen über eine Anlage mit 30 kWp von SolarEdge. Die Daten beziehe ich über FHEM.
Dabei werden die meisten Daten in Watt angezeigt, welche im FTUI3 mittels "| multiply(0.001) | round (2) | fix(2)" in KW umgerechnet und dann so in KW mit 2 Dezimalstellen angezeigt werden.
Die Daten der PV-Produktion, inklusive der aktuellen Anzeigen für den Verbrauch (sowohl von der PV als auch vom Netz) werden auf FHEM in KW angezeigt.
Im FTUI3 wird die PV-Produktion wie im FHEM dargestellt in KW mit 2 Dezimalstellen übernommen. Jene der Batterieeinspeisung, des direkten Verbrauchs und dem Bezug bzw. der Einspeisung ins Netz wird auf eine Ganzzahl gerundet in KW dargestellt.
Bei einer Produktion von bis zu 30 KW wäre eine Darstellung in W etwas unübersichtlich. Gibt es eine Möglichkeit, die auf Ganzzahlen gerundeten Werte so zu übernehmen, wie sie im FHEM dargestellt werden (2 Dezimalstellen)?
Gruss
Chris
Danke fürs positive Feedback. :D
Zitat von: outhouse am 02 Juli 2023, 10:52:59Dabei werden die meisten Daten in Watt angezeigt, welche im FTUI3 mittels "| multiply(0.001) | round (2) | fix(2)" in KW umgerechnet und dann so in KW mit 2 Dezimalstellen angezeigt werden.
Wenn dir die pipes zu komplex/viel werden kannst du immer noch ein userReading in FHEM einrichten und diese dann in FTUI3 zur anzeige nutzen. Nur so am Rand bemerkt.
Zitat von: outhouse am 02 Juli 2023, 10:52:59Gibt es eine Möglichkeit, die auf Ganzzahlen gerundeten Werte so zu übernehmen, wie sie im FHEM dargestellt werden (2 Dezimalstellen)?
Zitat von: yersinia am 16 Juni 2023, 11:40:51das müsste mit der pipe fix(n) (https://github.com/knowthelist/ftui/blob/master/www/ftui/modules/ftui/ftui.binding.js#L14) gehen.
Hallo Yersinia
Danke für deine Infos.
Nein. Die pipes sind nicht zu komplex/viel. Die funktionieren sehr gut. Ausser ...
Die Zahl der Produktion zeigt es FTUI3 perfekt mit 2 Kommastellen in KW an. Lediglich der Verbrauch bzw. die Einspeisung wird auf FTUI3 auf eine Ganzzahl gerundet, obwohl diese im FHEM mit 2 Dezimalstellen angezeigt werden.
Als Versuch habe ich nun ein userReading für die Produktion angelegt, welche neu statt in KW in W angezeigt wird. Wenn ich jetzt das userReading für [feed-receive] mit "| multiply (0.001) | round (2) | fix (2)" herbeiziehe, wird trotzdem auf die Ganzzahl gerundet.
Somit vermute ich eher, dass es am javascript liegt, welches nur Ganzzahlen zu den Berechnungen (Ladung/Entladung Batterie, Einspeisung/Bezug Netz) zulässt.
Chris
Ja, das ist/war so gewollt weil bei Anzeigen in W die Zahlen (>1000) für die Darstellung zu groß werden - es ist schwierig alle Anlagentypen unter ein Dach zu bekommen. Du kannst dies im dafür verantwortlichen pvvis.component.js (https://github.com/mr-petz/ftui/blob/addons/www/ftui/components/pvvis/pvvis.component.js) aber selber anpassen - du änderst folgende
toFixed()in
toFixed(2)in den Zeilen
- #383 (https://github.com/mr-petz/ftui/blob/bb7bff867494273ce7f48925d972a1e4d1e9b4be/www/ftui/components/pvvis/pvvis.component.js#L383) für den Hausverbrauch
- #502 (https://github.com/mr-petz/ftui/blob/bb7bff867494273ce7f48925d972a1e4d1e9b4be/www/ftui/components/pvvis/pvvis.component.js#L502) für die flows und deren Werte
Oder du entfernst die beiden .toFixed() einfach, dann kannst du es über die pipes/readings lösen.
Perfekt.
Danke
Diese Änderung
Zitat von: yersinia am 04 Juli 2023, 07:33:21Oder du entfernst die beiden .toFixed() einfach, dann kannst du es über die pipes/readings lösen.
sowie
Zitat von: mr_petz am 17 März 2023, 21:09:45Könntest an der oben genannten Stelle mal mit:
fill: transparent;
sind nun auch im offiziellen repo (https://github.com/mr-petz/ftui/commit/2f3e84df5d3f3f1153f01e8ab73684a03dcb24bc). Danke @mr_petz.
Dadurch werden die Flow-Werte und der Hausverbrauch nicht mehr auf Ganzzahl gerundet. Dies muss nun, wenn gewünscht, über pipes wie fix(n) geschehen.
Hallo zusammen,
ich habe mich mal mit diesem Thema beschäftigt um meine Solaranlage "hübscher" darzustellen und finde das hier richtig Klasse. Allerdings habe ich etwas den Überblick verloren.
Ich habe es zwar geschafft meine Readings als Parameter dem pvvis mitzugeben, allerdings scheint meine Anzeige ansonsten statisch zu sein. Nach meinem
Verständnis sollte sich ja die Balken "bewegen". Ich habe da "nur" konstante farbige Balken. Evtl. hat es ja mit der fhem-tablet-ui-user.css zu tun, die muss
zur entsprechenden widget_pvvis.js passen, oder? Wo finde ich die letzte Version für FTUI2 (also css und pvvis) und die entsprechenden Parameter dazu? Man kann ja scheinbar die
Batterie ausblenden, wenn man keine hat, usw. Eine Wikiseite habe ich nicht gefunden und über ein Update kommen die beiden Dateien auch nicht. Fragen über Fragen :)
Vielleicht kann mir jemand weiterhelfen. Würde mich sehr freuen.
Grüße
Micha
Aktuelle FTUI2 Versionen:
Zitat von: mr_petz am 07 Januar 2023, 11:29:53Diese hier sollten es sein:
von @papa
https://forum.fhem.de/index.php/topic,119440.msg1231479.html#msg1231479
von @fred_feuerstein
https://forum.fhem.de/index.php/topic,119440.msg1244211.html#msg1244211
Weitere Doku von papa findest du in seinem post #12 (https://forum.fhem.de/index.php?topic=119440.msg1231146#msg1231146), die user.css in #3 (https://forum.fhem.de/index.php?topic=119440.msg1138919#msg1138919) (keine Ahnung ob dies der letzte Stand ist)
fred_feuersteins Version ist in seinem post #161 (https://forum.fhem.de/index.php?topic=119440.msg1244169#msg1244169) beschrieben.
Vielen herzlichen Dank @yersinia. Das hat mir sehr geholfen. Nun läuft es wunderbar. Ich bin da echt mit den FTUI2/3 durcheinandergekommen. Das mit dem Ausblenden scheint nur mit der 3er Version zu gehen. Vielleicht finde ich mal die Zeit auf FTUI3 zu wechseln. Vielen Dank auch an alle anderen, die so eine tolle Funktion bereitgestellt und weiterentwickelt haben. Ach ja, das mit den bewegten Balken. Kaum bindet man das css mit ein, schon klappt es ;-)
Grüße
Micha
Zitat von: mrabdip am 17 Juli 2023, 17:57:26Das mit dem Ausblenden scheint nur mit der 3er Version zu gehen.
Ja, das scheint so. Da du es aber schon geschafft hast, das Widget aus dem Forum runterzuladen und in deine FTUI2 Instanz zu integrieren, könntest du auch im Quellcode des Widgets den Batterieteil einfach auskommentieren - dann wird dieser auch nicht mehr angezeigt. ;)
ZitatJa, das scheint so. Da du es aber schon geschafft hast, das Widget aus dem Forum runterzuladen und in deine FTUI2 Instanz zu integrieren, könntest du auch im Quellcode des Widgets den Batterieteil einfach auskommentieren - dann wird dieser auch nicht mehr angezeigt.
Nicht nur das, ich habe sogar noch Anregungen vom Post #292 (https://forum.fhem.de/index.php?topic=119440.msg1266503#msg1266503) geholt und weitere eigene Werte eingefügt. Funktioniert prima. Ich habe somit wieder einiges gelernt. Danke.
Moin,
da ich nun einen dynamischen Stromvetrag habe, lade ich gelegentlich den PV-Akku aus dem Netz.
Nun ist die Darstellung währen des Ladens aus dem Netz nicht so optimal.
Vermutlich war dies bisher nich mit dem Modul so vorgesehen.
@yersinia: Siehst eine Möglichkeit das mit einzubauen?
Also wie im zweiten Bild...
LG
Olli
Zitat von: octek0815 am 24 Oktober 2023, 13:33:45Nun ist die Darstellung währen des Ladens aus dem Netz nicht so optimal.
Vermutlich war dies bisher nich mit dem Modul so vorgesehen.
Die FTUI3 Version müsste das können:
Zitathas-grid-charge: optional; aktiviert das Laden des Akkus vom Netz und entsprechende Werte können mittels [grid-charge]="DEVICE:READING" übergeben werden.
[grid-charge]: reading, optional; übernimmt die Werte der Ladeleistung des Akkus aus dem Netz; muss gesetzt werden wenn has-grid-charge genutzt wird
#289 (https://forum.fhem.de/index.php?topic=119440.msg1260914#msg1260914)
Moin yersinia,
vielen Dank für die rasche Antwort. Hätte ich auch selbst drauf kommen können.
Ich habe das nun probiert, habe aber Darstellungsprobleme.
Im ersten Bild ist Netzladung zur Batterie zu sehen (fiktiver Wert), aber dann fehlt die Darstellung der Einspeisung und der Wert für die Batterieentladung ist unglücklich platziert.
Im zweiten Bild ohne Netzladung ist das nochmal ohne Netzladung zu sehen.
Wurde das vorher getestet oder ist das bewust so?
LG
Olli
Ich weiss gar nicht, ob man gleichzeitig in das Netz einspeist und den Akku aus dem Netz lädt!?
Außerdem ist dies bestimmt getestet worden, da ich die Akku-aus-dem-Netz-Einspeisung basierend auf einer Anforderungen aus diesem Thread eingebaut habe (https://forum.fhem.de/index.php?topic=119440.msg1233955#msg1233955).
Die Positionierung des Einspeisewertes ist zwar unschön - allerdings habe ich keine bessere Idee, wo ich den Wert für den mittleren Strang darstellen soll. Die Herausforderung habe ich auch für den Entladestrang bei potentieller Netzladung.
Wenn du Ideen hast, dies besser zu Positionieren immer her damit.
Leider nein. Durch den jetzigen Aufbau ist das nicht möglich.
Der im Bild angezeigte Aufbau wäre für diese Darstellung besser.
LG
Olli
Zitat von: Adimarantis am 18 April 2023, 09:17:02Hi,
ich verwende auf meinem Hannspree Titan3 Tablet den Fully Browser um meine FTUI3 Seiten anzuzeigen.
Bei Animationen im Zusammenhang mit einem Kamerabild, welches sich regelmässig aktualiert, gibt es immer wieder ein Geflackere von einzelnen Komponenten.
Jetzt ist mir aufgefallen, das meine Sonnenbatteriedarstellung auch hin- und wieder flackert (und auf der Seite ist sonst nichts animiert).
Hat sonst noch jemand so ein Problem?
Hatte ich auch, seit irgendeinem automatischen Update von jetzt auf gleich. Lösung: In Fully die Grafik-Beschleunigung von Hardware auf Software schalten. Ist insgesamt etwas langsamer bei meinem betagten Medion, flackert aber nicht mehr.
Hi,
tolles Widget - ich bin begeistert, aber habe noch meine Probleme meine Realität darin abzubilden.
Ich habe folgendes Setting: Wohnwagen mit PV, Batteriespeicher, keine Netzanbindung. Somit nur Eigenverbrauch und Einspeisung der Fehlmengen per Generator. Im Fall der Generatoreinspeisung möchte ich die Stränge zur Batterie und ins Haus(Wagen) mit unterschiedlichen Werten versorgen (Verbrauch Haus (linker Strang) - Ladeleistung der Batterie(rechter Strang)). Bisher habe ich nur [receive] entdeckt, dann werden aber beide Stränge mit gleichem Wert gezeigt. Ist meine Situation im Widget darstellbar?
LG
Ralph
Hi,
ich habe noch etwas in dem Beispiel gestöbert und feed-receive / grid-charge gefunden, damit kann ich meine Realität gut nachbilden.
LG
Ralph
Schau mal im post #289
https://forum.fhem.de/index.php?topic=119440.msg1260914#msg1260914
Unter examples sollte es in deiner lokalen Kopie auch eine pvvis.html Beispiel geben.
Hallo,
irgendwie stehe ich auf dem Schlauch:
Ich habe die FTUI2-Version von fred_feuerstein (https://forum.fhem.de/index.php/topic,119440.msg1244211.html#msg1244211) im Einsatz.
Auch habe ich die CSS-Datei aus diesem Beitrag (https://forum.fhem.de/index.php?topic=119440.msg1138919#msg1138919) installiert.
Aber im Browser werden die Energieflüsse nicht so dargestellt, wie bei allen anderen Screenshots hier, sondern als gefüllter Balken.
Was übersehe ich? Ich fürchte es ist trivial, aber ich bin zu blind es zu sehen...
Danke & Gruß
sweetie-pie
Hallo.
gewaltiges Modul, Danke!
LG
Hallo.
Habe eine Frage zu den Einstellungen:
kann man das so konfigurieren, das grid-charge nicht direkt vom Grid, sondern vom Haus läuft?
Jetzt wird bei mir ja doppelt gemessen, also die Akkuleistung, zusätzlich aber die Leistung was ins Haus geht, die aber ja incl. Ladeleistung ist.
Also der rechte rote Strom müsste weg, dafür vom Haus zu Akku als Ladung angezeigt werden. Weiters der gelbe Balken von PV zu Akku. Würde das funktionieren?
LG
[edit] habe mir die scripts angesehen, und jetzt zumindest einige balken schon entfernen können.
hofe ich bekomm den rest auch noch hin
Zitat von: satprofi am 01 April 2024, 10:09:24kann man das so konfigurieren, das grid-charge nicht direkt vom Grid, sondern vom Haus läuft?
Nein, das ist zZt nicht vorgesehen - war keine Anforderung und irgendwie auch nicht logisch, da imho der Hausverbrauch nicht ins Netz einspeist.
Zitat von: satprofi am 01 April 2024, 10:09:24Jetzt wird bei mir ja doppelt gemessen, also die Akkuleistung, zusätzlich aber die Leistung was ins Haus geht, die aber ja incl. Ladeleistung ist.
Also der rechte rote Strom müsste weg, dafür vom Haus zu Akku als Ladung angezeigt werden. Weiters der gelbe Balken von PV zu Akku. Würde das funktionieren?
Imho müsstest du die Werte der Akkuladung anpassen; mir ist nicht ganz klar, warum die Ladung vom Hausverbrauch zum Akku gehen sollte? Dann müsste auch die Beziehung PV->Akku weg, da in dieser Logik immer das Haus entscheidet, ob der Akku ent/geladen wird. Dann wäre der gesamte flow eigtl osbsolet: du speist aus der PV immer in das Haus, von dort dann in den Akku und/oder ins Netz. Genauso beziehst du aus dem Netz und lädst bei Bedarf den Akku. Irgendwie klingt das für mich nicht logisch.
Hallo.
Danke für Infos.
Aber meine Konfig ist so, PV-WR am Netz, logisch. Akku-WR parallel zu PV und Hausnetz. Heist, das PV alles ins Netz oder Haus speist incl. Akku-WR. Deshalb meine Frage. Weil Verbindung Haus-Akku gibts ja nur in eine Richtung in deiner Config.
Was aber bedeutet bei dir dann Akku von Grid gespeist?
Zitat von: satprofi am 05 April 2024, 14:51:02Aber meine Konfig ist so, PV-WR am Netz, logisch. Akku-WR parallel zu PV und Hausnetz. Heist, das PV alles ins Netz oder Haus speist incl. Akku-WR. Deshalb meine Frage. Weil Verbindung Haus-Akku gibts ja nur in eine Richtung in deiner Config.
Für mein Verständnis (bitte entsprechend korrigieren), du hast
- einen Wechselrichter (A), welcher die Leistung der PV in das Hausnetz einspeist; wenn der Hausverbrauch kleiner als der Bedarf ist, würde die "Überproduktion" in das Netz des EVU eingespeist werden (wenn es keinen Akku gäbe), richtig?
- einen weiteren Wechselrichter (B), welcher an das Hausnetz angeschlossen ist und den Akku lädt bzw entlädt
- eine "intelligente Messeinrichtung" (vulgo Stromzähler), welcher dir Werter für Verbrauch/Einspeisung liefert und deine Verbindung Hausnetz<->EVU/Grid darstellt
Du hast demnach (mindestens) folgende Werte:
- PV-Leistung, welche in das Hausnetz (durch WR A) eingespeist wird
- Akku-Ent/Ladeleistung, welche in das/aus dem Hausnetz gespeist wird (durch WR B; weiterhin gibt es Akkuladestand usw)
- Netzverbrauch/einspeiseleistung vom Stromzähler
Zitat von: satprofi am 05 April 2024, 14:51:02Was aber bedeutet bei dir dann Akku von Grid gespeist?
Der Akku wird nicht durch die PV Anlage (via WR) sondern über Netzbezug geladen (im Prinzip ist dies aus dem Hausnetz bezogen)
Richtig. aber wenn du dir meinen screenshot ansiehst dann passen die balken u. werte nicht. die 3329 gehen nicht ins haus, sondern sind in den 4356 includiert.
Danke für die Rückmeldung. Basierend darauf hier eine Testversion für deinen Fall. Die Datei muss in den gleichen Ordner wie pvvis - wahrscheinlich unter
/opt/fhem/www/ftui/components/pvvis
Und du kannst es parallel zum Standard-pvvis-Modul nutzen - und rufst 'deine' Version dadurch auch mittels
<ftui-pvvis-satprofi>auf.
Basierend auf deinen Screenshot habe ich dieses Beispiel genutzt:
<ftui-pvvis-satprofi
charge-discharge="3329"
battmax="2500"
soc="46"
produce="1814"
pvmax="9000"
feed-receive="-4356"
sun-icon="pvsun"
grid-icon="pylon2"
unit-soc="%"
unit-value="W"
has-no-grid-feed>
</ftui-pvvis-satprofi>Du musst has-no-grid-feed setzen - dadurch wird der Strang PV->Netz ausgeblendet. Der Rest folgt den Vorgaben/Doku aus #289 (https://forum.fhem.de/index.php?topic=119440.msg1260914#msg1260914) (insb die Werte-Definiton für feed-receive und charge-discharge).
vielen herzlichen Dank!
Zitat von: satprofi am 15 April 2024, 11:43:19vielen herzlichen Dank!
Läuft das so wie du es dir vorstellst? Passen die Werte/Berechnungen zu den Daten, die du anlieferst?
pull ist durch. ;)
Zitat von: yersinia am 15 April 2024, 11:45:09Läuft das so wie du es dir vorstellst? Passen die Werte/Berechnungen zu den Daten, die du anlieferst?
yessscircle_screenshot_1_FTUI.jpeg
Ich habe versucht , das mit meiner E3DC / GO-E Konstellation umzusetzen. Sieht ganz gut aus, aber ein paar Kleinigkeiten wären da noch.
- müsste bei Solarproduktion nicht die Sonne "leuchten". Derzeit ist sie dunkel.
- die Einheit für den Ladung des Autos müsste entweder in kW lauten (das reading aus dem Go-e) wird in KW ausgegeben oder das reading müsste im Code umgerechnet werden. Wie macht man das ? Durch das Komma, ergibt sich auch ein Komma im Hausverbrauch.
- der Parameter "no-wb-in-home" scheint nicht zu funktionieren
-die Kalkulation für die Ladezeit des Akkus wird nicht ausgerechnet. Der Parameter calc-bat-remain-time zeigt keine Wirkung. Ohne Parameter wird trotzdem 0.0 in der Batterie angezeigt.
- Könnte man den Hausverbrauch aus einem Reading direkt anzeigen lassen (der S10 gibt es ja aus)
<!-- pviis-->
<ftui-grid-tile row="1" col="2" height="7" width="7">
<header>Solaranlage</header>
<ftui-pvvis
width="400px"
[charge-discharge]="S10:battwatt"
battmax="19500"
[soc]="S10:battsoc"
[produce]="S10:sunwatt"
[wb-feed]="myGoE:KW_charging_measured"
pvmax="12580"
[feed-receive]="S10:gridwatt | multiply(-1)"
grid-icon="pylon"
unit-soc="%"
unit-value="W"
sun-icon="sun"
calc-bat-remain-time
no-wb-in-home>
</ftui-pvvis>
</ftui-grid-tile>
Zitat von: prenzela am 25 April 2024, 16:27:23- müsste bei Solarproduktion nicht die Sonne "leuchten". Derzeit ist sie dunkel.
Der Opacity Wert müsste bei 0.42 liegen, also relativ Dunkel. Das hängt von der produzierten Leistung (3576) im Verhältnis zur maximal möglichen Leistung (12580) ab. Die rechnung für die Deckkraft ist 0.2 + (0.8 * (aktuelle Leistung/Maximalleistung))
Zitat von: prenzela am 25 April 2024, 16:27:23- die Einheit für den Ladung des Autos müsste entweder in kW lauten (das reading aus dem Go-e) wird in KW ausgegeben oder das reading müsste im Code umgerechnet werden. Wie macht man das ? Durch das Komma, ergibt sich auch ein Komma im Hausverbrauch.
Entweder userReading in FHEM nutzen oder per pipe in W umrechnen.
[wb-feed]="myGoE:KW_charging_measured | multiply(1000)"Zitat von: prenzela am 25 April 2024, 16:27:23- der Parameter "no-wb-in-home" scheint nicht zu funktionieren
Pvvis weiss nicht, dass es hier kW von W abzieht (3576 + 3087 + 1845 - 7.17 = 8500.83); neu beobachten wenn die Einheiten einheitlich sind.
Zitat von: prenzela am 25 April 2024, 16:27:23-die Kalkulation für die Ladezeit des Akkus wird nicht ausgerechnet. Der Parameter calc-bat-remain-time zeigt keine Wirkung. Ohne Parameter wird trotzdem 0.0 in der Batterie angezeigt.
Dafür benötigt pvvis den Parameter ba
tmax - siehe auch die Parameter-Beschreibung in #289 (https://forum.fhem.de/index.php?topic=119440.msg1260914#msg1260914):
batmax="19500"Zitat von: prenzela am 25 April 2024, 16:27:23- Könnte man den Hausverbrauch aus einem Reading direkt anzeigen lassen (der S10 gibt es ja aus)
Könnte man bestimmt, ist aber derzeit nicht vorgesehen - und war auch bisher nicht gefordert. Könnte aber schwierig werden zwischen "Berechnung im Widget" und "kommt von FHEM" zu unterscheiden. Wenn gesteigertes Interesse bestehen sollte, könnte man über eine Lösung nachdenken.
<!-- pviis-->
<ftui-grid-tile row="1" col="2" height="7" width="7">
<header>Solaranlage</header>
<ftui-pvvis
width="400px"
[charge-discharge]="S10:battwatt"
batmax="19500"
[soc]="S10:battsoc"
[produce]="S10:sunwatt"
[wb-feed]="myGoE:KW_charging_measured | multiply(1000)"
pvmax="12580"
[feed-receive]="S10:gridwatt | multiply(-1)"
grid-icon="pylon"
unit-soc="%"
unit-value="W"
sun-icon="sun"
calc-bat-remain-time
no-wb-in-home>
</ftui-pvvis>
</ftui-grid-tile>
Danke, gerade getestet. Der Parameter "no-wb-in-home" funktioniert jetzt auch. War zuerst etwas verwirrt, da nach Aufruf der Seite der Gesamtverbrauch angezeigt wird, nach dem nächsten Update der Readings ist es richtig. Könnte man den Zeitraum verkürzen, dass gleich nach dem Aufruf der Seite die Rechnung durchführt und die richtigen Werte angezeigt werden.
Dann habe noch eine Frage (eines Einsteigers). In #15 ist der Code und ein Screenshot einer Chartdarstellung ersichtlich.
Bei mir ist der Chart leer. Was müsste denn da für Log, File und Spec angeben werden Auf was referenziert das ? Was müsste ich hier einstellen um Hilfe zu bekommen ?
<ftui-grid-tile row="6" col="2" height="5" width="10" shape="round">
<header>PV-Anlage / Grafik</header>
<ftui-chart height="320px" width="100%" popup-target="pvleistung">
<ftui-chart-data label="Verbrauch" log="logdb" file="HISTORY" spec="S10:homewatt"
fill background-color="#ffcc0050" color="#ffcc00" point-radius="0"></ftui-chart-data>
<ftui-chart-data label="PV-Leistung" log="logdb" file="HISTORY" spec="S10:Leistung"
fill background-color="#00cc3350" color="#00cc33" point-radius="0"></ftui-chart-data>
</ftui-chart>
</ftui-grid-tile>