diy solar

diy solar

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

View attachment 197079

Then why can't we have the above??

Just a simplified thought - don't bite me :)

# Question is mainly to the developers who already know some Maths to this

# and to any other technical-minded person out there on these kind of projects

Note: this is a High-Level Design.
in more detail, the Batt 2 wires actually connect to the Batt 1 before the BMS terminals....
I would install a breaker switch between them.
 
@
View attachment 197079

Then why can't we have the above??

Just a simplified thought - don't bite me :)

# Question is mainly to the developers who already know some Maths to this

# and to any other technical-minded person out there on these kind of projects

Note: this is a High-Level Design.
in more detail, the Batt 2 wires actually connect to the Batt 1 before the BMS terminals....
I would install a breaker switch between them.
@

Sleeper85


You haven't commented on this.

Would it work to have Battery -1 Passived balance itself after both batteries have received balancing from the JK modules ?#

Or would it be best to use all 24s between the 2 batteries and disable the remaining 4s or enable the remaining 4s and let them passive balance with the whole lot in the Battery -2 setup?


regards
 
On the back of that, do you have a link to the yaml script i can compile for a x 2 battery setup and the diagram to show me how RS go to RS and CAN goes to Inverter>?

I see someone has done it here , but i wanted to stick to your project:





regards
 
On the back of that, do you have a link to the yaml script i can compile for a x 2 battery setup and the diagram to show me how RS go to RS and CAN goes to Inverter>?

I see someone has done it here , but i wanted to stick to your project:





regards
@chaosnature, I don't believe there's a YAML that is set up and fully tested for a multi BMS environment.

It's on a list of potential enhancements, but please don't expect anything soon. @Sleeper85 is about to head on a long holiday, plus there's several features which are likely to be higher priority first.
 
@ MrPablo

I have a question

I currently have succeeded in configuring one of my JK2A24S15P model to communicate with my solis inverter after the rs to CAN conversion that you guys helped me out with

if i purchase the Model with CAN / RS485 below - Do you think i could get my current JKBMS to talk to this -HC version and then have the -HC new version talk to my Solis inverter?


1708649321401.png
 
View attachment 197079

Then why can't we have the above??

Just a simplified thought - don't bite me :)

# Question is mainly to the developers who already know some Maths to this

# and to any other technical-minded person out there on these kind of projects

Note: this is a High-Level Design.
in more detail, the Batt 2 wires actually connect to the Batt 1 before the BMS terminals....
I would install a breaker switch between them.
Just completed the trial of this concept and it seems to be working

Slave
1709256665529.png

Master
1709256698785.png
 
A very big thanks especially to Sleeper85 and also any other involved person!

On the Base of the newest Version 1.17.3, i adapted some personal things for me.
The most important things:
- Multiple BMSs are implemented and a Shunt can be also added via MQTT (in my case Victron SmartShunt).
- Shunt can override BMS states (like SOC, current, power and voltage)
- Only the CAN Communication in handled by this ESP - all other devices have own ESPs and communicate over MQTT
- As i´m running IObroker, everything is modifed to work via MQTT (HA not tested, but i left most HA-relevant code commented)

It works fine since 2 days now, but to be clear, the big downside is: It always needs to be connected to the MQTT broker and cant work standalone!
From a hardware perspective, maybe one JK-BMS could be implemented via BLE and/or a VictronShunt via UART (but additional JKs must be added over mqtt due to low SRAM)

If anyone is interested, i could share on github after cleaning everything up - please let me know
 
A very big thanks especially to Sleeper85 and also any other involved person!

On the Base of the newest Version 1.17.3, i adapted some personal things for me.
The most important things:
- Multiple BMSs are implemented and a Shunt can be also added via MQTT (in my case Victron SmartShunt).
- Shunt can override BMS states (like SOC, current, power and voltage)
- Only the CAN Communication in handled by this ESP - all other devices have own ESPs and communicate over MQTT
- As i´m running IObroker, everything is modifed to work via MQTT (HA not tested, but i left most HA-relevant code commented)

It works fine since 2 days now, but to be clear, the big downside is: It always needs to be connected to the MQTT broker and cant work standalone!
From a hardware perspective, maybe one JK-BMS could be implemented via BLE and/or a VictronShunt via UART (but additional JKs must be added over mqtt due to low SRAM)

If anyone is interested, i could share on github after cleaning everything up - please let me know
Hi @Der_Hannes, great to hear you've added quite a few features!
I'd definitely be interested to see your work, please feel free to post a link to your GitHub. As it relates to the open source project led by @Sleeper85, it probably makes sense to post it on the dedicated thread here if possible.

I only use MQTT for non-critical things, but I'm definitely interested in seeing how you handle overriding BMS values, etc.
 
A very big thanks especially to Sleeper85 and also any other involved person!

On the Base of the newest Version 1.17.3, i adapted some personal things for me.
The most important things:
- Multiple BMSs are implemented and a Shunt can be also added via MQTT (in my case Victron SmartShunt).
- Shunt can override BMS states (like SOC, current, power and voltage)
- Only the CAN Communication in handled by this ESP - all other devices have own ESPs and communicate over MQTT
- As i´m running IObroker, everything is modifed to work via MQTT (HA not tested, but i left most HA-relevant code commented)

