-
-
Notifications
You must be signed in to change notification settings - Fork 668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update EEBUS to use version 0.6 of EEBUS libs #13998
Conversation
DerAndereAndi
commented
May 20, 2024
•
edited
Loading
edited
- Update to eebus-go v0.6.0, spine-go v0.6.0 and ship-go v0.5.1
- Add better support for VW ISO VAS capable chargers and EVs, to enable them to go to sleep
This can also be used as a foundation to implement communication with a control box. But I recommend moving the eebus server then from charger to the server package. I tested this with a software emulation of a wallbox so far. Will test with multiple wallboxes during the next week. The updated version should also have everything needed to provide an interactive pairing UI. E.g. list all visible remote EEBUS devices, initiate a pairing request, but also react to incoming pairing requests. |
@DerAndereAndi ersetzt das dann #12407 oder ist das hier ein Zwischenschritt?
Könntest Du die teilen oder finde ich die in https://github.com/enbility/cemd? Vielen Dank!
Das wäre ein Thema dem wir uns widmen wollen wenn das Config UI released ist. |
Ja, das ersetzt deinen PR.
Nein, das geht leider nicht.
👍 |
Schade. Mir fehlt mangels Gerät jede Möglichkeit, hier etwas beizutragen ausser "trocken" coding. Es wäre Klasse den PR fertig zu bekommen- aktuell ist aufgrund der geänderten Struktur keine (einfache) Aktualisierung der Dependencies mehr möglich. |
Hi Andi, kann ich irgendwie helfen den PR zu finalisieren? Aufgrund der 0.x Versionen hängen wir sonst im Dependency Upgrade fest:
|
Ich kann erst nächste Woche wenn ich mein Auto wieder habe weiter machen. Alternative für upgrades: du änderst die bisherige Nutzung von Versionsnummer auf den entsprechenden Commit. |
Komischerweise klappt das beim cemd nicht:
Bei eebus-go gehts:
Sieht aus, als würde das Go Tooling das nicht zulassen. |
go.mod direkt editieren mit:
sollte gehen. Bei CEMD evtl. das Datum auch auf |
Tut auch nicht:
Ich warte einfach ;) |
Fixed by replacing the versions in 27d67d0 |
1f2a4a2
to
13d9155
Compare
Tested with two EEBUS compatible chargers and works great. It even seems to improve the crashing issues of the Elli Charger Connect and Pro wallboxes to some extend for me. |
This updates the eebus charger implementation to use the latest version 0.5 implementations of cemd, eebus, spine and ship
Only use OSCEV if the a wallbox with ISO15118-2 VW VAS is connected, and the EV is using this. This also enables full charging control and putting the EV to sleep. All other current implementations of the usecase are basically wrong and are no different than using OPEV.
- Updated to eebus-go v0.6.0, spine-go v0.6.0 and ship-go v0.5.1 - Various updates and fixes
13d9155
to
c0c1461
Compare
Ich hatte die use cases in #12407 noch (für meinen Geschmack) minimal eleganter erzeugt: // create use cases
service := c.cem.Service
c.uc = &Usecases{
EvseCC: ucevsecc.NewUCEVSECC(service, c.evseHandler),
EvCC: ucevcc.NewUCEVCC(service, c.evHandler),
EvCem: ucevcem.NewUCEVCEM(service, c.evHandler),
OpEV: ucopev.NewUCOPEV(service, c.evHandler),
EvSoc: ucevsoc.NewUCEVSOC(service, c.evHandler),
}
// register use cases
for _, uc := range []cemdapi.UseCaseInterface{
c.uc.EvseCC,
c.uc.EvCC, c.uc.EvCem, c.uc.OpEV, c.uc.EvSoc,
} {
c.cem.AddUseCase(uc)
} |
Klasse- hab noch ein paar Kleinigkeiten geändert und die Cert-Funktionen raus gezogen. |
Meinst Du das kann ins Nightly oder lieber bis nach Release warten? |
Wenn du kurzfristig ein Release planst, lieber danach |
Klasse- dann rein damit. Es steht grad nix Kritisches an. |
if err != nil { | ||
// there are no overload protection limits available, e.g. because the data was not received yet | ||
// there are limits available, e.g. because the data was not received yet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DerAndereAndi der Kommentar sollte "no limits" heißen? Oder ist die Bedingung falsch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Den Kommentar gibt es im aktuellen Code nicht und die Stelle greift nur bei VAS => Taycan. Das läuft sauber.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Arg, falsche Stelle. Den gibts immer noch:
limits, err := c.uc.OpEV.LoadControlLimits(evEntity)
if err != nil {
// there are limits available, e.g. because the data was not received yet
c.log.DEBUG.Println("!! OpEV.LoadControlLimits error", err)
return true, nil
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An der Stelle hier falsch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glaube ich kaum, denn Limits sind im Ablauf ja da und gesetzt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mir gehts nur um den Kommentar- der müsste heissen "no limits"? Dann würde ich das lokal korrigieren.