Elli Gen 1 (Connect/Pro) Support Status

[DerAndereAndi]

I'd like to share the current status of supporting Elli Gen 1 Wallboxes, namely the Connect and Pro devices which are also available with other branding than Elli.

The devices only support communication via the EEBUS protocol, but do have a lot of bugs. None of these bugs will ever be fixed as multiple customers got notified by the Elli customer support. All problems are known to Elli since they released the software update which introduced EEBUS support.
A few weeks ago, Elli announced a new Wallbox 2 which does not have any of the issues of the Gen 1 wallbox.

Here are some (not all) of the known bugs and what they mean for being used in evcc:

Problem 1 - invalid certificate

Description: EEBUS uses a websocket connection via TLS 1.2. The certificate of the wallbox does not comply with TLS 1.2 and is rejected by Go (the language used to develop evcc).

Solution: evcc needs to patch the Go system libraries to allow the invalid certificate to be accepted.

Problem 2 - invalid initial data

Description: When initiating the connection and reading initial values, lots of them are invalid or plain empty:

1. Initial charging limits are unknown
2. Charging measurements are unknown/not reported (even though the EV is charging!)
3. Valid limit ranges are unknown (that is minimum and maximum currents, according to the DIP switch settings, especially 1-phase setups seem to have issues)

Solution:

1. evcc has to assume that no limits are set, and the EV is allowed to charge at max speed (and max speed can be unknown, see 3.)
2. The customer should connect an external meter and configure it at the loadpoint. See https://docs.evcc.io/docs/reference/configuration/loadpoints#meter
3. Define the following values at the loadpoint configuration: phases, mincurrent, maxcurrent. See https://docs.evcc.io/docs/reference/configuration/loadpoints#phases

Problem 3 - missing measurement data

Description: In multiple scenarios, the wallbox does not sent valid or up to date charging measurements, or it doesn't send any at all:

1. If the websocket connection is lost and a reconnection happened, no measurements are sent. This also happens when evcc restarts while an EV is connected, e.g. because evcc was updated!
2. The validity of measurement data sometimes is unclear, because they are stuck and don't update even if charging limits change
3. The Connect device on top of this always assumes that the EV charges with the actively set limit. No matter if it really is charging or not

Solution:
The customer should connect an external meter and configure it at the loadpoint. See https://docs.evcc.io/docs/reference/configuration/loadpoints#meter

Problem 4 - changing charging limits is accepted but shows no effect

Description: When evcc sets a new charging limit, to e.g. stop charging, the change is acknowledged as being successfully done by the wallbox. But no new measurement data is provided.

Solution:

• evcc either has to assume that the charging limit is really in effect and will report the limits as being actively used (this is just an assumption and my not be real!). This is what evcc in some situations did until Version 0.127.3. This is not done in all subsequent versions!
• The customer should connect an external meter and configure it at the loadpoint. See https://docs.evcc.io/docs/reference/configuration/loadpoints#meter

Problem 5 - the EEBUS software on the wallbox crashes on connection

Description: When evcc establishes a connection to the wallbox, the EEBUS software on the wallbox sometimes crashes after a few seconds and the connection is gone.

Solution: Wait a few seconds and restart evcc or wait until evcc re-initiates the connection.

Problem 6 - the wallbox does not initiate a connection to paired energy management systems

Description: When the EEBUS software on the wallbox is restarted, it does always not initiate a connection to evcc itself

Solution: The EEBUS stack used by evcc has to make sure it always retries as long as the mDNS entry of the wallbox is visible or is visible again when it wasn't before.

Problem 7 - when connecting CT coils to the wallbox, EEBUS does not work

Description: When the users needs to use the wallbox built in load management feature by attaching CT coils to make sure the household limits are not exceeded, no charging limits via EEBUS are executed.

Solution: Either use CT coils or use evcc. There is no workaround to use both at the same time.

Problem 8 - frequent disconnects that trigger charging start

Description: When using a WLAN connection, often there are sometimes longer sometimes short (even invisible) disconnects. This leads to missing so called heartbeats or even loosing the websocket connection. Which then leads the wallbox to go into fallback mode and allowing the EV to charge with minimum power. When evcc reconnects, it doesn't know the EV is charging due to problem 3.

Solution:

• Use a LAN connection
• The customer should connect an external meter and configure it at the loadpoint. See https://docs.evcc.io/docs/reference/configuration/loadpoints#meter

