Redesign PV Mode

[andig]

Wie von @naltatis angekündigt wollen wir weitere Verbesserungen am neuen UI Design durchführen.

Eine der "Krücken" ist der sehr technisch benannte "Min+PV" Modus- letztlich unterbrechungsfreies PV-Laden. Darüber hinaus trägt auch der "PV" Modus seinen Namen mittlerweile zu unrecht, ist es doch auch der Modus in dem Zielladen, variable Tarife minSoC etc. relevant sind.

Die folgenden Gedanken spielen beim Redesign eine Rolle:

• genau ein "smarter" Lademodus mit verschiedenen Customizingmöglichkeiten (die auch persistiert werden)
• passender Name, z.B. "Smart" oder "Auto" - damit ändert sich die Modusauswahl auf soetwas wie Off Smart Fast

Anpassungsmöglichkeiten:

• unterbrechungsfreies Laden (analog "min" heute)
• jahreszeitliche Konfiguration: kein Netzbezug vs. keine Einspeisung (PV mit Null-Einspeisung #3448 (reply in thread))
• zusätzliche Nutzung der Batterie (siehe "Assisted PV" (war: Schaltfläche zum Laden mit morgendlichem Reststrom im Speicher / Battery-assisted PV) #3255, Szenario weiter zu detaillieren)
• feste Phasenkonfiguration (siehe Allow phase selection / disabling phase switching #3482, ggf. aber auch unabhängig von PV denkbar)

Lasst uns bitte über diese Ziele reden und nicht über die technischen Lösungen um da hin zu kommen!

[premultiply]

Mir erscheint die Reduktion auf einen Smart-Modus ohne separaten reinen Überschussmodus für mich nicht so richtig praxisgerecht.
Jedesmal in vielen Optionen Detailoption rumstellen möchte ich eigentlich nicht.

Ich persönlich brauche:

• So schnell wie möglich
• "Smart" (konfigurierbar) z.B. mit "Heimspeicher-Boost"
• Reines Überschussladen

[CarstensCar]

Auf FAST würde man stellen müssen, wenn ich nach Sonnenuntergang, also komplett mit Netzstrom, laden wollte.

Die Unterstützung der Hausbatterie würde ja über bufferSoC gesteuert. lt. Beschreibung

bufferSoC: 80 # Hausbatterie wird oberhalb SoC 80% als Puffer genutzt

Wenn ich also den bufferSoC nicht auf 100% stehen habe, wird auch aus dem Speicher geladen. So verstehe ich das.

[iot4all]

Auf FAST würde man stellen müssen, wenn ich nach Sonnenuntergang, also komplett mit Netzstrom, laden wollte.

und nicht zu vergessen im Winter bei wenig bis keiner PV

PV+ halte ich für keine gute Idee. Es geht ja um Modus-Reduktion.
Ein FAST deckt PV-Überschuss immer mit ab, sofern die Ladeleistung hoch genug eingestellt ist. Deshalb würde ein Ampere-Schieberegler im FAST mehr Sinn machen, um dort z.B. im Winter langsamer zu laden und die geringere PV-Produktion über lange Zeit mitzunehmen.

[Pihupt]

Guter Mann 👍

[torstenwiese]

Da die IEC-Kommunikation sehr eingeschränkt ist gibt es zwischen "Stop" durch Easee-App oder "Stop" durch evcc keinen Unterschied (C1->C2->B1). In beiden Fällen (identischen Fällen) kann das Fahrzeug keinen Energiebedarf anmelden (B1).

Das was du beschreibst kann eigentlich nur funktionieren wenn das Fahrzeug von sich aus trotz Status B2 keine Energieanforderung stellt bzw. trotz C1 nicht wirklich lädt und erst zum Zeitpunkt der Vorklima entsprechend aufwacht bzw. Strom zieht. Seitens des LPs ist dabei aber dauerhaft die PWM aktiv (B2).

ich denke das wird zu lang hier in diesem Thread. :-)
ich mach mal unter "Allgemein" einen seperaten Thread hierzu auf.

[Rossilio]

Einen Ampere-Schieberegler im "Fast" Modus würde ich mir auch sehr wünschen, um den Ladestrom individuell, aber dann konstant einstellen zu können.
Das wäre für mich auch von besonderer Bedeutung, da ich aktuell aufgrund eines sehr lahmen Netzbetreibers die Anlage noch auf Nulleinspeisung laufen habe und deshalb je nach Wetter evcc umkonfigurieren muss, um den maximalen Ladestrom tagesabhängig einzustellen.

[Mr-Watchdog]

Ich finde die Idee super, die Optionen zu vereinfachen, und auch für Laien zu verständlicher zu machen. Ich habe mir bisher schwer getan meiner Liebsten zu erklären, warum die bisherigen Modi "Sofort" und "Min" heißen, und warum sie "PV" nicht nutzen soll, obwohl wir doch eine PV-Anlage haben (weil wir das reine Überschussladen wegen zu kleiner PV-Anlage und 3-phasiger Wallbox nie nutzen könnten :-( )

Für mich würden folgende Optionen reichen:

• Fast (Laden mit maximaler konfigurierter Ladeleistung)
• Smart (bisheriges Min+PV, bei dem versucht wird den PV-Strom bestmöglich zu nutzen - vgl. auch jahreszeitliche Konfiguration)
• Off

Super finde ich auch die Idee eines "Jahreszeitenmodus", den man 1x pro Jahr umstellen kann (und 1x pro Jahr wieder zurückstellen), und ansonsten die Bedienung so einfach wie möglich hält...

[TRON4R]

Sorry, aber mir geht es genau andersherum. Ich lade - selbst jetzt im Winter - immer nur mit PV und nie mit Min+PV. Ich fände es jetzt schwierig, wenn der PV-Modus ersatzlos wegfällt und Min+PV dann in Smart unbenannt wird.

Dann müsste m.E. zumindest auf derselben Ebene (und bitte nicht in einem Untermenü!) ein Regler vorhanden sein, mitdem ich einen Min-Wert einstellen kann, wenn ich zum reinen PV-Überschussladen noch etwas festen Anteil dazugeben will.

Irgendwo in einem Untermenü (z.B. versteckt hinter dem Regler) dann einstellen zu müssen, dass für mich Smart heute ohne "Min" erfolgen soll, empfände ich persönlich als Verschlechterung.

Wobei man vielleicht dieses Untermenü, was wir jetzt haben, statt über das Riesendropdown von 0,125 bis 32 A den Ladestrom einzugrenzen und nachzuregeln, dann gleich mit umstrukturieren könnte.

Denn sonst wird es unübersichtlich, wenn man zwei "Mindestströme" hat. Einmal den jetzigen Mindeststrom, der vorgibt, wann die Wallbox überhaupt angehen darf, weil das Auto z.B. mindesten 6 Ampere. Und dann den Mindeststrom, den man mit Min+PV mindestens permanent ins Auto laden möchte. Das kann dann die Nutzer auch schnell verwirren, was denn jetzt was ist.

[hyperbart]

@SolarPowerEV yeah i feel you, I have partially the same things. But I can not charge my car with solar only. Are you retired? Can you cover your kilometers with PV only? 😮

What I do now is during winter:
I set the maximum amperes for my Alfen at 3 x 6A when the sun goes down (script).
I set the car with the planner to a minimum SoC of 70 percent
I arrive at home
I plug the car in, let it charge during the night, normally it will get to the 70 percent when the next day starts but sometimes it does not achieve 70 pct after a night of charging.
In the morning if it is still connected I check the SoC, if it is not at 70pct I drop the planner to a number which it already got and then let it continue to charge with solar, if it is not connected I switch to solar only

[torstenwiese]

weiteres Szenario für einen automatisierten Ladeprozess:
Vormittags zu Hause, Mittags mit Auto weg. Der Hausspeicher aktuell braucht nicht gefüllt zu werden, kann er tun wenn das Auto weg ist.

PV-Prio: pvPower minus homePower = chargePower

[andig]

@torstenwiese

Verstehe ich nicht. Genau das hatte ich doch eingangs unter

zusätzliche Nutzung der Batterie

geschrieben. Was willst Du abweichend davon haben?

[torstenwiese]

@torstenwiese

Verstehe ich nicht. Genau das hatte ich doch eingangs unter

zusätzliche Nutzung der Batterie

geschrieben. Was willst Du abweichend davon haben?

@andig “zusätzliche Nutzung der Batterie hab ich für den Use case der morgendlichen Überführung des Reststroms von der Hausbatterie in den EV Batterie verstanden.

mit diesem Szenario geht es darum, dass man die gesamte PV Energie abzüglich des aktuellen Verbrauches im Haus (ohne Berücksichtigung der Batterie und dessen SOC) zum Laden des Autos verwenden kann.
oder anders ausgedrückt, PV Laden und dabei prioritySoC und bufferSoC ignorieren. Bin aber nicht sicher, ob dies hier in diesem langen Verlauf schon mal vorkam. ;-)

[andig]

@VolkerK62

Ich hab gerade mit meiner Nachbarin Lieschen Müller gesprochen ;-).
Sie würde C2 so einstellen, dass das Auto möglichst ohne Unterbrechung mit soviel PV-Strom wie möglich geladen wird und spätestens morgen Früh um 7 Uhr SoC 80 erreicht hat. Eventuelle Ladeverluste sind ihr während der PV-Phase egal.

Zwei Antworten:

1. Lieschen Müller will m.E. ganz sicher nicht "C2", sondern sie will morgens das Auto voll haben und dabei günstig laden (=PV). Genau das bildet mein Vorschlag ab, also kein Wiederspruch.
2. "dass das Auto möglichst ohne Unterbrechung mit soviel PV-Strom wie möglich geladen wird" ist tatsächlich ein Zielkonflikt aus "Viel PV" vs. "wenig Unterbrechung". Der lässt sich nicht allgemeingültig und ohne Planner/Wettervorhersage lösen. Daher braucht es für die Anwender eine einfach Möglichkeit das Verhalten zu beeinflussen. Ein paar Vorschläge dazu habe ich oben gemacht.
   Update das gilt zumindest so lange, bis wir eine Planner Komponente haben die weitere Verbesserung bringen könnte.

Was habe ich übersehen?

[VolkerK62]

Ok, das mit Lischen Müller und C2 war nicht zielführend. Zurück zum Anfang :-)
Der Wunsch wäre, das man verschieden Anwendungsfälle (siehe z.B. meine Liste #3530 (reply in thread)) auf einfach Art auswählen kann, ohne in der Konfig (yaml) Änderungen vornehmen zu müssen.
Ich muss dazu sagen, das ich persönlich mit dem aktuellen Zustand völlig zufrieden bin, aber ich habe auch keine besonderen Umstände.

[andig]

ohne in der Konfig (yaml) Änderungen vornehmen zu müssen.

Das ist eh klar. Ich sehe da aber keine Abweichung vom Vorschlag. Ob/dass ich an allen Parametern (ständig) jenseits einer statischen Grundkonfiguration rumdrehen will kann man aber durchaus auch kritisch hinterfragen. Überleg mal kurz, was 98% der Anwender mit einer Wallbox machen (="An")...

[andig]

@iot4all

Nachtladen, Awattar/Discovery-Laden und morgendliche Ladebereitschaft sind Dinge, die schwerlich zu PV und Fast passen. Willst Du die zukünftig außen vor lassen?

1. Ich verstehe Du möchtest "Nachtladen". M.E. ist ads der heutige "minPV" Modus, im Redesign wäre das "Smart" mit "unterbrechungsfrei". Was übersehe ich dabei?
2. Awattar/Discovery-Laden haben wir heute schon und wäre Teil von Smart. Was fehlt?

[iot4all]

min PV => smart ist ok

Ich meine allerdings bei smart auch "nicht unterbrechungsfrei", also mittimer-Integration, um NL und automatisierte WB-Stromfreigabe für Vorklima abzudecken.

[andig]

Ich meine allerdings bei smart auch "nicht unterbrechungsfrei"

Das war Teil meines Vorschlags.

also mittimer-Integration

Hatten wir eben schon rausgearbeitet: #3586

#3586

Automatisiert haben wir schon, Timer fehlt #3558 (reply in thread). Ist erstmal kein Widerspruch zum eingangs gemachten Vorschlag.

[andig]

@torstenwiese @iot4all

bereitstellen von 6a ohne zu Laden, bzw. Sleep Modus, welcher den EVCC Server zwar laufen lässt, aber die Steuerung der Wallbox unterbindet.

Nein, das ist eine falsche Annahme. Die Box kann nur dem Fahrzeug Energie anbieten oder nicht. Das hat absolut nichts mit der Steuerung durch evcc zu tun.

Immer diese harten Worte wie "nein", "falsch" usw.. Etwas mehr konstruktive Denke wäre hilfreich.

@premultiply hat- wie an anderer Stelle schon geschrieben- recht. Es ist halt einfach nicht möglich; die Einschränkung liegt in der Schnittstelle Wallbox-Fahrzeug, nicht bei evcc. Und bitte entschuldigt, aber das hat mit konstruktiv nix zu tun.

[premultiply]

Hier mal einen Überblick über die Optionen bezüglich Vorklimatisierung um die diversen Diskussion (und Mutmaßungen) mal auf eine fachlich sinnvolle Ebene zu führen:

1. Es gibt zwei Möglichkeiten wie sich ein Fahrzeug grundsätzlich bei einer (im Fahrzeug) programmierten oder via App-API/Schlüssel angetriggerten Vorklimatisierung verhält:
   1.1. Die VK startet nur wenn das Fahrzeug an einem freigebenen Ladepunkt angeschlossen ist. Dabei wacht es ggf. selbstständig auf und wechselt in den Zustand C1. Wenn bereits parallel ohnehin bereits aktiv geladen wird ändert sich am Zustand selbstverständlich nichts.
   1.2. Die VK startet unabhängig vom Netzanschlussstatus im Zweifelsfall mit Energie aus der Traktionsbatterie. Bei freigegebenem Netzanschluss ansonsten identisch zu 1.1.

2. Um den Zustand der VK zu bestimmen gibt es also nur die Optionen
   2.1. zunächst die Verfügbarkeit von Netzstrom sicherzustellen und dann die VK ("selbst") aktiv anzutriggern
   2.2. den VK-Zustand passiv abzufragen und ggf. "rückwirkend" den Netzstrom freizugeben.

evcc hat Stand heute die Option 2.2. implementiert. Dazu wird prinziptbedingt ein Fahrzeug der Art 1.2. benötigt.
Variante 2.1. würde letztendlich eine timer- oder manuell gesteuerte Antriggerung seitens evcc über die Fahrzeug-API erfordern, würde dann aber auch Fahrzeuge vom Typ 1.1. die die entsprechenden Fahrzeug-API-Voraussetzungen mitbringen unterstützen.

Fahrzeuge ohne API-Anbindung bzw. ohne die entsprechenden API-Eigenschaften können wegen der grundsätzlichen Nichtunterscheidbarkeit von Netzanforderungen seitens des Fahrzeugs nur mit Netzstrom vorklimatisieren wenn (zumindest) zum gewählten Zeitpunkt (plus ausreichender fahrzeugabhängiger Vorlaufzeit!) der verbundene Ladepunkt freigegeben ist.
In evcc heisst das Stand heute Ziel-SoC 100% und Lademodus Sofort oder Min+PV.

[iot4all]

Danke!

[Tobias-N7]

Eine Unterteilung in 4 Modi halte ich auch für am Sinnvollsten um für Überschussladen nicht die Konfiguration ändern zu müssen.
Also dann in Reihenfolge nach Ladegeschwindigkeit von langsam nach schnell sortiert:

• Aus
• PV
• Smart
• Ein

PV strebt reines Überschussladen ohne Netzbezug an, wenn man weiß das man länger an der Station hängt und Smart lädt intelligent unter Berücksichtigung des Fahrzeug SoC, Hausspeicher SoC, Jahreszeiten, Wetterprognose, usw.

Max SoC usw. sollten aber für alle Modi unabhängig gelten.

Aktuell lade ich noch nicht mit evcc sonder mit einem Python Script was mir ermöglicht den Fahrzeug SoC mit für die Berechnung des maximalen Netzbezugs zu verwenden. So habe ich auch bei schlechtem Wetter immer noch ausreichen Reichweite und schalte das dann nur über die Wintermonate wo eh nicht genug herum kommt komplett ab. Wenn es richtig viel Überschuss gibt lade ich so auch mal über 80 % hinaus.

        #Toleranzfunktion Quadratisch
#       Tolerance = -500+(100-SoC)*(100-SoC)/2
        #Toleranzfunktion Kubisch
        Tolerance = -500+(100-SoC)*(100-SoC)*(100-SoC)/200

Den Offset von -500 W braucht es hauptsächlich, weil die API die ich Nutze etwas zäh ist und mir nur 8 und 16 A Ladestrom bietet, sodass ich dann lieber mehr einspeise als mehr zuzukaufen.

[naltatis]

Ich fasse die Diskussion hier noch mal aus meiner Sicht zusammen. Vorab schonmal ein großes Danke für eure Vorschläge, Ideen und Anregungen.

Wie @andig eingeführt hat ist unsere Motivation die Moduswahl zu vereinfachen und vor allem für normale Nutzer:innen besser verständlich zu machen. Zugleich wollen wir, mehr Kontrolle in die UI bringen um auch auf individuelle Bedürfnisse eingehen zu können - quasi für uns Pro-User. Das ist ein Spagat, aber ich bin zuversichtlich, dass wir das hinbekommen :D

1. Kein Bedarf für "nur PV" und "Min+PV" als gleichberechtigte Modi
   Auch wenn es niemand explizit gesagt hat scheint aus der Diskussion klar zu sein, dass das jetzige Nebeneinander von PV und Min+PV nicht notwendig ist. Das heißt nicht, dass die Min+PV Funktionalität überflüssig ist. Aber die Notwendigkeit für "unterbrechungsfreies Laden", große/kleine Timeouts, mehr/weniger Netzbezug ist eher etwas was abhängig von der eigenen Hausinstallation (kleine PV, empfindliches Auto) einmal bei der Einrichtung oder abhängig von der Jahreszeit verstellt werden muss.

2. Sofort (Schnell, An, ...) sollte genau so bleiben
   Es gab keine Argumente gegen diesen Modus der die Wallbox wieder zu einer dummen, ungesteuerten Steckdose macht. Es gab den Wunsch die maximale Ladeleistung und Phasenanzahl über die UI zu beschränken. Hier ist mir der Anwendungsfall (manuelles Lastmanagement, manuelle Lademengenplanung) noch nicht ganz klar.

3. Aus
   Hier gabs keine Gegenargumente. Allerdings die Diskussion ob "AUS" gleichbedeutend "Wallbox AUS" ist oder eher "evcc-Steuerung AUS" bedeuten sollte. Ich selbst nutze den AUS-Modus bspw. nie im Alltag.

4. Unterschiedliche Bedürfnisse beim Smart/PV/... Modus
   Hier ging es ordentlich durcheinander. Ich liste mal die Themengebiete über die geredet wurde:

• Hausspeicher: Hier gabs den Wunsch nach optionaler Mitverwendung des Heimspeichers wenns mal schneller gehen soll.
• Zeittarife: Laden zu bestimmten Uhrzeiten (Nachttarif, Tibber und co.) erlauben.
• Netzbezugs-/Aktivierungsregeln: Es wurden sich unterschiedlich starke/schwache PV Konfigurationen gewünscht um bei wechselhaften Tagen bei Bedarf mehr Energie laden zu können.
• Zielladen / Fahrzeug API: Hier gabs unterschiedliche Erfahrungen. Zielladen als Konzept funktioniert für mich bspw. vor Reisen sehr gut. Gerade bei Fahrzeugen mit unzuverlässigerer API oder Netzwerkbedingungen vor Ort ist die Funktion aber verständlicherweise nicht für jeden gleich gut geeignet.

Mir fällt es gerade noch schwer einen expliziten zusätzlichen Modus, der nicht erklärungsbedürftig ist, daraus abzuleiten. Existiert ein Speicher könnten wir ggf. sowas wie einen Akku-Turbo-Button der UI hinzufügen. Für Zeittarife wird's eine Konfigurationsmöglichkeit geben müssen. Soetwas wie "Lade auch wenns günstigen Netzstrom gibt". Gerade weil evccs Kern Überschussladen ist würde ich so etwas als "Zusatz" zum PV-Laden sehen, nicht als separaten Modus.

Ich würde vorschlagen, dass wir die Frage nach den konkreten Modus-Namen nicht weiter hier in einer offenen Diskussion führen. Auf Basis des bisherigen Inputs (an, aus, pv, pv+, smart, smart+, custom, [mein-eigener-modus], (akku)boost, schnell, fast, sofort, ...) würden wir mal einen konkreten Aufschlag machen über den wir dann, bspw. im Rahmen eines PRs, weiter diskutieren können.

[int5749]

@int5749 da muss man dann aber auch dran denken :-)