It works fine since 2 days now, but to be clear, the big downside is: It always needs to be connected to the MQTT broker and cant work standalone!
From a hardware perspective, maybe one JK-BMS could be implemented via BLE and/or a VictronShunt via UART (but additional JKs must be added over mqtt due to low SRAM)

If anyone is interested, i could share on github after cleaning everything up - please let me know
I am interested - but hoping I can comment the MQTT part out as Like MrPalo stated I don't really think I can rely on MQTT running for my batteries to be charging and discharging....however, the multiple aspects of your modification are a welcome addition as I have just yesterday completed a parallel setup and though its functions well...charging and discharging, I am trying to get both batteries leveled up and maybe your edit might solve this?

1709306181928.png
 
Last edited:
Hi @Der_Hannes, great to hear you've added quite a few features!
I'd definitely be interested to see your work, please feel free to post a link to your GitHub. As it relates to the open source project led by @Sleeper85, it probably makes sense to post it on the dedicated thread here if possible.

I only use MQTT for non-critical things, but I'm definitely interested in seeing how you handle overriding BMS values, etc.

I agree about using a single ESP32 to centralize information and communicate with the inverter on the CAN bus but using MQTT via WiFi is not a reliable solution for linking to BMS.

@Der_Hannes if you wish you can work with us to improve this project ;)
 
So .. as it stands the both JK.s discharges almost at the same rate, not really sure if there is much to add to the current code as the CVL DVL CCL DCL and SOC of the Slave setup will be controlled by the JKBMS parameters set on the slave setup

1709320827049.png

All i did was made sure both parameters were set almost equally...

the idea is when Slave gets to 15% SOC set on the JK firmware it should stop discharging
When Master gets to 15 % it should also stop discharging.

I am waiting to see what the battery cells on slave translate to be 15% then i can tweak if necessary.....
 
Here is my fork - i´m new to esphome github and programming in general, so any tips are appreciated

I also agree to that, but could not find any other option to communicate from esp to esp (other than UART or CAN - which are both to heavy for me) so that was my only option.
Maybe the esp32 would be capable of handlich the shunt and one BMS via BLE with reduced sensor data. Any additional would be non-critical addon over mqtt

Happy to collaborate
 
I use a Pi to connect to a SMA Sunny Island and reads SMAnet data via rs485 to an MQTT Server on the same Pi, I then feed the MQTT data to a modbus TCP server on the same Pi. This modbus server is read by a modbus client via cat 5 wired ethernet, the data runs 24 hrs a day and there are 20 sec gaps in data feed 3 or 4 times a day. Have tried WiFi but there were a lot more gaps so ethernet is the way to go.
 
I gat to say this.

This is a Beautiful project...I mean we are taking this to a different level better than out-of-the-box manufactural specifications for the professionally released components :)

The functionality available to us are becoming way more advanced than the original product itself.

You guys are amazing.....
 
I was just thinking about, if its possible to use an ESP for collecting the BMS data and then polling the raw serial data to the master esp over UART - which then processes anything without the BLE-overhead

Maybe it would´t be that hard to program and we stay close to the standard JK-Repo from syssi

what are your thoughts about that? Any other ideas?
 
I was just thinking about, if its possible to use an ESP for collecting the BMS data and then polling the raw serial data to the master esp over UART - which then processes anything without the BLE-overhead

Maybe it would´t be that hard to program and we stay close to the standard JK-Repo from syssi

what are your thoughts about that? Any other ideas?

What I can tell you is that an ESP32 can have max 3 UART connections. So it would be possible to collect information from 2 or 3 BMS via UART and send the necessary information via CAN bus (or other protocol) to a master ESP32 which would be connected to the inverter.

An ESP32 can also monitor several BMS via Bluetooth. But I think it becomes unstable to monitor more than 3 BMS.

Syssi offers examples of multi-device YAML.
 
What I can tell you is that an ESP32 can have max 3 UART connections. So it would be possible to collect information from 2 or 3 BMS via UART and send the necessary information via CAN bus (or other protocol) to a master ESP32 which would be connected to the inverter.

An ESP32 can also monitor several BMS via Bluetooth. But I think it becomes unstable to monitor more than 3 BMS.

Syssi offers examples of multi-device YAML.

thx for your reply,
already played the multi bms BLE configuration from syssi for a couple of days, but i can only get 2 BMSs kinda stable on one esp32 - and only with reduced sensor data.
Maybe it depends on differen hard- and software Versions (and differen BLE Protocols) on my 3 BMSs, but it was not stable...So i gave up on this.

But maybe it would be an option to use one ESP32 per BLE BMS and connect these 3 over UART to the Master (or maybe cascading for more than 3 BMSs).

there must be an reliable way to get this done
 
What I can tell you is that an ESP32 can have max 3 UART connections. So it would be possible to collect information from 2 or 3 BMS via UART and send the necessary information via CAN bus (or other protocol) to a master ESP32 which would be connected to the inverter.

An ESP32 can also monitor several BMS via Bluetooth. But I think it becomes unstable to monitor more than 3 BMS.

Syssi offers examples of multi-device YAML.
Syssi offers examples of multi-device YAML

yes I was just about to ask if this worked .... but Mr. Der answered my question
I didn't think it was sing one esp to do the master-slave thing, interesting to know this is the case.

Yes this is what I have suggested to sleeper85 who had said it's the next project after another project he is working on right now

@Sleeper85
Are you sure you will not end up prioritizing this as demands grow and probably a less piece of work to tackle? :unsure:;)

Regards
 
Back
Top