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

[SolarPowerEV]

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

[SolarPowerEV]

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?

[pencoe]

Bin gerade auf Umwegen hier gelandet...
Mein Vorschlag:

• es gibt zwischen "Aus" und "Schnell" ein Dropdown für benutzerdefinierte Lademethoden
• es können bis zu 10(?) eigene Definitionen fürs Laden auf der Konfigseite angelegt werden (mit eigener Namensgebung)
• im Auslieferungszustand ist eine Methode (Überschussladen?) vordefiniert

Dann kann sich jeder nach Belieben austoben (mit/ohne Batterie, wieviel Batterie, 1/3-phasig, minStrom, maxStrom, Reaktionszeiten,...)

BTW: die im Entstehen befindliche Konfigseite finde ich sehr schön!

[abuesen]

Ach ja, die beste Überschussvorhersage machen meine Frau und ich derzeit noch selbst. Das hängt ja nicht nur von der PV ab, sondern auch von genug anderen Dingen.

[abuesen]

Beim Mähen kann man gut überlegen.

Für den Anfänger sind die drei Modi wahrscheinlich gut.

Mit steigendem Bedarf braucht man mehr Einstellungen. Die sind im Modus PV zusammen mit MinSoC und Ziel zur Uhrzeit sinnvoll und dadurch wird wahrscheinlich der Min+PV überflüssig. Ob man den deshalb streicht? Möglich.
Das ganze im UI intuitiv für First-User zu verpacken wird ne spannende Aufgabe.

[pencoe]

@andig nach meiner Meinung ;-) ist es hier falsch, ausschließlich nach allgemeinen Use-cases zu suchen: ich würde z.B. gerne verschiedene Speicher-Nutzungsszenarien (wie lange batterieunterstützt laden, bis zu welchem Batterie-SoC überhaupt Strom fürs Auto) speichern, um die je nach aktuellem Anwendungsfall (abhängig von Jahreszeit, Wetter und der Nutzung des Fz an den nächsten Tagen) mit einem Klick abzurufen.

Um festzulegen, was als Standard bei der Auslieferung mitkommt, sind Use-cases notwendig, aber dem Nutzer die Freiheit zu geben, einfach seine eigenen Regeln/Use-cases zu definieren finde ich immer hilfreich. :-)

@floms79 kein noch so smartes System wird jemals wissen können, aus welchen Gründen ich gerade das Auto angesteckt habe ;-) Deshalb eben die Möglichkeit, die Parameter für das smarte System selbst beeinflussen zu können und die Varianten, die ich häufiger brauche, dann als Presets zur Auswahl abspeichern zu können

Aus, "gib alles was du hast" :-) und ein oder maximal 2 mitgelieferte Presets fürs Überschussladen (über deren sinnvolle Vorbelegung kann man dann ja weiter diskutieren...) und dann die Möglichkeit für Fortgeschrittene, eigene Presets zu definieren wäre deshalb meine präferierte Methode...

[andig]

aber dem Nutzer die Freiheit zu geben, einfach seine eigenen Regeln/Use-cases zu definieren finde ich immer hilfreich.

Absolut- aber das muss nicht in evcc. Klassisches Feld der Heimautomatisierung wofür wir alle notwendigen Schnittstellen mit bringen. Wir konzentrieren uns auf die Use Cases.

[abuesen]

@andig

Absolut- aber das muss nicht in evcc. Klassisches Feld der Heimautomatisierung wofür wir alle notwendigen Schnittstellen mit bringen. Wir konzentrieren uns auf die Use Cases.

Darin liegt mE der Kern der Diskussion: Wo zieht man die Grenze an Funktikonen in evcc?

Die Steuermöglichkeiten (über Homeassistant) meines Hybridwechselrichters sind sehr vielfältig. Viel mehr, als ich in evcc sinnvoll finden würde. Die Kunst liegt nun darin, möglichst allgemeingültige User cases für möglichst viele User zu finden um diese intuitiv bedienbar zu implementieren.