Nein, eben genau nicht, wenn man dies - wie bei mir - smart mit einer Hausautomatisierung steuern kann. Daher würde ich die Funktion vermissen, den Button nicht,

[naltatis]

Ich wollte mit meiner Anmerkung gar nicht gegen ein Ausschalten über UI oder API argumentieren. Habe nur festgestellt, dass der in meinem Alltag keine Rolle spielt.

[int5749]

Passt ja auch und mir ging es nur darum, das es eben auch anders sein kann ;-)

[VolkerK62]

Mein Loadpoint steht auf "off".
Schön wäre, wenn der beim Fahrzeug hinterlegte (onIdentify) Modus auch bei Single-Fahrzeugen funktionieren würde. Dann wäre bei unbekannten Fahrzeugen automatisch "off" und bei bekannten automatisch der hinterlegte eingestellt.

[ABBolle]

2. Sofort (Schnell, An, ...) sollte genau so bleiben
   Es gab keine Argumente gegen diesen Modus der die Wallbox wieder zu einer dummen, ungesteuerten Steckdose macht. Es gab den Wunsch die maximale Ladeleistung und Phasenanzahl über die UI zu beschränken. Hier ist mir der Anwendungsfall (manuelles Lastmanagement, manuelle Lademengenplanung) noch nicht ganz klar.

