Error query / activate manual charge

[Stefan28L]

System Health details

System Information

version	core-2024.12.5
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.13.0
os_name	Linux
os_version	6.6.62-haos-raspi
arch	aarch64
timezone	Europe/Berlin
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	5000
Installed Version	2.0.1
Stage	running
Available Repositories	1497
Downloaded Repositories	10

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 14.1
update_channel	stable
supervisor_version	supervisor-2024.12.0
agent_version	1.6.0
docker_version	27.2.0
disk_total	109.3 GB
disk_used	10.5 GB
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	rpi5-64
supervisor_api	ok
version_api	ok
installed_addons	File editor (5.8.0), Mosquitto broker (6.4.1), TasmoAdmin (0.31.2), Terminal & SSH (9.16.0), ESPHome Device Builder (2024.12.2), Samba share (12.3.2), MQTT Explorer (browser-1.0.1), WireGuard (0.10.2), Network UPS Tools (0.14.0), Samba Backup (5.2.0), Zigbee2MQTT (1.42.0-2), AdGuard Home (5.2.1)

Dashboards

dashboards	7
resources	2
views	16
mode	storage

Miele

component_version	2024.12.0
reach_miele_cloud	ok

Recorder

oldest_recorder_run	25. November 2024 um 16:50
current_recorder_run	22. Dezember 2024 um 15:23
estimated_db_size	592.37 MiB
database_engine	sqlite
database_version	3.45.3

Solcast PV Forecast

can_reach_server	ok

Checklist

• I have enabled debug logging for my installation.
• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of currently previous issues..

Describe the issue

Manual charging via the manual_charge action seems to work in principle if I trigger the service manually.
However, I would like to call the service in an automation and transmit the charge quantity via entity.
I defined the action as follows:

action: e3dc_rscp.manual_charge
metadata: {}
data_template:
device_id: c1bb223b4578e222a7a178ecb0db8383
charge_amount: "{{ states('input_number.e3dc_lademenge') | int }}"

When attempting to execute the automation, i find the correct amount (650Wh) in the log (s.below), but i get the message "Manual charging could not be activated".

Unfortunately, I am unable to capture the error in the diagnostic dump, as there also seems to be a problem retrieving the manual charge quantity.
I do not want to post the complete log / dump here, as it contains the complete data of my E3DC system.
If any important information is missing, I will of course be happy to add it later.

My System Info:
"model": "S10E_Compact",
"release": "S10_2024_028",

Reproduction steps

...

Debug logs

2024-12-25 11:58:35.087 DEBUG (MainThread) [custom_components.e3dc_rscp.coordinator] Starting manual charge of: 650 Wh
2024-12-25 11:58:35.094 WARNING (SyncWorker_7) [custom_components.e3dc_rscp.e3dc_proxy] Manual charging could not be activated
2024-12-25 11:58:35.095 DEBUG (MainThread) [custom_components.e3dc_rscp.coordinator] Manual charging start command has been sent.
2024-12-25 11:58:37.128 DEBUG (MainThread) [custom_components.e3dc_rscp.coordinator] Polling general status information
2024-12-25 11:58:37.193 DEBUG (MainThread) [custom_components.e3dc_rscp.coordinator] Poll power settings
2024-12-25 11:58:37.200 DEBUG (MainThread)

Diagnostics dump

"get_power_settings": {
"dischargeStartPower": 0,
"maxChargePower": 4500,
"maxDischargePower": 0,
"powerLimitsUsed": true,
"powerSaveEnabled": true,
"weatherForecastMode": 1,
"weatherRegulatedChargeEnabled": true
},
"EMS_REQ_GET_MANUAL_CHARGE": {
"exception": [
"Traceback (most recent call last):\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc_rscp_local.py", line 102, in sendRequest\n receive = self._receive()\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc_rscp_local.py", line 76, in _receive\n decData = rscpDecode(self.encdec.decrypt(data))[0]\n ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_rscpLib.py", line 263, in rscpDecode\n return rscpDecode(rscpFrameDecode(data)[0])\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_rscpLib.py", line 279, in rscpDecode\n innerData, usedLength = rscpDecode(data[curByte:])\n ~~~~~~~~~~^^^^^^^^^^^^^^^^\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_rscpLib.py", line 270, in rscpDecode\n strTag = getStrRscpTag(hexTag)\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_rscpTags.py", line 3692, in getStrRscpTag\n tag = RscpTag(tag)\n",
" File "/usr/local/lib/python3.13/enum.py", line 722, in call\n return cls.new(cls, value)\n ~~~~~~~~~~~^^^^^^^^^^^^\n",
" File "/usr/local/lib/python3.13/enum.py", line 1189, in new\n raise ve_exc\n",
"ValueError: 16777278 is not a valid RscpTag\n",
"\nDuring handling of the above exception, another exception occurred:\n\n",
"Traceback (most recent call last):\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc.py", line 227, in sendRequest\n result = self.rscp.sendRequest(request)\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc_rscp_local.py", line 108, in sendRequest\n raise CommunicationError\n",
"e3dc._e3dc_rscp_local.CommunicationError\n",
"\nDuring handling of the above exception, another exception occurred:\n\n",
"Traceback (most recent call last):\n",
" File "/config/custom_components/e3dc_rscp/diagnostics.py", line 111, in _query_data_for_dump\n tmp = call()\n",
" File "/config/custom_components/e3dc_rscp/diagnostics.py", line 80, in \n lambda: self.e3dc.sendRequestTag(\n ~~~~~~~~~~~~~~~~~~~~~~~~^\n RscpTag.EMS_REQ_GET_MANUAL_CHARGE, keepAlive=True\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n )\n ^\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc.py", line 264, in sendRequestTag\n return self.sendRequest(\n ~~~~~~~~~~~~~~~~^\n (tag, RscpType.NoneType, None), retries=retries, keepAlive=keepAlive\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n )[2]\n ^\n",
" File "/usr/local/lib/python3.13/site-packages/e3dc/_e3dc.py", line 238, in sendRequest\n raise SendError("Max retries reached")\n",
"e3dc._e3dc.SendError: Max retries reached\n"
]
},

[Stefan28L]

Sorry, I forgot to mention that I am using the latest version (V3.8.0):

"integration_manifest": {
"domain": "e3dc_rscp",
"name": "E3DC Remote Storage Control Protocol (Git)",
"codeowners": [
"torbennehmer"
],
"config_flow": true,
"dependencies": [],
"documentation": "https://github.com/torbennehmer/hacs-e3dc",
"homekit": {},
"integration_type": "device",
"iot_class": "cloud_polling",
"issue_tracker": "https://github.com/torbennehmer/hacs-e3dc/issues",
"requirements": [
"pye3dc==0.9.2"
],
"ssdp": [],
"version": "v3.8.0",
"zeroconf": [],
"is_built_in": false,
"overwrites_built_in": false

[torbennehmer]

@Stefan28L The error in the diagnostic dump is a known bug in pye3dc (see #114).

If you did run multiple calls, be aware, that there's a timeout, you can't call this service as often as you want. The documentation states, that one call/day with up to 3 kWh is allowed. I've had evidence from other users, that there's actually a limit around once/2h, I haven't confirmed that personally though. Also, the 3kWh from the docs seems to be outdated, my own unit can charge its full 4,5 kWh in one call.

Besides that, I don't have more logging than that available, if you're savvy in python, you could call the pye3dc method directly, use the code following Line 279 of e3dc_proxy.py as a baseline.

Since we're directly failing the E3DC RSCP call here, my bet would be on the time limit, normally, it looks good what I'm seeing in the logs.

With current codebase, I can't tell more, unfortunately, as I don't have any advanced debugging code of the e3dc communication in place (pye3dc does not provide this).

PS: From a privacy point of view, the full hacs-e3dc diagnostics dump can be shared here, all private data like serial numbers, mac addresses etc. should be eradicted out of the dump, what remains is a detailed description of the unit and its responses to the RSCP commands we send to it. It helps me to understand the units and their responses to RSCP commands in more detail, but that's it. In this case, I won't benefit from it besides having another dump for my archive to see what the units are doing. Since E3DC doesn't really react to any communication from me, this is my only way to gather real-life data on the way the units react.

I'll keep the case open for the moment, please check against the time restrictions and if possible, try to call the function directly within the limitations to gather more information.

[neuromancer3142]

Hi everyone,
I have a S10E Pro System and I can confirm the 2h time limit. My E3DC system allows me to trigger a manual chare approx every 2h. To be on the safe side I do that in automations with a pause of 2h 15mins in between calls - it never failed. Concerning the energy that can be charged: My system allows me to charge 12.000 Wh in one go. I assume it is a function of the system used (S10E Pro) and the installed battery capacity. My assumption is based on the fact that I could previously only charge 9.000 Wh in one go and after I doubled my installed battery capacity it allowed me 12.000 Wh. Could have also coincided with a system update (did not pay attention if anyting changed there), but I attribute it to the battery upgrade. Hope this info helps.
Cheers!

[Stefan28L]

Hello @torbennehmer, first of all thank you very much for your application and the time you invest.
My assumption was that I had an error in my code and that there was a difference whether I called a fixed value with "data:" or a variable value from a template with "data_template:"

actions:

• action: e3dc_rscp.manual_charge
  metadata: {}
  data_template:
  device_id: c1bb223b4578e222a7a178ecb0dbxxxx
  charge_amount: "{{ states('input_number.e3dc_lademenge') | int }}"

• action: e3dc_rscp.manual_charge
  metadata: {}
  data:
  device_id: c1bb223b4578e222a7a178ecb0dbxxxx
  charge_amount: 350

The fact that I see the correct value in the log file speaks against this.
I can confirm here that I had not activated a manual loading process at least 24 hours before calling the automation.
I will verify this again in the next few days and will post a complete dump here later.

Can you answer the following questions for me?

• @neuromancer3142 : Does your automation run with a fixed value or a template value?
• @torbennehmer : Have I understood correctly that there is no further diagnostic option?

[Stefan28L]

What can I say? I just tried to create a bug report and the automation just worked. This is the first time it has worked.
The last attempt, tonight at 3:00 a.m., didn't work. I don't see any difference in the trace.
I'll keep an eye on it for now.
At the moment I'm only trying to charge a small amount (350W) just to test the function.
config_entry-e3dc_rscp-874a8d7a0ec22fcac91543bbb6d94d61 (2).json

[neuromancer3142]

* @neuromancer3142 : Does your automation run with a fixed value or a template value?

I run the automation with a fixed value, because I did not manage to do it with a variable ;-). Happy to know how to do that.

[volkerrichert]

I'm using set_power_mode (still via iobroker, atm) to force charging battery. Sure, you can't limit the amount of power going into it, but it seems not having a limitation.

Can this be added to the integration?

[volkerrichert]

I could try to add a service or select to the integration

[Stefan28L]

I've been able to test the behavior a few times now.
The call seems to go to the E3DC system, but the battery isn't always charged!?

For example:
Yesterday evening at 9:05 p.m. the call didn't work.
At 11:15 p.m. the same call was triggered again and the battery was charged.
The log entries were the same at both times.

Unfortunately I can't narrow down the error any further, but I suspect that it's more a problem on the E3DC side.

It would be interesting to know if others have had a similar experience.

Since it's rarely worth charging the battery from the grid, I'll leave it at that for now.

Thank you very much for your help.
Let me know if there's anything else I can do.