Need help / info about CAN protocol from HV battery systems which communicate with Deye HV inverters.

[RichardRSB]

EDIT / UPDATE: As per May-29, i managed to get this working. Thanks for everyone who looked into this.

I am building an hybrid off-grid system with a Deye (Sol-Ark / Sunsink) and a Tesla model 3 battery connected with an OrionBMS2.
The system runs. Like a baby. But i can't get the OrionBMS2 communicating with the Deye.
The OrionBMS2 has a fully customizable CAN protocol. Everything is configurable.

The inverter is an Deye hybrid HV system model SUN-20K-SG01HP3-EU-AM2.
Those SG01HP3 series are quite new, and getting more and more popular due to the availability
of used EV HV batteries.
Since it is a HV system, it uses quite a different set of CAN Id’s compared with the
Low Voltage systems. Also the broadcast Id is different.

I found a document describing the CAN-Id’s. I tried this approach, but i can’t get it to connect.
Now i am fairly new to CAN. I do not fully understand the protocol, and despite of learning and reading tons
of documents i am not able to get it to work.

What i know:
The Deye inverters are “self-adopting” to battery systems, hence there is no setting in the inverter other than
enable, or disable. They approved a series of batteries, and PYLON is one of them. I am not sure how they recognize
the batteries, but i guess they look at the manufacturer name at CAN-Id 0x42F0. Here is the list the Deye handles without problems:

On CAN 00:
Deye BOS-G Series/GB-L Series
Dyness HV Series/TOWER Series/Orion Series
UZ UZ-PLH/UZ-PSE
Shoto SDA10-48100
PYLON Powercube Series/Force H Series
Greenrich HV IS001
On CAN 01:
BYD HVS Series/HVM Series

So i need to emulate one of those batteries in the OrionBMS.

Above batteries have a common dataset talking to the Deye. I have the Deye datasheet, but i can't get it running.
What am i doing wrong?
Is there anyone who knows the CAN data from one of the batteries in the above list?

I asked BYD and Pylon for the CAN HV protocol data. No positive response.
Also i asked Deye about this. My request needs to be approved. (sigh).
I’ve got a general document which i think Deye uses, but i can’t get it working. The inverter
does not recognize the data, maybe due to the fact i don't know if i implemented it correctly, and
how to insert the manufacturer name (e.g. PYLON) into the CAN data on the OrionBMS2.

I hope someone with a detailed knowledge of CAN can tell me how to format the CAN data send to the inverter.
I am capable of basic understanding if this stuff. I get confused in bit and byte orders, and got stuck on adding
ASCII data at CAN-Id 0x42F0. Also i don’t know if it is required to insert all the Id’s, or if you can safely leave out
unused / meaningless fields.

I only want the cell broadcast, SoC, SoH, Voltage, Temperature, Power and Current.

Attached the CAN data which Deye uses (listen to). The protocol is also used by Sermatec. I do have the Deye version also, but this Sermatec document is more readable and the register Id list is exactly the same.

 

[Ampster]

If you are using an Orion Jr2 there is an option in the CAN configuration tab to use a Victon out put. I have an Orion BMS Jr2 communicating with my SolArk. I am not sure the regular Orion BMS has that capability because it was designed for EV applications. The Jr2 is for 48 volt stationary batteries typically used in hybrid inverters. There may be a protocol that works if indeed you have the regular BMS2.

 

[RichardRSB]

If you are using an Orion Jr2 there is an option in the CAN configuration tab to use a Victon out put. I have an Orion BMS Jr2 communicating with my SolArk. I am not sure the regular Orion BMS has that capability because it was designed for EV applications. The Jr2 is for 48 volt stationary batteries typically used in hybrid inverters. There may be a protocol that works if indeed you have the regular BMS2.

The Id-set in the Victron / Pylon dataset is for LV batteries. The HV batteries are using a complete other Id dataset.

 

[Ampster]

The HV batteries are using a complete other Id dataset.

I did not see that you were using a Model 3 pack. I see that now and that would be why you are using the regular Orion BMS2.

 

[Ampster]