Ich hatte das Beschränken der Phasenanzahl in einigen Diskussionen (auch außerhalb dieses Threads) eher im Zusammenhang mit dem PV-Modus bei wechselnder Bewölkung mitbekommen, um ein häufiges Unterbrechen der Ladung zu vermeiden. Bei unserem ID.3 führen solche Unterbrechungen beispielsweise manchmal dazu, dass die Ladung dann irgendwann vom Fzg verweigert wird (wenigstens mit dem aktuellen Softwarestand).

[naltatis]

Was wäre deine Lieblingskombination?
Als Stimmungsbild würde ich euch einmal bitten eure persönliche Modus-Lieblingskombination kurz unter diesen Thread zu schreiben. Name der Modi und, falls erklärungsbedürftig, dazu schreiben was in dem Modus passieren soll. Also keine Allgemeingültige Lösung mitdenken, sondern nur euren privaten Anwendungsfall.

[torstenwiese]

• PV mit Unterkategorien wie normal (pv), Unterbrechungsfrei (min+pv), Priorisiert (ignoriert Hausbatterie)
• Sofort
• Smart: Zielladen mit chargedenergy ; Entladen der Hausbatterie
• Aus (keine Steuerung durch EVCC) - nur im Winter mit Zeitplan

[iot4all]

• Aus (Laden gesperrt, EVCC weiter aktiv)
• PV (Überschuss mit Abschalten, Überschuss mit Durchladeoption (= min+PV, dabei min A per slider vorgebbar))
• Smart (Nachtladen mit timer-Vorgabe)
• Sofort (mit A- und Phasenvorgabe per Slider/Button)

Die Freigabe für morgentliche Vorklima VK sollte in jedem Mode außer "Aus" zuschaltbar sein.

[VolkerK62]

• Aus (für unbekannte Fahrzeuge keine Ladung möglich, bekannte Fahrzeuge Wechsel in den bei Fahrzeug hinterlegten Modus)
• PV (reiner Überschuss ohne irgendwelchen Schnickschnack)
• Smart (mit diversen Einstellungen: 1p oder 3p; einstellbar min/max Current; nur solange (auch mit Netzbezug) laden wie (einstellbarer) Überschuss vorhanden ist)
• Sofort (volle Pulle)

[binderth]

ich denke, folgende Modi sind sinnvoll:

1. AUS: damit gehe ich sicher, dass egal wie und welches Auto angesteckt ist, nicht geladen wird
2. AN: Damit gehe ich sicher, dass egal was gerade passiert, das Auto mit der maximalen Geschwindigkeit geladen wird.
3. PV (Überschuss): Hier wird durch Einbeziehung fester Parameter ein PV-Überschuss-Szenario festgelegt, bei dem dann der Überschuss geladen wird
4. Smart (oder Profi): Hier möchte ich über diverse Konfigurationen in der Lage sein, aus diversen Szenarien zu wählen, bzw. zur Laufzeit Parameter ändern, die diesen Ladevorgang smart machen

Erklärung:
Ich denke, das die Szenarien 1-3 diejenigen sind, die "unbedarfte" Nutzer dann am häufigsten nutzen werden. AN/AUS, wenns halt schnell gehen muss und PV wird einmal definiert, in welcher Situation das zum tragen kommt.
Im Smart oder Profi Modus kann man mehr einstellen und dynamisch reagieren.

ad 1
Einfach AUS, d.h. kein Laden wird stattfinden, egal was passiert.

ad 2
Hier wird mit der einmal definierten Konfiguration (Anzahl Phasen, Maximale Ampere) geladen.

ad 3
Hier wird ein PV-Überschuss unter gut dokumentierter Berücksichtigung von Parametern wie heute z.B: residualPower, bufferSoC, prioritySoC, ... errechnet und damit geladen.

ad 4
Im Smart/Profi-Modus wünsche ich mir, dass alle Parameter dynamisch per API zur Verfügung gestellt werden und änderbar sind. Im Endeffekt kann man "von außen" dann 1-3 nachstellen und weiteres gewünschtes Verhalten nachstellen.
Wenn ich wirklich alles wünschen könnte, wäre meine (fachliche) Anforderung glaub ich am besten in diesen Parametern zusammengefasst:

• Laden erlaubt (ja/nein - ggf. auch auch einfach Wechsel in Modus AUS)
• Mindest-SoC (wieviel Prozent/km ich mindestens geladen haben möchte, egal was)
• Batterie-Entnahme erlaubt (ja/nein - egal, was bufferSoC, prioritySoC,... sagen)
• maximale Batterie-Entnahme (wieviel kW ich der Batterie entnehmen kann/will)
• erwarteter (Rest-) PV-Überschuss in kWh für den Tag (d.h. ich berechne außerhalb evcc den zu erwarteten Überschuss)
• Ziel-Laden (in SoC oder km; gerade für Unbedarfte finde ich km-Laden verständlicher)
• maximale Grid-Entnahme (wieviel kWh/Tag oder kW ich Netzbezug haben darf - für Winter/kleinere Anlagen)

und die vielen "kleinen" Parameter bitte alle per API änderbar, wie z.B.

• wie lange die Batterie/das Grid zur Überbrückung etwaiger Wolken genutzt wird (aktuell enable bzw. disable threshhold bzw. delay)
• wie lange Zeit zwischen diversen Umschaltungen (1p <> 3p, an/aus, ...) sein muss
• minimale Ladestärke, maximale Ladestärke
• ...

Das Ziel des "Smart" oder "Profi" Modus ist, dass ich durch eine externe Logik oder ein EMS in der Lage bin, das Verhalten von evcc zu beeinflussen. Wenn der Smart-Modus auch ohne externe Einflüsse laufen kann, wäre das natürlich das i-Tüpfelchen, evtl. kann man diesen Wechsel im selben Modus auch durch einen Schalter beeinflussen, so ähnlich wie aktuell evtl. hems funktioniert (da ich kein sma EMS habe, weiß ich nicht, was das macht). Ich habe ein auf openHAB-basiertes EMS, welches in der Lage wäre evcc die o.g. Parameter dynamisch mitzuteilen. Das weiß z.B. auch, wann die Waschmaschine läuft oder wann die Wärmepumpe wichtiger wäre als Autoladen...

[hyperbart]

#11324 (comment)

@naltatis it's not a wireframe (far from it) but I have been giving it some thinking, what does the core team and userbase think of this:

Load balancing is a priority 0 function, if it is activated/enabled it is active on all modes. It is there to prevent electrical outages and stay within circuit limits making sure not to trip any circuit breakers.

* Mode Off
  
  * **EVSE is turned off completely, relais open or PWM control pilot = 0**

* Mode Solar
  
  * **EVSE is active, available power follows solar production minus house consumption**
  * Only surplus (Total PV Power - House consumption - battery consumption) is put in the car
  * Phases you can choose yourself 1 or 3 or auto
  * You can use the slider to choose how full your car needs to be (SoC % control, If I want to prevent my car filling up above a certain percentage because I don't want to stress my battery)
  * If it is a guest vehicle it keeps supplying power as long as there is minimum solar power 1380W
  * Not enough power? Target SoC will not be met…

* Mode MinSolar
  
  * **EVSE is active, minimum power as defined in MinSolar is delivered and if solar surplus is > minsolar it will charge with more power**
  * Same as solar but your car will start charging anyhow and extra solar will be taken with it, basic EVCC philosophy
  * Phases you can choose yourself 1 or 3 or auto
  * You can use the slider to choose how much charge your car needs to have (SoC % control, If I want to prevent my car filling up above a certain percentage because I don't want to stress my battery). EVCC is the controller, not the car.
  * If it is a guest vehicle it keeps supplying power

* Mode Smart
  
  * **Charge to target SoC with efficiency on low power/solar/cost**
  * Smart contains a combo of the following potential/user choice enabling options
  * My father, a regular end user at his home wants to have his car ready the next day, with a default setting so all his trips for that day are covered and he wants this as cheaply as possible
  * My neighbor wants his car, ready to drive 2 x his commute and a bit extra, default setting and he will let me know if he needs more or if there is anything specific for the next day (almost never happens)
  * My wife wants our car charged for daily trips (commute + small trips for family activities) and I want to have this as cheaply as possible
  * Planner: the planner allows you to charge as electrical efficiently, cost efficiently and CO2 efficiently as is possible
  * Set target time and target SoC for tomorrow via manual setting or via "default for this car"
    
    * Boolean 1: ON/OFF Switch in smart mode, Power Shaving: Determine required lowest power kW to charge car at low speeds over planned period
      
      * Sub choice, overrides boolean 1: "max power peak == X", where the user can enable a sub function of the loadbalancer where the max power from grid never exceeds X amount of kW, a visual indicator will be shown to show the target SoC will never be met...
      * Benefit: the car will continuously charge and the battery will be at the correct temperature and clima will use grid power.
    * Boolean 2: ON/OFF Switch for taking into account dynamic rates, if you have a dynamic rate contract you can enable this
    * Boolean 3: ON/OFF switch for solar surplus charging, if target SoC has been reached you can use this switch to fill your battery even more but you don't have to if you want to keep your battery in better shape and not use the last 10-20-30 percent

[lblabr]

Hallo! Ich bin neu hier bei Euch und interessiere mich für dafür, damit ich korrekt antworten kann, könnt Ihr kurz sagen, ob und wie Auto- vs. Batterieladen priorisert wird oder ob das in den o.g. Regeln berücksichtigt werden soll?

Gibt es eine Option eine gewisse Menge zu tanken ?

Vielen Dank und Grüße

Lars

[andig]

Siehe Doku- prioritySoC und minSoC.

[lblabr]

Lieben Dank!

[lblabr]

vlt. noch ganz kurz, lässt sich der Stromspeicher auch nach Fahrplan (Zeittarif) laden?

[andig]

Nein

[andig]

Hallo Zusammen,

es gibt ja jetzt schon eine ganze Menge Feedback. Ein Punkt der sich dabei herauskristallisiert ist ein Wunsch nach einem "PV" sowie einem "Smart" Modus. Dabei sind- je nach Feedbackgeber- beide Modi mit einer ganzen Reihe spezifischer Sondereinstellungen belegt die zumindest optional zu tätigen wären.

Was aus der Diskussion noch nicht transparent geworden ist ist der Grund für die Trennung von PV- und Smart Modi. Ist das aus Eurer Sicht:

1. einfach die bessere User Experience weil leichter auszuwählen o.ä. oder
2. seht ihr die Eigenschaften der Modi als so inkompatibel an dass sie nicht in einem Modus kombinierbar sind oder
3. weitere Gründe

Mir würde es sehr helfen, die Motivation für Eure Lieblingskombination und speziell den Split PV/Smart besser zu verstehen.

[floms79]

@Horgul123 : Meines Erachtens sollte das eben kein eigener Lademodus sein, sondern in dem "smarten" Standardmodus konfigurierbar sein. Ich bin aber immer noch der Meinung, dass man eigentlich gar keine Lademodi braucht, sondern höchtens einen Schalter An/Aus und einen Taster "Einmal schnell voll". Letzteren könnte man z.B. auch super per Home-Assistant in IOS Kontrollzentrum / Android Quick Panel platzieren. Das funktioniert mit einem Drop-Down nicht.

[Horgul123]

@floms79 Dann müsste ich aber häufiger den Smartmodus ändern. Mal min+PV, mal PV+Puffer. sind 2 verschiedene Sachen, die sich verschieden verhalten.

Idee: Aus / Smart / Max
Bei Smart ein Pop-Up, wo man aus selbst definierten Settings wählen kann oder "schnell" was selbst stricken kann

[floms79]

@Horgul123 Die Frage ist doch, wieviel Abweichung vom "Optimum" man durch einen einheitlichen SMART-Modus verliert. Dafür brauchen wir Use Cases, anhand derer wir die Varianten bewerten können. Wenn wir am Ende über max. 10% Netzbezug reden, ist das m.E. ein Wert, der keine Differenzierung rechtfertigt. Das bewertet aber sicher jeder etwas anders. Aber die Weiterentwicklung muss ganz klar einen WAF haben.

[Horgul123]

@floms79: Es gibt ja bei meinen Fällen zwei "Extreme":

1. Kein PV verfügbar -> min+PV würde bei mir 1,4kW aus dem Netz ziehen, aber immer laden
2. Etwas PV Verfügbar und 300W Puffer (z.B zwischen 1.1 und 1.7kW Überschuss) -> Er würde zwischen 0 und 300W aus dem Netz ziehen, fällt der Überschuss zu weit stoppt das laden.

Ich kann jetzt nicht beurteilen, wie kompliziert eine Implementierung wäre. Aber gefühlt würde ich bei überschaubarem Aufwand den Usern soviel Flexibilität geben wie möglich.

Ist ja auch bei dem "Aus" der Punkt. Wenn jemand "Aus = EVCC hält sich einfach raus" haben will -> Why not. kann man in den Optionen z.B. konfigurierbar machen (Aus = Kein Laden Möglich oder Aus = EVCC hält sich aus der Steuerung raus.) Auch minimaler Aufwand aus meiner Sicht :)

Und ja: Der WAF ist wichtig... Aber auch die Bequemlichkeit...... Ich kann in der Konfig was ändern. Aber via UI ist das schöner :)

[TRON4R]

Kurz mein Feedback, auch wenn der Thread etwas älter ist, aber ich wurde erst gestern über Slack auf diesen Thread aufmerksam gemacht:
Ich fände die Trennung zwischen PV und Smart deswegen gut, weil man ja gerade in den "sonnigeren" Monaten bzw. wolkenfreien Tagen oft einfach nur anstecken und Überschuss laden will, ohne groß nachdenken oder konfigurieren zu müssen und eine Option zu haben, die dann auch technisch weniger versierte Menschen (Ehepartner, Eltern, Freunde) einfach bedienen können.

Aber wenn man einen sehr wolkigen Tag hat oder sich in der Winterzeit befindet und dann andere Faktoren mitberücksichtigt werden müssen, um häufiger Umschalten zwischen Phasen oder gänzlicher Ladeunterbrechung zu vermeiden oder weil man irgendeinen Stromtarif optimieren möchte, dann wäre es gut, wenn das eben in einem separaten Modus stattfindet, den man dann an diesen Tagen vorher entsprechend konfiguriert. Daher fände ich ein Zusammenlegen der beiden Modi in einen Button keine Verbesserung der UX.

Und umgekehrt erspart es Euch unnötiges Kopfzerbrechen, diese beiden Anwendungsfälle abstrahieren und alle benötigten Eigenschaften in einem Modus kombinieren zu müssen ohne das die UX dann zu sehr leidet.

Wichtig wäre aber in jedem Fall, dass wirklich alle denkbaren Einstellungen dann über das UI möglich sind und nicht mehr die yaml benötigen.

[Pihupt]

Der Einfachheit halber sollte das Laden mittels PV keinen weiteren separaten Button bekommen.
Einfach den vorhandenen Min/PV durch 2 Regler ergänzen.

• Auswahl: 1/3 Phasen
• zusätzl. Netzbezug zum PV (Schieberegler 0-90%)

Von mir aus noch ein Wahlschalter irgendwo
Priorisierung: Hausspeicher <>Ladestation

Zum Thema, was sind die Beweggründe:
Das Fahrzeug sollte bei bewölktem Himmel ab 15:00Uhr (Feierabend) größtenteils mit PV bis 18:00Uhr voll sein (22kw Zoe).

Kein Profi o. Nerd-Modus.
Ist doch Alles schon kompliziert genug.

[Bewalticus]

Wenn man die Modi an den Benutzern ausrichten will, dann würden meiner Meinung nach 3 Modi genügen:

1. PV: Der bisherige PV Modus als Plug and Charge Modus, zum Beispiel für meine Frau 😀
2. Smart: Ziellademodus, der die Kosten minimiert. Dieser bräuchte dann die Planungskomponente zur Berücksichtigung von PV-Ertragsprognose, (Haus-)Batterieladung, Stromtarifen und Wirkleistungsbegrenzung. Die eigentliche Ladung würde am aktuellen Zustand (PV Ertrag) orientiert und die Planung müsste in regelmäßigen Abständen aktualisiert werden. Der Modus würde auch den Sofortmodus beinhalten, denn wenn das Ladeziel nah genug liegt wird auch die Hausbatterie und ggf. Netzbezug verwendet.
3. Parametrisierter Modus: Dieser ist für die Pro-Benutzer gedacht, die evcc z.B. von ihrer Hausautomatisierungslösung steuern wollen. Parameter würden dann z.B. über API gesetzt. Das Parameterset könnte z.B. folgendes enthalten:
   • Minimale Ladeleistung
   • Maximale Ladeleistung
   • Residual Power
   • Erlaube Verwendung der Hausbatterie
   • Erlaube Verwendung von Netzstrom

Der eigentliche Steuerungskern würde immer mit den Parametern arbeiten, die im parametrisierten Modus auch verwendet werden. Im PV Modus würden diese einfach folgendermaßen gesetzt: Min Ladeleistung = 0; Max Ladeleistung = ∞; ResidualPower (fest aus Config), Erlaube Hausbatterie = false; Erlaube Netzstrom = false. Im Smartmodus würden diese dynamisch gesetzt.
Es gäbe weiterhin noch das Set an "physischen" Parametern (min/max Strom, Anzahl Phasen etc.), die der Steuerungskern berücksichtigen würde.

Den Steuerungskern würde man somit von den Lademodi entkoppeln. Dies würde die Programmlogik vereinfachen. Viel Gehirnschmalz müßte man in den Smart-Modus stecken, damit dieser auch korrekt plant und auf Abweichungen reagiert.

PS: Zusätzliche Lademodi, wie zum Beispiel der Min+PV, wären damit auch ohne großen Aufwand zu realisieren.

[andig]

Die Wahrheit liegt in der Mitte. Wir haben keinen Planner für niedrigste Kosten auf Basis PV-Erzeugung (=Wetter), sondern einen einfachen "mach im letzten Moment voll" Mechanismus. Mit #2211 gibts noch variable Tarife dazu. Nicht weniger, aber auch nicht mehr...

[VolkerK62]

Beitrag gelöscht

[andig]

...und hat auch so gar nix mit PV Modus zu tun. Bitte beim Thema bleiben.

[Bewalticus]

OK, passt soweit 😀 Man muß ja nicht alles auf einmal haben.

@andig und @premultiply , könntet ihr vll. noch ein kurzes Statement abgeben, ob ihr bezüglich meiner Idee, die Ladesteuerung von den Modi zu trennen, offen seid. Falls dem so ist, würde ich eine entsprechende Diskussion aufmachen. Das wäre zwar eine größere Änderung, könnte aber den Code vereinfachen und modularer machen.

[florianmw]

Hallo,
habe gerade erst die Diskussionsecke gefunden.. Blöderweise vorher ein Feature Request geschrieben, dass ich mir einen Modus Manuell wünsche oder, dass der Modus "Aus" die evcc Steuerung deaktiviert. Sehe gerade, dass ich mit "Aus" nicht allein bin. Würde mich einfach hier an der Diskussion beteiligen, das Ticket kann gerne auch wieder geschlossen werden.

Zu den Modi:
Ich würde mir wünschen, dass es so einfach wie möglich wird. Nutze derzeit eigentlich nur Min+PV (wobei ich die Timeouts angepasst habe und mit PV allein auch zufrieden wäre), PV und Aus.

Also "Off" "Auto" "Fast" würde mir persönlich erstmal reichen.

Bei Auto würde ich mir mehr Optionen bzgl. Batterie wünschen.
Mich stört es zB, dass bei "bufferSoC" das Laden auch gestartet wird, wenn die Batterie die % erreicht hat und PV so gut wie keinen Strom liefert (ist das ggf. ein Bug? - dann schreibe ich ein Ticket). Besser wäre doch, dass das Laden nur bei genug Überschuss gestartet wird und nur die Unterbrechung durch die Batterie gepuffert wird?!
Auto mit verstellbaren Parametern gefällt, am Besten direkt auf der UI verstellbar (Batterie Puffer %, maximaler Ladestrom, 1P3P Umschaltung deaktivieren, etc.).

Gerade noch eine Idee.
Profile in der Konfig hinterlegen: Standardmäßig sind dann die Modi Off, Auto, Fast vorhanden, die aber in der Konfig invdividuell durch Parameter erweitert/angepasst werden können. Damit würde man auch die "Nerds" bedienen, aber es bleibt für den Otto-Normal-Benutzer einfach.

Hoffe es ist nicht zu sehr in Feature Diskussionen ausgeartet.. Auf Hinweis schreibe ich die Punkte gern nochmal zu passenderen Diskussionspunkten oder erstelle Tickts.

[florianmw]

Nochmal eine kurze Erklärung, warum das Thema "Aus" für mich wichtig ist:
Wenn ich eine Steuerung für ein Gerät ausschalte (das ist EVCC für mich - liege ich da falsch?), dann erwarte ich, dass ich daraufhin das Gerät z.B. durch einen Schalter, den zb. meine Wallbox hat, manuell aktivieren kann. Die Steuerung sollte das dann nicht verhindern.
Ich nutze EVCC zusammen mit Influxdb + Grafana und logge damit meine Verbrauchswerte (super Feature übrigens!). Dadurch sehe ich noch mehr Sinn darin :)
@andig falls meine Definition von "Aus" keinen Sinn macht würde ich mir einfach einen Parameter wünschen.

[int5749]

Aber genau so ist es doch implementiert?
Zumindest meine ich mich zu erinnern (nutze dies halt nie so) das ich mein Auto auch direkt über die Wallbox laden konnte, nachdem ich evcc auf off gestellt hatte. Unsere Tinkerforge Warp (nun Smart) ist frei zugänglich und daher habe ich die Autostart Funktion der WB deaktiviert. evcc hatte da nix unterbunden oder dann gar eingegriffen, da ja die Steuerung off war.

ODer wurde an der Funktion etwas geändert? Ggfs reagieren auch andere WB anders?

[andig]

Die Steuerung sollte das dann nicht verhindern.

Aus heisst WB aus, nicht evcc aus. Das wird z.B. fürs Lastmanagement notwendig sein. Wie beim Rest der Diskussion auch würde ich gerne verstehen, warum Du evcc ausschalten musst. Diesen UC sollten wir dann supporten.

[florianmw]

Ok, verstehe. Macht für Lastmanagement Sinn, daran habe ich nicht gedacht.
Hier mal ein Anwendungsbeispiel für EVCC deaktivieren: Das Auto wurde am Abend auf 75% geladen und die Batterie auf 90% entladen (per bufferSoC). Am nach dem Aufstehen hat die Batterie noch 60% und ich noch eine Stunde, bis ich losfahre. Ich möchte dann in der Stunde 2,5kWh laden. Dann wäre für mich die Lösung: EVCC aus (min würde nur 1,4 kW machen) und die WB manuell auf 2,5kW stellen. Nach einer Stunde abziehen und losfahren.
Abends möchte ich die Batterie nicht so viel entladen, weil ich nicht unbedingt abschätzen kann, was über die Nacht verbraucht wird (WP könnte anspringen, wenn zu kalt), deshalb dann morgens manuell.
Wenn sich der Anwendungsfall auch mit EVCC lösen lässt, umso besser.
Ich finde nur manchmal gibt es spezielle Fälle, die ggf nich viele Leute betreffen und dann ist manuelle Steuerung eine schnelle, einfache Lösung.

[andig]

Yep, das haben wir als „assissted pv“ erkannt. Das „nativ“ einzubauen hilft mehr Anwendern als die externe Steuerung für die Bastler freizugeben.

[VolkerK62]

Seid ihr hier schon gedanklich weitergekommen (Stichwort Wintermodus)?

jahreszeitliche Konfiguration: kein Netzbezug vs. keine Einspeisung (#3448 (reply in thread))

[thebrainkafka]

Habt ihr darüber nachgedacht auch die Ladeleistung einstellbar zu machen? Sprich ich möchte jetzt gerade mit max. xA laden. Per Button zu verstellen.

[andig]

Habt ihr darüber nachgedacht auch die Ladeleistung einstellbar zu machen? Sprich ich möchte jetzt gerade mit max. xA laden. Per Button zu verstellen.

Das wird sicher nicht kommen. Wir haben weiter den Anspruch, den komplexeren Use Case dahinter zu lösen.

[Alestrix]

Sprich ich möchte jetzt gerade mit max. xA laden.

Wäre das ein Zwischending aus Min-PV und Sofortladung? Wofür bräuchte man das?

[binderth]

Das braucht man, wenn man über ein EMS z.B. den für den Tag verfügbaren Strom prognostiziert, mit anderen Parametern verknüpft und dann entscheiden lässt, nicht 100% des Überschusses zum Ladepunkt zu schicken, sondern nur bis xx A maxcurrent. Dann wird Auto und Hausbatterie geladen.

Aber die API gibt das ja bereits her, muss es wirklich in der GUI sein?

[AndyNew2]

Hallo, für mich sind die Namen der PV Lademodi nicht so entscheidend. Ich hatte hier nie Verständnisprobleme und Modus PV und PV+Min waren immer klar.
Allerdings kann man im PV (Überschussladen) Modus einiges verstellen und EVCC kann hier inter vieles Tricksen, was den Laien evtl. nicht soo verständlich ist.
Anbei ein Vorschlag meinerseits, wie man dies in der GUI aufbereiten könnte, so dass es

1. Jeder sofort versteht
2. Aber trotzdem niemand wirklich die Details verstehen muss
3. Aber wiederum trotzdem Hinweise an der GUI sind, um es bei Bedarf doch genauer verstehen zu können.

Erklärung im nächsten Post

[andig]

Der Slider wäre #16507

[AndyNew2]

An der jetzigen GUI würde ich so gut wie nichts ändern.
Der PV Modus bekommt nur einen "Konfigure" Button. Die Werte hinter diesen Dialog sind erstmal Standard. Damit muss ein absoluter Laie sich diese detaillierten Parameter erstmal gar nicht ansehen und muss damit auch nichts machen.

Wenn man auf den "Konfigure" Button drückt, kommt ein weiterer Dialog wie oben dargestellt.
Damit auch Laien nicht sofort damit überfordert sind, werden sämtliche Optimierungsalgorithmen und Parameter in einen einzigen Slider gepackt.
Dieser Slider hat eine Maximalausprägung nach links für Netzbezugverhinderung und ganz rechts für PV Nutzungsoptimieren.
D.h. links ist für den Sommer, wenn viel zu viel Energie vorhanden ist, und jede Wh aus dem Netz eine Verschwendung ist.
Rechts dagegen ist für den Winter, wenn eh viel zu wenig Energie vorhanden ist und jede eingespeiste Wh eine Verschwendung wäre.

Dazwischen können jedoch beliebige Zwischenschritte eingefügt werden und auch andere Algorithmen gesteuert werden. Das einzige wesentliche ist die Sortierung von Netzbezugverhinderung und PV Nutzung.
Darunter könnte ein Text in Abhängigkeit der Einstellung stehen. Mit diesem Text kann sich interessiertes "Publikum" in der Hilfe per Suche zurechtfinden. Da kann dann ein beliebig langer Text zur Erklärung stehen, den der Laie nicht sehen und auch nicht verstehen muss.

[tipuraneo]

Ich finde den Vorschlag mit einem Schieberegler eine gute Ergänzung zum Modus "PV". Er ist verständlich und analog zum Schieberegler bei SMA (Steuerung von Verbrauchern, siehe Verbraucher KANN laufen). Also

• linker Anschlag: Max. Eigenstromnutzung - Verschenke keinen PV-Strom, ergänze im Zweifel mit Netzstrom (Wintermodus)
• rechter Anschlag: Max PV-Stromnutzung - Beziehe keinen Strom aus dem Netz (Sommermodus)
  

Mit dem Schieberegler ließe sich auch #17830 abbilden.

[michiproep]

Soll das per Loadpoint oder global eingestellt werden?
Hört sich simpel an, kann sich dann aber im Detail mit den Batterieeinstellungen widersprechen.
Stand heute kann man doch mit residualPower, loadpoint-ladestrom und batterieeinstellungen genau das erreichen oder sehe ich das falsch?

[AndyNew2]

Wie ist es denn jetzt? Warum soll es dadurch anders werden? Vermischen von Themen ist kein Argument.

[AndyNew2]

Sehe gerade den Kommentar. Der Vorschlag hier geht über den verlinkten Slider hinaus.
Man kann beliebige verschiedene Algorithmen dahinter verstecken. Alles nur sortiert.
Ich würde es sogar kombinieren. D.h. ab sagen wir die ersten 30% des Sliders links steht für einen Algorithmus der Netzbezug weitgehenst verhindert. Der Bereich innerhalb der 30% erhöht den Sicherheitsabstand in W. Dies könnte in einer Kurzform unterhalb des Sliders als Text stehen:
"Netzbezugverhinderungsalgorithmus mit XXX Leistungsreserve". Das XXX wird immer größer je weiter der Slider nach links geht.
Aber 30% in Richtung rechts ändert sich dann plötzlich der Algorithmus.

Soweit verstanden?
Dies ermöglichst fast unbegrenzte Möglichkeiten verschiedenster Algorithmen etc. ohne dass dies der Nutzer im Detail verstehen muss.

[AndyNew2]

Etwas problematisch ist ja der Netzbezug bei fallender PV Leistung. EVCC kann natürlich schlecht vorhersagen, um wie viel die PV Leistung weiter einbricht. Aber ich hätte folgende Ideen für bessere Algorithmen:

• Eine lineare Funktion annehmen und entsprechend dem Abwärtstrend weiter interpolieren und entsprechend die Leistung vorrausschauend reduzieren.
• Evtl. eine Funktion höherer Potenz bzw. andere Annäherungskurven (Sinus).
• Einstellbarer Sicherheitsabstand (Reserveleistung)
• Regelung basierend auf dem PV-Verlauf der letzten 10 Minuten (Speicherung der Min- Max- PV Leistung) und Freigabe z.B. nur der Min- Leistung.
• Freigabe der PV Leistung erst nach einer Wartezeit (Abwarten, dass die PV-Leistung stabil bleibt) (Ähnlich wie beim Einschalten, hier aber für die Ladeleistung)

Das gleiche gilt dann natürlich umgekehrt für den Wintermodus, wenn die PV-Leistung ansteigt.

[andig]

Wozu soll diese Komplexität dienen? An der Stelle mal der Hinweis: die Logiken müssen v.a. intuitiv klar sein und sich an Otto-Normal-Anwender richten. Am Ende brauchts auch nicht nur tolle Ideen, sondern v.a. auch beherzte Umsetzung. Entwicklungskapazität ist leider rar und muss sich daher auf die wichtigsten Themen fokussieren...

[AndyNew2]

Habe da eine andere Meinung.
Der Regelalgorithmus muss nicht von jedem Anwender verstanden werden, sondern nur das Ziel, die Auswirkung.
An dieser Stelle mal der Hinweis, dass ich eigentlich nicht verstehe, wo sich EVCC hin entwickeln soll.
Einerseits werden Wärmepumpen etc. angesteuert und integriert. Da sehe ich klassische Heimautomatisierungen eher in der Zielgruppe hierfür. Das jetzt noch in EVCC zu integrieren ist schon ein großer Aufwand.
Auch die Ansteuerung von Wechselrichtern ist schon so ein Grenzbereich von EVCC. Das liegt thematisch näher als WP, aber erzeugt oft das Problem, dass der Wechselrichter zweimal Integriert werden, einmal in EVCC (mit Steuerung) und dann nochmal in eine Heimautomatisierung. Ich selbst z.B. nutze die Wechselrichteransteuerung von EVCC gar nicht (obwohl mein WR integriert wäre), weil EVCC nicht wissen kann, dass ich eine Stromkaskade mit zwei verschiedenen Stromtarifen habe. Da passt keine vordefinierte Konfiguration zu meinem Setup. Den WR steuere ich selbst in Home Assistant, das Gerüst von EVCC ist hierfür viel zu eng.

Ich würde dafür stimmen, EVCC in Bezug Überschußladen weiter zu optimieren, und offene Schnittstellen für Automatisierungen anzubieten. Die Automatisierungen etc. aber anderen Systemen überlassen, klassischerweise Heimautomatisierungen allen voran Home Assistant.
Ich würde die Entwicklungsaufwände bei Erweiterung von den Regelalgorithmen kleiner sehen, als eine ganze Reihe von WP oder anderen Systemen zu integrieren.

Das ist natürlich nur meine bescheidene Meinung und es steht Euch frei, EVCC in eine andere Richtung zu entwickeln, ich würde obiges Konzept begrüßen.

[andig]

Es wird leider weiter nicht klar, welchen Nutzen die zusätzliche Komplexität bringt?

Der Regelalgorithmus muss nicht von jedem Anwender verstanden werden

Das ist auch nicht notwendig. Aber muss sich erwartbar verhalten.

[LeonSol]

@AndyNew2: Du magst vielleicht ein versierter Anwender von HA sein, viele der Nutzer von EVCC sind es aber nicht und möchten oder können sich nicht in HA, openWB o.ä. einarbeiten. Für diese Zielgruppe ist EVCC ideal. Wenn du andere Ansprüche an die Nutzung hast, setze dies doch in HA um. Ich bin hoch erfreut, dass ich auch meine Wärmepumpe in EVCC einbinden kann und freue mich, wenn dieses feature weiter entwickelt wird.

[AndyNew2]

EVCC ist auch für mich ideal. Nur sehe ich die Kernfunktionalität von EVCC nicht in HEMS, was immer das auch ist (meiner Meinung nach ein sinnloser Pusch der Industrie noch ein weiteres Kasterl zu verkaufen), sondern tatsächlich im Überschussladen. Genau das war doch auch der Trigger für EVCC, Min Laden und Max Laden kann man meisten auch ohne EVCC.
Wenn ich fragen darf, wofür nutzen Sie die Integration der Wärmepumpe in EVCC. Meine wäre übrigens auch integriert, wüsste aber nicht, warum ich die in EVCC nutzen sollte. Soweit ich das EVCC Konzept hier verstanden habe, ist es das Weiterreichen der PV Daten an die Wärmepumpe, in der Hoffnung dass die dann das richtige draus macht.

[AndyNew2]

Der Nutzen ist die Optimierung zur Minimierung des Netzbezugs (Minimierung der Regelverluste) bei ausreichend PV Leistung.
Im Moment habe ich auch bei sehr konservativen Parameter bei EVCC (hatte z.B. heute 1500W als Reserveleistung eingestellt) immer noch Netzbezug. Die PV Leistung war halt extrem zappelig und EVCC hängt dann immer hinterher.
Dieser Thread geht ja um eine einfachere / bessere GUI. Hier hatte ich ja auch was vorgeschlagen, was die GUI vereinfacht und unabhängig von dem Regelalgorithmus macht.
Damit ist der Weg frei für weitere Regelalgorithmen, die ich hier vorgeschlagen habe.
Natürlich geht es dann immer zur Last von PV Leistung die dann ins Netz geht, aber je raffinierter der Algorithmus ist, umso besser kann es optimiert werden. Die angegebenen Algorithmen sind Ideen, wie man das erreichen könnte, bzw. weiter optimieren.

Das gleiche gilt auch im Winter andersherum. Da ist natürlich der Strom viel zu wenig, und da will man dann nicht unnötig einspeisen, wenn man eh Strom vom Netz zukaufen muss. Zum erklären der Algorithmen ist aber der Sommerfall einfacher und einleuchtender zu erklären.

[hyperbart]

I don't see why any more complex rules should be applied. You can reach the same thing with the enable parameter?

Currently I have EVCC combined with a homebattery. At 300W excess PV power (enable) EVCC starts charging my car.
As the combined PV power + minimum grid power ratio makes it very cheap below the costline to charge my car anyhow regardless if I had a homebattery or not.
Currently with a homebattery I have almost no grid feed in when my car is at home. The battery absorbs all the power below 300W or 1380W minimum power which is great. The battery covers the range of charging between 0 and 1400W which the car could not cover as it needs minimum 1400W.

For winter days I use the charge planner to always have a car charged to a set point in the most cost/CO2 efficient way. All is well then too.

I must say I am very very happy with the current modes, the load balancing, the peak shaving and the integration of the battery. The latter could be a bit improved as to use maximum left overs in the battery so to make the battery as empty as possible in the morning (with a small reserve) so when the sun comes up again we are almost near zero to absorb all the PV power.

[sigma415]

Ich bin mit den 4 heutigen Modi sehr zufrieden und m.E. müssen alle 4 auch in ihrer Funktionalität erhalten bleiben.
Wie die dann heißen ? ......... so what .... ;)
Ich krieg das dann meiner Frau (oder Lieschen Müller) schon erklärt ....

