svalouch
Battery.status2 / Battery extra status - Details
The OID = 0xDE3D20D, alias "battery.status2" / "Battery extra status" seems to be the better choice for those interested in more details. I observed that the other one battery status (OID = 0x70A2AF4F, alias "battery.bat_status") does not show all status anymore, e.g. normal balancing is not shown anymore on the RCT-App.
OID = 0xDE3D20D is also a 32-bit bitmask similar to the other battery status OID. My experience with "battery.status2" after monitoring it over some time and comparing it to the OID = 0xDE3D20D is a follows. Note that the wording is my wording, not any offical one:
OID = 0xDE3D20D bit structure, expressed bit position / decimal value of this bit if set:
Bit 0 / 1 = disconnected
Bit 1 / 2 = syncronizing
Bit 2 / 4 = connecting
Bit 3 / 8 = calibrating-charge (SOC target = 100%)
Bit 4 / 16 = ?
Bit 5 / 32 = ?
Bit 6 / 64 = ?
Bit 7 / 128 = ?
Bit 8 / 256 = balancing in progress (charge to 100%)
Bit 9 / 512 = empty / low voltage [short error condition when battery is self-discharging under SOC-min and going below min voltage]
Bit 10 / 1024 = calibrating-discharge (SOC target = 0%)
Bit 11 / 2048 = balancing required/pending
Bits 12.. = ?
Note: More than one bit can be set at a time! Therefore the OID decimal values can be in reality:
0 = normal charge/discharge (SOC target = xy%)
3 = disconnected, syncronizing
5 = disconnected, connecting
2048 = 2048+0 = normal charge/discharge, balancing required (SOC target = xy%)
2056 = 2048+8 = calibrating charge, balancing required (SOC target = 100%)
2304 = 2048+256 = balancing required and in progress (SOC target = 100%)
2312 = 2048+256+8 = calibrating charge + balancing required and in progress
2560 = 2048+512 = empty / low voltage + balancing required
3072 = 2048+1024 = calibrating discharge + balancing required (SOC target = 0%)
Feedback is welcome to gather more details for other bits.
Nice finding, but decimal valus are wrong (2^n)
Bit 0 / 1 = ?
Bit 1 / 2 = ?
Bit 2 / 4 = ?
Bit 3 / 8 = ?
Bit 4 / 16 = calibrating-charge (SOC target = 100%)
Bit 5 / 32 = ?
Bit 6 / 64 = ?
Bit 7 / 128 = ?
Bit 8 / 256 = ?
Bit 9 / 512 = balancing in progress (charge to 100%)
Bit 10 / 1024 = empty / low voltage [short error condition when battery is self-discharging under SOC-min and going below min voltage]
Bit 11 / 2048 = calibrating-discharge (SOC target = 0%)
Bit 12 / 4096 = balancing required/pending
Nice finding, but decimal valus are wrong (2^n)
Bit 0 / 1 = ? Bit 1 / 2 = ? Bit 2 / 4 = ? Bit 3 / 8 = ?
Well, decimal values are correct but bit positions got an offset. Issue text is corrected now.
My proposal: Quick fix lines 58-64 in const.py to the following?
class BatteryStatusFlag(IntFlag, boundary=KEEP):
normal = 0
charging = 2**4
discharging = 2**11
balancing = 2**9
calibrating = charging | discharging
Tested in my setup and works. What do you think, @svalouch?
Greetings, Heiko
My proposal: Quick fix lines 58-64 in const.py to the following?
class BatteryStatusFlag(IntFlag, boundary=KEEP): normal = 0 charging = 2**4 discharging = 2**11 balancing = 2**9 calibrating = charging | dischargingTested in my setup and works. What do you think, @svalouch?
Greetings, Heiko
Note that the bit position are corrected in the original issue post.
BTW: My inverted returns on status2 0 and on status 8 (which charging => 100%) Seems to depend on whether there are two batteries and/or version of the inverter (2.3.5681 here).
BTW: My inverted returns on status2 0 and on status 8 (which charging => 100%) Seems to depend on whether there are two batteries and/or version of the inverter (2.3.5681 here).
Could be. My original finding is based on inverter firmware version 2.3.5678, with single battery tower on BMS version 5608.
Interesting find, but does that have any impact on this project? Is there a request to do something, besides possibly adding this to the docs (e.g. in https://github.com/svalouch/python-rctclient/blob/main/docs/inverter_bitfields.rst)? Otherwise, the reference to the const.py quickfix is for a different project ... Anything to be done here? I'll have a look into https://github.com/svalouch/rctmon to see if I can do something there.
Interesting find, but does that have any impact on this project? Is there a request to do something, besides possibly adding this to the docs (e.g. in https://github.com/svalouch/python-rctclient/blob/main/docs/inverter_bitfields.rst)? Otherwise, the reference to the const.py quickfix is for a different project ... Anything to be done here? I'll have a look into https://github.com/svalouch/rctmon to see if I can do something there.
Yes, it is meant as input for documentation e.g. at https://github.com/svalouch/python-rctclient/blob/main/docs/inverter_bitfields.rst and to trigger other inputs to get the "decoding" more complete.
fyi: my status2 was 0 all the time since April 16. My last firmware update (2.3.5685/BMS 5610) was on April 13, so not directly related. Having a calibration today and can confirm the above mentioned values so far (2048->2056->2312->3072, and 2560 when empty). No new ones observed so far.