Wallbox support (configuration, switches and sensors)

[neuromancer3142]

Checklist

• I have filled out the template to the best of my ability.
• This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
• This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.

I would like to be able to configure my S10E Pro / Wallbox in order to be able to change the charging priorities wrt.:

• solar use only
• prioritisation of wallbox charging vs. battery charging
• enabling use of battery for charging your electric vehicle

Describe the solution you'd like

When charging an electric vehicle I would like to be able to remotely change via RSCP the charging behaviour of my E3DC S10E Pro system, i.e. to

• prioritise wallbox vs battery charging
• enable/disable the draining of the battery for charging the electric vehicle (down to a certain SOC level - the E3DC UI offers this)
• enable or disable solar use, i.e. the charging of the electric vehicle in "solar use" only will only charge if enough PV energy is available (or the battery use is enabled).

Screenshot of E3DC UI with those options is included in the screenshots.

The iOS "AutarkieManager" app (see one screenshot below) offers these 3 options in its RSCP extension pack. So I can remotely switch on/off those charging options. This would enable me to remote start/stop charging my car with PV energy and also enable automations to start/stop the charging based on SOC state and weather forecast.

Describe alternatives you've considered

None

Additional context

No response

Diagnostics dump

[AgentP38]

I´m also interested

[neuromancer3142]

@torbennehmer : I just updated to v3.3.3 and I can now download the diagnostic dump. So @bug#46 is now confirmed closed. Are you still interested in the diagnostic dump in order to work on the enhancement feature?

[torbennehmer]

Please wait for the moment. I'd like to scan the API listing of E3DC, I would suspect that we need some more data provided by the system, that's currently not logged for me to make an implementation plan.
Would you be capable of running custom python scripts against pye3dc as an alternative, in that case we could directly play around a bit how your unit reacts to various commands?

[neuromancer3142]

Please wait for the moment. I'd like to scan the API listing of E3DC, I would suspect that we need some more data provided by the system, that's currently not logged for me to make an implementation plan.
Would you be capable of running custom python scripts against pye3dc as an alternative, in that case we could directly play around a bit how your unit reacts to various commands?

If you give me some direction on how to do it: Would be more than happy to do that. Do you mean this script:
https://github.com/fsantini/python-e3dc ?

In the meanwhile I installed pip via HomeBrew and the python-e3dc library. I could run the following sample script and get an output:
*** start ***

from e3dc import E3DC

TCP_IP = '192.168.1.57'
USERNAME = '[email protected]'
PASS = 'MySecurePassword'
KEY = 'abc123'
CONFIG = {} 
# CONFIG = {"powermeters": [{"index": 6}]}

print("local connection")
e3dc = E3DC(E3DC.CONNECT_LOCAL, username=USERNAME, password=PASS, ipAddress = TCP_IP, key = KEY, configuration = CONFIG)
# The following connections are performed through the RSCP interface
print(e3dc.poll())
print(e3dc.get_pvi_data())

*** stop ***

So please let me know what commands I should run in order to help you with the implementation.

[torbennehmer]

That is actually not trivial to answer, the E3DC API is not really easy to read, and putting request objects together is possibly non-trivial. Let me ponder this for a week or two.

[neuromancer3142]

That is actually not trivial to answer, the E3DC API is not really easy to read, and putting request objects together is possibly non-trivial. Let me ponder this for a week or two.

If it helps, we can also execute some of the commands in an interactive session. Sometimes trial and error is quickest way to progress. Waiting for your input.

[bullitt186]

There is an open but apparently abandoned PR in 'python_e3dc' which implements basic wallbox features. I guess without this PR we won't see WB support in 'hacs-e3dc'.
I tested the abandoned PR, the features still work fine with my Multiconnect II, so I asked there what it takes to finish the PR and hope to finish the started work.

[neuromancer3142]

@bullitt186 : Any success re. the abandoned PR for the wallbox features?

[bullitt186]

Not really; I tested the PR with the most recent version of python_e3dc and it works fine. mstv suggested some improvements but these shouldn't be blocking. I don't find much time these days to include his suggestions as work and private life is busy, but adding these suggestions in a new PR together with the work of mdhom would probably be the way to go in order to move forward.

[neuromancer3142]

@bullitt186 : Thanks for your response. Would love to help, but I am not a SW coder myself. Otherwise, I would gladly contribute. Just let me know if I can support any other way. IT skills are just sufficient to google my way through home assistant configuration issues and yaml configuration ;-).

[neuromancer3142]

Not really; I tested the PR with the most recent version of python_e3dc and it works fine. mstv suggested some improvements but these shouldn't be blocking. I don't find much time these days to include his suggestions as work and private life is busy, but adding these suggestions in a new PR together with the work of mdhom would probably be the way to go in order to move forward.

Do you see any hope that this might be tackled by you in the coming months? If not I would need to look for alternative solutions. Thanks for letting me know.

[Wolfgang-03]

I am also very interested in support for the wallboxes. I have an "E3DC S10 E Pro" with storage and 2 "E3DC Wallboxes Easy Connect". Is there any progress on this? I am also happy to help with development and have sufficient experience in software development. Please let me know if there is anything I can do.

[bullitt186]

I got stuck last year, since the underlying python-e3dc hadn't wallbox integration supported yet. The corresponding PR 59 seems to be abandoned.
But only 2 days ago, a new PR within python-e3dc was openend by user mstv with the goal to add WB functionality: fsantini/python-e3dc#116

So maybe we will have WB functionality in python-e3dc...

[T1ppes]

It has been merged today

[bullitt186]

I am happy to contribute to the implementation of the wallbox-features in hacs-e3dc but frankly speaking, i am not a professional programmer, so it would take me a while and probably some re-work by @torbennehmer or other experts.

Before digging in, here are my thoughts how the implementation should be handeled.

1. During Setup, check if theres a Powermeter PM_TYPE_WALLBOX in order to identify there's a WB installed. If not, nothing else happens.
   Open question: how to distinguish a WB with Schuko (MultiConnect I) from a WB without (MultiConnect II)

2. Add sensors for all attributes of get_wallbox_data()

3. Implement the following setters:
   switch: set_battery_to_car_mode()
   service: set_wallbox_max_charge_current()
   service: toggle_wallbox_phases()
   switch: set_wallbox_schuko()
   switch: set_wallbox_sunmode()
   service: toggle_wallbox_charging()

While for the set_...calls a switch is obvious, for the toggles, a switch may be oversimplified and lead to confusion / ambiguity what is meant with the on state. (or if we read back actual values and set the switch based on those, it may also be confusing, that the switch state is changed without user interaction)
Thus i think using services is the more transparent way to handle those. For convenience, a Button entity to trigger these services could be added.

What are your thoughts: Would you also go that route as I am suggesting?
Is somebody else (more experienced) willing to pick up the work?

[neuromancer3142]

Hi bullitt186,

I am not able to comment on the programming approach as I lack the experience to do so. So I can only comment on useability - see below.

3. Implement the following setters:
   switch: set_battery_to_car_mode()
   service: set_wallbox_max_charge_current()
   service: toggle_wallbox_phases()
   switch: set_wallbox_schuko()
   switch: set_wallbox_sunmode()
   service: toggle_wallbox_charging()

While for the set_...calls a switch is obvious, for the toggles, a switch may be oversimplified and lead to confusion / ambiguity what is meant with the on state. (or if we read back actual values and set the switch based on those, it may also be confusing, that the switch state is changed without user interaction) Thus i think using services is the more transparent way to handle those. For convenience, a Button entity to trigger these services could be added.

What are your thoughts: Would you also go that route as I am suggesting? Is somebody else (more experienced) willing to pick up the work?

Your proposal seems logical for me. One additional feature I would add is the "Bis SOC" value that is shown in the screenshots above (dont know the variables for that). I often have my wallbox in the following configuration:

• "Lade-Priorität" --> "erst Wallbox"
• "Im Sonnenmodus" --> "erlaubt"
• "Bis SOC" --> "50%"
• "Im Mischmodus und während Haltezeit und Zeitfunktion" --> "erlaubt"

