GrimmiMeloni
commented
8 months ago @Cytron1980 für die Analyse benötige ich von Dir ein Log mit Easee auf Trace.
log: debug
levels:
cache: error
easee: traceClosed Cytron1980 closed 8 months ago
GrimmiMeloni
commented
8 months ago @Cytron1980 für die Analyse benötige ich von Dir ein Log mit Easee auf Trace.
log: debug
levels:
cache: error
easee: trace
Cytron1980
commented
8 months ago Werde ich beim nächsten Überschuss erstellen.
Cytron1980
commented
8 months ago Hier mal der Log von gerade eben. Nach hause gekommen, Auto angeschlossen, Klimatisierung erkannt (warum weiß ich nicht im Auto ist nichts aktiv) und er hat die Meldung ausgespuckt, dass keine Phasenumschaltung erfolgen konnte...
GrimmiMeloni
commented
8 months ago Der Climater ist hier erstmal nur Nebelkerze und verhindert lediglich das Abschalten.
@andig hier gibt es ein Problem mit der Logik im Loadpoint.
Wenn die phases als inconsistent erkannt werden, resetten wir measuredPhases auf 0.
Das führt dann aber automatisch dazu dass activePhases in
immer 1 ist, und somit ein Schalten der Phasen verhindert wird. Aus der Situation kommt man aber nicht mehr raus, weil der Loadpoint auf 1 beharrt, und der Charger korrekt immer wieder 3 melden wird.
Mir erscheint es generell nicht richtig, das Loadpoint.phases bei der Ermittlung von "activePhases" herangezogen wird. Eigentlich kennt doch nur der Charger die Wahrheit...?
andig
commented
8 months ago Wenn die phases als inconsistent erkannt werden, resetten wir measuredPhases auf 0.
Hilf mir mal bitte- wo passiert das? Vllt. sollten wir an der Stelle für einen 1p3p Charger zusätzlich auch wieder auf "auto" umschalten?
Mir erscheint es generell nicht richtig, das Loadpoint.phases bei der Ermittlung von "activePhases" herangezogen wird.
Im Zweifel ist das halt der letzte bekannte Stand. Ich frag mich ja eher, wie wir hier überhaupt in die inkonsistente Situation kommen?
GrimmiMeloni
commented
8 months ago Wenn die phases als inconsistent erkannt werden, resetten wir measuredPhases auf 0.
Hilf mir mal bitte- wo passiert das?
Hier.
Vllt. sollten wir an der Stelle für einen 1p3p Charger zusätzlich auch wieder auf "auto" umschalten?
Ich glaube das ist das, was die 0 ausdrücken soll? (Analog zur Konfiguration?)
Mir erscheint es generell nicht richtig, das Loadpoint.phases bei der Ermittlung von "activePhases" herangezogen wird.
Im Zweifel ist das halt der letzte bekannte Stand.
Ja, das ist auch OK. Das Problem ist, das die Logik in activePhases() mit der 0 nicht gut umgehen kann. Sie macht 3 draus. Dann wird aber das Minimum (in diesem Fall 1 vom Loadpoint) ermittelt, und das angenommen. Im Anschluß sieht dann die weitere Logik keine Notwendigkeit mehr die Phasen runterzuschalten, weil ja bereits 1 als aktiv ermittelt wurde. Und das ist falsch. Generell kann man sagen, wenn immer der Loadpoint weniger Phasen annimmt, als in Wahrheit aktiv sind, wird durch die aktuelle Implementierung ein runterschalten der Phasen verhindert, und man kommt deshalb in jedem Intervall wieder den "inconsistent phases" Fehler.
Ich frag mich ja eher, wie wir hier überhaupt in die inkonsistente Situation kommen?
Das konnte ich aus dem Log nicht erkennen, weil es erst beginnt wenn dieser Zustand schon erreicht ist. @Cytron1980 gibt es die Chance auf ein vollständiges Log, oder ist das schon gelöscht?
Cytron1980
commented
8 months ago Das Log vom besagten Tag wurde schon gelöscht. Da der Fehler sich aber reproduzieren lässt, werde ich sobald er wieder auftritt ( Auto ist gerade halbwegs voll) den Log hier einstellen...
andig
commented
8 months ago Ich mache mal zu bis es ein Logfile gibt.
Tonno87
commented
8 months ago Ich hab das gleiche Problem, ziemlich nervig... Muss man das loglevel auf Trace setzen? Denn debug liefert nicht wirklich was brauchbares.
andig
commented
8 months ago Das würde helfen. Nur für die Easee.
Cytron1980
commented
8 months ago Der Fehler mit der Phasenumschaltung ist bei mir nicht mehr vorgekommen. Nur der Logic Error kommt bei jedem Start nach wie vor. Log werde ich nachher noch erstellen.
Cytron1980
commented
7 months ago Hier ein neues Log von Heute: habe den priority soc auf 75 gesetzt und Ladung hat 3 Phasig mit 4,1kW angefangen zu laden ohne die Phasen auf einphasig zu steuern (bzw. hat die Easee dies nicht gemacht). Dann erkannt, dass der Überschuss zu gering ist (PV-Leistung war bei ca 2-3kW) um die Ladung nach 3 Minuten zu beenden und dann wieder einen Überschuss erkannt. Somit dann das ganze Prozedere von vorne.
Tonno87
commented
7 months ago Vielleicht packst du das besser in eine Textdatei.... So ist das schon mühselig.
Ich konnte bisher kein Log erstellen weil ich das HA Add-on benutze. Das erstellt kein Log und ich muss dann immer alles von Hand rauskopieren. Am Wochenende stelle ich das mal um auf eine VM.
Jedenfalls hatte ich das jetzt auch wieder: man hat Überschuss von 3kw und er startet die Ladung mit 3p und beeendet sie dann wieder wegen zu wenig Überschuss. Deshalb hab ich aktuell den Lademodus auf 1p festgesetzt und lade dann halt direkt einphasig.
Cytron1980
commented
7 months ago Vielleicht packst du das besser in eine Textdatei.... So ist das schon mühselig.
Ich konnte bisher kein Log erstellen weil ich das HA Add-on benutze. Das erstellt kein Log und ich muss dann immer alles von Hand rauskopieren. Am Wochenende stelle ich das mal um auf eine VM.
Jedenfalls hatte ich das jetzt auch wieder: man hat Überschuss von 3kw und er startet die Ladung mit 3p und beeendet sie dann wieder wegen zu wenig Überschuss. Deshalb hab ich aktuell den Lademodus auf 1p festgesetzt und lade dann halt direkt einphasig.
Danke für den Tip, habe meinen Eintrag editiert. Habe es jetzt auch mal auf 1-Phasig gestellt. Dieses funktioniert allerdings genauso wenig, da ja die Easee anscheinend ein Problem bei der Umschaltung des Phasenmodus von 3 auf 1-Phasig hat und somit auch bei der manuellen Umschaltung auf 1-Phasig. Edit: Habe jetzt in der Easee direkt den Modus auf 1-Phasig gestellt. Somit klappt dein Vorschlag fürs erste. Danke
Tonno87
commented
7 months ago In der Easee App kannst du das ebenfalls vorgeben bei den Einstellungen des Laderoboters:
Cytron1980
commented
7 months ago In der Easee App kannst du das ebenfalls vorgeben bei den Einstellungen des Laderoboters:
So hab ich es jetzt auch erstmal gelöst. Danke für den Tip. Habe nach beginn der 1-Phasigen Ladung jetzt direkt mal wieder auf Automatisch gestellt. Mal sehen, was EVCC dann macht, wenn auf 3-Phasig umgestellt werden soll.
Cytron1980
commented
7 months ago Neuer Log: nach dem Umschalten in der Easee Einstellung von Automatisch auf Einphasig ,dem Starten des PV-Modus in EVCC und dem erneuten aktivieren der automatischen Phasensteuerung in der Easee selber, scheint die Funktion wieder zu klappen.
Um ca 13:08 wurde automatisch von 3 auf 1-Phasig umgestellt. log nach umschaltung.txt
Edit: Ich beobachte weiter das Verhalten. Die Funktion scheint nur kurzzeitig zu sein und nicht von Dauer. Gerade eben wieder Probleme beim Umschalten der Phasen gehabt.
GrimmiMeloni
commented
7 months ago @Cytron1980 zwecks Klarheit. Ich brauche zur Analyse wenn der Fehler aufgetreten ist ein vollständiges(!) Log. Also, ab Startup von evcc. Ausschnitte helfen nicht, weil dann nicht klar ist, in welchem Zustand die Wallbox ist wenn die Fehler auftreten.
Cytron1980
commented
7 months ago Werde morgen zu Beginn der Überschuss-Periode EVCC neu starten und nach Auftreten des Fehlers hier einen kompletten Log einstellen.
Cytron1980
commented
7 months ago Kurze Rückmeldung. Gerade hat es ohne Probleme funktioniert. Ladung einphasig begonnen, obwohl sowohl Easee als auch EVCC auf automatische Phasenumschaltung steht. Warte die nächste Zeit ab und werde sobald der Fehler wieder auftritt hier das komplette Log hoch laden.
Cytron1980
commented
7 months ago Hallo, Gerade nach Hause gekommen und nach dem einstecken und starten direkt den Fehler provoziert. Danach EVCC neu gestartet und PV-Modus wieder aktiviert. Sofort wieder auf 3 Phasig gegangen. Easee erstmal auf Ein-Phasig gestellt.
Cytron1980
commented
7 months ago Ich mache mal zu bis es ein Logfile gibt.
Sollte der Fall wieder aufgemacht werden? Aktuelle Logfile habe ich vorgestern eingestellt. Danke
andig
commented
7 months ago @GrimmiMeloni willst du da rein schauen?
GrimmiMeloni
commented
7 months ago Nach dem Neustart: Loadpoint macht korrekten Scale down. Easee bestätigt das auch und geht für alle 3 Phasen von 40,40,40 auf 16,0,0 Amps.
[lp-1 ] DEBUG 2024/03/25 15:46:24 phase scale1p in 0s
[easee ] TRACE 2024/03/25 15:46:24 GET https://api.easee.com/api/sites/660895/circuits/624692/settings
[easee ] TRACE 2024/03/25 15:46:25 {"allowOfflineMaxCircuitCurrent":false,"equalizerId":null,"masterChargerId":"EHNRT639","useDynamicMaster":false,"dynamicCircuitCurrentP1":40.0,"dynamicCircuitCurrentP2":40.0,"dynamicCircuitCurrentP3":40.0,"enableIdleCurrent":true,"maxCircuitCurrentP1":16.0,"maxCircuitCurrentP2":16.0,"maxCircuitCurrentP3":16.0,"offlineMaxCircuitCurrentP1":16,"offlineMaxCircuitCurrentP2":16,"offlineMaxCircuitCurrentP3":16}
[easee ] TRACE 2024/03/25 15:46:25 POST https://api.easee.com/api/sites/660895/circuits/624692/settings
[easee ] TRACE 2024/03/25 15:46:25 {"dynamicCircuitCurrentP1":16,"dynamicCircuitCurrentP2":0,"dynamicCircuitCurrentP3":0}
...
[easee ] TRACE 2024/03/25 15:46:26 ProductUpdate EHNRT639: (2024-03-25 14:46:26 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P1 16
[easee ] TRACE 2024/03/25 15:46:26 ProductUpdate EHNRT639: (2024-03-25 14:46:26 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P2 0
[easee ] TRACE 2024/03/25 15:46:26 ProductUpdate EHNRT639: (2024-03-25 14:46:26 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P3 0Bisher alles gut. Kurz drauf schaltet aber die Easee ohne das evcc dazu Kommandos sendet wieder auf 40A hoch. Den Fehler im Error String no schedule to override, but restoring dynamic current anyway habe ich so erstmal noch nie gesehen.
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:42 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P1 40
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:41 +0000 UTC) ERROR_STRING no schedule to override, but restoring dynamic current anyway
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:41 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P1 40
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:41 +0000 UTC) DYNAMIC_CHARGER_CURRENT 32
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:42 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P2 40
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:41 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P2 40
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:41 +0000 UTC) DYNAMIC_CHARGER_CURRENT 32
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:42 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P3 40
[easee ] TRACE 2024/03/25 15:46:41 ProductUpdate EHNRT639: (2024-03-25 14:46:41 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P3 40
[easee ] TRACE 2024/03/25 15:46:42 CommandResponse EHNRT639: {SerialNumber:EHNRT639 ID:22 Timestamp:2024-03-25 14:46:42.10673 +0000 UTC DeliveredAt:2024-03-25 14:46:42.078 +0000 UTC WasAccepted:true ResultCode:0 Comment: Ticks:638469748021067305}
[easee ] TRACE 2024/03/25 15:46:42 CommandResponse EHNRT639: {SerialNumber:EHNRT639 ID:63 Timestamp:2024-03-25 14:46:43.268448 +0000 UTC DeliveredAt:2024-03-25 14:46:43.13 +0000 UTC WasAccepted:true ResultCode:0 Comment: Ticks:638469748032684480}
[easee ] TRACE 2024/03/25 15:46:42 CommandResponse EHNRT639: {SerialNumber:EHNRT639 ID:48 Timestamp:2024-03-25 14:46:43.31007 +0000 UTC DeliveredAt:2024-03-25 14:46:43.204 +0000 UTC WasAccepted:true ResultCode:0 Comment: Ticks:638469748033100705}
[easee ] TRACE 2024/03/25 15:46:42 CommandResponse EHNRT639: {SerialNumber:EHNRT639 ID:22 Timestamp:2024-03-25 14:46:43.308352 +0000 UTC DeliveredAt:2024-03-25 14:46:43.289 +0000 UTC WasAccepted:true ResultCode:0 Comment: Ticks:638469748033083524}
[easee ] TRACE 2024/03/25 15:46:42 ProductUpdate EHNRT639: (2024-03-25 14:46:43 +0000 UTC) DYNAMIC_CHARGER_CURRENT 32
[easee ] TRACE 2024/03/25 15:46:42 ProductUpdate EHNRT639: (2024-03-25 14:46:43 +0000 UTC) DYNAMIC_CHARGER_CURRENT 32
[easee ] TRACE 2024/03/25 15:46:42 ProductUpdate EHNRT639: (2024-03-25 14:46:43 +0000 UTC) ERROR_STRING no schedule to override, but restoring dynamic current anyway
[easee ] TRACE 2024/03/25 15:46:43 CommandResponse EHNRT639: {SerialNumber:EHNRT639 ID:11 Timestamp:2024-03-25 14:46:44.247579 +0000 UTC DeliveredAt:2024-03-25 14:46:44.093 +0000 UTC WasAccepted:true ResultCode:0 Comment: Ticks:638469748042475791}
[easee ] TRACE 2024/03/25 15:46:43 ProductUpdate EHNRT639: (2024-03-25 14:46:43 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P1 40
[easee ] TRACE 2024/03/25 15:46:43 ProductUpdate EHNRT639: (2024-03-25 14:46:43 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P2 40
[easee ] TRACE 2024/03/25 15:46:43 ProductUpdate EHNRT639: (2024-03-25 14:46:43 +0000 UTC) DYNAMIC_CIRCUIT_CURRENT_P3 40Auch wichtig - die Command Ticks die hier in diesem Block als Bestätigung vom Charger kommen (638469748021067305, 638469748032684480, 638469748033100705, 638469748033083524, 638469748042475791), haben wir sonst nicht im Log.
D.h. nach meinem Verständnis, irgendetwas anderes regelt hier parallel zu evcc.
@Cytron1980 falls Du noch irgendetwas anderes "smartes" in Deinem Netz hast, daß mit Easee spricht wird dies wohl der Grund sein. Alternativ, hast Du irgendwelche Ladepläne oder ähnliches bei Easee direkt definiert, die die Easee Cloud dazu veranlassen könnten deinen Charger wieder auf 40A zurückzusetzen? Ansonsten würde ich bei Easee mal anfragen, was genau dieser Fehlertext andeutet?
Nach jetzigem Stand ist das hier aber kein evcc Problem.
Cytron1980
commented
7 months ago @GrimmiMeloni Frohe Ostern und danke erst einmal für deine Bemühungen. Den "Verdacht" anderer Smarter Devices, die Zugriff auf die Wallbox haben, hatte ich auch schon und danach die Easee Instanz auf meinem Iobroker gestoppt. Daran liegt es wohl nicht. Desweiteren habe ich einen Stromvertrag bei Tibber, wo die Wallbox zwar eingebunden aber das "Smart-Charging" deaktiviert ist und der Zeitplan der Wallbox auf "Aus" steht. Die Wallbox bei Tibber aus dem System zu nehmen ist ohne Hilfe des Supports leider nicht möglich. Werde dieses aber mal bei denen anreizen und das Verhalten dann beobachten. soll ich die Command Ticks zu Easee senden oder den Error String? Womit können die wohl am Meisten was anfangen? Sollte es neue Erkenntnisse geben, so melde ich mich nochmal.
VG
Tonno87
commented
7 months ago Du kannst in der easee cloud den Betreiber entfernen oder wechseln:
Bei mir ist Tibber auch seit Monaten als Betreiber eingetragen, die Probleme sind aber erst seit kurzem vorhanden. Ich hab bei mir noch den Equalizer im System, aber der begrenzt ja über andere Parameter und sollte evcc eigentlich nicht stören.
Cytron1980
commented
7 months ago @Tonno87 Danke für den Tipp. Ist durch das Löschen des technischen Betreibers auch tatsächlich die Anbindung an Tibber aufgehoben? Wenn der Fehler erst seit kurzem vorhanden ist , sehe ich erst einmal keine Veranlassung dazu dieses zu Ändern. So wie ich das sehe, ist dieser Eintrag auch nur ein Text und hat keinerlei Auswirkung auf die Regelung des Laderoboters, oder?
VG
Tonno87
commented
7 months ago Über die Angabe des Betreibers wird diesem der Zugriff gestattet die Wallbox zu steuern, man kann natürlich nicht ausschließen daß trotz der Pausierung bei Tibber eine Beeinflussung stattfinden kann. Immerhin kann sich da ja auch etwas in der Cloud geändert haben. Wenn du den Eintrag rausnimmst hat tibber keinen Zugriff mehr, in der Kachel steht das dann auch so drin.
Ich vermute mal es handelt sich technisch gesehen um einen ocpp Zugang, daher kann man da auch nur einen Betreiber auswählen. Evcc greift ja direkt auf die API zu.
Tibber hat bei mir auch noch nie eine Phrasenumschaltung erzwungen, wenn solares laden aktiviert ist wird immer mit 11kW geladen. Daher würde ich da evcc auch gerne vorziehen 😃
Cytron1980
commented
7 months ago Stimmt, wirklich "Smart" ist das Laden von Tibber nicht. Aber wenn Tibber immer 3-Phasig laden muss/will, könnte das ja doch schon zu einer Umschaltung führen, oder? ich werde in jedem Fall mal den Support sowohl von Tibber als auch Easee bemühen. Mal sehen, was die dazu sagen.
Habe aber erstmal Tibber als Betreiber raus geworfen. Mal sehen, welche Auswirkung das hat. VG
Cytron1980
commented
7 months ago Kurzes Update: Nach dem Löschen von Tibber als Betreiber der Easee funktioniert alles wie gewollt. Danke für den Support hier. Viele Grüße
Describe the bug
Dies ist mein erstes Issue. Sollte also etwas nicht richtig angegeben oder falsch formatiert sein, so lasst es mich bitte wissen. zum Problem: Modus PV: Easee Home lädt bei einstecken des ID4 und Freischalten mittels RFID mit voller Leistung (dies wird über die Fehlermeldung "logic error: disabled but charging" angezeigt. Nach einer kurzen Zeit (ich denke mal, bis vom Server bei Easee eine Rückmeldung kommt) geht EVCC in den Standby. Sobald Überschuss da ist, wird angefangen zu Laden. Allerdings nicht wie in der Config und der WB selber, angegeben einphasig sondern direkt mit 4,7kW. Dadurch ist dann wieder ein Mangel an Überschuss, was die Ladung nach Zeit X unterbricht, nur um dann wieder festzuzstellen, dass wieder Überschuss vorhanden ist, wodurch das Prozedere von vorne beginnt. Es scheint also ein Problem mit der Umschaltung der Phasen zu geben, was durch die Meldung "ignoring inconsistent phases: 1p < 3p observed active" angezeigt wird.
Nach Neustart von EVCC funktioniert alles solange die 1. Ladung wegen zu wenig Überschuss pausiert wird. Dann beim nächsten Start wieder das gleiche Verhalten wie oben beschrieben.
![Uploading IMG_1207.PNG…]()
Steps to reproduce
1.Starte Laden
Configuration details
Log details
What type of operating system are you running?
Windows
Version
0.124.6