Da bleibe ich bei einer meiner Meinung nach recht einfachen Überschussregelung.

• Mit Netzbezug (ja, nein, Threshold)
• Mit Batterienutzung (ja, nein, Threshold)
• (minimum Laden (ja, nein))

Ich schreibe auch bewusst "Überschussregelung" und nicht "PV", um mir keine Gedanken zu Priorität der Batterieladung oder mehrere wechselrichter machen zu müssen. Das sehe ich eher im HEMS oder bei der Herstellerregelung.

[demichve]

Ich hätte da noch einen Use Case, wo ich öfters manuell eingreifen muss:
Im Frühjahr und Herbst komme ich in einen Bereich meiner PV Anlage, wo das System dazu neigt, ständig zwischen 1P und 3P hin- und herzuspringen. Ich schalte dann oft manuell auf 1P um, um das zu verhindern.
Glaubt Ihr, dass das System sowas erkennen kann und dann für mich auf 1P umschaltet?

[SolarPowerEV]

Gehen tut alles, das Problem liegt m.E. in der Definition der konkreten Grenzen. Sowas ist doch super-individuell und hängt von das Jahreszeit, dem Wetter (Art der Bewölkung) und natürlich der Peakleistung der jeweiligen PV-Anlage sowie der Verteilung der Solarzellen auf dem Dach (also deren Ausrichtung) ab.

Für den einen ist es völlig ok, wenn die Wallbox binnen 2 Stunden 10x zwischen 1p und 3p umschaltet, für den anderen sind schon 3 Umschaltungen in einem Ladevorgang zuviel. Jetzt könnte man sagen, wenn die Peakleistung minus Hausverbrauch <4.600 Watt ist, dann reicht 1p völlig aus. Aber was ist denn, wenn sich z.B. (wie bei uns) eine Menge Solarzellen auf einem primär nach Westen ausgerichteten Dach befinden und dann Nachmittags nochmal ein Kicker reinknallt bzw. vorher die nominelle Peakleistung zwar bei 18,92 kW liegt, der Wert aber faktisch eben wegen der Verteilung übers Dach (inkl. Nordnordost-Dachseite) nie erreicht wird.

Was Du jetzt schon einstellen kannst, sind die Werte für delay, threshold und vor allem guardduration mit denen Du ein zu häufiges Umschalten auf verschiedenen Ebenen verhindern kannst. Mir ist allerdings auch nicht ganz klar, wie man das System dazu bringen kann, dass es im Zweifel lieber bei einphasig als bei dreiphasig stehen bleibt, um nicht am Ende zu lange den Hausakku zu strapazieren bzw. Strom unnötig vom Grid dazuzukaufen.

[hyperbart]

All current modes cover all use cases I could think of. By adding the load balancing and the peak shaving EVCC is 100% covering all UC's. I am extremely happy with the current core functionality of EVCC. 🚀

[Xaelian]

Not 100%. The only addition which would be great and would cover all use cases:
Addition to price limit. For the ones who have 2 rates (peak time and low time).

e.g. My Energy price (excl. all additions):
14,4 cents/kWh during peak times consumption
9,6 cente/kWh during low times consumption
6cents/kWh export during peak
2,3cents/kWh export during low times.

During peak: if cost / kWh charging < 8,4 cents /kWh I want to use the grid + PV
During low: if cost / kWh Charging < 3,7 cents / kWh I want to use grid + PV.

Or even more simple: during peak usage when the total cost / kWh <= Total cost / kWh low times, I want to use grid + PV (minPV). When I’m only having an excess of 200W I’d better charge during the night (low usage time) then to use grid + PV since that ‘cost’ me more.
During winter periods with low solar this would also imply that when you use minPV and your dryer / oven / … get’s turned on by the misses, Charging Will be turned off since you’re using all excess solar for those things.

[11-Andreas]

Hier noch von mir gewünschte Funktionen mit dahintersteckenden Use Cases:

