Closed neuromancer3142 closed 2 months ago
I´m also interested
@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?
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?
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 = 'test@test.com'
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.
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.
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.
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.
@bullitt186 : Any success re. the abandoned PR for the wallbox features?
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.
@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 ;-).
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.
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.
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: https://github.com/fsantini/python-e3dc/pull/116
So maybe we will have WB functionality in python-e3dc...
It has been merged today
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.
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)
Add sensors for all attributes of get_wallbox_data()
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?
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:
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.
I implemented WB integration in https://github.com/torbennehmer/hacs-e3dc/pull/153. Feel free to test and add suggestions.
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.
@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.
@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 https://github.com/torbennehmer/hacs-e3dc/pull/155. So ideally, we get this integrated fast and can state in the README.md rightaway that multiple wallboxes are supported :-)
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).
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?
@derhappy Is this the soc from the car or from the battery? And is it an extra integration for HA or does it come into existing ones? And if so, which one?
@derhappy Is this the soc from the car or from the battery? And is it an extra integration for HA or does it come into existing ones? And if so, which one?
Until now I'm using https://github.com/spali/go-rscp via command line sensors / shell commands controlled by some HA scripts. TbH it's some "grown code" since I had to do some quick changes after adding another PV and then again after changing the car. (Our current car does only support charging with three phases, while the old model also supported two). SOC is the e3dc battery. During day I want to continue charging if a cloud covers the PV or a short term spike like the coffee maschine is limiting the available PV power. However, in the evening I want to ensure a higher SOC so the battery lasts through the night. Those settings are mostly important in spring / autumn.
@bullitt186 yes the wattage is only the label so if I want to manually set the charging power and compare it to the available power.
If there's interest I can make it public after vacation, I don't want to spam this thread any more.
@derhappy that sounds good I'm also interested in such automatisation.
@torbennehmer great work thanks a lot 👌
@AgentP38 In this case, thank @bullitt186, he did the work for the WB integration
@bullitt186 I've approved the PR, so that we get a new beta release out (I'll push that out shortly). What about introducing a separate Device per WB, so that we don't register on device (the all-mighty E3DC) but 1 for the e3dc and one per Wallbox? You could filter the service dropdowns by device IDs, so that only the actually connected wallboxes are available?
Cheers, Torben
All functions are available so far. I'm not experiencing any problems. I'll write more about the wallbox tomorrow if any problems occur
@bullitt186 & @torbennehmer: Many thanks for the implementation, great work! I have just tested this on my system "E3DC S10 E Pro" with 2 x "E3DC Wallboxes Easy Connect". In the "old" E3DC system - I haven't really got to grips with the new one yet - it looks like this for me:
I can use the selection box [5] to switch between the wallboxes, [1] to switch the sun mode on/off, [2] to switch the phase and [3] to start the charging process or stop it if it is currently running. With [4], I can set the charging current; in my case, values between 6 A (minimum) and 16 A (maximum) are possible.
In Home Assistant, this now looks like this with Beta 2:
[1] Is implemented as with E3DC [2] Works, I can switch "1 ph charging" on and off. [3] It works, in principle, but the E3DC system is a bit bitchy. If there is not enough sun on the roof, the wallbox will only start if the sun mode has been switched off beforehand, which also has a certain logic to it. When the sun mode is on, I can also press the "Ladevorgang starten" button in the E3DC system, which means that the "Ladevorgang starten" button disappears and the wallbox does not start. Presumably the system then waits for power from the roof and then starts automatically. So far so good. [4] Ladestrom: Unfortunately, a slider is still missing. That would be great if it were added. If I change the charging current in the E3DC system, it is displayed correctly in the HA under Sensors.
In principle, I think it would be better if [2] were also listed as a switch and not as a button (PRESS), as in the E3DC system. The same applies to [3], although this may be difficult, see above. The developers of the E3DC system probably had a reason why they didn't implement this as a switch? I would like to (am going to) implement the wallbox control system as an automation anyway, so that the HA-User would not see these switches or buttons at all, but from a logical point of view, I think switches would make more sense.
@Wolfgang-03, @Thomansky Thank you for your valuable and detailed feedback. I will look into it in the next days, currently I am focussing on the suggestion from @torbennehmer to have the wallboxes as separate devices as this would tidy up entity names and the entity list. once this is done and submitted for PR, i can tackle the next things :)
The logic of the binary sensors "plug_lock" is a bit confusing.
It is displayed correctly in the interface (locked | unlocked), but the values for the automation are reversed. When it's locked the value of "binary_sensor.s10e_pro_wallbox_1_plug_lock" is "off". From my point of view, the value should be "on | true" when the charging cable is locked, right?
@bullitt186 It does not yet have its own web interface, but can be accessed via the IP address. I think I saw there that the car battery is displayed correctly. I'll check again in the next few days. Password to log in: wallbe7213
Bug-Report:
Controls for "Wallbox 2" dosn't work proberbly. If I want to change a value, the changes are always sent to "Wallbox 1".
If sun mode is on for both wallboxes and I switch off "Wallbox 2 sun mode", then both go off first and then wallbox 2 comes back on. -> see Logbook.
Bug-Report:
Controls for "Wallbox 2" dosn't work proberbly. If I want to change a value, the changes are always sent to "Wallbox 1".
If sun mode is on for both wallboxes and I switch off "Wallbox 2 sun mode", then both go off first and then wallbox 2 comes back on. -> see Logbook.
I found that issue & root cause, is fixed with the next PR
The logic of the binary sensors "plug_lock" is a bit confusing.
It is displayed correctly in the interface (locked | unlocked), but the values for the automation are reversed. When it's locked the value of "binary_sensor.s10e_pro_wallbox_1_plug_lock" is "off". From my point of view, the value should be "on | true" when the charging cable is locked, right?
I stumbled on this as well but this is the way HA handles lock states, see Binary Sensor: "lock: on means open (unlocked), off means closed (locked)"
So it follows HA's intended behaviour
For me the Wallbox state of charge is 0% but the car has 90% car is an ID4 with 3.5 ICAS Software.
Any idea to change it?
Despite the weather I did a short test of the wallbox features today. Setting and reading charging current, toggle charging, wallbox consumption & energy, wallbox plug and charging state are working as expected, so for me everything is working. I did not check the other entities. We're using an Easy Connect with an S10E.
For me the Wallbox state of charge is 0% but the car has 90% car is an ID4 with 3.5 ICAS Software.
Any idea to change it?
At least for Audi this never worked for me (also using other RSCP implementations I tried in the last three years)
For me the Wallbox state of charge is 0% but the car has 90% car is an ID4 with 3.5 ICAS Software. Any idea to change it?
At least for Audi this never worked for me (also using other RSCP implementations I tried in the last three years)
I did some googeling: E3DC supports charging via IEC 61851, which then uses ISO 15118, if i understand correctly. While both are standards, when you google these terms + wallbox, you find a lot of discussions, e.g in the openWB Forum, showing that this standard is not fully supported by WB manufacturers / OEMs. the EVCC Project went the route of rather integrating with the OEMs web APIs.
So i will disable SoC by default to avoid confusion / false expectations and add a comment in the README.md in the next days
For me the Wallbox state of charge is 0% but the car has 90% car is an ID4 with 3.5 ICAS Software. Any idea to change it?
At least for Audi this never worked for me (also using other RSCP implementations I tried in the last three years)
Same to me. I have a BMW i3 and a BMW i4, both show me a "Wallbox state of charge" of 0%. I can get the value "state of charge" from BMW Integration, but i have to know which car is on which wallbox 1 or 2. But normally, of course, the vehicles are always parked at a fixed wallbox.
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
2.) Sun Mode - on/off
3.) Charging Start/Stop
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:
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
@neuromancer3142: This is very much in line with my experience. E3DC has a charging strategy that I think could be improved. In E3DC sun mode, the charging process only starts when the battery is almost full and at the same time there is enough power coming from the roof. But then the battery is discharged again if there are clouds, for example, because the holding time is observed.
I would actually like the wallbox to start much earlier, while the home storage system is still charging. If, for example, 8000 watts are coming from the roof and the house needs 1000 watts, then I would like 5000 watts to go into the car and 2000 into the home storage unit. This would charge the home storage system more slowly and avoid discharging the home storage system later.
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.
Yes, that's also my strategy, sun mode off, start the charging process and then use the automation to control what power should go into the wallbox and up to what level the battery should be discharged. I have already started to write such an automation for HA, but at the moment it is still failing because I cannot yet change the charging power of the wallbox(es) (6 ... 16 A) via the integration. That's why I can only work with a preset charging power at the moment and only control the discharging of the battery by switching the wallbox on and off. But I hope/think @bullitt186 is working on integrating the slider for the charging power.
Hi Wolfgang,
If you do have an automation that will trigger the charging of the car between the 2 threshold values that you can set with sliders as indicated above: I am very interested to get to know on how to do that. This is what I am looking for. An easy way to set each day how much it should charge in the car, without having to jump between all those E3DC apps ;-). Cheers
I have saved the draft for my script here. In lines 136 and 137 I use values from my car to get the charge status, you have to change this for yourself.
The trick is to create a few auxiliary entities (input_numbers & binary_sensors) at the beginning of the file to simplify the script.
Further instructions on how to install and start the script can be found in the readme.
The 2 threshold values are the input_numbers from the yaml, which can be placed on the lovelace interface of home assistant.
Just released https://github.com/torbennehmer/hacs-e3dc/releases/tag/v3.8.0-beta.3 including the new one-device-per-wallbox PR, happy testing
@bullitt186 What's your impression on the discussion between @Wolfgang-03 and @neuromancer3142 ?
I am exploring in a local branch two things right now:
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 😅
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
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.
Checklist
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.:
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
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