Problem 9 - the wallbox sometimes does not announce its IPv4 address

Description: To connect to an EEBUS device, all devices need to announce themselves using mDNS containing their IP address(es) and the port which is being used. Sometimes the wallbox does not announce its IPv4 address, and connecting using IPv6 never succeeds.

Solution:
Previously evcc provided the option to define the IP address. The user has to make sure that it never changes. Right now this is not possible, and maybe this has to be added again.

Problems in the EEBUS software in evcc

Starting in Version 0.128 a major update of the EEBUS software was integrated. This was tested with multiple wallboxes, but the Elli Connect wallbox. Therefor some of the issues weren't considered and sometimes possible workarounds implemented and the charging experience suffered. During testing and analyzing feedback from evcc users (via log files), hopefully most of the problems the EEBUS implementation used by evcc were found and solved. Starting with the (upcoming) version 0.129.1 hopefully everything should work as smooth as possible again. Of course there still maybe issues that weren't identified yet.

General

While in some scenarios the measurements data is provided properly, in a lot of scenarios it didn't. Therefor I recommended to ignore the measurement data coming from the wallbox for both devices in all scenarios. This means that evcc will simply assume that the EV is actively charging with the set limits by default. The only way to improve this is to attach an external meter to the wallbox and configure it to the loadpoint. See https://docs.evcc.io/docs/reference/configuration/loadpoints#meter

This doesn't solve all issues in all scenarios. But this is simply impossible. You may think in version 0.127.3 things worked better, but in any provided log so far, I didn't see it being really better. The only difference was, that evcc assumed the limits to be measurements. This will work in some scenarions, but e.g. doesn't work if the EV is full!

I spent hundreds of free time on supporting this wallbox and searching for workarounds. I am not getting paid and don't use this wallbox myself. EEBUS is a monster protocol and complex as hell. There is hardly anyone out there knowing EEBUS better than me, which is kinda sad. You may think things are easy, things worked better before, but I truly think it wasn't better in Version 0.127.3 than what we'll have with version 0.129.1 onwards. At least evcc know has the chance to support §14a and communicate with a control box. The EEBUS open source stack implemented by myself over the past 2 years has more than 30.000 lines of code. 95% written by myself. For free.

So please, do me a favor, get and use an external meter with these wallboxes or get another one if the situation isn't good enough for you. But I am done with it, I can't do it any more. I am sorry.

Note: If you think your setup will work with the internal meter, you can still do so by using a different configuration for the charger. But please don't report bugs or expect support for this scenario.

chargers:
  - name: my_charger
    type: eebus
    ski: # SKI (Subject Key Identifier)
    meter: true
    chargedEnergy: false

Update 03.09.24: Starting release 0.130.7 the template: ellipro now again supports built in meters, but with a catch: If the wallbox does NOT provide measurements, an error will be shown in the user interface that currents are not available. If you see this problem, then the only fix is to add an external meter!

[StefanSchoof]

Thank you for making it so far for us.

[askp66]

Many thanks from me too! I use an external meter and have had pretty good experiences so far - except for problem 5, for which there is a simple workaround

[Marty56]

Thanks a lot for explaining all the issues and also for your rentless work.
Great job against all the odds.

I am really look forward for release 129.1. I guess I need to install a LAN connection.

[Marty56]

I have to compute the charging power from an energy measurement because my sensor does not provide power.
What are the latency requirements for power changes?

I am using a derivate function which is only updated when the energy sensor changes.
In case the charging power is turn off, the sensor only updates after several minutes.
I guess this is too slow.

I have therefore implemented a workaround which sets the power to 0 after 30 seconds if the sensor is not updated.
This workaround leads to every imprecise measurements for power consumption between 100 - 500 W.
But I guess those power values should never occur.

Please comment.

[DerAndereAndi]

Please create a separate discussion for this

[andreasfritz]

Can you already say that Rev 2 is significantly better? Is it worth switching?
Unfortunately, I'm forced to stick with Elli.

[Marty56]

But who would be so silly to buy again from a vendor that has betrayed its customers

[andreasfritz]

I have no choice because my employer uses Elli Fleet Charging.

[DerAndereAndi]

I would be so „silly“.

[gnujuba]