BTW: für mich wäre es weitaus hilfreicher, wenn es endlich mal die seit langem versprochenen "Mini Loadpoints" gäbe, oder eine andere Möglichkeit für die reine Visualisierung von Verbrauchern, ohne dass man dafür Dummy loadpoints und Dummy charger definieren muss, die das ganze Regel-Timing sinnfrei aufhalten.
(OK, das war jetzt off topic, aber ich könnte die Minis sooo gut brauchen ...)

[hyperbart]

Apologies, indeed, integrateddevice is: https://docs.evcc.io/en/docs/reference/configuration/chargers#integrateddevice

-->

This parameter causes chargers that operate without a "vehicle" (e.g. heat pump, eBike) to not display a vehicle, thus omitting vehicle detection.

In connection with this parameter, an icon can also be assigned (see vehicle.icon), which will then be displayed at the charger.

[michiproep]

correct. That brings us back to the question "what's different for a mini loadpoint"

[hyperbart]

What do you mean with a mini loadpoint? I only know of loadpoints in general.

[AndyNew2]

I did not know this at all. Just seen in #7235
According this, it is a concept to allow a plugin for all kind of energy consumption devices via a 2nd API, that allows less control compared to a usual loading point API.
So instead of controlling the power consumption in kW, it only would allow on/off. (Hope got this right)

My honest view on this, is the wrong direction of EVCC. It immediately attrackts all problems all other integrations have, and it would reinvent the already solved weel of other systems.

Example:
I have a heatpump, which probably is one of the goals of such an mini loadpoint. It actually is integrated in EVCC, but I do not see any reason to use it. I have a lot of issues with my heatpump, because its developed control is not good enough. By just passing PV information to it and further switch it on and off based on surplus, would lead to a problem of heatpumps too often switch on/off. That is not desireable and one of the main issues of my current heatpump logic.
My heatpump is also well integrated to Home Assistant and this was done quite a while ago (long before EVCC starts this). In HA I have loads of possibilities to overcome the flaws the heatpump developer did and actually could improve the system a lot. To have similar capability in EVCC, it would need a kind of scripting, which is not easy to introduce and probably even more harder to make that user friendly. HA did quite a good job on this, also ioBroker, FHEM, etc. There is loads of this software already available.

That all may be different for other energy consumption devices, but I have no experience on that.

[AndyNew2]

..

BTW: für mich wäre es weitaus hilfreicher, wenn es endlich mal die seit langem versprochenen "Mini Loadpoints" gäbe, oder eine andere Möglichkeit für die reine Visualisierung von Verbrauchern, ohne dass man dafür Dummy loadpoints und Dummy charger definieren muss, die das ganze Regel-Timing sinnfrei aufhalten. (OK, das war jetzt off topic, aber ich könnte die Minis sooo gut brauchen ...)

D.h. Sie planen die Mini Loadpoints für die Visualisierung zu nutzen? Und das soll jetzt sinnvoller sein als den Regelalgorithmus zu verbessern? Für Visualisierungen gibt es ganze opensource software Lösungen, ich hätte EVCC nie dazu verstanden das als Hauptanwendung zu machen. Hatte die GUI oberhalb immer nur als nettes Plus gesehen, aber so verschieden sind halt die Meinungen.

[AndyNew2]

Keine Angst ich schlage nichts vor, was irgendein Feature in diesem Bereich entfernen würde.
Es soll nur zusätzliche Optionen geben, die auf der GUI auch nur dann sichtbar werden, wenn ein weiterer Dialog geöffnet wird. Auch dieser Dialog ist so aufbereitet, dass es jeder User sofort versteht.

Zu sagen, bei mir ist es jetzt super ist ja toll, nur ist das nicht bei allen der Fall (z.B. mir) und Ihr kommt irgendwann relativ sicher auch in diese Situation. Ein Überschussladen funktioniert sehr gut bei ruhiger Sonneneinstrahlung (d.h. kaum Wolken und diese relativ dünn) oder in Kombination mit einer Stützbatterie.
Letzteres (Stützbatterie) funktioniert auch nur bis zu einer Ladeleistung, die von der Hausbatterie abgedeckt wird. Bei 11kW Ladeleistung oder sogar 22kW, gibt es wenig Lösungen. D.h. Ihre bis jetzt sehr gute Erfahrung basiert auf glücklichen Kombinationen, die nicht jeder hat und so nicht unbedingt auch für Sie bestehen bleiben. (Die Kombination ist wahrscheinlich einphasiges Laden bis max 3.6kW bei großer PV über 10kWp, richtig?)

Die Situation ist doch folgende:
Bei einer großen PV Anlage und durchschnittlichen Fahrleistungen ist im Sommer immer genügend Energie vorhanden. Warum sollte man dann beim PV Überschussladen 3 - 5% aus dem Netz ziehen, wenn es 1. eh nicht eilt (weil ja die Tagesleistung eh leicht in die Autobatterie kommt) und 2. ich dann später sowieso alles ins Netz einspeise. Dann möchte ich doch lieber beim Laden meinetwegen auch 10% weiter ins Netz einspeisen, um den Netzbezug idealerweise auf 0% zu drücken. Die Netzeinspeisung hätte ich eh gehabt, weil ich später die Energie eh nicht verbrauchen könnte.
Das gleiche umgekehrt im Winter. Da muss ich sowieso aus dem Netz zuladen und möchte nichts ins Netz verschenken.

Genau aus diesem Anwendungsfall der Vorschlag.

[michiproep]

Die Situation ist doch folgende: Bei einer großen PV Anlage und durchschnittlichen Fahrleistungen ist im Sommer immer genügend Energie vorhanden. Warum sollte man dann beim PV Überschussladen 3 - 5% aus dem Netz ziehen, wenn es 1. eh nicht eilt (weil ja die Tagesleistung eh leicht in die Autobatterie kommt) und 2. ich dann später sowieso alles ins Netz einspeise. Dann möchte ich doch lieber beim Laden meinetwegen auch 10% weiter ins Netz einspeisen, um den Netzbezug idealerweise auf 0% zu drücken. Die Netzeinspeisung hätte ich eh gehabt, weil ich später die Energie eh nicht verbrauchen könnte.

