Go-E hardware v3 hat FW Update bekommen bzgl. api fix

[amnesia106]

v 051.3

#1384

[sebnaf]

Naja… 13s…

sna@arbeitsgeraet  ~  time curl 'http://10.10.20.22/mqtt?payload=alw=1'

{"version":"B", ... ,"loa":0,"lch":507}
curl 'http://10.10.20.22/mqtt?payload=alw=1'
0.00s user 0.00s system 0% cpu 13.417 total

[amnesia106]

bedeutet?

[sebnaf]

Dies bedeutet, dass das kein Fix ist, sondern ein mittelmässiger Workaround von go-e.

Mein Vorgehen hier wäre:

• @andig fragen, ob so lange warten OK ist oder ein Timeout bringen könnte
• prüfen, ob nur der alw-Endpoint so langsam ist oder auch das Setzen der Ladeleistung
• wenn es nur der alw-Endpoint ist: schauen, ob er trotzdem zuverlässig funktioniert und ggf die Prüfung nach dem Setzen entfernen, da ich heute nochmals einen out-of-Sync bekommen habe.

Wenn obiges nicht wie erwartet funktioniert, das Ganze mit der v2-Api von go-e testen. Ggf dort den CEO mal einschalten, damit die Doku endlich verfügbar wird und ihm von den technischen Problemem erzählen.

Die Tests kann ich Ende kommender Woche machen. Vorher habe ich leider keine Zeit.

[andig]

Du kannst beliebig lange waretn, die Regelung wird nur träger. Ist aber nix Schlimmes.

[sebnaf]

Super. Dann schaue ich mir am Donnerstag mal die anderen Punkte an.

[sebnaf]

@andig muss ich mir ansehen. Den Timeout bekomme ich nun auch

charger disable: Get "http://10.10.20.22/mqtt?payload=alw=0\": net/http: request canceled (Client.Timeout exceeded while awaiting headers)

[ttjaden]

Kurze Frage: Ich habe auch den neuen go-e Charger v3 inkl. dem neusten Software-Stande, siehe oben. In der Config habe ich:

chargers:
- name: go-e Schuppen (11kW) # v3 Hardware
  type: go-e
  uri: http://192.168.178.93
- name: go-e Gulfhof (22kW) # v2 Hardware
  type: go-e
  uri: http://192.168.178.9

In den Settings des v3 Chargers habe ich die Einstellungen so gesetzt:

Jedoch bekomme ich folgenden Fehler, wenn ich ein Fahrzeug anschließe.

Das Auto lädt nach dem Anstecken ca. 20s und dann hört es auf.
Frage: Gibt es eine Einstellung, dass es funktioniert, oder muss ich noch auf Anpassungen seitens go-e oder evcc warten?

[amnesia106]

Müssen uns noch etwas gedulden. Wie @sebnaf es beschrieben hat, wird er die neue FW testen. Vorab vielen Dank für euer Engagement! Solange heißt es für die v3 Besitzer: abwarten

[e-up-driver]

Die Firmware ist sicher nicht ausgereift. Bei mir (VW e-up) läuft es aber mit der 0.62 von EVCC auf der V3-Hardware mit Firmware 051.1, WENN ich auf den Modus min+PV gehe. Probleme gibt es immer dann, wenn EVCC den Ladevorgang unterbrechen oder Starten will (alw update failed, charger out of sync).

[sebnaf]

Die Firmware ist sicher nicht ausgereift. Bei mir (VW e-up) läuft es aber mit der 0.62 von EVCC auf der V3-Hardware mit Firmware 051.1, WENN ich auf den Modus min+PV gehe. Probleme gibt es immer dann, wenn EVCC den Ladevorgang unterbrechen oder Starten will (alw update failed, charger out of sync).

Genau, das ist bekannt. Danke fürs ebenfalls melden! Gerne kannst Du Dich auch dem Thread bei go-e anschließen: goecharger/go-eCharger-API-v1#75

[sebnaf]

"peterpoetzi commented 28 minutes ago
Ich kann bestätigen dass bei manchen Usern die v1 API jetzt mehrere Sekunden zum Antworten braucht. Wir arbeiten hier an einem Bugfix"

[sebnaf]

@ttjaden Dir ist bekannt, dass jeder Dein evcc über http://tjaden.synology.me/#/ erreichen und ändern kann?

[ttjaden]

@sebnaf Ja, zu Demo-Zwecke habe ich das immer mal wieder online. Dadurch, dass man ja nun das Laden starten und stoppen kann, war ich der Meinung, dass es auch nicht sicherheitsrelevant ist. Kannst du kurz darauf eingehen? Hat man über das Webinterface einen Zugang zum Inhalt der evcc.yaml? Wenn ja, dass beträfe das bei mir das Passwort für den SOC des Fahrzeugs...

[sebnaf]