@DerAndereAndi, can you share details of the Gen2 and what to go for?
Is the Connect 11 ok for a "standard" user?
Will it support 1p3p switching? Datasheet says Charging power 0.023 - 11 kW (3 phase, 0.1 - 16A)
What configuration to use, etc.

I know it is not out yet, website says "Release in August"...

Happy to create a new discussion.

[DerAndereAndi]

I would recommend to do a new discussion, which than can also evolve with findings once it is available.

[gnujuba]

Hi Andi,

thanks for all the work - we felt your pain :-/

Can you clarify the last note, the configuration? I am on 0.129.0 (ElliConnect with added internal meter) and it is working for me.

Do we need to switch from template: ellipro to type: eebus at some point?

Again, thanks!

[q2doc]

And switching to eebus solves this?

[StefanSchoof]

Yes, but you may run into the Issue from Problem 3 and

But please don't report bugs or expect support for this scenario.

[mscheibler]

Working yes, but not like it have meter. So evcc will assume that the car charges with the power evcc told the Wallbox. When the car is nearly full and will charge slower, evcc will still assume it uses the given power. So In and Output are no longer balanced and the energy in the history is higher then actually loaded.

I can confirm this behavior, i observed it a few times already. It's not nice, but okay for me.
I will live with it until i buy a different Wallbox, which will be no Elli Charger.

[gnujuba]

Working yes, but not like it have meter. So evcc will assume that the car charges with the power evcc told the Wallbox. When the car is nearly full and will charge slower, evcc will still assume it uses the given power. So In and Output are no longer balanced and the energy in the history is higher then actually loaded.

I can confirm this behavior, i observed it a few times already. It's not nice, but okay for me. I will live with it until i buy a different Wallbox, which will be no Elli Charger.

Hi @mscheibler, did you switch to 0.130 and type eebus already with the internal meter?
I am still on 0.129.0 with the ellipro template because everything works for me. Never checked the energy though.

[mscheibler]

Hi @mscheibler, did you switch to 0.130 and type eebus already with the internal meter? I am still on 0.129.0 with the ellipro template because everything works for me. Never checked the energy though.

Hello @gnujuba
I'm running v0.130.0 with the elliconnect template. I have a Charger Connect wallbox with no additional meter or CT coils.
The behavior is exactly as described above: The EVCC UI shows full charging power even when the actual energy consumed by the EV is reduced (due to the almost full battery). In this situation the In/Out balance in the EVCC UI does not match, because EVCC assumes more consumption that actually happens.

With all the issues that the Elli wallboxes have, i think this is the best one can expect from this kind of setup. This behavior does not affect the charge control, it is just the numbers in the UI are not correct.

Some off topic info, not related to EVCC:
I also had some lengthy disputes with the Elli support about some other issues. With the knowledge that i have now, i would not buy an Elli wallbox any more. It took Elli almost 2 month to deploy a firmware update to my wallbox after installation. During that time it was impossible to do any charge control via EVCC, because the preinstalled firmware was too old. I also have some ongoing discussions about the wallbox configuration, related to the integration of the chargers into the Cupra-Connect-App. The support responds, but can't provide any solutions.

[jhfin]

Thanks Andi for all your efforts.

I asked Elli support about this discussion and their reply for me was:

"If you encounter any issues specifically related to the wallbox or its firmware, please report them to us. We are committed to investigating and resolving any wallbox-related concerns. However, we cannot provide support for issues originating from the HEMS itself."

So in theory with clear evidence on both the error on the charger and standard compliance on the EVCC side one could at least try to get support.

I have just setup my chargers. It's working quite ok with one charger but connecting two at the same time seems pretty impossible. I will continue testing.

[DerAndereAndi]

They responsible team is aware of all issues since 2 years. I was in direct contact and reported them all. There won't be any software updates, no matter what support tells you.

For specific issues, please create a new discussion, otherwise it will blow up this discussion and nothing can be found. Thank you!

[IerwinDE]

Hello Andi,

could you elaborate what is wrong with the certificate mentioned in "Problem 1"?
If I got it right, the solution was to patch the handling of boolean in the ASN.1 library?
Is the certificate the box uses on the EEBus interface the same as whats used in the gui towards the browser?

Best regards

Ier

[StefanSchoof]

See evcc-io/eebus#1 (comment)

[winfotiker]

