Don't stop charging while switching phases (let charger handle that) #7723

MarkusGH · 2023-04-28T11:11:33Z

Nachfolger von #7234 (Branch versehentlich gelöscht)

GrimmiMeloni · 2023-04-29T08:10:40Z

@andig können wir auf dem Branch einen CI Lauf durchführen?

andig · 2023-04-29T08:50:33Z

Die lief schon?

GrimmiMeloni · 2023-04-29T10:38:13Z

Ja, jetzt ist sie durch. Ist scheinbar 10-15 Minuten nach meinem Kommentar gestartet. Vielleicht einfach unglückliches Timing.
Egal - Test sieht gut aus. Review und dann merge? Möchte jemand die Änderungen am Test erklärt haben?

andig · 2023-04-29T10:47:26Z

Läuft das denn bei dir lokal fehlerfrei?

MarkusGH · 2023-04-29T12:56:19Z

Ich bin so frei und stelle das auf "Ready for review".
Die Änderungen an loadpoint.go sollten passen, die Tests sollten jetzt ja auch OK sein.
Gerne teste ich das nächste Nightly, ob in meinem Setup mit openWB alles so läuft wie es soll.

andig · 2023-04-29T13:15:52Z

Das können wir erst mergen wenns hemand getestet hat

GrimmiMeloni · 2023-04-29T19:25:55Z

@andig OK.

Ich habe einen docker build mit den Änderungen jetzt hier lokal laufen.
Falls noch jemand interessiert ist, der Tag ist grimmimeloni/evcc:nightly.

GrimmiMeloni · 2023-04-30T10:00:47Z

Mein nightly von gestern Abend war scheinbar vom master branch. Habe ich gerade korrigiert. Jetzt gerade habe ich auch bereits Phasen Wechsel erfolgreich beobachtet in beide Richtungen.

GrimmiMeloni · 2023-04-30T12:23:54Z

Hat jetzt doch etwas länger gedauert. Der Docker build ist auf den master branch festgelegt, hatte also immer noch den falschen build am laufen. Leider war das Auto jetzt schon fast voll. Zumindest einen automatischen Scale up habe ich mit dem Change gesehen. Funktioniert, allerdings war das Verhalten der Easee Box etwas merkwürdig.

Reihenfolge der Aufrufe passt zum Code

Zunächst 6A setzen
dann 3 Phasen aktivieren

jetzt wird es aber interessant - zumindest bei Easee

Charge Power wird mit 1380kw (6A @ 1P) protokolliert. Wirkt so, als hätte die Phasenumschaltung noch nicht stattgefunden. Ich vermute als Grund hier die Verzögerung durch die Cloud API).
evcc setzt 16A (Vermutung: Reaktion des Regelkreis auf die gemessenen geringen 1,4kW ?)
10 Sekunden später wird Charge Power mit 0kW geloggt. Ich nehme an, daß dies eine kurze durch Easee veranlasste Zwangspause für die eigentliche Phasenumschaltung ist.
10 Sekunden später wird Charge Power mit 11kW geloggt (also 16A @ 3p)
evcc greift jetzt direkt ein und setzt 9A und ab jetzt passt es

Scheint also erstmal soweit zu funktionieren.

Scale Down habe ich manuell über die UI ausgelöst, daß hat auch funktioniert. Ich nehme an, der Codepfad ist der Gleiche, so daß auch diese Beobachtung valide ist.

In Summe bleibt also bei der Easee ein kurzes Überschwingen auf 11kW nach der Umschaltung was dann aber direkt von Easee geregelt wird. Ich würde vermuten, daß Wallboxen mit einer lokalen API hier weniger Verzögerung haben, und die Umschaltung schnell genug ausgelöst wird, daß nicht vor dem Phase Switch wieder auf 16A hochgeregelt wird.

andig · 2023-04-30T12:31:02Z

Eigentlich sollte es vor der Umschaltung auf 6A runter gehen. Sonst ist 1p->3p keine gute Idee. Evtl. ist das jetzt weggefallen weil es keinen Enable() Schritt mehr gibt? Müsstest Du im Log sehen ob das bei der Easee überhaupt noch aufgerufen wird.

MarkusGH · 2023-05-01T09:59:35Z

Eigentlich sollte es vor der Umschaltung auf 6A runter gehen.
Sonst ist 1p->3p keine gute Idee.

Ich sehe ehrlich gesagt nicht warum dieser kurze Überschwinger (egal in welche Richtung) ein Problem ist.
Kannst Du bitte schreiben, inwiefern Du das als Problem siehst?

Evtl. ist das jetzt weggefallen weil es keinen Enable() Schritt mehr gibt?
Müsstest Du im Log sehen ob das bei der Easee überhaupt noch aufgerufen wird.

Ich denke das Problem ist schlicht, dass evcc nach Starten der Phasenumschaltung zu früh wieder eine Messung der genutzten Phasen macht. Habe mal versuchsweise einen Timeout eingebaut.

@GrimmiMeloni: Kannst Du bitte testen, ob das bei Dir das Problem vermeidet?

GrimmiMeloni · 2023-05-01T10:00:24Z

Eigentlich sollte es vor der Umschaltung auf 6A runter gehen.

Wird es. Das Problem ist, daß bevor Easee die Phasenumschaltung initiiert, bereits der evcc Regelkreis wieder anläuft, und dieser dann bei 1P korrekt wieder auf 16A erhöht. Easee braucht einfach zu lang.

Der letzte Change von @MarkusGH addressiert dies.

GrimmiMeloni · 2023-05-01T11:57:36Z

@MarkusGH habe meinen Nightly mit Deinem letzten Change aktualisiert.
Auto ist aktuell geladen - kann erst in den kommenden Tage etwas zum Ergebnis sagen.

GrimmiMeloni · 2023-05-03T10:41:02Z

Heute Vormittag konnte ich nochmal testen.
Das Ergebnis ist durchwachsen. Ich habe den kurzen Überschwinger auf 11kW direkt nach dem Umschalten erneut gesehen. Aber auch Ladung mit 32A@1p - was ich vorher noch nie gesehen habe. Ich glaube das hängt alles mit der trägen Verarbeitung auf der Easee Seite zusammen.

Für verlässliches Verhalten brauchen wir erst den change der in #7366 diskutiert wird. Oder jemand anders (ohne Easee) testet den Change hier.

MarkusGH · 2023-05-03T12:00:04Z

Wichtig wäre zunächst einmal, dass der Ablauf grundsätzlich richtig ist.

Meine Erwartung wäre:

Phasenumschaltung 1 -> 3:

Absenken des Ladestroms auf 1/3 (im Rahmen der konfigurierten Grenzen)
Phasenumschaltung
Regelung. Hier ist interessant wie viele Phasen bei der Berechnung der neuen Ladeleistung verwendet werden
Frühestens 60 Sekunden nach initiieren der Phasenumschaltung erstmals die Meldung: detected active phases: ...
Regelung auf Basis der in 4) gemessenen Zahl aktiver Phasen

Phasenumschaltung 3 -> 1:

Erhöhen des Ladestroms um den Faktor 3 (im Rahmen der konfigurierten Grenzen)
Phasenumschaltung
Regelung. Hier ist interessant wie viele Phasen bei der Berechnung der neuen Ladeleistung verwendet werden
Frühestens 60 Sekunden nach initiieren der Phasenumschaltung erstmals die Meldung: detected active phases: ...
Regelung auf Basis der in 4) gemessenen Zahl aktiver Phasen

Interessant insbesondere 3) und 4).

Ist das gegeben?

Wenn die Wallbox nachhängt oder den Befehl ignoriert dann ist das halt so, am Ende löst die Regelung das Problem anhand der gemessenen Leistung und Phasen.

GrimmiMeloni · 2023-05-03T13:19:17Z

@MarkusGH generell passt der Ablauf zum Code wie oben auch erwähnt. Das deckt sich mit Deiner Beschreibung. Auch die Verzögerung von 3*interval bis "detected active phases" gelogged wird ist hier zu sehen. Aus meiner Sicht macht der Code was er soll.

Es wird allerdings auch schwierig das hier komplett nachzuvollziehen, denn evcc verwendet nicht die Live Daten vom Charger, sondern einen lokal gespeicherten Wert. Heute morgen in meinem Versuch wurde z.B. der Aufruf verschluckt, der auf 6A gesetzt hat. evcc nimmt aber intern diesen Wert an (was ja auch korrekt ist), und entscheidet dann beim Phaseswitch das ein erneutes setzen auf 6A nicht nötig ist, weil es ja bereits der vermeintlich aktive Wert ist. Das in diesem Moment meine Wallbox aber mit 32A lädt, geht hier nicht in die Betrachtung ein.

Generell stimme ich Dir aber zu, daß die Logik richtig aussieht. Wie oben geschrieben, bleibt in meinem speziellen(?) Fall das Überschwingen, was aber auf das Zusammenspiel der Wallbox und des Cloud Dienst zurückzuführen ist.

Mehr kann ich hier aktuell nicht zuverlässig beisteuern, bis die Kommunikation mit Easee stabiler ist.

MarkusGH · 2023-05-03T13:32:04Z

@GrimmiMeloni: Danke - das reicht mir aus. 3 * Interval ist es allerdings leider (noch) nicht, sondern fix 60 sec, da ich nicht herausfinden konnnte wie man aus der loadpoint.go auf die Config zugreift.

@andig: Was muss ich tun um aus loadpoint.go auf das konfigurierte Regelintervall zuzugreifen?

andig · 2023-05-03T14:02:54Z

Was muss ich tun um aus loadpoint.go auf das konfigurierte Regelintervall zuzugreifen?

Da hast du keinen Zugriff drauf :(

MarkusGH · 2023-05-03T14:07:12Z

Was muss ich tun um aus loadpoint.go auf das konfigurierte Regelintervall zuzugreifen?
Da hast du keinen Zugriff drauf :(

Schade - dann bleibt nur der Workaround über guardGracePeriod. Geht, ist aber hässlich...

MarkusGH · 2023-05-03T15:09:39Z

Oder jemand anders (ohne Easee) testet den Change hier.

@GrimmiMeloni: Kannst Du mir das Binary (für ein x86 Linux) zukommen lassen?

GrimmiMeloni · 2023-05-03T15:24:47Z

Oder jemand anders (ohne Easee) testet den Change hier.

@GrimmiMeloni: Kannst Du mir das Binary (für ein x86 Linux) zukommen lassen?

Das Binary einzeln habe ich hier nicht rumliegen. Ich habe das in GitHub bauen und in den Docker Hub gepusht. Findest Du hier: https://hub.docker.com/r/grimmimeloni/evcc/tags

Kommst Du damit zurecht?

MarkusGH · 2023-05-04T15:10:10Z

Das Binary einzeln habe ich hier nicht rumliegen. Ich habe das in GitHub bauen und in den Docker Hub gepusht.
Findest Du hier: https://hub.docker.com/r/grimmimeloni/evcc/tags
Kommst Du damit zurecht?

Mangels Docker und (momentan) Zeit mich damit auseinanderzusetzen leider nein.

MarkusGH · 2023-05-04T15:16:53Z

Ich habe das Verhalten der aktuellen Nightly 0.116.7 (ohne den PR) mal angesehen - auch da ist ein Peak in der Ladeleistung.
Ablauf:
1p -> 3p (bei mir 2p weil das PHEV nur 2p kann):

Ladeleistung 16A
Ladeleistung 0A
Phasenumschaltung
Ladeleistung 16A
Regelung greift und regelt runter auf 8A

@andig: Ich sehe nach wie vor keinen echten Grund für die zusätzliche Anpassung des Ladestroms, nur weil wir jetzt vor der Phasenumschaltung nicht mehr explizit auf 0A gehen. Warum können wir das nicht der Regelung überlassen?

MarkusGH · 2023-05-19T12:09:47Z

OK, habe getestet.
Ergebnis ist:

keine schwerwiegenden Probleme auftreten
dass die Änderung des Ladestroms vor der Phasenumschaltung sowohl in der alten (also Ialt-> 0 -> Phasenumschaltung -> Ineu -> IRegelung) , als auch in der neuen Implementation (Ialt -> Ineu ->Phasenumschaltung -> IRegelung) so wie es gemacht wurde sinnlos ist.

Grund ist, dass die Wallboxen (mindestens die openWB, potenziell jede Wallbox) asynchron sind und ein unbekanntes Regelintervall haben. Man hat deswegen keine Kontrolle , wann und in welcher Reihenfolge Befehle ausgeführt werden.

Bei der openWB wird in meiner Version z. B. erst der Befehl zur Phasenumschaltung gelesen und dann erst Änderungen des Stroms. Das bedeutet man sieht das folgende:

Fri May 19 13:55:04 2023: switching phases on cp2: old=1 new=3
Fri May 19 13:55:14 2023: lp2 current change: 16 -> 8

Und das obwohl evcc erst die Änderung des Stroms und dann die Phasenumschaltung sendet.

premultiply · 2023-05-19T12:25:52Z

Ein solches asynchrones Verhalten mit "Ramdisk"-Puffer ist sonst eher ziemlich unüblich.

MarkusGH · 2023-05-19T12:30:58Z

Ein solches asynchrones Verhalten mit "Ramdisk"-Puffer ist sonst eher ziemlich unüblich.

Ich kenne die Firmware anderer Wallboxen nicht, insofern würde ich persönlich diesbezüglich keine Annahmen treffen.
Allerdings beweist der Fall openWB dass ein solches Verhalten mindestens nicht ausgeschlossen ist.

Den Mehrwert eine Änderung des Ladestroms vor der Phasenumschaltung halte ich auch für eher gering.

Wenn man die Anpassung des Ladestroms rein an die Wallbox und evcc's PV Regelung delegiert, hat man wenigstens keine zusätzliche Komplexität, die gepflegt werden muss.

MarkusGH · 2023-06-05T12:52:08Z

OK - meine Hoffnung war, dass die Reihenfolge der Befehle garantiert ist - schade.

naltatis · 2023-06-05T12:52:39Z

Mit der gleichen Hoffnung sind wir auch gestartet 😆

This reverts commit dd787ce.

andig · 2023-06-05T13:13:50Z

Reverted for time being :/

GrimmiMeloni · 2023-06-05T13:21:28Z

OK, das heißt dieser Change ist jetzt abhängig von #8307. Ich versuche heute Abend Zeit zu finden mir die Kommentare von @andig anzuschauen um das zu beschleunigen.

MarkusGH · 2023-06-05T13:37:31Z

Reverted for time being :/

Menno! Ich hätte noch einen Lösungsansatz gehabt, war aber gerade verhindert.

Lösungsansatz für den Übergang:

Charger Disabled sich bei der Phasenumschaltung.
Im nächsten Zyklus wird das dann ohnehin erkannt und der Charger wird enabled.

andig · 2023-06-05T14:52:38Z

das heißt dieser Change ist jetzt abhängig von #8307

Nur indirekt. In der Umschaltung müssen wir es dennoch berücksichtigen.

MarkusGH · 2023-06-05T16:09:42Z

In #8320 sollte ein Fix für das Verhalten sein. Easee disabled sich nach Senden des Befehls für die Phasenumschaltung, das Synchronisieren des enabled/disabled Zustands wird 30 sec verzögert bis der Befehl hoffentlich umgesetzt ist.

MarkusGH · 2023-06-05T16:13:32Z

@naltatis, @GrimmiMeloni: Mögt Ihr das ausprobieren?

GrimmiMeloni · 2023-06-05T19:52:00Z

Hab mir den Change zumindest im Source angeschaut, kann gerade nicht testen, weil Auto voll.
Ich sehe den Change für den Charger Level phase switch, den müßte sowieso @naltatis testen, da ich keinen zweiten Charger hab und nicht in dem Codepfad lande.
Ich verstehe aber den Change im Loadpoint nicht (mehr). Was hat es jetzt genau mit dem neuen zusätzlichen Timeout auf sich. Kannst Du das nochmal kurz erläutern, @MarkusGH ?

MarkusGH · 2023-06-05T20:00:32Z

Nach Phaseswitch meldet der Charger, dass er disabled ist und der Loadpoint würde ihn direkt wieder enablen. Die Änderung verzögert das um 30 Sekunden. Außerdem (der Schönheit willen) wird nach Phaseswitch für 60 Sekunden keine „Out of sync“ Meldung ausgegeben.

GrimmiMeloni · 2023-06-05T20:27:14Z

OK danke dafür.

Nur um sicher zu gehen, einmal mein Verständnis: Dieses konkrete Problem ist nun entstanden, weil wir innerhalb vom Easee Adapter den Charger disablen, und der Loadpoint das nicht mitbekommt. Somit erzeugen wir jetzt also ein "Charger out of sync" Zustand, und der Loadpoint würde ohne diesen Timeout das sofort wieder gerade ziehen.

Ferner haben wir auch über loadpoint.API keine Möglichkeit diese Änderung aus dem Charger heraus dem Loadpoint mitzuteilen.

Mir stellt sich die Frage, ob es nicht sinnvoller wäre den Loadpoint zu erweitern, so dass dieser mit beiden Varianten (Charger braucht enable/disable, oder nicht) umgehen kann. Diese Info könnte beim Charger abgefragt werden. Dann würde die ursprüngliche Logik bleiben, und Charger könnten ggf. diese Optimierung als unterstützt angeben (ähnlich wie api.ChargerEx auch optionalen Support für milliAmps anbietet). Das erscheint mir zumindest auf Dauer wartbarer als die diversen ineinander geschachtelten Timeouts.

andig · 2023-06-05T20:37:14Z

Der LP hat >1000 Zeilen Code. Weniger ist mehr.

MarkusGH · 2023-06-05T21:24:08Z

Nur um sicher zu gehen, einmal mein Verständnis: Dieses konkrete Problem ist
nun entstanden, weil wir innerhalb vom Easee Adapter den Charger disablen,
und der Loadpoint das nicht mitbekommt.

Nein - das ist kein Problem sondern so wie ich es hier vorschlage ein gewolltes Verhalten:

Loadpoint schickt an die Charger Implementierung ein Kommando zur Phasenumschaltung, die Charger Implementierung schickt das Kommando an die Charger Hardware.

Fall a)

Die Charger Hardware macht das einfach und gut ist.

Fall b (Easee)

Die Charger Hardware (in dem Fall Easee) braucht einen Ladestopp um die Phasenumschaltung durchzuführen.

Die betreffende Charger Implementierung unterbricht die Ladung und Charger.Enabled reflektiert das entsprechend.
Loadpoint ignoriert für 30 Sekunden nach Phasenumschaltung den Fall (Loadpoint.Enabled == true && Charger.Enabled == false).
Ab 30 Sekunden nach der Phasenumschaltung wird der Charger vom Loadpoint still und heimlich wieder enabled.
Ab 60 Sekunden nach der Phasenumschaltung tritt das normale Verhalten (Warnung + enable) in Kraft.

Das ist das was ich mit meinen bescheidenen Fähigkeiten anbieten kann.

Fall c) wäre meines Erachtens der Königsweg, den kriege ich aber nicht hin:

Die betreffende Charger Implementierung unterbricht die Ladung, aber Charger.Enabled reflektiert das nicht und gibt in der Zeit true zurück..
Nach einer für die jeweilige Hardware angemessenen Zeit startet die Wallbox implementierung die Ladung wieder.

Loadpoint kriegt das genausowenig mit, wie in Fall a)

Ist aber für mich in Go nicht programmierbar, da man dafür einen neuen Task aufmachen muss, der sich um das ggf. verzögerte Enable kümmert. Dieser muss aber beendet werden, wenn Charger.Enable(false) aufgerufen wird.

Somit erzeugen wir jetzt also ein "Charger out of sync" Zustand,

Ja - für Fall b) gewollt. In Fall c) würde das nicht passieren.

und der Loadpoint würde ohne diesen Timeout das sofort wieder gerade ziehen.

Ja - wobei das durchaus auch OK sein könnte. Kann ich nicht testen und ich wollte sicher gehen.
Man kann den entsprechenden Timeout auch auf 0 setzen.
Aber es mag andere Charger geben, die eine längere Pause brauchen.

Ferner haben wir auch über loadpoint.API keine Möglichkeit
diese Änderung aus dem Charger heraus dem Loadpoint mitzuteilen.

Das ist nicht notwendig.

Mir stellt sich die Frage, ob es nicht sinnvoller wäre den Loadpoint zu erweitern, so dass
dieser mit beiden Varianten (Charger braucht enable/disable, oder nicht) umgehen kann.
Diese Info könnte beim Charger abgefragt werden. Dann würde die ursprüngliche Logik
bleiben, und Charger könnten ggf. diese Optimierung als unterstützt angeben
(ähnlich wie api.ChargerEx auch optionalen Support für milliAmps anbietet).
Das erscheint mir zumindest auf Dauer wartbarer als die diversen ineinander geschachtelten Timeouts.

