I’m just spit balling here, but isn’t it also a candidate to set them to keep batteries charged for a while to allow the algorithm and balancing to do its thing? The idea being that the cells gets top balanced properly now that the algorithm helps and then in future it won’t happen / be as bad. (Obviously if it’s not a warranty issue already) Might be worth a shot.
Sorted, thanks @JacoDeJongh !
It’ll be weird not to get 8 “high voltage” notifications on my phone every day 
2 Likes
If you still get some, that second battery worried me a bit. Sometimes the damage is irreversible, I hope in your case its not.
1 Like
Precisely what we recommend. That’s the fastest way. In the past I always recommended cycling, because I (correctly, but also not) figured that balancing can only happen while some charge current is actually flowing. In reality, of course, whenever the balancer fires that bypass/bleeding resistor on the high cell, it burns off a small amount of energy, which causes current to flow. The fastest way to balance, is to hold the BMS in a condition where it constantly fires the bypass resistors (which it will usually do in a interleaved manner).
I have excess solar generation from late morning until early afternoon, which allows the balancer enough time to bring the cells back in balance:
In the graph above you can see that about 90 minutes after the peak the high cell has been bled off and the low cells have caught up. The problem is that after the overnight discharge the imbalance will be back the next day.
I got feedback from Pylontech this morning and they advised that they would authorise a replacement of the battery under warranty. So far they have given me either a new battery or a full refund every time I’ve had issues. Of course I would prefer to not have issues in the first place, but I cannot complain about their product support.
I find this really weird, to be honest. Once cells are top-balanced, they should stay top-balanced. Does anyone have a theory as to why a cell would lose more energy than its neighbours on the way down?
- Give it a week or so of balancing.
- If the big discrepancy is still there after a week of balancing, on discharge, then that cell could be a weaker one, hence the quicker drop, hence the need for replacement.
If a cell was losing more energy than its neighbours then the symptom would surely be one low cell the next day, not one high cell?
I’m also dying to know the underlying reason for this. Every one of the Pylontech batteries I have had to replace so far exhibited this exact same behaviour: One cell shoots out when nearing 100%, the balancer brings it back into balance, and then rinse and repeat the next day. It only gets worse with each cycle, never better.
The best theory I can come up with is that the cell is in a death spiral and that it loses significant capacity every night during the discharge cycle. The next day it cannot absorb the same amount of energy as its neighbours and thus overshoots.
Yes, the reverse of what posted, is also true.
If a cell shoots out during charging and one can identify the exact cell number to see if it is the same cell each time, it then discharges quicker than the rest, then the cell needs replacing. It has a different resistance to the others.
My theory is that this may well be the case. The fact that you manage to bring up that lowest-cell-voltage within a few hours makes me think it is just one cell, not many.
It is completely normal for one cell to jump out. That will always happen. One cell always fills up before the others and then jump out. But over time, you want to see the delta between the highest and lowest cell narrow by the time this jump happens.
Maybe it just needs a bit more time, as TTT says. You’re pretty much resolving the issue every day within 90 minutes. That doesn’t seem like a severe problem.
Edit: Then again, I suppose the reverse is also possible. That you have one high cell that needs the cr*p bled out of it every day, but because all the others are fairly full already, they catch up quickly enough.
If you wanted to spend more time on this… might be interesting to connect BatteryView and check individual voltages around the time this happens.
Exactly this. In all cases so far there’s been one cell (always the same one) that overshoots every day.
I do, that’s how I know the above 
I dug through my previous correspondence with Pylontech and found screenshots of two previous batteries that were returned under warranty:
August 2024:
February 2021:
Same single high cell behaviour as the current battery. Only difference is this time it is cell 10.
After further testing I’ve found Pylontech do not publish on 0x70 or 0x371. The forum and charts I had seen that on seem wrong.
To activate the transmission of min/max cell voltages etc by the battery you have to send both 0x305 and 0x307 from the inverter to the battery.
1 Like
Did you mean 0x370? The first time I saw that, I assumed you meant 370, but seeing it repeated makes me think it is a mistake. Also, 370 and 371 are for the battery/bms name, they allow up to 16 characters combined for a longer name. If you are looking for cell voltages and temperatures, that is on 0x373.
These are not Pylontech specific. They are Victron extensions, which are being picked up by other manufacturers. A Pylontech battery also looks for 0x307, which has the content:
(This was actually an idea proposed by BYD, which got adopted).
If the battery sees that frame, it sends more info than it does without it. So if you are on a non-Victron system, you could try tricking the battery into sending it (assuming Linux and a CAN interface):
cansend can0 '307#1234567856494300'
The 0x70 and 0x371 were from another forum,
and on further examination were probably interpreted from the Seplos protocol.
0x307 can actually be as you say or Byte 0 -7 can be all 0x00 for the Pylontech.
The Pylontech protocol for 0x307 is actually;
Byte 0 to Byte 3 Reserved
Byte 4 to Byte 7 Ascii (Inverter Brand)
0x370 doesn’t feature in the latest Pylontech protocol.
That’s what I have been doing. 
I’ve now incorporated the Victron algorithm in my Teensy setup, not that I’ve had any problems with any cell going over voltage. (Other than once, but that was a firmware issue and the cell hadn’t gone over voltage- the battery was actually discharging at the time!!)
1 Like
0x360, in that table, is charge request. If you send 0xFF in the first byte of that message, then the inverter will charge the battery for as long as you keep sending that message. A battery can use this to request charge if it has been too low for too long, or has suffered SOC drift that it wishes to correct.
Pylontech has something similar on 35C. One of the bits is set if the battery has been below 97% for a whole month, and triggers a full charge.
That was byte0 Bit3 and seems to have been dropped in the latest Pylontech protocol.
They do still have byte0 Bit4 and Bit5 ‘Request Force Charge’, but the description of its use seems slightly different.
That’s not good news. We literally just added support for triggering charging on that… and now they take it out 
This is description for bit 4 and 5.
Bit 4 is supported for years already, so that’s good news at least.
