Various EEBUS improvements

[DerAndereAndi]

• This adds support for Elli Charger
• Removed EEBUS template and type parameter forcePVLimits as it is not needed
• Updated EEBUS reference to https://github.com/evcc-io/eebus/pull/2/commits
• Added Elli Charger template
• Moved mDNS Library to libp2p/zeroconf (currently a fork with a fix for avahi 0.8 support)
• Accept SKIs with upper letter and spaces
• Show any mDNS entry that claims to support SHIP
• Added support for coordinated charging in ISO EVs. Probably needs adjustments as this in general is a conflict between who controls the charging, but at least this allows evcc to react.
• Improved connection handling with improved automatic reconnects

Still work in progress, as the Elli Charger does not yet accept load limit changes.

This PR will not work unless the Elli certificate issue is fixed or a different workaround is found and implemented, see https://github.com/evcc-io/eebus/issues/1

[DerAndereAndi]

Update: This current state is working on my end if the certificate check in go is changed. We are still in progress to get the certificate error fixed. So this is not ready for merging as of now.

[DerAndereAndi]

@andig Was wäre das gewünschte Verhalten wenn keine Measurements verfügbar sind z.b. weil kein Messgerät verbaut ist. Also für Currents und für ChargedEnergy. Man wird nicht prüfen können ob so ein Gerät eingebaut sind, sondern nur "warten" ob entsprechende Werte kommen oder nicht.

Oder sollte man das eher über die Templates abfangen?

Bei den Elli Chargern gibt es die Connect ohne Zähler und Dienstprogramm mit Zähler. Man kann den Zähler auch selbst nachträglich einbauen in die Connect. Momentan wird die geladene Energiemenge nicht zurück gegeben (Bug) und in der Connect wird einfach die vorgegebene maximale Stromstärke als Messwert zurückgegeben.

[andig]

Ich fang mal von hinten an:

Momentan wird die geladene Energiemenge nicht zurück gegeben (Bug)

Gibts Gesamtzählerstand? Der reicht. Sonst rechnen wir das aus der Leistung zusammen falls es die gibt, sonst aus dem eingestellten Strom.

in der Connect wird einfach die vorgegebene maximale Stromstärke als Messwert zurückgegeben.

Dann gibts auch analog geladener Energie auch keine Strommessung- einfach weglassen. Oder werden wenigstens die Phasen richtig ausgegeben? Das hätte dann schon einen Wert, weiter verarbeitet als für Phasenerkennung werden die in evcc eh nicht.

Was wäre das gewünschte Verhalten wenn keine Measurements verfügbar sind z.b. weil kein Messgerät verbaut ist.

Zwei Optionen- das gleiche Problem haben wir bei OCPP auch:

• Anwenderkonfiguration (hasMeter: true)
• Erkennung beim Start (z.B. 60s warten) und decorators benutzen (da kann ich helfen)

Vielleicht auch Beides- das hasMeter könnte dann einfach die Zeit der automatischen Erkennung abkürzen. In jedem Fall muss die Verfügbarkeit beim Start von evcc bekannt sein, das kann leider nicht dynamisch passieren.

Wenn es mal keinen Meßwert geben sollte dann api.ErrNotAvailable zurück geben.

[andig]

Prinzipielle Frage: der Heartbeatfehler ist ja genereller Natur- wie wäre es, den schonmal in einen eigenen PR raus zu ziehen, ebenso die mDNS Themen? Dann bleibts hier übersichtlicher was wirklich elli-spezifisch ist?

[DerAndereAndi]

Gibts Gesamtzählerstand? Der reicht. Sonst rechnen wir das aus der Leistung zusammen falls es die gibt, sonst aus dem eingestellten Strom.

Es gibt keine Zählerstände.

Dann gibts auch analog geladener Energie auch keine Strommessung- einfach weglassen. Oder werden wenigstens die Phasen richtig ausgegeben? Das hätte dann schon einen Wert, weiter verarbeitet als für Phasenerkennung werden die in evcc eh nicht.

Wenn kein Messgerät vorhanden ist, wird nichts korrekt ausgegeben, sondern immer nur die vorgaben zurückgegeben. Wenn ein Messgerät vorhanden ist, werden die Stromwerte pro Phase korrekt zurückgegeben. "Einfach weglassen" geht nicht, da man das nicht automatisch erkennen kann ob ein Messgerät nun verbaut ist oder nicht.

Zwei Optionen- das gleiche Problem haben wir bei OCPP auch:

• Anwenderkonfiguration (hasMeter: true)
• Erkennung beim Start (z.B. 60s warten) und decorators benutzen (da kann ich helfen)

Vielleicht auch Beides- das hasMeter könnte dann einfach die Zeit der automatischen Erkennung abkürzen. In jedem Fall muss die Verfügbarkeit beim Start von evcc bekannt sein, das kann leider nicht dynamisch passieren.

Wenn es mal keinen Meßwert geben sollte dann api.ErrNotAvailable zurück geben.

Ich schau mir das mal an.

[DerAndereAndi]

Prinzipielle Frage: der Heartbeatfehler ist ja genereller Natur- wie wäre es, den schonmal in einen eigenen PR raus zu ziehen, ebenso die mDNS Themen? Dann bleibts hier übersichtlicher was wirklich elli-spezifisch ist?

Im Porsche Charger stört der Fehler nicht, also ist das Problem nicht relevant. Es gibt ja bisher keine weiteren EEBUS Wallboxen.

Außerdem sind die Änderungen nicht alle Elli spezifisch, es sind auch Anpassungen für den Porsche Charger mit Hybrid enthalten. Daher ist der PR auch im Titel und der Beschreibung nicht Elli spezifisch.

[andig]

Außerdem sind die Änderungen nicht alle Elli spezifisch, es sind auch Anpassungen für den Porsche Charger mit Hybrid enthalten. Daher ist der PR auch im Titel und der Beschreibung nicht Elli spezifisch.

Deshalb könnten wir die auch gerne vorab mergen.

[DerAndereAndi]

Ich möchte diesen PR nicht komplett auseinandernehmen. Maximal die Templates raus und dann damit und weiteren Anpassungen einen neuen PR. Dazu sollte der EEBUS PR auch gemerged werden,

[andig]

Templates gerne als eigenen PR. Der ski Parameter kann in die defaults.yaml um Doppelungen zu vermeiden. Das forcePVLimits is auch im backend noch drin- da ebenfalls raus? Soll ich dabei helfen?

[DerAndereAndi]

Elli template wurde entfernt, master wurde in den Branch gemerged. Elli support geht dann in einem neuen PR weiter.