-
-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Random min/max cell voltages go very high or very low in a single read. #1046
Comments
For completeness, I was able to solve the issue with the following patch. I wonder if it occurs in other platforms as well and the solution could be generalized.
|
You state that your JKBMS is connected via Bluetooth, but you edited the serial JKBMS driver? That makes no sense to me. |
Your right! The funny is that the issue does not show in days, while it was happening every day. :-) |
Please use my branch, to keep things simple. |
I hope you tested, if the error exists also in the latest nightly available. |
Well, based on my suspicion now, which is a race condition between decoding and reporting, the bug will be there for sure.
|
Any updates? |
That particular patch is no good. I am now very sure there is a race between the collection of the data and the submission to dbus. I have a new patch, but has reported a suspicious min cell voltage. I cannot really know for sure if it was an actual reading from the BMS or a corruption. I will run it for a week to make sure it does not persist. I will create a pull request, once done. I include the patch for reference. The patch seems big, but it is not.
|
Please open a PR for it. |
I will, however I still see the random values showing up. I will do an implementation similar to initial propose solution, by detection of corrupted values. |
I'm not using the BLE connection and most of the users don't track the values in Grafana. So I do not saw this behavior. |
I'm also seeing this behaviour monitoring 2x JKBMS via bluetooth. Every day or 2 a single cell will report an extremely high value for a single reading and then return to normal. This is easy to see in Grafana, but it also triggers a cell inbalance alarm in the VRM portal. I'm running the latest stable release, but can try the nightly if you think that will help? I have 2 other systems with different configurations which don't have this issue. 1 is monitoring a JKBMS via serial / RS485 and the other a JBD BMS via bluetooth and neither of these have ever exhibited the same behaviour as the JKBMS monitoring via bluetooth. |
Can you try with |
Have just installed and will monitor over the next few days |
Just to give an update, even with my concurrency fixes in the update process, I still see this random values. I am starting to believe it is related to some firmware bug in jkbms bluetooth. |
Which values do you see? I limited them to be => 1 V and <= 5 V. Therefore they are filtered if different from the BMS. |
Ok, but that is not sufficient. You should check from differences in consecutive readings and only allow them if they persist. |
Theoretically there is checksum to verify integrity. dbus-serialbattery/etc/dbus-serialbattery/bms/jkbms_brn.py Lines 375 to 379 in 59a6d00
|
I know that, however I meant that it was some data corruption within hardware before the checksum is computed. It could also be our rpi that might have some less stable memory that gets corrupted as well. At this point I am out of ideas for the cause. :smile |
It could also be a faulty BMS or the connection to the VMR portal. Do you also log the values on a local InfluxDB? You could try that |
I did also get the values being logged by homeassistant collected from the node-red. So I am sure it is not VRM. Faulty BMS, I doubt unless it is a problem of the firmware itself. I think @howetech confirmed the problem, actually. |
If it is a firmware problem it should been have filtered with this |
Since running the latest nightly release I haven't seen any spikes or errors in the data received by MQTT into influxdb. I have received 2 VRM notifications about cell inbalance during this time, however the VRM graphs do not show it so I'm guessing the device is sending the notification to VRM but its potentially so brief it doesn't show in any of the graphs. Either way it is better than previously and I'll keeep monitoring it. |
@mr-manuel It is filtered with your condition, however the problem is more general then just the cell voltages. I believe that it is why @howetech is still seeing those errors. Indeed @howetech VRM does seem to log some sort of average and not all readings. |
Just open a PR and I wil llook through it. Please open the PR in my repository, this will make things easier. |
I still did not have the time to work on fixing by checking the values. I will try to do it tomorrow which is an holiday around here. I will open a PR with a rough implementation, if you so allow it. Thanks |
Describe the bug
I noticed that sometimes dbus-serialbattery reports very low or high single cell voltage, affecting SOC calculation and general state of the system.
To diagnose the problem I made node-red in venus os to report as a sensor in home assistant, every single read from cell voltages.
I could then identify that the reported low/high value occurred random and in a single reading. It occurs randomly, usually once a day.
How to reproduce
Wait!
Expected behavior
Not having random reads from cell voltages.
Driver version
v1.2.20240408
Venus OS device type
Raspberry Pi 3
Venus OS version
v3.13
BMS type
JKBMS / Heltec BMS
Cell count
16
Battery count
1
Connection type
Bluetooth
Config file
Relevant log output
Any other information that may be helpful
No response
The text was updated successfully, but these errors were encountered: