Open sofkaski opened 2 months ago
From the debug output:
~20004600806200001000020002000000020000000000000000060000000000000000140002000000020182001000000000000000000010EB21
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.I can try to fix this and make a PR for review.
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
).
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.
BMS Version 🔄
Seplos V2. (Integration reports: Device Details for 0x00: {'device_name': '1101-JK06 ', 'software_version': '16.4', 'manufacturer_name': 'CAN:PNGDYE'}
Connection Method 🌐
USB-RS485
Pre-submission Checklist ✅
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 🔍
BMS - 0x00 - Alarm Event 1
andBMS - 0x00 - Alarm Event 5
(BMS
is the prefix I use)Debug logs 📜
Diagnostics dump 📦
No response