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.“)

[Solthur]

There is a new firmware update available: https://www.elli.eco/de/changelog/wallbox/charger

[DerAndereAndi]

The new firmware doesn't fix any of the issues.

[ToughAce]

@DerAndereAndi - Thanks for all the effort you have put into this. Really frustrating to read your summary above...

• @ALL
  I also have an Elli Charger Pro that used to work fine for me, but since a few a weeks it often goes into an error state where all LEDs blink red when when I stop charging via the car or in the Elli App. During charge or if the car is fully charged, there's no error.
  Error description from the manual is attached and it sounds alarming as it says the relays are welded together:
  
  Up to now, the error went away after restarting the charger.
  I have contacted Elli support on this issue.

However, as this roughly occurs since the time of the major upgrade of the EEBUS implementation in evcc, I wanted to check here.
Even though it's not one of the Problems mentioned above, could this be related to Elli's faulty EEBUS implementation? I will try to downgrade to see if that changes anything.

Does anybody have the same issue?

[DerAndereAndi]

I do not see how this can be related

[pencoe]

I had this (all lights blinking red) one ore two times in the past - long before the major rewrite of the EEBUS Code. Seems it happens from time to time...
Without evcc i had changed to another kind of wallbox in the meantime.

[Marty56]

Since I have connected my Elli Box via Lan, I have not seen any issues.
Note, I am also using an external meter.

[ToughAce]

Yes, mine is also connected via LAN. I use the internal meter and had the error that charge currents are not available. Overall was still quite happy with the way it worked until the above mentioned issue occured.

[nonamesay]

The SW Update : v3.9.0-rc3;v3.29.11 states in changelog 29.Okt.'24:...e Wallbox wurde optimiert, damit das Relais auch bei schnellem Ein- und Ausschalten sicher öffnet...
That may help on the issue?.

[Kludi2019]

Hallo Andi, vielen Dank!

Allerdings scheint etwas an mir vorbei gegangen zu sein. Ich habe so lange gewartet, um bei meiner Elli Pro weiterhin das interne Messgerät zu nutzen und habe jetzt von 129.0 auf 131.1 geupdatet. Mit dem Hinweis Update 03.09.24: Ab Release 0.130.7 template: ellipro hatte ich es so verstanden, dass in der yaml keine Änderungen erforderlich sind. Nun wird die Leistung sofort korrekt angezeigt, das Fahrzeug nicht mehr als verbunden, keine Lademenge und somit auch keine Ladezeit angezeigt. Sorry, ich habe verstanden dass das Thema nervt. Muss nun noch etwas geändert werden?

Vielen Dank und ein weiterer Hinweis: Hat jemand die yaml Änderung bei Einbindung eines Shelly 3Pro. Denn in der Doku finde ich es nicht konkret?

[pencoe]

Meinst du einen Shelly 3EM Pro? Der sieht in meiner yaml (im Abschnitt meters:) so aus:

- name: wb3em
  type: template
  template: shelly-pro-3em
  usage: charge
  host: 192.168.48.148

Findet sich aber auch exakt so in der Doku: Shelly Pro 3 EM unter "Wallbox"

[Kludi2019]

Hallo Peter, vielen Dank für deinen Hinweis. Grundsätzlich habe ich es jetzt am laufen, aber evcc meldet jetzt eine Phasendrehung zwischen Eilli WB und shelly pro 3, wenn nur mit einer Phase geladen werden soll. Das liegt daran, dass die Elli dann nur L1 hat und L2 und L3 abgeschaltet sind und dann der shelly keine Versorgungsspannung auf L3/C hat. Wie hast du das gelöst? Gruß Gerhard

[pencoe]

Bei mir sitzt der Shelly im Sicherungskasten zwischen FI/Sicherungsblock und Wallbox: da ist immer Strom, egal was die Wallbox macht.

[Kludi2019]

Ich denke, wenn alle 3 Phasen aktiv sind, erkennt evcc alle drei Phasen und meint es muss dreiphasig geladen werden? Denn wenn das funktionieren würde, könnte ich mir die Spannungen auch vorweg abgreifen.

[Kludi2019]

@pencoe Danke erstmal,

so habe ich es auch eingegeben. Die kpl yaml sieht so aus:

open evcc at http://evcc.local:7070

network:
schema: http
host: evcc.local # .local suffix announces the hostname on MDNS
port: 7070

log: info
levels:
cache: error

unique installation id

plant: 6d0cd584651b8821c9f9c4c885404a80de75220ae4fed45689c3c651a401e207

interval: 10s # control cycle interval

meters:

• type: template
  template: tasmota
  usage: grid
  host: 192.168.178.61
  user: admin
  password:
  name: my_grid

• type: template
  template: sonnenbatterie
  usage: pv
  host: 192.168.178.33
  port: 8080
  name: my_pv

• type: template
  template: sonnenbatterie
  usage: battery
  host: 192.168.178.33
  port: 8080
  name: my_battery

• type: template
  template: shelly-pro-3em # Leistungsmessung für Elli Pro
  host: 192.168.178.123
  user: admin
  password: Passwort
  name: my_charger # eingefügt bei Umstellung auf externe Messung
  usage: charge

• type: template
  name: Mobilladegerat_Pwr
  template: shelly-1pm
  user: admin
  password:
  usage: charge
  host: 192.168.178.26

chargers:

• name: wallbox
  type: template
  template: ellipro
  ski: 136C 5261 EDEF B7E6 9D4B 8472
  ip: 192.168.178.74

• type: template
  template: shelly
  host: 192.168.178.26
  standbypower: 5
  user: admin
  password:
  name: Mobilladegeraet

vehicles:

• type: template
  template: fiat
  title: Paulchen
  user:
  password: '#######'
  vin: ZFAEFAC4XNX
  capacity: 42
  name: ev4

• type: template
  template: id
  title: Id5
  user: g
  password: '#Warum sollte ich von OpenWB auf EVCC wechseln? #2'
  vin: WVGZZZE
  capacity: 77
  timeout: 10s
  name: ev1

loadpoints:

• title: Elli
  charger: wallbox
  meter: my_charger # eingefügt bei Umstellung auf externe Messung
  mode: pv

• title: mobil
  charger: wallbox
  meter: Mobilladegerat_Pwr
  mode: off

mqtt:
broker: 192.168.178.32:1887
topic: evcc
clientid: foo
user: admin
password: '###########'

tariffs:
currency: EUR
grid:
type: fixed
price: 0.38

feedin:
type: fixed
price: 0.082

site:

• title: Im Scha#######
  meters:
  grid: my_grid # Shelly 1PM für Ladebox
  pv: my_pv
  battery: my_battery
  charge: my_charger # Shelly 3PM Pro für Elli WB
  residualPower: 100

eebus:
certificate:
private: |
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIL0mhWia5hk/EDBVPMXzsK+G2ScD58mnFybVMre1i3WCoAoGCCqGSM49
AwEHoUQDQgAEb0t9jj7FWNin99dLvJfrqtbryKXcqbHML0erDTZ1uIAIMhrpvtI8
eeLDq9JIMbQqCvMs1Hpzp9do6qxEJrH8GQ==
-----END EC PRIVATE KEY-----
public: |
-----BEGIN CERTIFICATE-----
MIIBhzCCAS2gAwIBAgIBATAKBggqhkjOPQQDAjAzMQswCQYDVQQGEwJERTENMAsG
A1UEChMERVZDQzEVMBMGA1UEAwwMRVZDQ19IRU1TXzAxMB4XDTIyMTAzMTA5MzQx
MFoXDTMyMTAyODA5MzQxMFowMzELMAkGA1UEBhMCREUxDTALBgNVBAoTBEVWQ0Mx
FTATBgNVBAMMDEVWQ0NfSEVNU18wMTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA
BG9LfY4+xVjYp/fXS7yX66rW68il3KmxzC9Hqw02dbiACDIa6b7SPHniw6vSSDG0
KgrzLNR6c6fXaOqsRCax/BmjMjAwMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYE
FCNlU4HENAR0BV4oWM6B8o8QrM9UMAoGCCqGSM49BAMCA0gAMEUCIQDE9HHTldX/
N2CSc9SxXT0qsUKYehin6OiebycLNUEfkwIgQIhWCZH1CaNmCLK0ClxEqzrfx2Xo
ougJGx5M07FNtqE=
-----END CERTIFICATE-----
und der Fehler, der kommt ist: [main ] FATAL 2024/10/25 17:29:53 decoding failed due to the following error(s): 'meters' has invalid keys: charge
evcc-20241025-173102-debug.log

[Prodec-]

Have I understood correctly that at the moment ip: parameter in ellipro template is not used? If so, could it be reimplemented? I am currently having problems with Elli's really intermittent communication which I suspect is because I have ipv6 implemented in my IoT vlan. Also could it be possible to log on trace level the IP address evcc is trying to connect to Elli on? Then it would be easy to confirm if ipv6 is used in connection.

[DerAndereAndi]

No, you can optionally add the IP, see the documentation at https://docs.evcc.io/docs/devices/chargers#charger-pro-1

[Prodec-]

Ok, thanks. The solution for Problem 9 is already implemented, or did I misunderstand something?

[mmrazovic]

Gestern hat meine Elli (Gen 1, Pro) ein SW Update durchgeführt: v3.9.0-rc3;v3.29.11:

Ist irgend etwas bekannt dass die beschriebenen Probleme (teilweise) behoben wurden?

[DerAndereAndi]

Es wurde nichts daran behoben. Siehe auch meine Antwort dazu hier #15367 (reply in thread) in diesem Thread.