Dazu kann man schon heute den Ladepunkt selbst auf unter 16A drosseln.

Und dass man minimal Netzbezug hat liegt im Normalfall nicht an evcc, sondern an der verzögerten Regelung vom WR/Akku.

Alles in allem muss ich hier @andig Recht geben. Das wird zu kompliziert. evcc macht das alles schon ziemlich gut und spezielle Feinheiten müssen die "Nerds" dann via API regeln.

Das Einzige was ich mir tatsächlich noch vorstellen könnte ist ein "Profi-Modus" bei dem man einen eigenen Algorithmus/Plugin hochladen kann. Ähnlich wie beim "custom-css feature" kann dann evcc keine Gewährleistung/Support mehr übernehmen.

Wenn dir die Regelung zu langsam geht kannst du ja mal das Standard-Intervall von 30s auf x runterstellen.
Ich hab 5 Ladepunkte (1 Auto, 1 WP, 1 Pool, 2 kl. Heizungen). Da hab ich auf 12s gestellt, so dass zumindest jeder LP einmal pro Minute dran kommt. Mit einem 5-Personen-Haushalt hab ich ab Mitte März ca. 1kWh NetzBezug pro Woche. Da gibt's für mich nichts mehr zu optimieren...

[kscholty]

Auch ich bin bei @andig.
Mir ist es wichtig, zu verstehen, was das System macht, ansonsten werde ich es nicht einsetzen.
Ein simpler Algorithmus, meinetwegen mit Parametern ist OK. Irgendwelche Heutistiken, die unverständliche Dinge tun, will ich nicht.

[hyperbart]

@AndyNew2 : and how does your proposal fix that issue (could you explain to me again what your proposal is in English?). Because even with a battery i have at average per day something like 1.5kWh of grid injection and 1.5kWh of usage. I am using a Victron system which is able to control the output of the battery by 400W/s so i will always have some "trailing".

If you want more grid injection than grid usage I would suggest to use the residualPower setting as it allows you to keep EVCC "below" zero instead of "right on it".

Indeed I do most of the time single phase charging but (!) I have an 22kW/32A Alfen box.
I have 3 single phase SMA inverters (1.5kW | 1.8kWp SE + 2.5kW | 3.5kWp NW + 4kW | 6.7kWp) + 1 single phase Victron battery 5kVA 15kWh

By using a single phase charging I can serve my care 1.4kW-7.4kW. My PV collection can generate maximum around 8kW .
Sometimes it is also about designing the system correctly and making sure the balances are OK. Using a 32A/22kW box (it only takes a license cost, my Alfen was virtually limited) greatly enhances my range of self consumption.

[pencoe]

Ich finde, man muss auch mal sehen, was man da durch noch optimalere Algorhitmen einsparen würde: wenn die Komplexität zu sehr steigt, nur um 20 kWh im Jahr zu sparen, dann ist das einfach nicht sinnvoll. Wir haben jetzt seit 13 Jahren PV und seit 4 Jahren E-Auto(s): am Anfang versucht man krampfhaft, jede einzelne Wh Netzbezug zu vermeiden, später sieht man das viel gelassener :-)

Wer seinen Netzbezug wirksam senken will muss einen Batteriespeicher haben: dann ist auch wechselnde Bewölkung kein Problem mehr. Mit den jetzt vorhandenen Modi komme ich schon ziemlich gut klar. Ich hatte ja auch schon mal den Vorschlag, sich eigene Presets bauen zu können, die man dann (wenn vorhanden) als Dropdown angeboten kriegt, das wäre dann sowas wie ein "Profi-Modus", aber ich kann auch (gerade) mit der Schlichtheit von evcc gut leben ;-)

[hyperbart]

Yes, I agree on this. The home battery covers the quick clouds as we now have in Belgium today.
But you also just have to accept @AndyNew2 there will always be some "lagging kWh" used or injected to the grid.

You got a whole chain of components which have to do control loops. I think these are even specific courses in master education, it's not as easy or responsive as you need to evaluate every time with new parameters.

[AndyNew2]

Oder macht halt dann die Steuerung selbst in HA ;-)

Naja sieht eher so aus, als wäre der Vorschlag abgelehnt. Damit muss ich halt leben.

Ich hätte es sinnvoller gefunden, EVCC weiter in der kernkompetenz Überschussladen (und genau darum geht es hier) weiter zu optimieren, anstatt in anderen Gebieten doppelte Implementierungen einzubauen. Natürlich wird es immer Anwender geben die das auch zu schätzen wissen, Im meinen Fall wäre es genau so, ich habe einen Azzurro WR, der durch EVCC unterstützt wird und eine Wärmepumpe von iDM, die auch von EVCC unterstützt wird. Keines der beiden nutze ich in EVCC und mache es in HA, weil dies meine Hausautomatisierungsbasis ist und EVCC wohl nie meine Lüfter und Rollos, etc. steuern wird. Da brauche ich aber auch die Daten der PV.

Wie gesagt, mein Vorschlag ist eine Erweiterung. Wenn Euch das nicht interessiert oder braucht, würde es so wie ich es vorgeschlagen habe nicht weiter betreffen. Es würde nichts komplizierter machen oder schwieriger zu benutzen.
Für die, die es interessiert, würde es zusätzliche Möglichkeiten schaffen. Wird aber wohl nichts werden, dann muss ich halt mit HA schauen, wie weit ich EVCC hier triggern kann. Das wird aber immer schlechter sein, als wenn EVCC das nativ machen würde.

[nicx]

Für mich hat ein HEMS nichts mit einer Hausautomatisierungslösung zu tun. Ich sehe die Kernkompetenz von EVCC in Zukunft als HEMS, und ich hoffe die EVCC Entwickler ebenso. :)

Mit Home Assistant mache ich Dinge wie automatisierte Beleuchtung, Verschattung, etc., aber eben keine Dinge wie Überschussladen oder Straten von Stromverbrauchern nach Prognose o.ä., hier sehe ich EVCC als Lösung. Andere Themen wie Mini Loadpoint etc. gehen genau in diese Richtung, was mir sehr gut gefällt ;)

[AndyNew2]

Naja dann viel Spaß. Z.B. für die iDM Integration hatte ich einiges Optimierungspotential, dass die iDM Steuerung intern nicht hergibt. Was macht denn ein generisches HEMS mit den Geräten? Diese HEMS Diskussion ist mir sowieso ein Rätsel, weil ein HEMS niemals alle Kombinationen und Konfigurationen gerade von verschiedenen Herstellern abdecken kann.
Genau da braucht es doch eine eigene Automatisierungsebene, und die nochmal in EVCC nachzubauen, obwohl es die in Home Assistant ioBroker etc eh schon gibt? Das sehe ich konzeptionell nicht als sinnvoll an.

[jodabis]

Bin gerade über diese Diskussion hier gestolpert.
Gäbe es die Möglichkeit, dynamisch eigene Ladeprofile anlegen zu können? Dann gäbe es mehr Möglichkeiten für Nutzer, ihr evcc zu individualisieren. Es gibt einfach zu viele Anwendungsszenarien, zu viele Bedürfnisse um alles mit einer Lösung abzudecken. Daher wäre mein Vorschlag: "Off", "Smart", "Fast" als Standardoptionen und zusätzlich die Möglichkeit, weitere Profile (evtl auf Basis von Templates, zB "no grid", "no feed") zu erstellen und danach aktivieren zu können.

[marcelGoerentz]

Ich weiß nicht ob es bereits vorgeschlagen wurde, aber vielleicht kann man ja eine Option beim PV laden hinzufügen, dass eine gewisser Prozentsatz Netzbezug in Ordnung geht. So könnte man zum Beispiel an Wolkigen Tagen mit maximal nutzbaren Überschuss laden. Für Anlagen Besitzer mit Batterie mag es vielleicht weniger relevant sein, für Einspeiser nach Abzug eigener Last macht es bestimmt Sinn.

[andig]

Nennt sich disable threshold.

[VolkerK62]

und es gibt #16507

[marcelGoerentz]

Seit wann ist das Prozentual?

[marcelGoerentz]

und es gibt #16507

Sieht gut aus!

[AndyNew2]

https://www.youtube.com/watch?v=e3CVlQMSnBs
Hier ein Video von Gewaltig Nachhaltig zur Erklärung des Phänomens von Netzbezug bei wechselhaftem Wetter.
Auch ein Akku kann das dann nicht abdecken, wie von mir vorrausgesagt. Man müsste hier bessere Algorithmen anwenden.

[andig]

Es ist nicht erkennbar, was das Video mit der Regelung durch evcc zu tun haben sollte. Da es dazu schon eine separate Diskussion gab lass uns bitte beim Thema bleiben.

[abuesen]

Wo ist die andere Diskussion @andig ?

Für das "Phänomen" braucht man kein Video und evcc hat alles, um passend zu regeln. Mit enable/disable bzw threshold und residential power habe ich meine Anlage so eingestellt, dass ich im Juni, Juli und August ganz ohne Nutzung der Hausbatterie bei über 95% Sonne lag.

Netzbezug wegen wecheslhafter Wolken lässt sich nur durch eine sehr schnelle Regelung vermeiden.

[andig]

Das ist #22516

[andig]

Damit haben wir uns 360° im Kreis gedreht und sind wieder beim Thema Latenz bei Async angekommen das in #22516 schon diskutiert wird. Hier OT.