Open eikowagenknecht opened 10 months ago
That is strange, I'm still on vacation, will look into it next week.
I believe this is a problem of library configuration. The current GIT head version has a fix for the diagnostic dumper (in case your tech-savvy enough to try that), I'll release that later. The dump might give a mit more information back. However: My best guess is, that the config defaults in pye3dc do not match your unit. I've got some thoughs in the back of my head to solve this, but I can't give you an ETA here.
@eikowagenknecht Could you please update to v3.3 and provide me with a debuggin dump along with any errors in the debug log (assuming there are any)
I suspect, that the S10X does have some weird behavior in its battery data dump. This needs further investigation and possibly fixes in the pye3dc base lib as soon as we get to the bottom of this.
Unfortunately I still cannot download the diagnostic dump. I get the same error message as shown above.
Please provide me with the stack traces out of the debug log. The new diagnostics dump system should in theory capture the exceptions flying around there, I don't understand what's going on at that point.
I think this is the stack trace for that problem:
2023-09-25 18:09:08.284 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
resp = await request_handler(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle
resp = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 100, in forwarded_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 31, in headers_middleware
response = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 148, in handle
result = await handler(request, **request.match_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/diagnostics/__init__.py", line 249, in get
data = await info.config_entry_diagnostics(hass, config_entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/e3dc_rscp/diagnostics.py", line 26, in async_get_config_entry_diagnostics
dumper.create_dump()
File "/config/custom_components/e3dc_rscp/diagnostics.py", line 49, in create_dump
self._redact_private_information_from_dump()
File "/config/custom_components/e3dc_rscp/diagnostics.py", line 119, in _redact_private_information_from_dump
for dcb in bat["dcbs"]:
~~~^^^^^^^^
TypeError: string indices must be integers, not 'str'
Ah, now I understand what happens, I believe. What fails here is the piece of code which tries to redact serial numbers from your batteries.
Would you be able to create a manual python script and send me its contents to torben
from e3dc import E3DC
TCP_IP = '10.128.20.10'
USERNAME = '...'
PASS = '...'
KEY = '...'
CONFIG = {}
e3dc = E3DC(E3DC.CONNECT_LOCAL, username=USERNAME, password=PASS, ipAddress=TCP_IP, key=KEY)
print(e3dc.get_batteries_data())
The contents of your dcbs array is somewhat different from what I'd expect.
It seems that the batteries array is empty.
Exception has occurred: TypeError
'NoneType' object cannot be interpreted as an integer
File "C:\Users\mail\Desktop\x\test.py", line 10, in <module>
print(e3dc.get_batteries_data())
^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object cannot be interpreted as an integer
If I change the code to include some config parameters (just random experiments):
CONFIG = {
"batteries": [
{
"index": 0,
"dcbs": 0
}
]
}
e3dc = E3DC(E3DC.CONNECT_LOCAL, username=USERNAME, password=PASS, ipAddress=TCP_IP, key=KEY, configuration=CONFIG)
print(e3dc.get_batteries_data())
I get a result:
[
{
"asoc":100.0,
"chargeCycles":25,
"current":-0.03,
"dcbCount":4,
"dcbs":{
},
"designCapacity":33.25,
"deviceConnected":true,
"deviceInService":false,
"deviceName":"AtlSerialBattery1006_0_0",
"deviceWorking":true,
"eodVoltage":336.0,
"errorCode":0,
"fcc":32.0,
"index":0,
"maxBatVoltage":432.0,
"maxChargeCurrent":0.0,
"maxDischargeCurrent":32.0,
"maxDcbCellTemp":31.5,
"measuredResistance":-0.0336,
"measuredResistanceRun":400.6,
"minDcbCellTemp":26.6,
"moduleVoltage":400.6,
"rc":32.0,
"readyForShutdown":1,
"rsoc":100.0,
"rsocReal":100.0,
"statusCode":33554435,
"terminalVoltage":400.6,
"totalUseTime":0,
"totalDischargeTime":0,
"trainingMode":0,
"usuableCapacity":29.66,
"usuableRemainingCapacity":29.66
}
]
But I totally could not even figure out what dcbs means, so take it with a (large) grain of salt.
This is interesting, E3DC reports 4 DCBS, but apparently, there is something going astray here. We'll have to forward this to pye3dc, just recently, we got an auto-detection of the available powermeters, we'll probably have to build something similar for batteries.
You might want to test one thing before we forward this to fsanti. You can use the request below to cycle through the DCBs. Your system should allow BAT_REQ_DCB_INFO values from 0 to 3 without error. In theory...
print(e3dc.sendRequest(
(
"BAT_REQ_DATA",
"Container",
[
("BAT_INDEX", "Uint16", 0),
("BAT_REQ_DCB_INFO", "Uint16", 2),
],
),
))
Summarizing this up, could you please open an issue for this at https://github.com/fsantini/python-e3dc ? You can mention me there, but it would be helpful if you could be part of the issue, so that tests can be run against your system. At this point I guess it has to be fixed there.
I've to think if the diagnostics system can be adapted here to be more resilient, however, this runs the danger of exposing private information, so I'm relucatant to just drop this kind of errors in the diagnostics system.
Running the code you provided results in the following:
('BAT_DATA', 'Container', [('BAT_INDEX', 'Uint16', 0), ('BAT_DCB_INFO', 'Error', 'RSCP_ERR_OUT_OF_BOUNDS')])
Running it with BAT_REQ_DCB_INFO set to 0 instead returns:
('BAT_DATA', 'Container', [('BAT_INDEX', 'Uint16', 0), ('BAT_DCB_INFO', 'Container', [('BAT_DCB_INDEX', 'Int32', 0), ('BAT_DCB_LAST_MESSAGE_TIMESTAMP', 'Uint64', 1695756996057), ('BAT_DCB_CURRENT_AVG_30S', 'Float32', -2.610990285873413), ('BAT_DCB_VOLTAGE_AVG_30S', 'Float32', 392.6000061035156)])])
Other values (1, 3, 4) also just return the error.
I think this issue here might be the same: https://github.com/fsantini/python-e3dc/issues/71
I commented there. Would be great if the diagnostics system could be adapted to not crash.
I left a fix here: https://github.com/fsantini/python-e3dc/pull/86
Maybe you can try if that works in combination with your package? I don't know how to run the custom version of this required package on my Home Assistant system... would be interested if there's an easy way to do this.
Hello! I'm also interessed in fixing this issue, because I get also "Installed battery capacity 0,0 kWh". At the moment I'm not able to play with manual python scripts... I've to find out how it works ;-)
Version 0.8.0 of the underlying library was just released. Not sure about the HA ecosystem: How to update so that it is used in my HA installation now? :-)
Version 0.8.0 of the underlying library was just released. Not sure about the HA ecosystem: How to update so that it is used in my HA installation now? :-)
Thanks for the heads-up, I'll look into it in the next days, have to push out a release anyway with the other changes regarding power meter detection.
I'll have to update the dependency definition for the integration, so that it will pick it up. This is no great change, I just want to give it a quick test run before doing so.
3.4 has just been released, it will pull pye3dc 0.8 into your HA, please test.
Thank you! Can you upgrade to v0.8.1 instead? 0.8.0 unfortunately still contained an error.
Thank you! Can you upgrade to v0.8.1 instead? 0.8.0 unfortunately still contained an error.
Sure do, will be ready shortly. Please use a new issue next time, makes management life for me a bit easier :)
Unfortunately the battery capacity is still shown as 0 and the diagnostic export still fails:
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
resp = await request_handler(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle
resp = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 100, in forwarded_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 31, in headers_middleware
response = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 148, in handle
result = await handler(request, **request.match_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/diagnostics/__init__.py", line 249, in get
data = await info.config_entry_diagnostics(hass, config_entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/e3dc_rscp/diagnostics.py", line 27, in async_get_config_entry_diagnostics
dumper.create_dump()
File "/config/custom_components/e3dc_rscp/diagnostics.py", line 50, in create_dump
self._redact_private_information_from_dump()
File "/config/custom_components/e3dc_rscp/diagnostics.py", line 127, in _redact_private_information_from_dump
] = f"{bat['dcbs'][dcb]['serialCode'][:3]}<redacted>"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
TypeError: 'NoneType' object is not subscriptable
Seems like there's a check needed if there are any dcbs with a filled serialCode value (in my case there are not because the device doesn't deliver them).
Unfortunately the battery capacity is still shown as 0 and the diagnostic export still fails:
Ok, so I believe your unit behaves erratically here. When digging deeper, it looks to that your E3DC doesn't give you any installed battery capacity. What pye3dc does is about this:
sys_specs = self.sendRequestTag(
RscpTag.EMS_REQ_GET_SYS_SPECS, keepAlive=keepAlive
)
for item in sys_specs:
if (
rscpFindTagIndex(item, RscpTag.EMS_SYS_SPEC_NAME)
== "installedBatteryCapacity"
):
self.installedBatteryCapacity = rscpFindTagIndex(
item, RscpTag.EMS_SYS_SPEC_VALUE_INT
)
# ...
This comes back empty, as this is the value (installedBatteryCapacity) I'm using for the sensor in question.
Could you please create a bug at https://github.com/fsantini/python-e3dc - it is probably best fixed there and no deal-breaker for hacs-e3dc at the moment. If you need assistance there, ping me on the issue.
Seems like there's a check needed if there are any dcbs with a filled serialCode value (in my case there are not because the device doesn't deliver them).
Yeah, that's something I try to redact for privacy reasons. I'll look into this once more, currently, known serial number locations are more or less hardcoded. I'm gonna switch this to a recursive, regex-based search, that should fix these exceptions once and for all - hopefully.
When I run pye3dc manually (the new tests.py), I get the following output:
get_system_info():
{
"deratePercent": 100.0,
"deratePower": 4730.0,
"externalSourceAvailable": 0,
"installedBatteryCapacity": 33,
"installedPeakPower": 4730,
"maxAcPower": 12000,
"macAddress": "***redacted***",
"maxBatChargePower": 12000,
"maxBatDischargePower": 12000,
"model": "S10X",
"release": "H20_2023_024",
"serial": "***redacted***"
}
So installedBatteryCapacity
is definitely not 0.
For what it's worth, 33 also seems like nonsense to me (according to the data sheet, it should be around 11,8 kWh), but other tools like RscpGui show the same as the pye3dc library here.
Forget that, it's 33 Ah. with a voltage of around 400V this results in 13,2kWh. Not sure if 400V is exactly the right value to use here, but it seems to be in the right range.
I would expect the Home Assistant integration to pick up that value instead of 0.
Values from RscpGui:
Not all of those are available in pye3dc I think, but if more of those are needed for valid calculations, I could create a PR to add them there.
So installedBatteryCapacity is definitely not 0.
I think here lies the problem. My unit gives "4600", which I interpret as Wh in the integration. since 33 Wh rounds to 0,0 kWh, so that would be expected.
Forget that, it's 33 Ah. with a voltage of around 400V this results in 13,2kWh. Not sure if 400V is exactly the right value to use here, but it seems to be in the right range.
It might be something like that, but probably per cell. When looking at manually charged power, it is Ah there too, but in relation to the individual cell's storage. In my case I've to multiply it with 3,65 V approx to get the right value. Maybe it is similar there, the battery reports 31.2 Ah as maximum capacity.
If it really is that way, I suspect that there are rounding errors involved. The field in question is an integer, so it'll loose some precision when going against some design voltage.
It should be reported to pye3dc, maybe @fsantini might be able to do something. (Actually, this looks like an E3DC firmware bug.)
The only alternative I can think of right now is deducing the capacity of the battery from the actual battery data instead of the general system stats. I've been thinking about this for a while, as it could also take state-of-health into account (I'm at 85%, so that's a significant difference). That would hide the problem and actually give us some more features, you could target your loading cycles to your actual remaining capacity, not to design capacity. My long term goal was to add the individual batteries as their own sensors/devices, so that you can track SoH etc. of them easier. That would solve this problem as well.
I'll see if I can get around to it at some point. If you need it for optimizing your charging, I'd suggest to use a template sensor giving you a static value back as a basis until I find the time.
Thanks for having a detailled look at this.
I already created an issue upstream. It's very unfortunate that E3DC devices seem to behave just slightly different from each other.
I think it would be a great idea to switch to the battery stats instead. For my unit, those would report as:
"designCapacity": 33.25,
"usuableCapacity": 28.856252670288086,
"usuableRemainingCapacity": 6.853645324707031,
"fcc": 31.200000762939453, // Full Charge Capacity?
"rc": 9.199999809265137, // Remaining Capacity?
Hi Eiko and Torben,
any update on this? Just installed my integration for the new setup of my S10 X Compact and also (still) miss the battery capacity. Did you find any way around which can be expected for any near release?
BR Mirko
Hi Eiko and Torben,
just installed integration of my S10 X. Shown battery capacity is 0 kWh.
BR
Sprollonis
@Sprollonis Can you please attach a diagnostic dump?
...gerne.
Schöne Grüße
Sprollonis
Am Di., 28. Mai 2024 um 12:57 Uhr schrieb torbennehmer < @.***>:
@Sprollonis https://github.com/Sprollonis Can you please attach a diagnostic dump?
— Reply to this email directly, view it on GitHub https://github.com/torbennehmer/hacs-e3dc/issues/45#issuecomment-2134928278, or unsubscribe https://github.com/notifications/unsubscribe-auth/APAYKKXUMQIA5SD3G4J27DDZERPH5AVCNFSM6AAAAAA326C3DCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZUHEZDQMRXHA . You are receiving this because you were mentioned.Message ID: @.***>
System Health details
System Information
Home Assistant Community Store
GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 5000 Installed Version | 1.32.1 Stage | running Available Repositories | 1268 Downloaded Repositories | 15Home Assistant Cloud
logged_in | true -- | -- subscription_expiration | 19. August 2024 um 02:00 relayer_connected | true relayer_region | eu-central-1 remote_enabled | true remote_connected | true alexa_enabled | true google_enabled | false remote_server | eu-central-1-0.ui.nabu.casa certificate_status | ready can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okHome Assistant Supervisor
host_os | Home Assistant OS 10.5 -- | -- update_channel | beta supervisor_version | supervisor-2023.08.1 agent_version | 1.5.1 docker_version | 23.0.6 disk_total | 58.0 GB disk_used | 10.3 GB healthy | true supported | true board | rpi4-64 supervisor_api | ok version_api | ok installed_addons | Samba share (10.0.2), Studio Code Server (5.10.1), Home Assistant Google Drive Backup (0.111.1), SQLite Web (3.9.2), Advanced SSH & Web Terminal (15.0.7), RaspberryMatic CCU (3.69.7.20230626), Mosquitto broker (6.2.1), Zigbee2MQTT (1.32.2-1), Network UPS Tools (0.12.0), MQTT Explorer (browser-1.0.1), eufy-security-ws (1.6.3)Dashboards
dashboards | 3 -- | -- resources | 8 views | 12 mode | storageRecorder
oldest_recorder_run | 19. August 2023 um 09:06 -- | -- current_recorder_run | 22. August 2023 um 16:26 estimated_db_size | 291.15 MiB database_engine | sqlite database_version | 3.41.2Spotify
api_endpoint_reachable | ok -- | --Checklist
Describe the issue
The "installed battery capacity" sensor shows "0".
My E3DC device is a S10 X COMPACT 14, so it should be around 14 kWh.
Reproduction steps
Debug logs
Diagnostics dump
Trying to download diagnostic info for this device I only get "unknown server error". Other devices work fine. Can't say if this is an integration or an upstream issue.