1. Funktion PV + Batterie. Use Case: Man kommt zu Mittagspause für 30 min nach Hause, der Hausspeicher ist voll, die Sonne knallt. Man möchte so viel wie möglich ohne Bezug nachladen. Oder man ist Mittags zu Hause, Auto SoC ist auf 80%, Hausspeicher ist voll. Man entscheidet sich für einen Ausflug, der in 30 minuten losgehen soll. Hier will man unter Nutzung des Hausspeichers vie nachladen.

2. Use Case: morgentliche Nutzung der im Hausspeicher verbliebenen Stroms. Dies ist speziell in Herbst und Frühjahr sinnvoll (für mich), wo man zu Sonnenscheinstunden nicht zu Hause ist. Als mögliche Lösung könnte hier schon eine uhrzeitabhängig programmierbare BufferSoC-Einstellung denkbar. Z.B. Abends 90 % und morgens um 6 Uhr 5 %.

[andig]

Funktion PV + Batterie

Das Problem hier ist, dass die Entladeleistung der Batterie nicht bekannt ist. Da könnte man allenfalls mit leichtem Netzbezug das Auto laden um immer das Maximum der Batterie auszuschöpfen. M.E. wirklich schwierig.

morgentliche Nutzung der im Hausspeicher verbliebenen Stroms

Das ist m.E. analog zu oben. Das Problem ist "maximal aus dem Akku ziehen" was nicht einfach umzusetzen ist (und vmtl. auch nicht toll für den Akku).

Als mögliche Lösung könnte hier schon eine uhrzeitabhängig programmierbare BufferSoC-Einstellung denkbar.

Das kannst Du mit jeder Heimautomatisierung machen- dafür hat evcc die APIs.

/cc @premultiply

[abuesen]

Das Problem hier ist, dass die Entladeleistung der Batterie nicht bekannt ist

@andig, wenn ich richtig verfolgt habe, wird bei evcc die Batterie per discharge energy gesteuert. Das hatte ich zunächst (mit homeassistant) auch versucht, war mir dann zu kompliziert. Inzwischen setze ich während dem EV-Ladevorgang die Workmode meines Speichers (FoxESS H3) auf "Backup" und danach wieder auf "SelfUse".

Kern ist, die Hausbatterie nur durch deren eigene Regelung zu betreiben oder abschalten.

Unabhängig wie sinnvoll es einem erscheinen mag kann man den Modus manuell wieder umstellen, so dass man auch beim EV-laden die Hausbatterie nutzt, die sich selbst richtig regelt.

In der evcc Oberfläche könnte das durch einen einfachen Schalter "Batterienutzung [ja|nein]" abgebildet werden. Default per yaml.

[11-Andreas]

Das Problem hier ist, dass die Entladeleistung der Batterie nicht bekannt ist.

Das verstehe ich nicht. Wenn hier die aktuelle Entladeleistung gemeint ist, dann wird sie schocn jetzt in der UI angezeigt. Wenn jedoch die maximal mögliche Entladeleistung gemeint war, dann ist diese aus technischen Daten bekannt und könnte konfiguriert werden.

Das kannst Du mit jeder Heimautomatisierung machen- dafür hat evcc die APIs.

Das stimmt. Mein wunsch wäre eben nicht weitere Automatisierungen dafür nutzen zu müssen.
PS. Mit ist absolut bewußt, dass hier nicht jeder Wunsch erfüllt wird. Ich habe nur die Gelegenheit genutzt ein Verbesserungspotential zu benennen und diesen mit dem Use Case zu belegen.

[andig]

Wenn jedoch die maximal mögliche Entladeleistung gemeint war, dann ist diese aus technischen Daten bekannt und könnte konfiguriert werden.

Mehrfach diskutiert: nein, kann sie nicht da nicht-linear.

[abuesen]

Was mir am PV-Modus fehlt ist die einfache Veränderung des Threshold für den Netzbezug per UI oder API.

Im Winter ist es ok, 2kW aus dem Netz zu holen, um die anderen 2kW von der PV zu nutzen, wenn vorhanden. (1p/3p Umschaltung geht hier leider nicht). Beim Übergang passe ich den Wert mehrfach an. Das mache ich derzeit über yaml und Neustart.

