I’m hoping @alexpescaru might know the answer to this one.
I have a pair of batteries (100Ah, 16s, LiFePO4) with a AFBMS. The firmware for the BMS has been updated to the latest, and there is a field in the BMS to set various flavours of CAN, such as Pylontech, GoodWe, Growatt, Victron.
I’ve set the field to Victron, and this causes most data to show up in the GX - requested charge voltage, DCL, CCL, alerts, etc.
Some fields are interpreted incorrectly by the GX - now in this case i know that its the BMS’s fault for not sending the correct bytes, but i can’t get a change made to the BMS firmware, and i don’t have the sourcecode for this BMS either. With that in mind … the BMS sends CAN message id 0x379 (8 bytes) with certain values which i have confirmed are little endian, and are correct, however the GX takes the raw value for the “Installed Ah”, whereas my code (which prints the correct value) divides by 100.
– My Question: –
Can i hack a small change in a driver or template in the GX so that “Installed / Available Capacity” on the Details page of the battery (in the remote console) contains the correct values?
Currently the GX display says “Installed / Available Capacity 20.0kAh / – Ah”, but it should be 200Ah / 142.8Ah (at the present time).
For the “Available Capacity”, the BMS is sending the 142.8 in the 5th and 6th bytes, but i think the GX is looking in the 2nd and 3rd.
I’ve tried Pylontech - this was the 2nd best result, but although according to this CAN message IDs and descriptions table, the Pylontech should be sending 0x379, for me it doesn’t - probably a shortcoming in the firmware.
GoodWe was also looking good, but still not quite right.
I’m now running through a formal testing process, checking every firmware back as far as i can go.
As for the “Installed / Available” stuff, on my system it’s the same: “----” for the Available capacity…
If you take a look inside Venus OS, on the qui’s qml files, you’ll see that the Available capacity is a mirror/telltale of the battery’s “/Capacity” path in the system’s d-bus.
That path (/Capacity), I have the feeling (but I am not so sure), that it’s only populated for their BMSes (Victron’s) and is taken from 35F, bytes 4 & 5.
But Pylontech is not sending 35F… Don’t know if the AFBMS is sending that info on 35F…
Pylontechs is sending only the first 4 bytes on the 379, and the info is in Ah there, on 32 bit format.
So, no, the bytes 2 and 3 are the high bytes of the Installed capacity.
Probably because they populate 35F ID with proper info. Good to know. Thanks!
Pylontech doesn’t and RPNZ may tell us if the AFBMS does. I have the feeling it doesn’t…
Interesting mix. I decided to re look at all of the ones we have.
BSL - only installed capacity shows
Freedom won - installed capacity
Blue nova - installed capacity
Yes. You are right they just aren’t sending it.
Many other manufacturers do the same. Just send the installed capacity not the available.
Some battery manufacturers have made the effort to send out the information though. I have seen other even more comprehensive natively. Just not had personal experience installing them. So the can address for the information is not a mystery and hasn’t changed in a while. 2017 is the can date on the jk i just rechecked.
The Victron Definition that I found on line gives 0x379 as installed capacity in Ah (UN16). 0x35f byte 4&5gives available capacity also in UN16.
both are little endian.
I’ve found that both of these work properly…
I don’t think it would be easy to ‘hack’ the firmware in the Gx to get the installed capacity in 1/100 th Ah, and the firmware ‘knows’ when it has been hacked, and adds a ‘modification’ warning in the GX menu.
as the numbers are all UN16, you can’t send fractions of Ah. so the 142.8 should be rounded to 143, and sent as 0x8f in the 4th byte of 0x35f.
The easiest way to fix this would be with a CAN ‘interpreter’ device on the bus between the BMS and the GX, where the BMS messages are received, decoded and then re-coded correctly for the GX.
Which firmware does this?
And where is the warning shown?
I am asking because, some time ago, I’ve made a little modification at the machine code level on the can-bus-bms driver to swap around the min and max cell voltages for a certain BMS that was sending them swapped and all went OK, without any warning…
This is version 3.60; first time I’ve seen this.
Perhaps this only shows if you edit a .py file on a running Cerbo / GX, but not if you edit the code at the low level before running.
I’ve downloaded the last beta and took a little peek.
It seems that the option is for modification of things in /data/rc.local, /data/rcS.local, partition info and filesystem, ssh keys, Node-Red and Signal K stuff, etc.
So, don’t believe it has to do with binary modifications.
Thanks Mike.
We (RoarPower) were at one stage working on a bablefish like device that would be MITM and could speak any inverter language and any battery/BMS language, and where necessary correct deficiencies in the firmware, but after we got it mostly working we moved onto other projects.
That bablefish would be a good project to finish, but really its up to the battery manu to fix their firmware, and we stopped trying to help them when it was clear they weren’t interested in fixing edge cases.
So my assessment from everyone’s comments is that Installed/Available capacity is not an input to anything meaningful?
i.e. the operation of the GX/MP doesn’t seem to be negatively affected by errors or missing values in this pair of values?
This is what i’m hoping to do - tweak that driver to overcome the lack of correctness of my firmware.
To wrap up this chapter: i’ve had to stop working on this since i’ve bricked 2 batteries - i down graded the firmware 1 version at a time, and for each firmware I setup the params the same, and then put the BMS through a bunch of correctness tests and documented which params were correct. When i got to the oldest firmware, i suddenly found i couldn’t flash again. So of course i tried a different laptop over a different cable to a different battery, and bricked that too. The bricking isn’t total - the BMS just won’t go into write mode, so i can’t then flash back to the best firmware
Now i’m waiting for a colleague to save me - he is an expert at things like this, he can probably bypass the UART and flash the bms in true hacker style.
Population of 35F depends on which firmware we run, and which flavour of CAN we choose.
For most firmware versions, if we choose “SoFar” or “Sorotech” as the CAN flavour, 35F is correctly sent.
For all other choices (GoodWe, LuxPower, Pylontech, and some others i didn’t test) 35F isn’t sent.
The 35F info is on the todo list of Pylontech… Since exactly 4 years ago.
Maybe some security bits were set by default on the programming stage and therefore you can’t program it any further.
In that case, indeed, a direct connection to the microcontroller will save the day.
And by the way D., I’ve managed to finally find the software for that BMS.
Modified/lowered the cell’s starting voltage for balancing and programmed it on my friend’s battery and results are already showing as the battery is already balanced.
Thanks for taking the time to listen and help!