I did just get the following from SolArk support about the CANBUS protocol. I don't know if it will work for the DEYE but passing it along in case it does.

 

[RichardRSB]

I did just get the following from SolArk support about the CANBUS protocol. I don't know if it will work for the DEYE but passing it along in case it does.

Thanks for posting. This is indeed the protocol from Deye / Sol-Ark, but only for the LV inverters. The HV series uses a different set of Id's

 

[ProPV]

I am building an hybrid off-grid system with a Deye (Sol-Ark / Sunsink) and a Tesla model 3 battery connected with an OrionBMS2.
The system runs. Like a baby. But i can't get the OrionBMS2 communicating with the Deye.
The OrionBMS2 has a fully customizable CAN protocol. Everything is configurable.

The inverter is an Deye hybrid HV system model SUN-20K-SG01HP3-EU-AM2.
Those SG01HP3 series are quite new, and getting more and more popular due to the availability
of used EV HV batteries.
Since it is a HV system, it uses quite a different set of CAN Id’s compared with the
Low Voltage systems. Also the broadcast Id is different.

I found a document describing the CAN-Id’s. I tried this approach, but i can’t get it to connect.
Now i am fairly new to CAN. I do not fully understand the protocol, and despite of learning and reading tons
of documents i am not able to get it to work.

What i know:
The Deye inverters are “self-adopting” to battery systems, hence there is no setting in the inverter other than
enable, or disable. They approved a series of batteries, and PYLON is one of them. I am not sure how they recognize
the batteries, but i guess they look at the manufacturer name at CAN-Id 0x42F0. Here is the list the Deye handles without problems:

On CAN 00:
Deye BOS-G Series/GB-L Series
Dyness HV Series/TOWER Series/Orion Series
UZ UZ-PLH/UZ-PSE
Shoto SDA10-48100
PYLON Powercube Series/Force H Series
Greenrich HV IS001
On CAN 01:
BYD HVS Series/HVM Series

So i need to emulate one of those batteries in the OrionBMS.

Above batteries have a common dataset talking to the Deye. I have the Deye datasheet, but i can't get it running.
What am i doing wrong?
Is there anyone who knows the CAN data from one of the batteries in the above list?

I asked BYD and Pylon for the CAN HV protocol data. No positive response.
Also i asked Deye about this. My request needs to be approved. (sigh).
I’ve got a general document which i think Deye uses, but i can’t get it working. The inverter
does not recognize the data, maybe due to the fact i don't know if i implemented it correctly, and
how to insert the manufacturer name (e.g. PYLON) into the CAN data on the OrionBMS2.

I hope someone with a detailed knowledge of CAN can tell me how to format the CAN data send to the inverter.
I am capable of basic understanding if this stuff. I get confused in bit and byte orders, and got stuck on adding
ASCII data at CAN-Id 0x42F0. Also i don’t know if it is required to insert all the Id’s, or if you can safely leave out
unused / meaningless fields.

I only want the cell broadcast, SoC, SoH, Voltage, Temperature, Power and Current.

Attached the CAN data which Deye uses (listen to). The protocol is also used by Sermatec. I do have the Deye version also, but this Sermatec document is more readable and the register Id list is exactly the same.

This is great!!!!!

I want to use batteries from GSO - High Voltage 115kWh 16000€ - but GSO doesn't get the protocol.
Could you send / post the original Deye CAN protocol document also?

Would help soooo much

 

[ProPV]

GSO Batterie solution high voltage GBP 384300

384v 100kwh 200kwh Lfp Solar Battery Lifepo4 Lithium Ion Battery Pack 40kwh For Ess - Buy 384v Lithium Battery,384v Battery,Lithium Battery 384v Bms Product on Alibaba.com

384v 100kwh 200kwh Lfp Solar Battery Lifepo4 Lithium Ion Battery Pack 40kwh For Ess - Buy 384v Lithium Battery,384v Battery,Lithium Battery 384v Bms Product on Alibaba.com

www.alibaba.com

 

[RichardRSB]

This is great!!!!!

I want to use batteries from GSO - High Voltage 115kWh 16000€ - but GSO doesn't get the protocol.
Could you send / post the original Deye CAN protocol document also?

Would help soooo much

Here you go... I got this from Deye. Let me know if you find something useful.
What i need / want to know is:
Comms: Little Endian or Big Endian?
How does the Deye recognize an approved battery. How to emulate an approved battery.
I use an OrionBMS2 which has a fully programmable CAN system. Problem is, i don't know what to put in the CAN-Id's besides
the obvious.

 

[ProPV]

wow thank you,

I understand your questions / problems, but still have no good answer. But I'm trying to get these answers too.

Is it for sure, that the document is Deye origin?

 

[ProPV]

I still try to get a confirmation this is the real Deye inverter high-voltage battery protocol.

BUT did you know about the "USER DEFINED BATTERY MODE" of DEYE High Voltage Inverter???

As far as I understood you can connect high voltage batteries to the Deye Inverter without CAN-BUS or RS-485 communication!!!

 

[ProPV]

Explanation:

DEYE BMS - User Defined Battery:

With the Deye, certain voltages, capacitance and currents are set. The Deye uses this to control the charging of the battery. The cells are not managed here. That's why you shouldn't connect LIFEPO4 to the Deye without an additional real BMS (e.g. Daly or OrionBMS).

If this real BMS can also communicate with the DEYE via CAN-BUS, i.e. the so-called inverter battery protocol, then it is even better.
In this case, the battery's BMS tells the DEYE Inverter what voltage to apply and what currents to apply. Then the DEYE does exactly what the BMS of the battery tells it to do.

 

[RichardRSB]

Explanation:

DEYE BMS - User Defined Battery:

With the Deye, certain voltages, capacitance and currents are set. The Deye uses this to control the charging of the battery. The cells are not managed here. That's why you shouldn't connect LIFEPO4 to the Deye without an additional real BMS (e.g. Daly or OrionBMS).

If this real BMS can also communicate with the DEYE via CAN-BUS, i.e. the so-called inverter battery protocol, then it is even better.
In this case, the battery's BMS tells the DEYE Inverter what voltage to apply and what currents to apply. Then the DEYE does exactly what the BMS of the battery tells it to do.

Correct. V-mode is a bit limited due to the voltage losses over the cable. If the BMS communicates it tells the correct voltage off the pack, and thus it enables potentially more capacity. This works at the moment, but i need to iron out some wrinkles.
In Lithium mode the Orion tells the Deye the Voltage, current, and temperature measured at the battery, also the BMS can limit the inverter. This adds an extra layer of security. Currently i see correct %, Volts, current, and temperatures. I only need to find the correct hysteresis values in the Orion to prevent it switches off the contactor if the Deye leaks current (and it does).
In Lithium mode i can charge the 403V battery to 100% or 90% exactly. In voltage mode that is not possible. The same is valid for the lower end (0% and 10%).

 

[RichardRSB]

wow thank you,

I understand your questions / problems, but still have no good answer. But I'm trying to get these answers too.

Is it for sure, that the document is Deye origin?

I got this from Deye support / Service upon repeatedly request.

 

[JoergenS]

EDIT / UPDATE: As per May-29, i managed to get this working. Thanks for everyone who looked into this.

I am building an hybrid off-grid system with a Deye (Sol-Ark / Sunsink) and a Tesla model 3 battery connected with an OrionBMS2.
The system runs. Like a baby. But i can't get the OrionBMS2 communicating with the Deye.
The OrionBMS2 has a fully customizable CAN protocol. Everything is configurable.

The inverter is an Deye hybrid HV system model SUN-20K-SG01HP3-EU-AM2.
Those SG01HP3 series are quite new, and getting more and more popular due to the availability
of used EV HV batteries.
Since it is a HV system, it uses quite a different set of CAN Id’s compared with the
Low Voltage systems. Also the broadcast Id is different.

I found a document describing the CAN-Id’s. I tried this approach, but i can’t get it to connect.
Now i am fairly new to CAN. I do not fully understand the protocol, and despite of learning and reading tons
of documents i am not able to get it to work.

What i know:
The Deye inverters are “self-adopting” to battery systems, hence there is no setting in the inverter other than
enable, or disable. They approved a series of batteries, and PYLON is one of them. I am not sure how they recognize
the batteries, but i guess they look at the manufacturer name at CAN-Id 0x42F0. Here is the list the Deye handles without problems:

On CAN 00:
Deye BOS-G Series/GB-L Series
Dyness HV Series/TOWER Series/Orion Series
UZ UZ-PLH/UZ-PSE
Shoto SDA10-48100
PYLON Powercube Series/Force H Series
Greenrich HV IS001
On CAN 01:
BYD HVS Series/HVM Series

So i need to emulate one of those batteries in the OrionBMS.

Above batteries have a common dataset talking to the Deye. I have the Deye datasheet, but i can't get it running.
What am i doing wrong?
Is there anyone who knows the CAN data from one of the batteries in the above list?

I asked BYD and Pylon for the CAN HV protocol data. No positive response.
Also i asked Deye about this. My request needs to be approved. (sigh).
I’ve got a general document which i think Deye uses, but i can’t get it working. The inverter
does not recognize the data, maybe due to the fact i don't know if i implemented it correctly, and
how to insert the manufacturer name (e.g. PYLON) into the CAN data on the OrionBMS2.

I hope someone with a detailed knowledge of CAN can tell me how to format the CAN data send to the inverter.
I am capable of basic understanding if this stuff. I get confused in bit and byte orders, and got stuck on adding
ASCII data at CAN-Id 0x42F0. Also i don’t know if it is required to insert all the Id’s, or if you can safely leave out
unused / meaningless fields.

I only want the cell broadcast, SoC, SoH, Voltage, Temperature, Power and Current.

Attached the CAN data which Deye uses (listen to). The protocol is also used by Sermatec. I do have the Deye version also, but this Sermatec document is more readable and the register Id list is exactly the same.

Could you share how you manaked to get the Deye inverter to communicate with the Orion2BMS?
Very curious as I'm looking to the best way of utilizing some 36s LGChem 151v modules and thinking 4-5 in seriel with a big Orion2BMS could be great - but are missing a suitable inverter/charger
Br

 

[Ampster]

Could you share how you manaked to get the Deye inverter to communicate with the Orion2BMS?

I assume you are talking about the OrionJR2 BMS. I set the OrionJR2 to a Victron output and then followed the instructions on the SolArk communications document to connect to the CAN port on the SolArk 12K. I assume the Deye has a similar configuration. Or the thread in my signature or this thread where it is discussed:

How to get OrionJr2 CANBUS working with Sol-Ark?

Anyone have luck getting OrionJr2 BMS talking with Sol-Ark over CANBUS? It has taken me a year since the cells were delivered for me to get everything together but I am finally in the last stages of building a 32 cell 48V battery and Sol-Ark's website listed the Orion BMS on their site as one...

diysolarforum.com

EDIT: I did not see my earlier post where I realized that you were also talking about the High Voltage DEYE inverter with high voltage batteries. Earlier I had an original Orion BMS and talked with Orion about the CAN protocol and discovered that it is not implemented on that BMS. Mine was a version 1 and I do not know if it was . Sorry for the digression. I am traveling and cannot easily remember the details in past threads like these.

 

[JoergenS]

I assume you are talking about the OrionJR2 BMS. I set the OrionJR2 to a Victron output and then followed the instructions on the SolArk communications document to connect to the CAN port on the SolArk 12K. I assume the Deye has a similar configuration. Or the thread in my signature or this thread where it is discussed:

How to get OrionJr2 CANBUS working with Sol-Ark?

Anyone have luck getting OrionJr2 BMS talking with Sol-Ark over CANBUS? It has taken me a year since the cells were delivered for me to get everything together but I am finally in the last stages of building a 32 cell 48V battery and Sol-Ark's website listed the Orion BMS on their site as one...

diysolarforum.com

EDIT: I did not see my earlier post where I realized that you were also talking about the High Voltage DEYE inverter with high voltage batteries. Earlier I had an original Orion BMS and talked with Orion about the CAN protocol and discovered that it is not implemented on that BMS. Mine was a version 1 and I do not know if it was . Sorry for the digression. I am traveling and cannot easily remember the details in past threads like these.

No problem - thank you for the info

 

[д52]

ну почему так. а сеть есть подключена.

 

[д52]

ну чому так. а сеть є підключена.

а ще. чому така напруга инверор високовольтний SUN-15K-SG01HP3-EU-AM2

 

[TRRRR]

Any progress on this? I am struggling to get the Orion BMS 2 to communicate with my 30 kVA HV hybrid inverter from Deye. I tried setting my CANBUS on the BMS to match the documents provided by Richard and messed around a bit with different comm parameters, but still no luck.

 

[TRRRR]

I GOT IT TO WORK (sort of). Here is where I'm at:

The setup: I am assembling an off-grid system using a Deye HV hybrid inverter 30 kVA 220/380 V using a custom pack I built using 8 Tesla model S battery modules in series with Orion BMS 2. The setup is simple, I have a 120-240V to 24V DC converter, where the input is the HV battery pack and the output powers up the 'Always On' and 'Charge' power inputs of the BMS and the positive terminal on the GIGAVAC contactor coil, the negative terminal is controlled by the BMS's Multi Purpose Enable output pin. Communication is established via the CAN1 port of the BMS connected to the RJ45 port labeled 'BMS1' on the inverter, all with twisted pair, shielded cables and with termination resistors.

The CAN specs: I finally got the BMS to communicate with the inverter. Through trial and error, I figured out that there is a slight misinformation in the CAN specs provided by Richard (attachment in the first post of the thread), or maybe it is poorly written in the document. The document states that any message sent by the BMS should have its ID (extended format) composed of a 4-digit prefix + 1-digit suffix (i.e.: 0x42100), where the suffix is the equipment address, possibly to differ between multiple BMS in parallel. The thing is, doing this wasn't working at all. How I got my data to appear on the inverter screen was to ignore the suffix and build my CAN messages with only the first four digits (i.e.: 0x4210). It's such a simple change that took me days to figure out.

From there, following the document will pretty much get you all set. It is important to note that the bit order should be set to Most Significat Bit, despite what the document may suggest, and byte order should be Little Endian. More trial and error and I got to adjust the scale of each value to show properly on the inverter screen. Here is a photo I took just a few moments ago.



What is left: Well, a lot. I have been testing the inverter and so far it seems to work great, but I still have many tests I want to execute. I haven't done a full discharge or charge cycle, that is coming next. As you can see from the photo above, I still have an alarm set, identified as 0x8000. I did my best to build the alarm flags based on the alarm table provided by the CAN specs document and, from analysing the live CANBUS, all alarm flags the BMS is sending are off. There may still be a misalignment in a few CAN frames, or it may be an internal alarm flag raised by the inverter internally. Either way, it doesn't seem to be messing with the operation of the inverter so far.

Main thing I am still worried about are the 'Charge', 'Discharge' and 'Balancing' requests that the inverter seem to base its logic around. I am ignoring them for now, as the operation for charge and discharge on the Orion BMS 2 work differently, but I am trying to emulate the 'response from battery' message on those requests. Like I said in the beginning, I am only powering up 'Always On Power' and 'Charge Power' constantly, so internally the BMS is always in charge mode and always attempting to balance the cells, but so far it is not messnig with my discharge attempts. I would really appreciate any suggestios on how to revision my logic here.

Another important thing are the messages transmitted by the inverter. I captured two ID's: 4200 on a 490-ish ms cycle and 1871 on a 3000-ish ms cycle. 4200 matches the document, but I have no idea what 1871 is. As you can see, I have not captured any other inverter TX ID's present in the document a single time, those being 8200 and 8210. They may have been rearranged and combined into 1871 in a previous update? No idea.

Also, small thing, I wanted to write my company's name in ASCII on the 'manufacturer name' CAN frame, but couldn't get it to work. Maybe it checks a list of approved manufacturers before dispalying it? Maybe the ID's are wrong again.

I love the Orion BMS 2, but with this type of application, there are a lot of compromises one has to make. This is my best effort so far. Attached are my latest Orion BMS config file and CAN DBC file, both in the compacted file. I also attached a PYLON CAN specs document (more documentation poorly translated from chinese, yay) that seems to only be for LV inverters, but helped me get an understanding on how these protocols work. I hope we can get more people working on this, since it has potencial to be a great high power, high confiability off-grid setup. Thank you, RichardRSB, you are a legend.

 

[TRRRR]

The great dziiq uploaded a document to the resource page that will be of great use to us. A full CAN specs of the BMS on the PYLON HV ESS for integration with Deye HV hybrid inverters. This is huge. It confirms a lot of ID's we already new about, but also rectifies wrong/out-of-date ID's and adds new ones we didn't know about. At this point, the number of available CANBUS messages on the Orion BMS 2 is running low, so we'll have to pick and choose the most important ones.

You can find the full document in this page or the attachment below. Thank you so much, dziiq!

 

[dziiq]

The great dziiq uploaded a document to the resource page that will be of great use to us. A full CAN specs of the BMS on the PYLON HV ESS for integration with Deye HV hybrid inverters. This is huge. It confirms a lot of ID's we already new about, but also rectifies wrong/out-of-date ID's and adds new ones we didn't know about. At this point, the number of available CANBUS messages on the Orion BMS 2 is running low, so we'll have to pick and choose the most important ones.

You can find the full document in this page or the attachment below. Thank you so much, dziiq!

Actually its confusing because our bms (hinen) uses pylon hv 1.26 but not working with deye hv inverters. Still trying to figure this out

 

[Tomato88]

I GOT IT TO WORK (sort of). Here is where I'm at:

The setup: I am assembling an off-grid system using a Deye HV hybrid inverter 30 kVA 220/380 V using a custom pack I built using 8 Tesla model S battery modules in series with Orion BMS 2. The setup is simple, I have a 120-240V to 24V DC converter, where the input is the HV battery pack and the output powers up the 'Always On' and 'Charge' power inputs of the BMS and the positive terminal on the GIGAVAC contactor coil, the negative terminal is controlled by the BMS's Multi Purpose Enable output pin. Communication is established via the CAN1 port of the BMS connected to the RJ45 port labeled 'BMS1' on the inverter, all with twisted pair, shielded cables and with termination resistors.

The CAN specs: I finally got the BMS to communicate with the inverter. Through trial and error, I figured out that there is a slight misinformation in the CAN specs provided by Richard (attachment in the first post of the thread), or maybe it is poorly written in the document. The document states that any message sent by the BMS should have its ID (extended format) composed of a 4-digit prefix + 1-digit suffix (i.e.: 0x42100), where the suffix is the equipment address, possibly to differ between multiple BMS in parallel. The thing is, doing this wasn't working at all. How I got my data to appear on the inverter screen was to ignore the suffix and build my CAN messages with only the first four digits (i.e.: 0x4210). It's such a simple change that took me days to figure out.

From there, following the document will pretty much get you all set. It is important to note that the bit order should be set to Most Significat Bit, despite what the document may suggest, and byte order should be Little Endian. More trial and error and I got to adjust the scale of each value to show properly on the inverter screen. Here is a photo I took just a few moments ago.

View attachment 287746

What is left: Well, a lot. I have been testing the inverter and so far it seems to work great, but I still have many tests I want to execute. I haven't done a full discharge or charge cycle, that is coming next. As you can see from the photo above, I still have an alarm set, identified as 0x8000. I did my best to build the alarm flags based on the alarm table provided by the CAN specs document and, from analysing the live CANBUS, all alarm flags the BMS is sending are off. There may still be a misalignment in a few CAN frames, or it may be an internal alarm flag raised by the inverter internally. Either way, it doesn't seem to be messing with the operation of the inverter so far.

Main thing I am still worried about are the 'Charge', 'Discharge' and 'Balancing' requests that the inverter seem to base its logic around. I am ignoring them for now, as the operation for charge and discharge on the Orion BMS 2 work differently, but I am trying to emulate the 'response from battery' message on those requests. Like I said in the beginning, I am only powering up 'Always On Power' and 'Charge Power' constantly, so internally the BMS is always in charge mode and always attempting to balance the cells, but so far it is not messnig with my discharge attempts. I would really appreciate any suggestios on how to revision my logic here.

