Incorrect alarm interpretation

[sofkaski]

BMS Version 🔄

Seplos V2. (Integration reports: Device Details for 0x00: {'device_name': '1101-JK06 ', 'software_version': '16.4', 'manufacturer_name': 'CAN:PNG_DYE_'}

Connection Method 🌐

USB-RS485

Pre-submission Checklist ✅

• This issue is focused on a single problem (For multiple issues, create separate reports).
• I've checked for existing issues and confirmed mine is unique.

What's happening? 🤔

The battery pack has 'Monomer overvoltage protection' and 'Intermittent charging' alarms on based on EN BMS Android application. These warning/alarms makes sense based on the actual state of the battery pack.

What gets reported by bms_connector integration are Alarm Event 1: Temperature sensor fault and Alarm Event 5: Charge over current protection .

These interpretations seem to be offset by one. The correct interpretation can be found from Alarm Event 2 and Alarm Event 6

Steps to Reproduce 🔍

1. Observe alarms and warnings that are on from the Android app
2. Observe the state of entity BMS - 0x00 - Alarm Event 1 and BMS - 0x00 - Alarm Event 5 (BMS is the prefix I use)

Debug logs 📜

2024-05-03 11:50:55.444 DEBUG (SyncWorker_5) [custom_components.bms_connector.connector.local_serial.local_serial] ['~20004642E00200FD37\r', '~20004644E00200FD35\r', '~20004647E00200FD32\r', '~20
004651E00200FD37\r']
2024-05-03 11:50:55.451 DEBUG (SyncWorker_5) [custom_components.bms_connector.connector.local_serial.local_serial] ~20004642E00200FD37
2024-05-03 11:50:55.952 DEBUG (SyncWorker_5) [custom_components.bms_connector.connector.local_serial.local_serial] ~20004644E00200FD35
2024-05-03 11:50:56.455 DEBUG (SyncWorker_5) [custom_components.bms_connector.connector.local_serial.local_serial] ~20004647E00200FD32
2024-05-03 11:50:56.957 DEBUG (SyncWorker_5) [custom_components.bms_connector.connector.local_serial.local_serial] ~20004651E00200FD37
2024-05-03 11:50:57.461 DEBUG (SyncWorker_5) [custom_components.bms_connector.connector.local_serial.local_serial] ['~2000460010960000100CF10DF90CF00DE90CF10D1F0CF10D850CF10CF00CF10CF10CF10CF10CF
10CF1060BC70BCA0BC60BCA0C0C0BC9000014FB254A0A254A03E86D60003D03E81535FFFC00070BE50B6CDC11', '~20004600806200001000020002000000020000000000000000060000000000000000140002000000020182001000000000000
000000010EB21', '~200046008152003C0DAC0D480B540C1C0E420D480A8C0C1C0D4805DC15E01518122012C01680151810E012C0189C17D40C9F0C810ABF0ADD0CD10C9F0A470AAB0CB30C810A470AC90CD10C9F0A150AAB0AAB0B0F0C9F0C810
AAB0AC90D030CD10A470AAB0E2F0DFD0E930DFD4E204C2CAFECB0B45208ADF88AD007D06D6036B01B321E1E140A100A0A1E3C0505010A0A1EF0300F0560506409000D0008FFFFFF3FBF9FAF1E313130312D4A4B303620B27A', '~20004600C0403
13130312D4A4B303620100743414E3A504E475F4459455F4C7578705F544242F017']
2024-05-03 11:50:57.464 DEBUG (MainThread) [custom_components.bms_connector.bms.seplos.v2.data_parser] Calculated Checksum: DC11
2024-05-03 11:50:57.465 DEBUG (MainThread) [custom_components.bms_connector.bms.seplos.v2.data_parser] Telemetry Result for 0x00: {'cellsCount': 16, 'cellVoltage': [3313, 3577, 3312, 3561, 3313, 
3359, 3313, 3461, 3313, 3312, 3313, 3313, 3313, 3313, 3313, 3313], 'tempCount': 6, 'temperatures': [28.4, 28.7, 28.3, 28.7, 35.3, 28.6], 'current': 0.0, 'voltage': 53.71, 'resCap': 95.46, 'custom
Number': 10, 'capacity': 95.46, 'soc': 100.0, 'ratedCapacity': 280.0, 'cycles': 61, 'soh': 100.0, 'portVoltage': 54.29}
2024-05-03 11:50:57.465 DEBUG (MainThread) [custom_components.bms_connector.bms.seplos.v2.data_parser] About to return from extract_data_from_message. Telemetry: cellsCount: 16, cellVoltage: [331
3, 3577, 3312, 3561, 3313, 3359, 3313, 3461, 3313, 3312, 3313, 3313, 3313, 3313, 3313, 3313], tempCount: 6, temperatures: [28.4, 28.7, 28.3, 28.7, 35.3, 28.6], current: 0.0, voltage: 53.71, resCa
p: 95.46, customNumber: 10, capacity: 95.46, soc: 100.0, ratedCapacity: 280.0, cycles: 61, soh: 100.0, portVoltage: 54.29
2024-05-03 11:50:57.466 DEBUG (MainThread) [custom_components.bms_connector.bms.seplos.v2.data_parser] Calculated Checksum: EB21
2024-05-03 11:50:57.466 DEBUG (MainThread) [custom_components.bms_connector.bms.seplos.v2.data_parser] Teledata Result for 0x00: {'cellsCount': 16, 'cellAlarm': [0, 2, 0, 2, 0, 0, 0, 2, 0, 0, 0, 
0, 0, 0, 0, 0], 'tempCount': 6, 'tempAlarm': [0, 0, 0, 0, 0, 0], 'currentAlarm': 0, 'voltageAlarm': 0, 'customAlarms': 20, 'alarmEvent0': 0, 'alarmEvent1': 2, 'alarmEvent2': 0, 'alarmEvent3': 0, 
'alarmEvent4': 0, 'alarmEvent5': 2, 'onOffState': 1, 'equilibriumState0': 130, 'equilibriumState1': 0, 'systemState': 16, 'disconnectionState0': 0, 'disconnectionState1': 0, 'alarmEvent6': 0, 'al
armEvent7': 0}
2024-05-03 11:50:57.466 DEBUG (MainThread) [custom_components.bms_connector.bms.seplos.v2.data_parser] About to return from extract_data_from_message. Teledata: cellsCount: 16, cellAlarm: [0, 2, 0, 2, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0], tempCount: 6, tempAlarm: [0, 0, 0, 0, 0, 0], currentAlarm: 0, voltageAlarm: 0, customAlarms: 20, alarmEvent0: 0, alarmEvent1: 2, alarmEvent2: 0, alarmEv:

Diagnostics dump 📦

No response

[sofkaski]

From the debug output:

1. The second response that contains alarms is: ~20004600806200001000020002000000020000000000000000060000000000000000140002000000020182001000000000000000000010EB21
2. The part that contains Alarm event 1 - Alarm event 6 is 000200000002. From SEPLOS BMS Communication Protocol_V2.0 .pdf we can interpret this so that Alarm event 2 and Alarm event 6 have non-zero values.

[sofkaski]

I can try to fix this and make a PR for review.

[sofkaski]

I have a fix proposal in https://github.com/sofkaski/bms_connector/tree/fix-alarm-mapping. It contains also unrelated commits that resolve Ruff findings. I was about to make a PR against next-branch as instructed in contributing guidelines, but noticed that the the next-branch is far behind the main. @flip555 could you rebase/merge next-branch to the level of main?

(If I make the PR now, it would look a bit crowded, since it would also include commits from main).

[sofkaski]

I have the version from my branch running in my environment (Seplos V2): Based on first few update rounds it seems to be working, but I would assume to get more alarms tomorrow to see if they are correct.