Hi Andi for all your efforts.
I understand your frustration. But Evcc set out to persuade even the dumbest wallboxes to use as much solar power as possible. I thought that was brilliant. That seems to have faded a bit.
Personally, I no longer care about the new home battery charging features. My home system can already charge itself via Tibber.
I think it's a shame that the new version marks the de facto end of support for a fairly common wallbox. With version 0.127.3, I at least had an approximate value for the amount of power being charged. With the current version, not even that. Just more error messages.
Of course I will continue to annoy the manufacturer with the bugs.
I find the advice to buy new wallboxes for a few thousand euros a bit strange. For one thing, it will never pay off. For another, I could just as easily use the wallboxes from the manufacturer of my solar system. They can do all that right out of the box. But I have no choice because my employer uses Elli Fleet Charging, too.
For my part, I'll stick with the old version for a while. It works best for me under the circumstances.
And so I'm off.

[ilion1]

Thanks for clarification. I will try within next few days.

[ilion1]

When looking at the documentation the syntax should be:

chargers:
  - name: my_charger
    type: template
    template: eebus
    ...

and not

chargers:
  - name: my_charger
    type: eebus
    ...

Is this correct or are both versions possible?

[DerAndereAndi]

The proper syntax to use the internal meter is posted at the end of the thread starting post.

[DerAndereAndi]

I find the advice to buy new wallboxes for a few thousand euros a bit strange.

I don't see that I gave this advice. But well.

[ilion1]

The proper syntax to use the internal meter is posted at the end of the thread starting post.

OK, but then the documentation should be updated as it is stated there differently.

[JabeBRD]

Have to ask, if Elli Charger Pro internal meter is no longer used by evcc via eebus.
Can i disconnect meter from charger and connect it directly to evcc via modbus?
Does Pro version need that meter to function or is it just for reporting charge value to mobile app?

[IerwinDE]

I know from personal experiece that if you forget to connect the meter interally witth the little RS485 cable the pro charger works fine for charging but of course does not report the charged energy to the app anymore.
I think I have seen some threads on german forums where people have used am microcontroller to access the RS485 inside the box, but I did not really read into it enough to tell how far the way from that to possibly sending these values directly to evcc would be

[joneskoo]

Got this answer from Elli Support. I wonder if the mentions about experimental can be removed or are they still valid? First line support doesn’t really get open source based on the answer :(

Elli is constantly working on developing modern energy solutions from a single source. One of these solutions is EEBus compatibility for our internet-enabled wallboxes.?

The wallbox can only communicate with a photovoltaic system via the EEBus communication protocol and we have no influence on what the manufacturers of photovoltaic systems offer.

In addition, the website of the manufacturer of the EVCC photovoltaic system states that it does not support the EEBus protocol “EEBUS support is still at an experimental stage. There will certainly be one or two problems here!”. Therefore, please address all questions regarding compatibility directly to the manufacturer of the respective solution.

[DerAndereAndi]

Elli knows that this implementation is not experimental. And they know evcc as well. Their support may not know that and maybe look for excuses.

[DerAndereAndi]

Also it is quite telling, that documented issues of the wallbox are considered issues of evcc.

[klgill24]

Welchen externen Stromzähler würdet ihr für die Elli Charger Pro empfehlen? Z.B. Shelly Pro 3EM?

[pencoe]

@klgill24 ich habe hier einen Shelly Pro 3EM im Einsatz: das funktioniert super. Den hatte ich vor allem deshalb installiert, weil ich die absolut grottige VW-App zum Abrufen der tatsächlichen Ladedaten satt hatte. Jetzt habe ich in EVCC präzise Daten mit Zählerstart und -ende :-)

[klgill24]

@pencoe Danke für die Antwort. Ich habe mich jetzt doch für ein anderes Meter entschieden (Siemens SENTRON 7KM2200-2EA40-1EA1).

[krulli71]

Thank you for your perseverance and effort.
I have sent Michael @naltatis a direct contact at Elli via email. They would like to get in touch with you.

[DerAndereAndi]

Just for clarity: Elli product development is and was in direct contact with me. There won't be any updates for the Gen1 wallbox, they focus on the Wallbox 2.

[krulli71]

Okay, then I must have misinterpreted the last sentence in the 'Elli Charger: Status Update' on Michael's blog.
(„Wir würden uns auch über einen direkten technischen Kontakt zu Elli freuen. Bislang sind unsere Versuche allerdings alle ins Leere gelaufen.“)