Battery.status2 / Battery extra status - Details

[SaxonWood]

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.

[42Bastian]

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

[SaxonWood]

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.

[heikone]

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

[SaxonWood]

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

Note that the bit position are corrected in the original issue post.

[42Bastian]

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).

[SaxonWood]

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.

[sfudeus]

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.

[SaxonWood]

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.

[sfudeus]

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.