Another important thing are the messages transmitted by the inverter. I captured two ID's: 4200 on a 490-ish ms cycle and 1871 on a 3000-ish ms cycle. 4200 matches the document, but I have no idea what 1871 is. As you can see, I have not captured any other inverter TX ID's present in the document a single time, those being 8200 and 8210. They may have been rearranged and combined into 1871 in a previous update? No idea.

Also, small thing, I wanted to write my company's name in ASCII on the 'manufacturer name' CAN frame, but couldn't get it to work. Maybe it checks a list of approved manufacturers before dispalying it? Maybe the ID's are wrong again.

I love the Orion BMS 2, but with this type of application, there are a lot of compromises one has to make. This is my best effort so far. Attached are my latest Orion BMS config file and CAN DBC file, both in the compacted file. I also attached a PYLON CAN specs document (more documentation poorly translated from chinese, yay) that seems to only be for LV inverters, but helped me get an understanding on how these protocols work. I hope we can get more people working on this, since it has potencial to be a great high power, high confiability off-grid setup. Thank you, RichardRSB, you are a legend.

Thank you very much for sharing your work, TRRR!

I am working with the SA 60k-480-3P inverter and a large LFP 384V battery with Orion2 BMS.

Your .o2BMS file allowed the SA inverter to operate without Alarms on first try. My first problem to work through is that the Sol-Ark is displaying an SOC value that is 2X of the value the BMS is broadcasting. I cycled the battery once and as discharge occurred I noticed this discrepancy. The result was BMS self-protection at low SOC as the inverter over-estimated SOC during discharge by exactly 2X.

This version of the Sol-Ark HV hardware has split the battery input into two terminal sets to get the higher current of a 60kW capable pack into the inverter. The setup screen has a check box to confirm you are using two batteries (both terminal sets) but I just split the one larger battery into two cable sets. obviously the BMS is sending only one message set, and I expect that a multi-battery set from an approved battery list would self-manage and also send only one message set for all attached batt strings. Maybe a poor assumption?

I am guessing that the checkbox instructing the Sol-ark to use two terminal sets to intake the current may be inserting a factor of two somewhere in the calculations and throwing off the SOC estimate(?) I will test this today by removing one set of terminal connections to the battery. I know the inverter does not like having the dual-battery checkbox unchecked when both sets of terminals are connected - the unit makes a hissing sound!

I opened the hood on your "deye... .o2bms " file and found a large text string about 7/8ths through it and pattern matched the CAN IDs to locate the message definitions - especially the x4210 instance with the SOC definition. I found that the offset info is easily decoded and verified from hex as matching the .dbc definition, but I am a lightweight in my understanding of CAN, and so when I searched for parts of the string that might encode for the scale parameters in each message, I came up short. I do note that the scale value for the SOC message is 0.5 in the .dbc. Do these messages even utilize the scale values during broadcast or is that info just for human readability? I am still looking for the elusive "factor of two".

Do you have a more complete description of the string payload for each message you would share? How about any useful changes you have made in the .o2bms file in the last month?

Thank you immensely for getting me so close to goal. This project is a charitable exercise for a farm collective that has been off-grid for 40 years (!) All I can keep telling them is "soon...".

 

[Tomato88]

Following up: the SOC overestimation problem in the inverter is unrelated to the number of battery input terminals used. Silly thought in retrospect, but it gave me something to test while I am looking for more ideas and information.

The mystery remains then regarding how .dbc file message parameters become formatted into .o2bms string parameters. Said parameters instruct the BMS to send messages to the Sol-Ark inverter over CAN that command the inverter to operate in protection of battery and cell charge and discharge limits. I did observe reduction of discharge limit current as the pack SOC dropped, but i did not observe these limits tapering appreciable as limiting low cell voltage value approached my prescribed lower limit value of 2.8V. The BMS had to open the contactor to save the lowest cell, so perhaps more than the SOC is miscast in the translation from .dbc to .o2bms string.