Klassisches COULD. Komfortfeature.

[VolkerK62]

Ich wollte @JoSilverguard halt eine Lösung anbieten, die er sofort anwenden kann ohne auf weitere Entwicklungen warten zu müssen.

negative residualpower einstellen, geht ja jetzt schon bequem im WebUI.
Einzig die Batterieeinstellungen wirken dann nicht. Die muss man aktuell noch im Auge behalten, sonst zieht es den Akku leer.

[SolarPowerEV]

Das finde ich am inzwischen bei evcc erreichten Featurestand schon so beeindruckend. Oft gibt es für ein Thema mehr als einen Lösungsweg, mit dem man sein Ziel (fast) erreichen kann. Klar geht es immer noch einen Tacken bequemer oder in noch stärker optimierter Form. Aber zumindest eine Näherungslösung bzw. einen Work Around, der sofort und ohne zusätzliche Code-Anpassungen funktioniert, findet man dank der vielen Regelmöglichkeiten doch fast immer.

[VolkerK62]

Wobei residualpower ja streng genommen eigentlich den Netzbezug bzw. die Netzeinspeisung regeln soll und eben nicht, wie sehr man den Hausspeicher für eine Ladung des Autos heranzieht.

das Schöne daran ist, das evcc auf einen kleinen Netzbezug regelt, der immer wieder von der Batterie ausgeglichen wird und diese somit an ihre max Entladeleistung bringt, ohne diese konfigurieren zu müssen.

[JoSilverguard]

Ich habe es so verstanden, dass PV + max Batterie Entladung gewünscht ist.

Exakt. Wenn ich z.B. in einer Stunde los muss, der Akku voll ist und die PV Anlage nur 5 kWh liefert. Mit so einem Modus käme ich dann auf eine Ladeenergie von 10 kWh, da mein Akku 5 kWh liefern kann. Der Akku wird dann während des verbleibenden Tages wieder vollgeladen.

[abuesen]

Die Zeit zum Threshold, wie bei enable und disable kann man nicht per UI einstellen, richtig?

[kscholty]

Ich finde den jetzigen Zustand recht gut. Entweder PV oder Schnell. Ich nutze oft "Schnell" und setze über die Wallbox Einstellungen Anzahl Phasen und max Strom. Leider ist das für meine Frau zu kompliziert und auch ich vergesse manchmal, dass ich da was eingestellt habe und wundere mich dann.
Da wäre es wirklich besser, man hätte verschiedene Voreinstellungen, die man schnell wählen kann.

[mrfreezer]

Ich hätte hier noch einen "Sonderfall" hinzuzufügen, den ich so noch nicht gelesen / gesehen habe:

Ladung so schnell wie geht, "mit alles" außer Netzbezug.

Ich hab nen recht großen Akku, der ist aber leider (fronius halt) nicht in der lage, die vollen 10kW zu liefern, die der WR AC-seitig könnte, weil nicht größte ausbaustufe, dadurch Batteriespannung zu klein um mit 22A 10kW zu schaffen. sind halt nur 7,88kW (Kellerdecke zu niedrig^^)

jedenfalls führt das dazu, dass, wenn die pv-leistung sinkt, an 3 stellen probleme auftreten:

1, stufe: produktion der beiden zusätzlichen Wechselrichter + 10kW vom Hybrid reichen nicht um Hausverbrauch + Ladung zu decken
2. stufe: produktion der module am hybrid reichen nicht um die 7,8kW aus dem akku auf 10kW aufzustocken
3. hausverbrauch steigt stark an (kochen/waschen/sauna) und erzeugt somit 1 oder 2.

hier wäre es also toll, wenn man mit pv und akku laden könnte, aber dennoch nullbezug erreichen könnte. aktuell mache ich das über bergrenzung der maximalen ladung, gerate aber spätestens bei 3 doch in netzbezug.

[meniku]

[SolarPowerEV]