What this configuration does is to use any incoming PV energy and directly put it into my car. It also discharges my battery to help charging the car, until the SOC is emptied until 50%. At that point it only continues using incoming PV energy. If that is not sufficient anymore, the charging will stop.

I rarely change the charging phases in the meanwhile, as doing so also necessitates physically changing the charging cable at my car. By simply changing the 4 variables mentioned above I manage to remotely start / stop the loading of my car and manage the content of my battery at home. E.g. I will empty the battery before I leave the house in the morning by lowering the SOC value to 3% so that my battery at home can recharge during the day while I am away. In the evening I will empty some of my battery again into my car.

Happy to help with the testing and trouble shooting if needed.

[bullitt186]

I implemented WB integration in #153.
Feel free to test and add suggestions.

[bullitt186]

Your proposal seems logical for me. One additional feature I would add is the "Bis SOC" value

With the wallbox features implemented in the PR, it should be easy to implement this as an automation in home assistant (trigger = SoC; action = turn sun mode on)

what i have in mind doing is that per default it only charges in sun mode but when i trigger an automation by "Alexa: Auto jetzt laden an", it charges fully once (or until disconnected) and then falls back to sun charging.
THis may be handy if i need a fully charged car in the morning.

[torbennehmer]

@bullitt186 I've merged the PR so that we can test this. Could you please update the README.md (in another PR), I totally forgot this on the existing one, go over it and update it at your discretion, the minimum would be describing the new service at the bottom of the file. It'd be great if we had this for the stable release.

[torbennehmer]

https://github.com/torbennehmer/hacs-e3dc/releases/tag/v3.8.0-beta.1 out of the door

[bullitt186]

@bullitt186 I've merged the PR so that we can test this. Could you please update the README.md (in another PR), I totally forgot this on the existing one, go over it and update it at your discretion, the minimum would be describing the new service at the bottom of the file. It'd be great if we had this for the stable release.

For sure!
@Thomansky's feedback regarding multiple wallboxes triggered me to add support for multiple wallboxes rightaway. See #155. So ideally, we get this integrated fast and can state in the README.md rightaway that multiple wallboxes are supported :-)

[derhappy]

Thank you so much for the implementation!
I'm already using a quite extensive WB integration using shell commands to toggle charging and controlling the current based on the available solar power, soc and time.
I will shift my current implementation to use the new features as much as possible and start testing end of June (after vacation).

[bullitt186]

Nice :-)
I guess the setting the charging wattage is "under the hood" setting max charging amps or is there a separate setting for wattage via RSCP?

[torbennehmer]

@bullitt186 What's your impression on the discussion between @Wolfgang-03 and @neuromancer3142 ?

[bullitt186]

I am exploring in a local branch two things right now:

• the requested number input for maximum charging current
• setting a percentage threshold for battery discharging

While the first one is more straight forward introducing a new class for Numbers and figuring out how to register an input_number which trigger the rscp call "on change" with parameter,
The second one may be more difficult: regardless what I write to the rscptag, I get 124% as target battery SoC back.
So this needs some more trial-and-error.

As work, family and finally some summer days in germany distract me right now, progress may be slow.

I am very curious on feedback regarding the updated beta.
Personally, I use my now-merged branch since a couple of days and it works flawlessly for me.

So if there are no bugs reported, i'd suggest to aim for a release with the current feature set and safe any additions for future releases.
When released, I'd also suggest to close this issue and get back to "one topic / one issue" - this issue has become the "catch all" for everything Wallbox related 😅

[Thomansky]

I am satisfied with the current version so far and have not been able to find any errors except for the story with the soc a little thing wonders me and namely I have the identities once in the house power plant and there but not available and with the other two devices individually the display is somehow still a bugg or is that due to my system

[torbennehmer]

So if there are no bugs reported, i'd suggest to aim for a release with the current feature set and safe any additions for future releases.
When released, I'd also suggest to close this issue and get back to "one topic / one issue" - this issue has become the "catch all" for everything Wallbox related 😅

