diy solar

diy solar

JK BMS CAN bus comms now possible for inverters that support Goodwe and Pylontech batteries

If you installed esphome on your computer, I had some PATH weirdness I had to fix on my MAC even though I had esphome path correct, just follow the steps @Sleeper85 has in the readme. Clone down his repo, modify for your use, test the config, run to flash the device.
Where is the readme file ?
 
@Sleeper85 how do you access the webserver when this line is uncommented?
#web_server:
# port: 80
# log: false
# ota: false

What will the webserver display?
 
@Sleeper85 how do you access the webserver when this line is uncommented?
#web_server:
# port: 80
# log: false
# ota: false

What will the webserver display?
If you look in the readme it will show you what it looks like, similar to HA. You access it by the IP address of the device over port 80.
 
Thanks @ChrisG

Indeed, I spent a lot of time explaining everything in detail in the readme.
Thank you for taking the time to read it ;)

I just updated the installation procedure hoping it will be even clearer for beginners.

1705864104399.png
 
Thank you @Sleeper85 for the continued support.
Did anyone try an ESP8266? I have a bunch of those lying around that I need to use up. Or I can use the one already connected to the inverter doing the "pipsolar" home assistant integration.
On another note, my inverter is MPP Solar 6048MT (Victron) I suppose I would need to use can_protocol 4?
 
Thank you @Sleeper85 for the continued support.
Did anyone try an ESP8266? I have a bunch of those lying around that I need to use up.
Unfortunately the majority of this code is intended for the ESP32, especially the CAN bus part. It is possible to make the UART connection to JK-BMS with an esp8266 (see the sissy Github) but for the CAN bus part you would have to use other extension cards. That said, the code is open-source, you can always try to adapt it.
 
Last edited:
@Sleeper85 the best way to implement alarm is to set the figures in the yaml file a little lower than actual alarm figures in the bms rather than using values from the bms.
This is because before the inverter reacts, the bms would have acted first.
Otherwise, there's no point implementing alarm other than just reporting it in the corresponding CAN IDs
 
@eumobong
Yes it's true, I already thought about it. This would be a major change in the YAML and could act as a double alarm system and therefore double security. For the moment, I'm not making any big changes to the code because I'm preparing for a long 4-month trip. I'm putting this on my todo list.
 
There is a major infuriating bug :

What I managed to understand is this;

If the battery is sufficiently discharged , and while charging (say, 25 Amps @ 54 V) a load comes on that drops the amperes and thus voltage down in the float range (53.6 V), and the ESP somehow reboots in between,
The charging logic gets stuck at float. Which means charging is now happening at (12 Amps @ 53.6 V) and solar is being wasted.
The way around for me was to force bulk or disable float, both flags don't survive ESP reboots.

And I assume this is happening because Voltage comparison is being done in the code while current comparison isn't.

Screenshot showing web_interface indicating FLOAT status at [14:00]
and BMS reading showing charging after I forced bulk [14:02]
Screenshot_20240127-140022.pngScreenshot_20240127-140221.png
 
Indeed, the choice between bulk and float is made on the basis of the voltage.
Perhaps it could be done based on other parameters such as the soc but it is not always reliable.

Regarding the reboot, if this happens every day then it is not normal.
You need to monitor the ESP32 uptime and find the cause of the reboots.
 
Last edited:
There is a major infuriating bug :

What I managed to understand is this;

If the battery is sufficiently discharged , and while charging (say, 25 Amps @ 54 V) a load comes on that drops the amperes and thus voltage down in the float range (53.6 V), and the ESP somehow reboots in between,
The charging logic gets stuck at float. Which means charging is now happening at (12 Amps @ 53.6 V) and solar is being wasted.
The way around for me was to force bulk or disable float, both flags don't survive ESP reboots.

And I assume this is happening because Voltage comparison is being done in the code while current comparison isn't.

Screenshot showing web_interface indicating FLOAT status at [14:00]
and BMS reading showing charging after I forced bulk [14:02]
View attachment 191787View attachment 191788
I experienced this too. I thought it was my inverter that was causing it. I edited the original code from @uksa007 and never experienced it again. My repo has the correction to Uksa007 code but not that of sleeper85. You can look through it and edit your charging logic in like manner.

Mine maintain the charging state and additionally, exit absorbtion and re-enter bulk, if voltage sags too much within absorbtion.
 
Indeed, the choice between bulk and float is made on the basis of the voltage. Perhaps it could be done based on other parameters such as the soc but it is not always correct.

Regarding the reboot, if this happens every day then it is not normal. You need to monitor the ESP32 uptime and find the cause of the reboots.
The bug happens if there's a restart for any reason and the voltage falls within the bracket for float. Restart can happen for many reasons: If wifi can't connect for more than for 15min, or memory is lacking etc. Putting timeout in wifi sections helps but that's not all that can happen. It's best to address restart in each of the if else logic of charging.

Monitor startup in each of the conditions in the charging logic. That's what I did in my case.
 
My ESP32 is super stable and I don't observe a reboot.
That said, I agree to improve the charge logic to make it better.

Currently the logic is still that of uksa007 : Bulk V. 55.2 - Rebulk offset 2.5 = 52.7V

Bat. Voltage <= 52.7 = Bulk Charge + Absorption
Bat. Voltage > 52.7 = Wait or Float (if the FLoat switch is activated)

You can of course change the value of rebulk_offset if you want different behavior.

Do you think it would be a better idea to base this logic on the SoC?
 
The way around for me was to force bulk or disable float, both flags don't survive ESP reboots.

If you disable Float, if your ESP reboots and the battery voltage is greater than Bulk V. - Rebulk_Offset then the Charge status will be Wait and there will be no charge at all.

As I just said, I'm open to programming better logic and at the same time I think that an ESP that restarts every day is a problem that needs to be corrected because it is not normal.

JK-BMS-CAN_Charging_Logic_Diagram.png
 
I have two ESPs. The one that was connected kept rebooting multiple times in a row before stabilizing. I have yet to figure out what keeps causing it.

But at the same time, the BMS already has information about current going into the battery.
Im guessing it to be a
Code:
if (voltage == float_voltage) && (bat_current <= some threshold)

Type of correction
 
Back
Top