search

goecharger / go-eCharger-API-v1

API specification for V2 go-eCharger (compatible with V3 too)
100 stars 26 forks source link

"dwo" funktioniert nicht mehr zur Abschaltung nach Lademenge, vermutlich weil die interne Einheit geändert wurde in der Wallbox (siehe https://github.com/goecharger/go-eCharger-API-v1/issues/56) #86

Open chk2902 opened 3 years ago

chk2902 commented 3 years ago

Finde den Fehler...

{"version":"B","tme":"1009210629","rbc":"23","rbt":"2893421130","car":"4","amx":"16","amp":"16","err":"0","ast":"0","alw":"1","stp":"0","cbl":"32","pha":"56","fsp":"1","tma":[27,32],"dws":"9440237","dwo":"80","adi":"1","uby":"0","eto":"2456","wst":"3","fwv":"051.1","nrg":[235,233,233,0,0,0,0,0,0,0,0,0,0,0,0,0],"sse":"056129","wen":"1","cdi":"0","tof":"101","tds":"1","lbr":"255","aho":"0","afi":"6","azo":"0","ama":"16","al1":"6","al2":"10","al3":"12","al4":"14","al5":"16","cid":"255","cch":"65535","cfi":"65280","lse":"1","ust":"2","r1x":"2","dto":"0","nmo":"0","sch":"AAAAAAAAAAAAAAAA","sdp":"0","eca":"0","ecr":"0","ecd":"0","ec4":"0","ec5":"0","ec6":"0","ec7":"0","ec8":"0","ec9":"0","ec1":"0","rca":"1","rcr":"","rcd":"","rc4":"","rc5":"","rc6":"","rc7":"","rc8":"","rc9":"","rc1":"","rna":"User 1","rnm":"User 2","rne":"User 3","rn4":"User 4","rn5":"User 5","rn6":"User 6","rn7":"User 7","rn8":"User 8","rn9":"User 9","rn1":"User 10","loe":0,"lot":32,"lom":6,"lop":50,"log":"","lof":0,"loa":0,"lch":2859385}

Mein Leaf hat gestern abend auf 100% geladen, obwohl ich mit 33% ankam und 8 kWh nachladen wollte.

Dieser Datensatz sagt also, dass ich 8 kW nachladen wollte ("dwo"), aber "dws" sagt, dass ich 26 kWh geladen habe.

Das ist NICHT OK, ich wollte den Leaf nicht so viel laden!!!

e-up-driver commented 3 years ago

Mit Softwareversion 0.51.1 für die Hardware V3 wurde die mit "dws" übergebene Energiemenge auf Dekawattsekunden umgestellt (wie in der Doku der API V1 beschrieben). Vorher waren das fälschlicherweise Dekawattstunden. Wahrscheinlich hängt Dein Problem damit zusammen.

chk2902 commented 3 years ago

Ohne interne Kenntnisse zu haben, vermute ich, sie haben die interne Lademengen-Einheit mit der V3 geändert, damals aber erst mal vergessen, das korrekt für die HTTP-Implentation zu konvertieren. Und nun haben sie vergessen, dass "dwo" auch noch angepasst werden muss, um die gleiche Einheit zu haben, um mit dem internen Wert verglichen werden zu können.

e-up-driver commented 3 years ago

Ja, denke ich auch. Mit der go-e eigenen App eigenen App funktonieren ja alle Funktionen und Fehlerkorrekturen/Updates kommen relativ schnell. Warum es so schwierig ist, die Schnittstelle, die sie für die App benutzen, auch nach außen zur Verfügung zu stellen und zu dokumentieren, erschließt sich mir nicht. Die Phasenumschaltung funktoniert z.B. auch über die App ohne Probleme, dann sollte das mit EVCC oder OpenBW auch gehen.....

chk2902 commented 3 years ago

Weil sie eine andere Schnittstelle nutzen... 😁

peterpoetzi commented 3 years ago

Die neue API, die auch die App verwendet, findet man hier: https://github.com/goecharger/go-eCharger-API-v2

chk2902 commented 3 years ago

"Die neue API, die auch die App verwendet"...

Kannst Du dafür Deine Hand ins Feuer legen, dass die go-e App die HTTP API V2 nutzt? Mein IP-Capture sagt was anderes.

chk2902 commented 3 years ago

@e-up-driver PS: "Mit der go-e eigenen App eigenen App funktonieren ja alle Funktionen und Fehlerkorrekturen/Updates kommen relativ schnell."

das scheint nicht der Fall zu sein, mein Issue hier betrifft m.W. auch die hauseigene WebSocket-API, siehe https://www.goingelectric.de/forum/viewtopic.php?p=1677514#p1677514

e-up-driver commented 3 years ago

Ok, mit "alle" habe ich mich zu weit aus dem Fenster gelehnt. Die Abschaltung nach geladener Energiemenge habe ich nicht probiert, da ich das Feature nicht benötige.

0xFEEDC0DE64 commented 3 years ago

Unsere "interne" websocket api für die app wird bewusst nicht dokumentiert, da es für manche features manchmal schon notwendig war, "breaking changes" im websocket protokoll einzuziehen. Wir behalten uns bei jedem Charger Firmware update vor, das komplette websocket protokoll umzureissen und anzupassen. Wäre die websocket offiziell beschrieben und würde von allen Kunden genutzt werden, erschwert das dann die Implementierung zukünftiger Features zwischen Charger und App.

Die für den Kunden bereitgestellte http-api-v2 soll genau dafür ein Ersatz bieten, gibt's mit der irgendein Problem?

joscha82 commented 2 years ago

Die für den Kunden bereitgestellte http-api-v2 soll genau dafür ein Ersatz bieten, gibt's mit der irgendein Problem?

Auf der Fronius Wattpilot Hardware wird allerdings aktuell ausschliesslich die (undokumentierte) WebSocket API bereitgestellt.

chk2902 commented 2 years ago

@0xFEEDC0DE64 Ein Problem? Klar. Ansonsten könnt ihr die HTTP1 ja gleich von der Box entfernen, wenn HTTP2 vollwertiger Ersatz sein soll. Nein, die ist drauf (korrigiere mich bitte, wenn es nicht so ist) damit die V3 kompatibel ist zur V2 auch für alte Software. Und eben das ist nicht der Fall.

Ich habe nun nicht das Mords-Problem damit, meine App unterstützt HTTP2, aber es ist ein "Issue" wert, damit ihr es wisst und es korrigiert werden kann.

chk2902 commented 2 years ago

Ach, ich vergaß... Die HTTP2-Doku ist nicht wirklich dokumentiert: die meisten Schlüsselwerte schon (sehr rudimentäre Erklärungstexte, keine echte Erklärung), bei Objekten nur die "root"-Ebene, .... Und wie man welche Art von Ladung (Kombination von acs, frc, lmo) durchführen soll, ist mehr ein trial-and-error als angeleitetes Verfahren, ohne ab und zu hier im Issue eine Hilfe zu bekommen ist das ziemlich schwierig. Was man hier an meinen Issues sieht...