Observations and Bugs connecting to US2000C (y2022)

[stei-f]

Hi,

first, thanks for implementing this crappy protocol.

Initially I thought my RS485 connection was not working as I was not able to establish any communication. But as soon as I did send the example "string" from the protocol documentation the battery started talking. So I thought that something was wrong with the code or the checksum (or python version) and started reversing and debugging. It does also NOT help that the checksum explanation in the PDF is wrong (wrong sum for the sample characters given). Anyway, the code is/was ok.

I'm not able to query anything except "get_values_single" (I'm getting ignored by the battery, no response). And the first battery is 2, for whatever reason. So no get_protocol_version, no get_module_serial_number. (?)

Is this normal? I do not have a gateway. Just 4 linked batteries us2000C of the same type.

Also I found a bug in the code:

According to the PDF (Page 15 "M+N+6") there is a field "UserDefinedData" in the data returned by get_values_single (42H), that is missing in the code/struct. This leads to data garbage after "RemainingCapacity".

Sooo... around Line 99:

     99     get_values_single_fmt = construct.Struct(
    100         "NumberOfModule" / construct.Byte,
    101         "NumberOfCells" / construct.Int8ub,
    102         "CellVoltages" / construct.Array(construct.this.NumberOfCells, ToVolt(construct.Int16sb)),
    103         "NumberOfTemperatures" / construct.Int8ub,
    104         "AverageBMSTemperature" / ToCelsius(construct.Int16sb),
    105         "GroupedCellsTemperatures" / construct.Array(construct.this.NumberOfTemperatures - 1, ToCelsius(construct.Int16sb)),
    106         "Current" / ToAmp(construct.Int16sb),
    107         "Voltage" / ToVolt(construct.Int16ub),
    108         "Power" / construct.Computed(construct.this.Current * construct.this.Voltage),
    109         "RemainingCapacity" / DivideBy1000(construct.Int16ub),
    110         "UserDefinedItems" / construct.Byte,
    111         "TotalCapacity" / DivideBy1000(construct.Int16ub),
    112         "CycleNumber" / construct.Int16ub,
    113     )

See line 110 of my code snipped. Also this is still not correct according to the protocol (PDF), as the following numbers are an array of the size of "UserDefinedItems". Did not investigate further into this. I do not know if this breaks something I'm not able to call. For me this fixes "TotalCapacity" and "CycleNumber", but I do not have batteries > 65ah.

Protocol version is still 2.0 for me (b'~200246...).

Greetings Frank

[abelsson]

Indeed! thanks for this code which parses this mess of a protocol! :)

I agree - the get_values_single_fmt is is currently missing the UserDefinedItems field which causes bogus parsing for everything after RemaingCapacity. I just noted it's there for get_values_fmt (as _undef1).

For batteries with >65AH such as my UP2500 the RemainingCapacity and TotalCapacity is saturated to 65535 and there are two additional fields (creatively named) RemainingCapacity2 and TotalCapacity2 which are 3 bytes (Int24ub) - this is as described in the docs and actually seems to match the behavior of my battery. I've pushed an example of such a message to my branch.

[abelsson]

Hm, I pushed some changes which should hopefully handle both the >64AH and <64Ah cases. It's not that pretty, but I think it should hide the protocol differences externally, see abelsson/python-pylontech@cd3f9f5f00ce874cd8a82b801d98d72dc8e9aad1. @Frankkkkk does this seem like a feasible approach? I'm far from an expert on using the construct library :)

[Frankkkkk]

Hi @abelsson thanks for your work on the lib ! I'll take a look. Indeed it should be feasible. I'll try to work on it tonight/tomorrow. Cheers

[Frankkkkk]

As for the issue, indeed it looks like a bug, i'll take a look too