Sporadic wrong byte_index when reading multiple packs

[asdt1803]

Hello @Tertiush,

I'm using the development version of the script to read out 4 Gobel Power packs. With the current BMS firmware 2.06 I recognized that implausible values are published via mqtt every now and then a few times per day. Reason for this is a wrong byte_index.
The analog data from my second battery pack sometimes contains 0x10 in the unused data following the SOH figure. This causes the condition in line 874 of the current version 2.3dev to start reading the next packs data prematurely.

In order not to trigger the condition if inc_data contains "10" after SOH I think it would make the script more robust to check for the sequence "00 00 10" instead.

Therefore, I changed line 874 to:

while (byte_index < len(inc_data)) and (cells != int(inc_data[byte_index-4:byte_index+2],16)):

This seems to solve my problem.
I think this might be the same issue that was reported here: #28

Thank you
as

[Tertiush]

Only saw this one now, oops. Without giving it too much thought, have you tried setting the force_pack_offset value to force a jump in the byte_index? Could also be a fix and is easier to manage across different firmware versions.

[asdt1803]

You're probably right, setting a fixed pack offset would probably also mitigate the symptom. I haven't tested this as I suspect this would be harder for me to manage across firmware versions. I would suspect that it is more likely that additional data is appended or removed in future firmware versions (so that I would need to remember I set the force_pack_offset and correct it if the script fails after an firmware upgrade ). I suspect that it is much less likely that the start sequence will change in the future.

My understanding from manually dissecting the inc_data is that the start sequence is 6 byte long, but the script currently only matches the last two bytes out of this sequence to determine the start point to read the next packs values. I currently cannot see any drawback in the fix proposed here, but please feel free to close the issue if you disagree.

[github-actions]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.