@ttjaden Ich kann Deine Ladevorgänge starten und stoppen und verändern. Theoretisch kann ich dafür sorgen, dass Deine Auto morgen früh nicht voll geladen sein wird. Wie wichtig Dir das ist, musst Du wissen.

Weiter stehen in den Logs (UI-Warndreieck) Meldungen, die in Klartext Dein Gmail-Login und Passwort beinhalten. Ob Du diese so rausgeben möchtest, musst Du wissen. Das Passwort schaut jedoch sehr genererisch aus…

[andig]

Ich empfehle für den Fall, mit Docker ein Google Login davorzuschalten.

die in Klartext Dein Gmail-Login und Passwort beinhalten

Wo kommen die her? Sollten wir in evcc egtl. nicht mit drin haben?

[ttjaden]

@andig einen Docker mit Traefik oder Google Login kann ich natürlich mal machen. Jedoch ist das System eh nur temporär im Netz (WWW). Wichtig ist aber, was hinsichtlich der Log-Daten noch offen ist. Gmail-Login Daten können da ja in jedem Fall nicht drin stehen. @sebnaf meint eine Gmail-Mailadresse mit Passwort. Die Gmail-.Adresse gehört zum vehicle (Renault Login) und sollte ja tatsächlich am besten nicht in den Log-Files im Frontend aufgelistet sein. Ob das Passwort im Klartext oder als Hash gezeigt wurde, kann ich nicht mehr nachvollziehen, weil ich aktuell dort keine Fehlermeldung habe.

@andig: Verstehst du, was gemeint ist?

[andig]

Yep. Log: debug statt Trace sollte das Problem egtl lösen?

[sebnaf]

@ttjaden Dein Gmail-Passwort solltest Du nun auch ändern…

[andig]

Ich denke wir sollten wenigstens eine fette Warnung in der README spendieren.

[andig]

Ich denke hier gibts zwei Probleme:

• Fehlermeldungen beinhalten die technischen Details (die alle sein können). Falls wir das nicht wollen müssten alle potenziellen Fehler an der richtigen Stelle abgefangen und umformuliert werden. Wie würden dann „gute“ Fehlermeldungen aussehen?
• Die Logger (aus denen wir auch UI Meldungen generieren) sind nicht „redacted“. Log Redaction wäre generell nett (alle „bösen“ Daten ausblenden), eine gute Lösung ist mir aber nicht eingefallen.

[sebnaf]

Neues Update auf 051.4 ist da, nach einigem "Herumklicken" bisher keine Fehlermeldung.

[amnesia106]

time curl 'http://192.168.2.119/mqtt?payload=alw=1'
real	0m0,497s
user	0m0,000s
sys	0m0,011s

Jupp, sieht gut aus

[e-up-driver]

Bei mir läuft jetzt EVCC v0.63 mit einem go-e charger V3, Firmware 051.4 und einem VW e-up von 2021 ohne Fehlermeldungen und Probleme. Starten und Stoppen des Ladevorganges durch EVCC geht und der e-up "meldet sich nicht ab".

[Sillium007]

@bacanol Phasenwechsel ist schon drin, nur halt für die Box noch nicht :)
@sebnaf Ich würde erstmal "dumm" damit wie andig es für openWB gemacht hat anfangen. Einen Konfigparameter und anhand von dem entscheiden ob v2 API oder v1

[sebnaf]

@Sillium007 OK. Wenn ich Dir die Endpoints rausschreiben soll, sag Bescheid.

[Sillium007]

Erwartet aber nicht dass ich das diese oder nächste Woche fertig präsentieren kann. Derzeit ist meine Zeit leider etwas begrenzt

[andig]

Das muss @andig entscheiden. Ich persönlich würde es "offen" lassen, vorallem, wenn Du es integrieren würdest.
Zu bedenken ist, dass Du vorher prüfen musst, auf welcher API die Box läuft und dann entsprechend die Requests auch anpassen müsstest. Die Matrix und Beispiele in einer Postman-Collection könnte ich Dir jedoch bereitstellen.

Beim Sponsortoken gibt es 2 Aspekte. Zum Einen muss nicht nur die Entwicklung passieren sondern auch laufender Support. Die v3 hat gezeigt, was das bedeuten kann… Zum Anderen profitieren die kommerziellen WB-Hersteller hier von einer recht ausgereiften Lösung ohne selbst zu investieren. Den Open Source Lösungen- OpenWB, EvseWifi oder Warp entsteht dadurch ein Nachteil der ein klein wenig kompensiert werden kann.

[andig]

Ich würde jeden Hersteller herzlichst einzuladen, Projekte wie evcc zu unterstützen und damit gute Lösungen für IHRE Kunden langfristig verfügbar zu machen. OpenWB wird dabei übrigens bzgl. der SoC Module gleich behandelt.

[sebnaf]

@Sillium007 Ist bei uns allen so. Keine Sorge.