Fully agreed.

[bullitt186]

@Thomansky
Thank you for the feedback. Did you use the different beta versions after another?
As i only introduced the support for multiple wallboxes in beta2, you still see the old entities from beta1 in your list. you have to delete those manually unfortunately.
In case you have not edited E3DC entity names, icons, etc. manually, it may be easier to just remove the e3dc integration and re-add it. by this, you get a "fresh" set of all entities with the old ones removed.
But please be aware, this may cause that you will also lose the history / statistics within HA for other E3DC entities.
With Beta3 (released yesterday by @torbennehmer), Each Wallbox is now an individual device which should de-clutter the entity list with the nice addition, that you can name the Wallboxes to your liking instead of "Wallbox 1", "Wallbox 2", etc.

As I only have one Wallbox at home, I'd be curious to get your feedback if both wallboxes work as intended with Beta3.

[sjongele]

Since beta3, the “Set Power Limits” and “Clear Power Limits” services complain that the Device is no E3DC.
Did something change there since beta 2?

[Thomansky]

I've had this problem since I switched to Peter three, even though I've now switched back to Peter two, it actually affects all the services you can access![image]

[bullitt186]

Thank you for your feedback. I have a slight idea what may be the cause this but have to investigate.
Could you please remove the integration once (so that the devices and entities are removed) and re-add it?
Is the behaviour still the same?

[Thomansky]

I have just completely deleted the indication and then reinstalled it - nothing has worked

[bullitt186]

Thank you for the feedback - i will investigate!

[torbennehmer]

Hi @bullitt186

Thank you for your feedback. I have a slight idea what may be the cause this but have to investigate. Could you please remove the integration once (so that the devices and entities are removed) and re-add it? Is the behaviour still the same?

The service problems are probably related to the mutliple device change. The code verifies, that we're talking to the E3DC, that's coded in _resolve_device_id in services.py.

@Thomansky I think this is the reason for #164, which thus is a duplicate of this (my assumption at least)

[neuromancer3142]

Hi @bullitt186 and @torbennehmer,

Thanks especially to bullitt186 for implementing the wallbox features. Looks really great. I am using an S10E Pro System together with an E3DC Easy Connect Wallbox and tested it with the v3.8.0-beta.2 version. Here are my main observations:

1.) Cable / Plug Detection: Works

* Entity: binary_sensor.s10e_pro_wallbox_plug

* Works as expected. Correctly recognizes when charging cable is plugged into and unplugged from the car.

2.) Sun Mode - on/off

* Entity: switch.s10e_pro_wallbox_sun_mode

* Changing the switch correctly switches the "Sonnenmodus" on the Wallbox Settings Page of E3DC.

3.) Charging Start/Stop

* Entity: button.s10e_pro_wallbox_charging

* This is probably with which I struggle most. I tested charging start/stop today, with only about 1,1kW coming from the PV.

* As expected it did not start charging the car.

* When disabling sun mode --> the car started charging.

* I could successfully stop the charging process by pushing the button again.

Overall, it seems I have not yet fully understood the E3DC logic. My normal way to charge the car "automatically" without Home Assisstant is as follows - as set on the new E3DC Portal (https://my.e3dc.com/) under Settings - Wallbox:

* Allgemein: "Sonnenmodus" on "An", "Schlüsselschalter: Sonnenmodus"
  ![Bildschirmfoto 2024-07-07 um 17 09 45](https://private-user-images.githubusercontent.com/102355089/346344831-b87cf755-1cef-4321-b27c-4cc23a87b429.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE0MDM2MjEsIm5iZiI6MTcyMTQwMzMyMSwicGF0aCI6Ii8xMDIzNTUwODkvMzQ2MzQ0ODMxLWI4N2NmNzU1LTFjZWYtNDMyMS1iMjdjLTRjYzIzYTg3YjQyOS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNzE5JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDcxOVQxNTM1MjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1hMGRkMjg0YTJmYWZiMGYxZTk5OTVkZWE5NDUyOTVjNDE5MjIxMThkMjdmZTAwZWFiNjM4NjEzODZjNjE5NWY4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.OK4arpKq27iU1xXhDrYOAOBNEd9-uXvf2f3IoHEcBeg)

* Ladepriorisierung: Set as shown in the screenshot - priority on Wallbox, discharging of battery allowed down to a certain SOC limit
  ![Bildschirmfoto 2024-07-07 um 17 08 41](https://private-user-images.githubusercontent.com/102355089/346344786-b504e20f-71ee-4976-b461-c4e1907f0174.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE0MDM2MjEsIm5iZiI6MTcyMTQwMzMyMSwicGF0aCI6Ii8xMDIzNTUwODkvMzQ2MzQ0Nzg2LWI1MDRlMjBmLTcxZWUtNDk3Ni1iNDYxLWM0ZTE5MDdmMDE3NC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNzE5JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDcxOVQxNTM1MjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0wYmVmMjQ5MjY3NTdhZTlkMTgzODAyMTAzYjQ0MWNjZWUwMWUyYzA5NDBkNjA4ZmRhMGI5OWNhMjI2NTQ3YzNiJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.NBl5yBPy4GfymYFr87I5zCyL6I9e0UmJLHrQHwQFIXQ)

Those settings enable a smooth discharging of the battery and using available PV energy until I reach a certain battery threshold. With the current E3DC HACS integration I cannot set those things.

I can only manually start the charging process by setting switch.s10e_pro_wallbox_sun_mode to off and pushing the button.s10e_pro_wallbox_charging. Probably, because there is not enough available PV energy to start the process otherwise. To stop the charging process I need to push the button again. So I think I would need to configure my system in sun mode off and then create an automation in Home Assistant to get the discharging done to a certain battery level. I somehow hoped that I could simply set the proper values to the E3DC system an be done with it.

Thanks for letting me know your thoughts on this on how to best get this done. My current way of calling up the E3DC portal and reconfiguring this everytime is not what I want. I really would love to be able to push one button in HA to get the car charged down to a certain limit and thats it. Cheers

19.07.2024: One additional observation - when triggering the charging with the sun mode off, it can happen that additional power is drawn from the grid. And enabling the charging using battery and PV only, while sun mode is on (normal E3DC setting I use) will not do this. I will play around with the next beta once the charge until PV SoC reaches option is implemented.

[bullitt186]

@Thomansky @sjongele @torbennehmer
I found the cause though this was pretty tricky as i wasn't able to reproduce it in the test environment (devcontainer) and it took me quite a while to track it down in my prod environment.

I assume you have also the Fritz!Box Integration installed, so your E3DC looks something like this:

If this is the case, I am positive that i have solved the issue.
The PR #166 contains the fix and has some more details.

[torbennehmer]

@bullitt186 That does make sense. I actually had this before, but thought that was fixed originally. Also funny is, that apparently my own installation does not hit this issue. Maybe it depends on the actual IDs HA assigns.
I'll check your PR in a minute. Thanks for the fix.

[torbennehmer]

Just pushed out Beta 4 with the latest changes.

@bullitt186 I'd like to call for a feature freeze now. Lets fix bugs of course, but no new features for 3.8. There are many good things in there and we can improve upon then later. It would be my last call on API stability as well, so if you still have reservations about the current API, please let me know.

Also: As far as I understand it, right now we did not change the existing API, correct? I'm just updating my own HA setup to validate this as far as I can, but I'd like to have your input. If we break the API, we've to move to 4.0 instead of 3.8 and collect instructions how to migrate.

[bullitt186]

Hey Torben, Thanks for updating the Beta.
Yeah feature freeze makes sense. I may work on separate branches for additional stuff but i see no need to include them prior to release.

Regarding API changes:
There are no changes to the actual Hauskraftwerk entities or functions related to them, , so same uids etc.
As a matter of fact, even though i used every branch on my HA prod instance, i still have the history of all sensors, so all identifiers are unchanged.
I think the only change to the Hauskraftwerk I did was to add serial_number in the DeviceInfo and change configuration_url to the new portal.

From my point of view the now-found setup with wallboxes as devices can be considered "final" and i don't foresee bigger/breaking changes. Throughout my testing on Dev and Prod i have monitored the logs and also found no issues/warnings caused by e3dc_rscp.

[Wolfgang-03]

Hello @bullitt186,

I have now installed Beta4 and am testing this version with my 2 wallboxes.

In my configuration the entities are now all called "wb_rechts_XXXX", for example "binary_sensor.wb_rechts_charging" and "wb_links_XXXX", where the wallbox on the right is wallbox 1 with E3DC-ID[0] and the wallbox on the left is wallbox 2 with E3DC-ID[1].

On "Wallbox Rechts" = Wallbox 1 = E3DC-ID[0], the controls have no function.

As far as I can see, the problem is the call of the lambda-function, for example:

button.by, line 58:

            async_press_action=lambda coordinator: coordinator.async_toggle_wallbox_phases(wallbox["index"]),

replaced by

            async_press_action=lambda coordinator, index=wallbox["index"]: coordinator.async_toggle_wallbox_phases(index),

solves the problem. -> Same for line 66 (toggle-wallbox-charging) -> Same must be changed in switch.py, 2 times (sun-mode & wallbox-schuko).

---

Furthermore there are wrong entries in the log:

After pressing the button, I get "changed to DateTime" in the log, which (I assume) should be "changed to 3" or "changed to 1". A few seconds later, the information form the sensor is correct. The same applies to the "Charging" button -> I get "Changed to DateTime".

[bullitt186]

@Wolfgang-03, Thank you for your in-depth feedback.

Lambda:
You are right, my Lambda-function had an error, but for some reason it worked for me with one single wallbox (i guess somewhere my false index was treated as 0).
I changed the lambdas exactly like you suggested and can confirm it still works for my one wallbox.

Logbook:
This is misleading in the logbook view:
The first entry with the timestamp is caused by the button, e.g. button.multi_connect_phases.
The second entry, e.g. "1" or "3" comes from sensor.multi_connect_phases with the next poll to the E3DC.

I checked with several other buttons from other integrations & helpers: Reporting the timestamp in the log book on-press is the default behaviour, so there is nothing we can do to improve the logging.
To make it more clear, I'll change the Entity names of the buttons to "Toggle phases" and "Toggle sun mode"

[bullitt186]

@sjongele @neuromancer3142 @derhappy @T1ppes @AgentP38 It would be great if you could give Beta 4 a try to get some more feedback before pushing it out.

[sjongele]

I have been running beta 4 for a few days. With this beta, setting the charging limit works again for me. I can also use the sensors for the power station and wall box also work and I can switch the wall box between sun and mixed charging mode. Great!

Being able to set the charging strategie would be a very nice addition (since the car integration tell some how much solar juice the car would like, but that is of course outside the scope of this version.

[derhappy]

I've been using beta 4 since it came out. I have quite a lot of trouble currently, but it seems there was also an update by e3dc which screwed up the wallbox somehow. It seems like I can only start charging using at least 8 amps (afterwards I can dial back to 6 again without issues).
I will create a ticket with e3dc, but based on the last issues I reoported my expectations are very low.

[bullitt186]

This behaviour is a known issue at E3DC, see the message at the bottom of this screen in the E3DC Portal:

So it would be interesting if you have HA integration specific issues or all related to E3DC (and with that out of our control)

[derhappy]

Sorry my last post was a bit misleading. I think all issues I have are related to the E3DC-bug since it's been working fine before. Your implementation is working as expected

[Wolfgang-03]

I have also noticed that my BMW does not start charging when the charging power is set to 6 A. BMW requires at least 7 A charging power so that I can start the charging process via RSCP. However, this is not a specific problem of HA integration, but rather one of E3DC in cooperation with BMW, I suspect.

[torbennehmer]

3.8.0 has been released! It includes all changes added via this issue, thus, I'll close it now.

Please do not use this issue to report Wallbox problems anymore. Check existing other issues for known bugs or - if none found - create new issues.

Thanks again @bullitt186 for your contributions!