Du weißt aber, dass man das Entladen der Hausbatterie (zumindest bei den Akkus/WRs, die das unterstützen) evcc-seitig durch verschiedene Parameter in diesem Konfigurations-Fenster unterbinden kann, oder?

[abuesen]

Warum fängt es nachts aus der Batterie an zu laden? Es soll doch nur die PV unterstützt werden, also wenn auch Ertrag vorliegt. So wie es im Screenshot zu lesen steht.

Fehlt nicht eher Schwelle und Zeit, wie lange die Batterie mit welcher maximalen Leistung unterstützen soll? Analog zu enable/disable für das Grid.

[andig]

Bitte neues Thema mit Logfile. Fehlersuche gehört nicht hier hin.

[meniku]

ich erstelle ein neues Thema, wie von @olafz gefordert, auch wenns ein feature-request ist, und keine fehlersuche

[dglaude]

Sorry, I could not translate everything discuss here... so maybe this idea is a duplicate, but at least I appear to be in the right discussion.

My request is to have a "manual" or "passive" mode where EVCC does not:

• "stop"
• "start"
• "change the charging amps"

Of course EVCC should be your only way of controlling the car charging, but maybe someone in the family prefer to use the car application or car UI and have the expected result. But even then, I want to keep EVCC running to observe and so that power user can deal with it.

My initial idea idea was to have a mode: passive that is different from mode: off.

This could be a good mode during installation, to verify that all the meter and various communication works well. It could be an observation mode to see how things behave before commiting to EVCC for every charge. (that is more like a simulation mode)

[michiproep]

Ich verfolge den Thread hier jetzt schon seit längerem. Die individuellen Anforderungen und Kombinationen sind schier unendlich.
Die Tagesgewohnheiten der einzelnen Leute, die PV Installationen, etc
Was im Thread noch wenig zur Sprache kam sind "viele Loadpoints" (zB Heizen) mit unterschiedlichen Prioritäten.

Ich glaube nicht, dass evcc durch neue Einstellmöglichkeiten das alles abdecken kann.

Was man aber sieht ist, dass viele Leute über externe Systeme (iobroker, etc) die Parameterisierung von evcc dynamisch verändern und somit ihre Umstände gut abbilden können. Im Grunde geht es doch darum auf Basis der eigenen Prioritäten und Bedingungen (Wetter, Jahreszeit, etc) die evcc Einstellungen zu ändern und zu automatisieren.

Was ich mir schon gut vorstellen könnte wäre eine in evcc integrierte SkriptEngine (evtl. sogar mit UI / DragDrop), die es erlaubt die Parameter ohne externes System zu handeln und Ladevorgänge mit einer gewissen Parametrierung zu starten/stoppen (zB setzte um Mitternacht Batterie minSoc auf 20 und starte Loadpoint2 im PV mit max 5kw => würde Batterieunterstützt bis morgens/20% laden).
Dazu bräuchte es noch eine Forecast Api, die Tageserträge und maxPeak liefern könnte.

Damit sollten sich dann die individuellen UseCases abbilden lassen. Durch fixe Einstellungen und Algorithmen wird man nie alle UseCases treffen können.

Ein kleines Beispiel von mir (via iobroker):
Ich lasse zB die Batterieeinstellungen je nach Forecast und voraussichtliche Grundlast (zb muss heizen) von morgens 10% auf 100% langsamer oder schneller anwachsen. Das ermöglicht morgens schon eine Ladung (da die Batterie nicht im HausHatPrio Bereich ist) und schaltet aber früh genug alles ab so dass der Akku abends voll ist.
Danach rechne ich je nach Vorhersage die Verbräuche meiner Loadpoints und schalte sie übernacht auf Min oder Schnell, so dass der Akku wieder leer wird und der Ertrag am nächsten Tag höher ist (HybridWR) und der Komfort höher ist (PoolWärmepumpe).

[Timer2000]

Wie wäre es eine Plugin Schnittstelle zu integrieren, wo die Community dann ihre unterschiedlichen Anforderungen selbst erfüllen kann...

[andig]

Ähhh... guckst Du API Doku?

[meniku]

Ich glaube er meint, es sollte in evcc scriptbar sein, ohne externes Tool, welches die API verwendet

[Timer2000]

Also für mich klingt Smart sehr gut, wobei ich mir wünschen würde das da eine KI die optimale Lösung einstellt.
Zusätzlich fände ich einen manuellen Modus gut, in dem man die Einstellungen selbst hinterlegt. Richtig gut wäre auch eine Art Profil Umschaltung, wo man für verschiedene Szenarien verschiedene Einstellungen für den Man Mode hinterlegt. Zum Beispiel Profil Winter, Sommer usw.

[andig]

wo man für verschiedene Szenarien verschiedene Einstellungen für den Man Mode hinterlegt

Das ist nicht sehr spezifisch. Wie immer ist die Frage: "was ist der Use Case". Mehr Einstellungen sind kein Weg den wir gehen wollen.

[Timer2000]

Es ist doch so das die PV Anlage im Winter eine ganz andere Produktion als im Sommer hat. Gleichzeitig verändert sich im Winter der Verbrauch des EAutos. Somit benötigt man im Winter mehr % Soc als im Sommer für die gleiche Strecke. Ich muß also zwingend den mind. Ladestand im Winter anpassen. Da die Nächte länger dauern benötigt man auch mehr Akku für die Eigennutzung. Ich muß also mehr Energie im Hausspeicher reservieren. Das Laden auf 3 Phasen funktioniert bei meiner Anlage gar nicht mehr muß also ebenfalls umgestellt werden usw. und sofort. Es wäre aus meiner Sicht total hilfreich wenn ich alle diese Einstellungen zusammen ändern könnte und einfach von Sommer auf Winter umstelle.

[andig]

Dann aber ich Wochenschritten, denn es gibt ja auch eine Übergangszeit! Oder parametriert nach Wettervorhersage! 😀

[Chillkroete1206]

Gibt es eine Möglichkeit sich einen Modus "Keinen Netzbezug" zu basteln, der PV und Leistung des Akkus berücksichtigt? Allgemein wäre die Ladeleistung also Leistung PV + Max Leistung Batterie [bei mir max 5KW] - Hausverbrauch

Falls das aktuell noch nicht funktioniert, würde ich mich für diesem Modus stark machen :)

[michiproep]

Also "PV+MaxAkku" sozusagen?
Ich versteh die Denke, aber so richtig sinnvoll find ich das nicht.
Dazu muss man erstens wieder die max Hybridleistung kennen, zweitens haben Akkus meist keine lineare Entladeleistung (zb 1kw bei < 5%, sonst max) und dann ist bei diesem Modus in der meisten Zeit der Akku nach einer Stunde leer.

Wenn ich das erreichen möchte (oder annähernd) stell ich meinen Ladepunkt auf "maxAkkuLeistung" (zb 3p/10A) und lade mit "schnell"

[meniku]

dafür gibt's doch das "Betterieunterstütze Laden", was für den PV Modus konfiguriert werden kann. Hier lässt sich ein Bereich einstellen, bis zu dem die Batterie entladen werden darf.

Es ist nur schade, dass es hierfür leider keine Zeitpläne gibt. Für mich wäre es sehr sinnvoll, wenn ich vor allem morgens und nachmittags das Batterieunterstütze Laden verwende, und gerne auch etwas grosszügig. Am späten Nachmittag würde ich das gerne wieder unterbinden, damit ich genug Akku für die Nacht habe

[michiproep]

Jein, so ganz ist das nicht das selbe, weil in dem Bereich nur minimal geladen wird. Also Akku zulassen, aber nicht Vollgas.

Das mit dem Zeitplan ist super wichtig. Ich lass dazu via API die Batterieeinstellungen von Sonnenauf- bis -untergang alle 10 Min anwachsen. Aber dazu gibts schon eine andere Diskussion

[meniku]

Achso ok, verstanden

[capi]

In #17682 wurde ich auf diese Diskussion verwiesen, und möchte meinen Use-Case auch kurz hinterlegen:

