CAN interface - is there a standard rule set that allows two CAN devices to cooperate?

[IslandBill]

For example, the 6000XP says it supports CAN. The BMS in a DIY battery like the SEPLOS or EEL support CAN. Does that mean hooking a cable between these ports results in them both knowing what each is requesting/sending and results in mutual cooperation to support the battery pack?

 

[hwy17]

No, it's not an assurance. The canbus protocol means they can probably figure out how to send messages to each other, but they need to agree on how to write them and how to read them.

I don't know if there's a most common standard for that. RS485 with a variety of originally proprietary message formats is more popular in DIY solar. Pylontech messaging being probably the most common.

 

[IslandBill]

No, it's not an assurance.

That's what I figured. I was hoping it's like BlueTooth where every device identifies itself and there's a known set of requests and replies to make the two ends of the communications cooperate.

With the popularity of the 6000XP and the JK BMS used in the SEPLOS, EEL and other units, they may mind meld and come up with a solution. I'll do more digging on CAN and RS485 to get a better understanding.

Thanks for the reply.

 

[shvm]

For example, the 6000XP says it supports CAN. The BMS in a DIY battery like the SEPLOS or EEL support CAN. Does that mean hooking a cable between these ports results in them both knowing what each is requesting/sending and results in mutual cooperation to support the battery pack?

For any non-recent JK-BMS, the CAN protocol they 'speak' won't be understood by the 6000XP.
Fortunately, the problem is relatively easy to fix!
Just use a MCU like ESP-32 in-between to do the 'translation'.

It will cost you like ~$15 in parts and maybe an hour or two of your time.

 

[kommando]

SMA wrote the first Canbus Protocol, Pylontech took the SMA one and simplified it and this became the most popular Protocol as it was copied by other Chinese battery makers. So Deye and Goodwe are very close to Pylontech.

The latest JK PB BMS supports amongst others

SMA, Pylontech LV (low voltage), Goodwe and Deye. Pylontech Plus is very close to SMA.

 

[IslandBill]

Just use a MCU like ESP-32 in-between to do the 'translation'.

I'm a software developer by profession and have experience with the esp32.

Can you provide some additional information that would allow me to further investigate that route?

 

[IslandBill]

The latest JK PB BMS supports amongst others

Does that mean the latest iteration of the JK BMS is compatible with the 6000xp out of the box?

 

[kommando]

Does that mean the latest iteration of the JK BMS is compatible with the 6000xp out of the box?

You have to find the info on the 6000xp protocol or protocols available if they have more than one and if they match. I don't have one so can't answer.

 

[wpns]

For example, the 6000XP says it supports CAN. The BMS in a DIY battery like the SEPLOS or EEL support CAN. Does that mean hooking a cable between these ports results in them both knowing what each is requesting/sending and results in mutual cooperation to support the battery pack?

CAN says they can communicate. The protocol (language) they speak also has to be compatible. Oh, you are a sofware developer, you know this stuff. CAN goes up to Layer 4 in the OSI stack

 

[IslandBill]

CAN says they can communicate. The protocol (language) they speak also has to be compatible. Oh, you are a sofware developer, you know this stuff. CAN goes up to Layer 4 in the OSI stack

I didn't want to use the term 'API set' or anything too software technical since this isn't a software forum. The documentation for the 6000XP I've downloaded doesn't mention anything about the details of the communications capabilities.

I'm not inclined to purchase a 100ah box of old technology at a jacked up price from anyone. I want the latest 300+ah cells in one box for starters and possibly another one for more 'autonomy time' later.

 

[shvm]

I'm a software developer by profession and have experience with the esp32.

Then you're in for a treat. Join us.

Can you provide some additional information that would allow me to further investigate that route?

Link to the repo containing instructions and code:

GitHub - Sleeper85/esphome-jk-bms-can

Contribute to Sleeper85/esphome-jk-bms-can development by creating an account on GitHub.

github.com

Forum thread discussing the same

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

ESPHome component to monitor a Jikong Battery Management System (JK-BMS) and communicate with inverters supporting CAN bus protocol compatible with Pylontech, GoodWe, Seplos, SMA or Victron. The project on GitHub Changelog Current version: 1.17.5 It's with pleasure that I announce the new...

diysolarforum.com

 

[IslandBill]

Then you're in for a treat. Join us.

Link to the repo containing instructions and code:

GitHub - Sleeper85/esphome-jk-bms-can

Contribute to Sleeper85/esphome-jk-bms-can development by creating an account on GitHub.

github.com

Forum thread discussing the same

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

ESPHome component to monitor a Jikong Battery Management System (JK-BMS) and communicate with inverters supporting CAN bus protocol compatible with Pylontech, GoodWe, Seplos, SMA or Victron. The project on GitHub Changelog Current version: 1.17.5 It's with pleasure that I announce the new...

diysolarforum.com

Thanks - I'll check it out.

 

[marionw]

CAN. RS485, RS232 and RS232-TTL are all "Hardware interface" protocols. Each is implemented using different hardware circuitry (i.e. IC chips) and specify how data (doesn't matter what data) is transmitted or received across the connecting cable between endpoints. CAN and RS485 are "bus" type hardware protocols that allow multiple devices to exist on the same "wire".

The hardware part is standard, the "Software protocols" (i.e. Pylontech, Growatt, PACE, Seplos etc) that determine the format for the data being sent or received is not standard and varies from manufacturer to manufacturer or the manufacturer has provisions for selecting one of several "Software protocols" when setting up communications.

For example, the Modbus RTU used by many inverters generally takes on the format of "slave address" + "function" (read or write) + "register address" + "number of registers to read". There are no standards for what register address holds what value. SRNE used register 0x100 for Battery SOC. Other manufacturers may have this value at another register address.

Many implement their protocol as HexAssci format over an RS485 "hardware interface" which is formatted as:
SOI start of information
VER protocol version
ADR device address
CID1 device type
CID2 command/command information
LENGTH length of INFO data
DATA normally data which is being "set" in the device
CHKSUM
EOI End of information.

In particular these values vary between various protocols. i.e. Pylontech, Growatt, PACE, Seplos etc.
The SOI can be wildly different between protocols
The VER can be wildly different between manufacturers
The CID1 can be wildly different between manufacturers
There tends to be some commonality with CID2 but they also include different ones defined by each manufacturer
The response formats also vary by protocol.
This is why the "software protocol" has to be the same for both ends of the communication

 

[IslandBill]

CAN. RS485, RS232 and RS232-TTL are all "Hardware interface" protocols. Each is implemented using different hardware circuitry (i.e. IC chips) and specify how data (doesn't matter what data) is transmitted or received across the connecting cable between endpoints. CAN and RS485 are "bus" type hardware protocols that allow multiple devices to exist on the same "wire".
...

I have no solar equipment at present, so have very little insight into how things work. I'm planning a test system to run a small A/C (9000 BTU) and some lights in my warehouse office using the EG4 6000 XP and a DIY battery using 300+ ah cells. The A/C is an inverter type so it starts once and runs at varying speeds as needed; one startup motor load and then continuous running for months.

The latest JK inverter BMS looks promising and may already support the 6000 XP. I'll find out.

 

[zanydroid]

The GitHub’s are a good starting point, as is reading up on ESP development (both flavors? Dunno if 32 or 8266 are a better bet to get into if you want to modify).

Beyond that this is industrial controls/PLC/embedded programming territory. Think “1980s” design lineage. 20+ years before standard device classes in consumer products.

You can search manual or forums for the protocols that a given inverter supports. Or look at YT videos where they scroll the settings. For instance Dexter’s MidNite One video from few days back scrolled through all comms options on that inverter

Note also that the pinouts need to be validated before connecting.

 

[IslandBill]

I've got an ESP32 project on a breadboard now. It's a filament heater for 3D printing with the options I want, plus graphical reporting to tell me how things are going.

ESP32 is the more modern platform with more of almost everything the 8266 has.

Can you be more specific about the Dexter video. Searching on YT brings up too much junk. Thanks.

 

[zanydroid]

I've got an ESP32 project on a breadboard now. It's a filament heater for 3D printing with the options I want, plus graphical reporting to tell me how things are going.

ESP32 is the more modern platform with more of almost everything the 8266 has.

Makes sense. I have a stock of 8266 from when I was doing a lot of ESPhome. I think it boils down to whatever the stack or project picked in the past. If something works already on 8266 there is no reason for it to be proactively ported to ESP32

Can you be more specific about the Dexter video. Searching on YT brings up too much junk. Thanks.

Here it is.

Post in thread 'Midnite Solar Announced their new 10kw AIO at Intersolar Today'
https://diysolarforum.com/threads/m...kw-aio-at-intersolar-today.76840/post-1118590