YamBMS JK-BMS-CAN with new Cut-Off Charging Logic (open-source)

[chaosnature]

thanks anyways for your support MrPablo......

 

[upnorthandpersonal]

Based on @upnorthandpersonal analysis I thought that no derating (at very low temperatures !) was even necessary, since you'd just need an extreme voltage to be able to push that current.

This is correct. At low temperatures, the increased internal resistance will automatically prevent high C rates.

 

[MrPablo]

thanks anyways for your support MrPablo......

Is it now working as expected?

I'm hoping so as the upcoming v1.17.4 has a couple of changes that might be good for you. In particular, the option to select a non-Pylontech battery protocol that is still compatible.

Solis inverters don't seen to respect the requested charge voltage correctly when using the Pylontech protocol. This can result in lower or higher battery voltages than requested.

 

[MrPablo]

Along side, human readable time is now only getting up to about 42 seconds in HA.

You're using v1.17.3 from @Sleeper85's GitHub?

There used to be an issue in older code where the ESP32 would reboot if CANbus comms with the inverter failed, but that was fixed several versions ago.

The last time I saw instability where the ESP32 kept rebooting, it was because the voltage supplied dipped below 5v at points.

 

[chaosnature]

Is it now working as expected?

I'm hoping so as the upcoming v1.17.4 has a couple of changes that might be good for you. In particular, the option to select a non-Pylontech battery protocol.

Solis inverters don't seen to respect the requested charge voltage correctly when using the Pylontech protocol. This can result in lower or higher battery voltages than requested.

Yes it is Perfect at this stage - working as expected

you read my mind on the topic of the Solis protocol - I basically just finished testing User-Define protocol option from the Solis inverter, it worked fine except it did not allow me to change the Overdischarge SOC below 20 .

It was stock on 20, so I have gone back to using the Pylontech protocol - yes i know the values seem very low, but i had to set it low to get more capacity out of my system as at 20% there is still a lot left in the Batteries, so i use the JKBMS to control the Overdischarge SOC instead (keeping it at the operational values set on the Growatt GBLI5001 Datasheet)

 

[ChrisG]

You're using v1.17.3 from @Sleeper85's GitHub?

There used to be an issue in older code where the ESP32 would reboot if CANbus comms with the inverter failed, but that was fixed several versions ago.

The last time I saw instability where the ESP32 kept rebooting, it was because the voltage supplied dipped below 5v at points.

Yes, using Sleeper85 code, cloned from Git. Using the M5stack. I've pulled it off for now, not reliable. The power supply is powering another test I'm doing with a separate ESPDEV kit and MCP2515 with no problem, working fine.

 

[MrPablo]

Yes, using Sleeper85 code, cloned from Git. Using the M5stack. I've pulled it off for now, not reliable. The power supply is powering another test I'm doing with a separate ESPDEV kit and MCP2515 with no problem, working fine.

Yes, I thought it would be a long shot that it was a power issue, as you said it was working for a longer period at first.

When you get a chance, can you provide a view of CAN status over time, alongside ESP32 uptime? I'd like to see if the CANbus is going down before it restarts.

 

[ChrisG]

Yes, I thought it would be a long shot that it was a power issue, as you said it was working for a longer period at first.

When you get a chance, can you provide a view of CAN status over time, alongside ESP32 uptime? I'd like to see if the CANbus is going down before it restarts.

Can't attach .csv unfortunately, but here is the data from this morning before I disconnected it.

 

[MrPablo]

Can't attach .csv unfortunately, but here is the data from this morning before I disconnected it.

View attachment 201573

Do you have CAN status as well?

 

[ChrisG]

Yes, I thought it would be a long shot that it was a power issue, as you said it was working for a longer period at first.

When you get a chance, can you provide a view of CAN status over time, alongside ESP32 uptime? I'd like to see if the CANbus is going down before it restarts.

Sorry, grabbed the wrong item. Let me try a table here. Edit, tech is not cooperating.

 

[MrPablo]

Nothing is jumping out there, perhaps try connecting to the ESP32 and getting live logging at some point, no rush.

 

[NorthTown2022]

It's definitely feasible, do you have any good reference for C-rate vs temp?

EVE LF280K's here:


Have you seen the dbus-serialbattery project at Github? If you scroll down to line 255 in the config you'll see some of their control logics.

 

[NorthTown2022]

This is correct. At low temperatures, the increased internal resistance will automatically prevent high C rates.

Interesting.. I think I remember seeing a video of someone trying to charge one well below zero but I don't remember the outcome.

I didn't realize *that* much derating is required ...

Based on @upnorthandpersonal analysis I thought that no derating (at very low temperatures !) was even necessary, since you'd just need an extreme voltage to be able to push that current.

In my case batteries were sitting at around 10-20 °C this winter and charging up to 100A (280Ah). So *barely* within limits ...

Each battery in my system is sized (breakers, cables, ...) for 100A RMS only. So you could say that the margin is "built in" in my case (unless I try to charge below 0°C, but BMS won't let me do that).

Yup check out your datasheet. Even if low temperature IR will compensate for high C rates I don't think this will hold true at higher temperatures. IMHO temperature compensated dis/charging limitations can't be a bad thing!

 

[SeaGal]

Solis inverters don't seen to respect the requested charge voltage correctly when using the Pylontech protocol. This can result in lower or higher battery voltages than requested.

AFAIAA the "requested" charge voltage actually defines a "max" charge voltage. The actual voltage generated by the Solis will be the voltage required to create the requested charge current, up to the specified "max" voltage. Obviously the voltage that Solis will deliver will depend on the voltage of the battery and the resistance of the wires to deliver the requested charge current.

 

[SeaGal]

Yes it is Perfect at this stage - working as expected

you read my mind on the topic of the Solis protocol - I basically just finished testing User-Define protocol option from the Solis inverter, it worked fine except it did not allow me to change the Overdischarge SOC below 20 .

It was stock on 20, so I have gone back to using the Pylontech protocol - yes i know the values seem very low, but i had to set it low to get more capacity out of my system as at 20% there is still a lot left in the Batteries, so i use the JKBMS to control the Overdischarge SOC instead (keeping it at the operational values set on the Growatt GBLI5001 Datasheet)

View attachment 201519

I think you will find that the OverDischarge SCO % simply cannot be set lower than the ForceCharge SOC %. And likewise, the ForceCharge SOC % cannot be set higher than the OverDischarge SOC %. Hence, the order in which you set them is critical.

 

[chaosnature]

I think you will find that the OverDischarge SCO % simply cannot be set lower than the ForceCharge SOC %. And likewise, the ForceCharge SOC % cannot be set higher than the OverDischarge SOC %. Hence, the order in which you set them is critical.

I know - currently i am telling the system to stop at 5% if it fails to do so and it goes below - charge again from the below 4% value to a 5% Resting SOC. - thats o.k with me.

 

[SeaGal]

Great. Just be aware that once OverDischarge SOC% is reached, the Solis will (obviously) stop using the battery to supply the house load... BUT, about 30W will still be consumed by the Solis to power its internal electronics. Therefore, depending on the size of your battery, the SOC will still drop. Mine will drop about 1% per 3 hours with a 14kWh battery pack.

Therefore, if your ForceCharge SOC % is only one percent lower than the OverDischarge SOC value, you will find that charging from grid will kick in sooner. IMO it is better for the two values to be a bit further apart if you want to avoid grid charging.

 

[chaosnature]

Great. Just be aware that once OverDischarge SOC% is reached, the Solis will (obviously) stop using the battery to supply the house load... BUT, about 30W will still be consumed by the Solis to power its internal electronics. Therefore, depending on the size of your battery, the SOC will still drop. Mine will drop about 1% per 3 hours with a 14kWh battery pack.

Therefore, if your ForceCharge SOC % is only one percent lower than the OverDischarge SOC value, you will find that charging from grid will kick in sooner. IMO it is better for the two values to be a bit further apart if you want to avoid grid charging.

o.k...i get your point thanks

 

[MrPablo]

AFAIAA the "requested" charge voltage actually defines a "max" charge voltage. The actual voltage generated by the Solis will be the voltage required to create the requested charge current, up to the specified "max" voltage. Obviously the voltage that Solis will deliver will depend on the voltage of the battery and the resistance of the wires to deliver the requested charge current.

That's what I expected the inverter to do, but my results didn't always match.

If I set the requested voltage to 58.7v (I run a 17s pack) and the pack was being fully charged (off-peak overnight, etc), then the Solis would supply up to 60.2v (inverter DC voltage via modbus), giving 59.5v at the BMS.

Other times, it would settle at 58.7v at the inverter, so 58.3v at the battery. I calibrated the BMS, but I can't see a way to calibrate the Solis.

As soon as I changed to the SMA protocol with SMA battery name, using AoBo on the inverter... it behaves itself.
The inverter will supply the required voltage to get the battery to 58.7v at the BMS. Overshoots have been reduced to 0.1v at most.

It's a guess, but I think Solis + Pylontech profile results in the inverter referencing internal DC voltage vs requested voltage.
On SMA / AoBo at least, it seems to reference BMS voltage vs requested voltage.
I've seen the same behaviour on a couple of other Solis inverters - perhaps that's part of the reason for Pylontech OV warnings when using a Solis.

 

[SeaGal]

That's what I expected the inverter to do, but my results didn't always match.

If I set the requested voltage to 58.7v (I run a 17s pack) and the pack was being fully charged (off-peak overnight, etc), then the Solis would supply up to 60.2v (inverter DC voltage via modbus), giving 59.5v at the BMS.

Other times, it would settle at 58.7v at the inverter, so 58.3v at the battery. I calibrated the BMS, but I can't see a way to calibrate the Solis.

As soon as I changed to the SMA protocol with SMA battery name, using AoBo on the inverter... it behaves itself.
The inverter will supply the required voltage to get the battery to 58.7v at the BMS. Overshoots have been reduced to 0.1v at most.

It's a guess, but I think Solis + Pylontech profile results in the inverter referencing internal DC voltage vs requested voltage.
On SMA / AoBo at least, it seems to reference BMS voltage vs requested voltage.
I've seen the same behaviour on a couple of other Solis inverters - perhaps that's part of the reason for Pylontech OV warnings when using a Solis.

That's all very interesting, thanks. Was thinking about a 17s implementation, but my Solis specify DC range of only up to 58V.

Interesting about the differences with the PylonLV profile. I use the user-defined profile, which responds to standard SMA CANBus comms OK. Then there is clearly something odd with the Solis implementation of Pylontech protocol.

 

[silverstone]

@Der_Hannes, @Sleeper85 : do your code also handle the transition from / to CC (Constant Current) and CV (constant voltage)? Right now I have a charger connected in parallel to the battery and to charge at full speed (force it into CC) I have to set the "reference voltage" to 58V or so (then it will work in constant current mode). Of course I'll habe to reduce that as I near the float voltage and the absorbtion voltage especially.

But is this something your code does or is it something that the inverter or my charger controller has to do?

 

[MrPablo]

That's all very interesting, thanks. Was thinking about a 17s implementation, but my Solis specify DC range of only up to 58V.

Interesting about the differences with the PylonLV profile. I use the user-defined profile, which responds to standard SMA CANBus comms OK. Then there is clearly something odd with the Solis implementation of Pylontech protocol.

17s is definitely feasible on the RHI and EH1 inverters. Max charge voltage can be set to 60v, inverter overvoltage protection is 62v max.
I run 17 cells at 3.45v, so well away from the overvoltage danger zone.

 

[silverstone]

@Der_Hannes, @Sleeper85 : do your code also handle the transition from / to CC (Constant Current) and CV (constant voltage)? Right now I have a charger connected in parallel to the battery and to charge at full speed (force it into CC) I have to set the "reference voltage" to 58V or so (then it will work in constant current mode). Of course I'll habe to reduce that as I near the float voltage and the absorbtion voltage especially.

But is this something your code does or is it something that the inverter or my charger controller has to do?

Just for reference... Right now I am facing this issue on my temporary cabling setup.

For instance 16mm2, 10m each way (20m loop) yields approximatively 20mOhm wire resistance. 2 such set of wires in parallel and 2 chargers. So basically 10mOhm overall.

Actually a bit more due to fuses breakers, etc.

So at 100A it takes approx 1V to compensate that.

Put another way: if I don't put at least 1V more that needed on the reference voltage, the charger doesn't deliver the full current and operates instead (from its point of view) in constant voltage mode.

 

[MrPablo]

Just for reference... Right now I am facing this issue on my temporary cabling setup.

For instance 16mm2, 10m each way (20m loop) yields approximatively 20mOhm wire resistance. 2 such set of wires in parallel and 2 chargers. So basically 10mOhm overall.

Actually a bit more due to fuses breakers, etc.

So at 100A it takes approx 1V to compensate that.

Put another way: if I don't put at least 1V more that needed on the reference voltage, the charger doesn't deliver the full current and operates instead (from its point of view) in constant voltage mode.

The inverter will be responsible for transitioning from CC to CV, the code will continue to request charge voltage until it meets the conditions for float.

16mm² seems small for 100A, I use 25mm² for my setup and in hindsight, should have gone to 35mm².

 

[silverstone]

The inverter will be responsible for transitioning from CC to CV, the code will continue to request charge voltage until it meets the conditions for float.

16mm² seems small for 100A, I use 25mm² for my setup and in hindsight, should have gone to 35mm².

As I said it's temporary. 2x16 mm2 on each polarity. Or otherwise said each charger 50A on a 16mm2 wire. Plenty.

Internal to the batteries it's hugely oversized. 50mm2. Next time I'll go with 35mm2 for 100A...

So I should I simply set charge voltage to 58V and then let it drop once approaching OVP?