Da bin ich bei @andig. Das alte Verhalten war aus meiner Sicht deutlich zu komplex.

Die Änderung in #8320 ist bezüglich Loadpoint recht einfach - es gelten nur diese zusätzlichen Regeln:

Unternimm nach Phasenumschaltung für phaseSwitchCommandTimeout keine Versuche den Charger wieder zu enablen falls er unerwartet meldet dass er disabled ist.
Gib nach Phasenumschaltung für phaseSwitchDuration keine Warnungen aus falls der Zustand des Chargers von dem des Loadpoints abweicht.

GrimmiMeloni · 2023-06-06T06:09:48Z

Ich habe den Branch von MarkusGH gebaut und lokal deployed. Ich schaue mal was passiert.

@MarkusGH binary für Dich im Anhang.
evcc.50ee2cd.zip

MarkusGH · 2023-06-06T06:42:11Z

Ich habe den Branch von MarkusGH gebaut
und lokal deployed. Ich schaue mal was passiert.

Erwarten würde man in Deinem Fall dass nichts passiert.
Oder kannst Du auch mit Deiner einzelnen Easee erzwingen in den Condepfad zu kommen wo das Handling geändert ist?

GrimmiMeloni · 2023-06-06T11:18:00Z

Richtig. Bei mir sollte es keine Änderung im Verhalten geben. Aber schadet ja nicht das mal auszuprobieren. ;)

MarkusGH · 2023-06-06T11:29:43Z

Richtig. Bei mir sollte es keine Änderung im Verhalten geben. Aber schadet ja nicht das mal auszuprobieren. ;)

Auf jeden Fall - aber nochmal die Frage: Ist es in Deinem Fall nicht möglich Easee-seitig in den alternativen Codepfad zu kommen?

GrimmiMeloni · 2023-06-06T12:01:16Z

Ist es in Deinem Fall nicht möglich Easee-seitig in den alternativen Codepfad zu kommen?

Nicht das ich wüsste. Das hängt direkt mit der Physik zusammen. Beim Init wird erkannt das nur ein Charger am Circuit hängt, und dann wird der entsprechende Pfad genutzt.

premultiply · 2023-06-06T12:19:55Z

@naltatis Macht das wirklich technisch (=Flash Wear) bei Easee so einen Unterschied ob man für die Phasenumschaltung über Circuit oder Charger im API geht? Woraus leiten wir das ab? Ich gehe davon aus dass dass so oder so immer geschrieben wird, oder?

naltatis · 2023-06-06T12:23:11Z

@premultiply steht so in der Easee Doku:

https://developer.easee.cloud/docs/current-limits-and-control

https://developer.easee.cloud/docs/ocpp-smart-charging#set-charging-profile

(hier gehts um OCCP und Profiles, nicht um Charger Settings, aber ich vermute die Größenordnung ist hilfreich)

premultiply · 2023-06-06T12:28:44Z

Und Ciruit ist da immer dynamic (= nur flüchtig) und Charger immer persistent? Da wurde ich nicht richtig schlau aus der Doku. Hab das immer so verstanden dass sich das nur auf die Änderung der Ladeströme über Einstellungen die eigentlich nur für die einmalige Festeinstellung bzgl. Elektroinstallation bezieht.

Geht mir ja nur darum dass wir hier nicht einen riesen Aufwand treiben für etwas was am Ende ohnehin egal ist, auf einer unklaren Doku von Easee beruht und am Ende immer (oder nie?) in den Flash schreibt - egal wie.

naltatis · 2023-06-06T12:29:37Z

Und Ciruit ist da immer dynamic (= nur flüchtig) und Charger immer persistent?

Ja, das wird dann in den API Endpoints dazu klar. Der Charger hat ein dynamic* Property für Current. Beim Circuit is alles Dynamic.

MarkusGH · 2023-06-07T14:15:57Z

@naltatis: Hast Du mal ausprobiert, ob das von @GrimmiMeloni gebaute Binary evcc.50ee2cd.zip bei Dir funktioniert?

This reverts commit dd787ce.

…to UI (#8115) * Plugins: make javascript return values more permissive * Persist targetSoc/Energy, minSoc and target time, remove experimental from minSoc UI * go generate * Fix tests * Update minSoc description * Store settings by index. Show plan outside pv mode. Add help texts. * remove slug * go mock * lint * chore: simplify templates (#8304) * Add e2e tests with playwright (#8123) * Revert "1p3p: let charger handle session stop/restart (#7723)" This reverts commit dd787ce. * mazda2mqtt: document vin required (#8319) * FoxESS: split H1/H3 devices (#7376) Co-authored-by: premultiply <4681172+premultiply@users.noreply.github.com> * Translations update from Hosted Weblate (#8124) * Translated using Weblate (Czech) Currently translated at 37.3% (99 of 265 strings) Co-authored-by: Dusan Suja <bc.suja.dusan@googlemail.com> Translate-URL: https://hosted.weblate.org/projects/evcc/evcc/cs/ Translation: evcc/evcc * Translated using Weblate (Finnish) Currently translated at 100.0% (265 of 265 strings) Co-authored-by: Arna Lepikkö <arna.lepikko@telemail.fi> Translate-URL: https://hosted.weblate.org/projects/evcc/evcc/fi/ Translation: evcc/evcc * Translated using Weblate (German) Currently translated at 100.0% (265 of 265 strings) Co-authored-by: ThinkEV <claas@rootdir.de> Translate-URL: https://hosted.weblate.org/projects/evcc/evcc/de/ Translation: evcc/evcc * Translated using Weblate (Croatian) Currently translated at 100.0% (265 of 265 strings) Translated using Weblate (Slovenian) Currently translated at 100.0% (265 of 265 strings) Co-authored-by: Žiga Deisinger <ziga@deisinger.si> Translate-URL: https://hosted.weblate.org/projects/evcc/evcc/hr/ Translate-URL: https://hosted.weblate.org/projects/evcc/evcc/sl/ Translation: evcc/evcc * Translated using Weblate (Catalan) Currently translated at 100.0% (265 of 265 strings) Co-authored-by: Norbert Poch <npoch@yahoo.com> Translate-URL: https://hosted.weblate.org/projects/evcc/evcc/ca/ Translation: evcc/evcc * Translated using Weblate (Dutch) Currently translated at 76.6% (203 of 265 strings) Translated using Weblate (Dutch) Currently translated at 74.3% (197 of 265 strings) Co-authored-by: Ruben Van Boxem <vanboxem.ruben@gmail.com> Translate-URL: https://hosted.weblate.org/projects/evcc/evcc/nl/ Translation: evcc/evcc * fix toml --------- Co-authored-by: Dusan Suja <bc.suja.dusan@googlemail.com> Co-authored-by: Arna Lepikkö <arna.lepikko@telemail.fi> Co-authored-by: ThinkEV <claas@rootdir.de> Co-authored-by: Žiga Deisinger <ziga@deisinger.si> Co-authored-by: Norbert Poch <npoch@yahoo.com> Co-authored-by: Ruben Van Boxem <vanboxem.ruben@gmail.com> Co-authored-by: premultiply <4681172+premultiply@users.noreply.github.com> * Add OBO Betterman Ion (#8321) Also aligns heartbeat implementations * Enphase: add token auth (firmware D7.x.xxx) and grid (#8247) * Mqtt: fix smartCostLimit topic case (#8328) * Add ISO15118 vehicle template (#8302) * Mqtt: simplify setters * Mqtt: disable message ordering to improve performance * chore: simplify random state generation * Porsche: remove deprecated mobile api (#8349) * Porsche: remove remaining mobile api types * Cupra: add odometer (#8340) * chore: refactor go-stylish * chore: fix stale handler * mazda2mqtt: longer timeout (#8364) * chore: pre-process toml * chore: prevent toml double quotes * Audi: temporarily switch to etron (#8374) * Fix nightly build (#8384) * Update SunSpec templates (#8270) * Revert "Fix nightly build (#8384)" This reverts commit 536dbc9. * Revert "Add e2e tests with playwright (#8123)" This reverts commit 0df8157. * Easee: update Observation IDs (#8391) * Easee: handle smartCharging errors (#8389) * TWC: add non-Tesla vehicle warning (#8329) * TWC: allow loadpoint to wakeup vehicle (#8284) * chore: use gridx consts * Fix ISO15118 vehicle (#8402) Such vehicles would be reported as `(Offline)` previously, as no Soc can be fetched and thus needs to behave as the `offline` template. The SoC is fetched via the charger, so hardcode it to 0 in here * Modbus: add coils (#8385) * OpenEVSE: fix api (#8415) * chore: refactor offline vehicles (#8404) * Easee: wait for api confirmation (#8307) * Revert "Easee: wait for api confirmation (#8307)" This reverts commit ce0e427. * automatically switch session log energy unit (#8371) Show the charged energy in the session log table and details in Wh for values below 1 kWh and in kWh for larger values * Fix nightly/release + integration workflow (#8450) * Revert "Add e2e tests with playwright (#8123)" This reverts commit 0df8157. * Revert "Revert "Add e2e tests with playwright (#8123)"" This reverts commit 2299306. * fix nightly/release * fix nightly/release * fix nightly/release --------- Co-authored-by: andig <cpuidle@gmx.de> * chore: no integration on nightly * chore: no integration on nightly * chore: no integration on nightly * Sessions: filter, monthly sums, paging (#8278) * fmt * Update i18n/en.toml Co-authored-by: Simon Riepl <43091717+savus4@users.noreply.github.com> * Use exp/slices * Use mux consistently * add integration tests --------- Co-authored-by: andig <cpuidle@gmx.de> Co-authored-by: C64Axel <33828760+C64Axel@users.noreply.github.com> Co-authored-by: premultiply <4681172+premultiply@users.noreply.github.com> Co-authored-by: Weblate (bot) <hosted@weblate.org> Co-authored-by: Dusan Suja <bc.suja.dusan@googlemail.com> Co-authored-by: Arna Lepikkö <arna.lepikko@telemail.fi> Co-authored-by: ThinkEV <claas@rootdir.de> Co-authored-by: Žiga Deisinger <ziga@deisinger.si> Co-authored-by: Norbert Poch <npoch@yahoo.com> Co-authored-by: Ruben Van Boxem <vanboxem.ruben@gmail.com> Co-authored-by: salz3n <79696598+salz3n@users.noreply.github.com> Co-authored-by: Daniel Paschke <paschdan@gmail.com> Co-authored-by: Andreas Linde <42185+DerAndereAndi@users.noreply.github.com> Co-authored-by: lex777777 <84906358+lex777777@users.noreply.github.com> Co-authored-by: Oscar <OAltr@users.noreply.github.com> Co-authored-by: Michael Heß <GrimmiMeloni@users.noreply.github.com> Co-authored-by: RTTTC <94727758+RTTTC@users.noreply.github.com> Co-authored-by: kscholty <47229207+kscholty@users.noreply.github.com> Co-authored-by: Jan Alexander <jan.alexander@posteo.de> Co-authored-by: Simon Riepl <43091717+savus4@users.noreply.github.com>

MarkusGH marked this pull request as draft April 28, 2023 11:12

MarkusGH mentioned this pull request Apr 28, 2023

Don't stop charging while switching phases (let charger handle that) #7234

Closed

MarkusGH marked this pull request as ready for review April 29, 2023 12:56

andig added the enhancement New feature or request label May 3, 2023

andig added a commit that referenced this pull request Jun 5, 2023

Revert "1p3p: let charger handle session stop/restart (#7723)"

a437f87

This reverts commit dd787ce.

MarkusGH restored the No-charge-stop-before-phase-switch branch June 5, 2023 15:24

MarkusGH mentioned this pull request Jun 5, 2023

1p3p: let charger or charger implementation handle session stop/restart (BC) #8320

Merged

GrimmiMeloni mentioned this pull request Jun 5, 2023

Easee: wait for pause/resume to be acknowledged #8307

Merged

naltatis pushed a commit that referenced this pull request Jun 14, 2023

Revert "1p3p: let charger handle session stop/restart (#7723)"

451cf7c

This reverts commit dd787ce.

GrimmiMeloni mentioned this pull request Jun 29, 2023

Easee: Ladeleistung wechselt von 3.7kW auf 11kW im PV Modus #8572

Closed

Don't stop charging while switching phases (let charger handle that) #7723

Don't stop charging while switching phases (let charger handle that) #7723

Conversation

MarkusGH commented Apr 28, 2023 • edited Loading

GrimmiMeloni commented Apr 29, 2023

andig commented Apr 29, 2023

GrimmiMeloni commented Apr 29, 2023

andig commented Apr 29, 2023

MarkusGH commented Apr 29, 2023

andig commented Apr 29, 2023

GrimmiMeloni commented Apr 29, 2023 • edited Loading

GrimmiMeloni commented Apr 30, 2023

GrimmiMeloni commented Apr 30, 2023

andig commented Apr 30, 2023

MarkusGH commented May 1, 2023 • edited Loading

GrimmiMeloni commented May 1, 2023

GrimmiMeloni commented May 1, 2023

GrimmiMeloni commented May 3, 2023 • edited Loading

MarkusGH commented May 3, 2023 • edited Loading

GrimmiMeloni commented May 3, 2023

MarkusGH commented May 3, 2023 • edited Loading

andig commented May 3, 2023

MarkusGH commented May 3, 2023

MarkusGH commented May 3, 2023

GrimmiMeloni commented May 3, 2023

MarkusGH commented May 4, 2023 • edited Loading

MarkusGH commented May 4, 2023

MarkusGH commented May 19, 2023 • edited Loading

premultiply commented May 19, 2023

MarkusGH commented May 19, 2023 • edited Loading

MarkusGH commented Jun 5, 2023

naltatis commented Jun 5, 2023 • edited Loading

andig commented Jun 5, 2023

GrimmiMeloni commented Jun 5, 2023

MarkusGH commented Jun 5, 2023

andig commented Jun 5, 2023

MarkusGH commented Jun 5, 2023 • edited Loading

MarkusGH commented Jun 5, 2023

GrimmiMeloni commented Jun 5, 2023

MarkusGH commented Jun 5, 2023

GrimmiMeloni commented Jun 5, 2023

andig commented Jun 5, 2023

MarkusGH commented Jun 5, 2023 • edited Loading

GrimmiMeloni commented Jun 6, 2023

MarkusGH commented Jun 6, 2023 • edited Loading

GrimmiMeloni commented Jun 6, 2023

MarkusGH commented Jun 6, 2023

GrimmiMeloni commented Jun 6, 2023

premultiply commented Jun 6, 2023

naltatis commented Jun 6, 2023 • edited Loading

premultiply commented Jun 6, 2023 • edited Loading

naltatis commented Jun 6, 2023 • edited Loading

MarkusGH commented Jun 7, 2023

MarkusGH commented Apr 28, 2023 •

edited

Loading

GrimmiMeloni commented Apr 29, 2023 •

edited

Loading

MarkusGH commented May 1, 2023 •

edited

Loading

GrimmiMeloni commented May 3, 2023 •

edited

Loading

MarkusGH commented May 3, 2023 •

edited

Loading

MarkusGH commented May 3, 2023 •

edited

Loading

MarkusGH commented May 4, 2023 •

edited

Loading

MarkusGH commented May 19, 2023 •

edited

Loading

MarkusGH commented May 19, 2023 •

edited

Loading

naltatis commented Jun 5, 2023 •

edited

Loading

MarkusGH commented Jun 5, 2023 •

edited

Loading

MarkusGH commented Jun 5, 2023 •

edited

Loading

MarkusGH commented Jun 6, 2023 •

edited

Loading

naltatis commented Jun 6, 2023 •

edited

Loading

premultiply commented Jun 6, 2023 •

edited

Loading

naltatis commented Jun 6, 2023 •

edited

Loading