Meine Situation: E-Auto, PV, kein Akku, fixer Strompreis.
Im Allgemeinen sind die Einstellmöglichkeiten derzeit für mich völlig ausreichend, ich arbeite meist mit "PV" Modus und mit dem Ankunfts und Abfahrtsplänen.

Nun ist es aber öfter so, dass, wenn ich nach Hause komme, keine sonderliche Eile habe, wann der Mindest-Ladezustand erreicht werden soll. Um die Last am Hausanschluss zu reduzieren, und die Zeit, wo vielleicht doch noch Sonne scheinen könnte, zu maximieren, würde ich eigentlich an diesen Tagen gerne möglichst langsam bis zum MinSoc laden.

Jedoch wird bei MinSoc derzeit immer im Fast-Modus geladen, bis MinSoc erreicht ist. Ich würde mir eine Möglichkeit wünschen (UI und/oder API), dass ich das MinSoc Ladeverhalten zwischen "Fast" (derzeit) und "Min+Solar" umschalten kann. Da ich diese Umstellmöglichkeit auch per API nicht habe, kann ich das gewünschte Verhalten nicht extern nachprogrammieren.

[binderth]

ich mache das einfach so:

1. der "minSoC" steht auf dem wirklich absoluten Minimum (10%) und das darf (und sollte) auch wirklich schnellstens geladen werden.
2. das laden per "min+PV", "PV" oder "fast" kann ich dann einstellen.

Du kannst auch per API den MinSoC pro Fahrzeug setzen: https://docs.evcc.io/docs/integrations/rest-api#vehicles (POST /api/vehicles/<name>/minsoc/<soc>)
und du kannst natürlich die Modi ebenfalls per API ändern: https://docs.evcc.io/docs/integrations/rest-api#loadpoints (POST /api/loadpoints/<id>/mode/<mode>)

[capi]

Ich könnte die komplette Steuerlogik außerhalb bauen, darüber hab ich auch schon nachgedacht. Ich mag halt das UI von evcc, daher wollte ich das eigentlich nicht aufgeben. Aber ja, prinzipiell wäre eine externe control loop, die das macht, was ich will, über REST auch aktuell schon lösbar. Die Anzeige in evcc zeigt dann hat nicht die "tatsächlichen" Lade-Limits an, sondern halt von der aktuellen Phase in der ich mich befinde (Phasen wären dann sowas wie "fast minsoc bis 40%", "min+pv bis 70%", "PV Überschuss bis 90%").
Danke für die Anregung.

[binderth]

ach so! aufgrund deiner Aussage du arbeitest bereits mit einer API hab ich angenommen, du hast eine externe Regelung vor evcc.

Ich habe das zumindest, weil in meinem Smarthome (openHAB bei mir) auch Vorhersagen habe für etwaige PV-Erträge, meine anderen Verbraucher anhand deren Status, usw. in einer externen Logik. Darin "errechne" ich dann die nötigen Einstellungen im evcc und schicke die per API.
Weil im anderen Thread erwähnt wurde, das Redesign der Lademodi dauert noch etwas wäre das dann eben eine Möglichkeit, das zu umgehen - und noch dazu automatisiert...

[naltatis]

Kurze Ergänzung: Mit dem nächsten Release wird es auch die lang erwarteten "wiederholenden Pläne" #16091 geben. Das hat in meinem Verhalten schon dazu geführt, dass ich den MinSoC auf das nötigste (Batterieschutz) abgesenkt habe und die verbleibende Energie für den täglichen Gebrauch dann morgens bis um 7 zu den günstigsten Stunden via Plan nachgeladen wird.

[tipuraneo]

Hier gibt es viele gute Vorschläge. Insbesondere der Modus "Smart§ gefällt mir. Ich möchte den Vorschlag "do not feed grid" mit einem konkreten technischen Vorschlag zum Regelverhalten von evcc ergänzen:
#17830: wirtschaftlich optimiertes Laden: PV-Leistung mit zusätzlichem Netzbezug voll ausnutzen