Installed battery capacity 0 #45
Comments
|
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: |
|
@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: |
|
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. 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.
|
|
If I change the code to include some config parameters (just random experiments): 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: Running it with BAT_REQ_DCB_INFO set to 0 instead returns: Other values (1, 3, 4) also just return the error. I think this issue here might be the same: fsantini/python-e3dc#71 I commented there. Would be great if the diagnostics system could be adapted to not crash. |
|
I left a fix here: fsantini/python-e3dc#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! |
|
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. |
Rewrite all Tags / Types to use the new enum. Fixes #45
|
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. |
Sure do, will be ready shortly. |
|
Unfortunately the battery capacity is still shown as 0 and the diagnostic export still fails: 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). |
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.
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: So
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. |
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.
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? |
System Health details
System Information
Home Assistant Community Store
Home Assistant Cloud
Home Assistant Supervisor
Dashboards
Recorder
Spotify
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.
The text was updated successfully, but these errors were encountered: