diy solar

diy solar

EG4 6000xp CANBUS Comms with Victron Smart Shunt w/DIY Battery

ChrisG

Solar Addict
Joined
Sep 23, 2019
Messages
1,834
Just finished a small test project with a ESP32 Devkit and MCP2515 CANBUS module following the instructions at the below post on the forum. In short, YES!, the Victron Shunt is reporting SOC%, Voltage, Current, and other items to the EG4 6000xp and controlling charge/discharge/etc. Thanks to the members in that thread for the core work done before. I'm using LFP Battery and Battery #02 (Pylontech) on the 6000XP.

And yes I converted a Lynx Power-In with M8 bolts and mega fuses.

Simply wanted the shunt to report this information regardless of what type of DIY batteries I have behind it, in my case EVE 105s. Now I need to make a real PCB for it and a case.

Link: https://diysolarforum.com/threads/d...hunt-to-inverter-integration-solis-etc.44750/

Here is some cool pics of it working and some serial output from ESP:
IMG_4648.jpeg




IMG_4795.jpeg
IMG_4798.jpeg



IMG_4799.jpeg
IMG_4800.jpeg

IMG_4797.jpeg



Serial Output from ESP:
[ 1056][main.cpp:113] UpdateCanBusData(): Battery Voltage Update: 52822V
[ 1059][main.cpp:119] UpdateCanBusData(): Battery Current Update: -11673mA
[ 1066][main.cpp:125] UpdateCanBusData(): Battery SOC Update: 995%
[ 1072][main.cpp:196] loop(): Sending Switch Update Data
[ 1128][CANBUS.cpp:60] SendAllUpdates(): Sending all CAN Bus Data
[ 1129][CANBUS.cpp:304] SendParamUpdate(): Sent PYLONTECH String.
[ 1135][CANBUS.cpp:333] SendParamUpdate(): Inverter Parameters update via CAN Bus sent.
[ 1138][CANBUS.cpp:138] SendBattUpdate(): Inverter SOC Battery update via CAN Bus sent.
[ 1151][CANBUS.cpp:160] SendBattUpdate(): Inverter Battery Voltage, Current update via CAN Bus sent.
[ 1161][CANBUS.cpp:182] SendBattUpdate(): Inverter Protection / Alarm Flags via CAN Bus sent.
[ 1169][CANBUS.cpp:205] SendBattUpdate(): Battery Charge Flags via CAN Bus sent.
[ 1559][main.cpp:190] loop(): New block arrived; Value count: 17, serial 1
[ 2056][main.cpp:190] loop(): New block arrived; Value count: 13, serial 2
[ 2056][main.cpp:113] UpdateCanBusData(): Battery Voltage Update: 52819V
[ 2059][main.cpp:119] UpdateCanBusData(): Battery Current Update: -11682mA
[ 2066][main.cpp:125] UpdateCanBusData(): Battery SOC Update: 995%
[ 2176][CANBUS.cpp:60] SendAllUpdates(): Sending all CAN Bus Data
[ 2177][CANBUS.cpp:304] SendParamUpdate(): Sent PYLONTECH String.
[ 2183][CANBUS.cpp:333] SendParamUpdate(): Inverter Parameters update via CAN Bus sent.
[ 2186][CANBUS.cpp:138] SendBattUpdate(): Inverter SOC Battery update via CAN Bus sent.
[ 2199][CANBUS.cpp:160] SendBattUpdate(): Inverter Battery Voltage, Current update via CAN Bus sent.
[ 2209][CANBUS.cpp:182] SendBattUpdate(): Inverter Protection / Alarm Flags via CAN Bus sent.
[ 2217][CANBUS.cpp:205] SendBattUpdate(): Battery Charge Flags via CAN Bus sent.
[ 2561][main.cpp:190] loop(): New block arrived; Value count: 17, serial 3
[ 3058][main.cpp:190] loop(): New block arrived; Value count: 13, serial 4
[ 3058][main.cpp:113] UpdateCanBusData(): Battery Voltage Update: 52816V
[ 3060][main.cpp:119] UpdateCanBusData(): Battery Current Update: -11770mA
[ 3067][main.cpp:125] UpdateCanBusData(): Battery SOC Update: 995%
[ 3224][CANBUS.cpp:60] SendAllUpdates(): Sending all CAN Bus Data
[ 3225][CANBUS.cpp:304] SendParamUpdate(): Sent PYLONTECH String.
[ 3231][CANBUS.cpp:333] SendParamUpdate(): Inverter Parameters update via CAN Bus sent.
[ 3234][CANBUS.cpp:138] SendBattUpdate(): Inverter SOC Battery update via CAN Bus sent.
[ 3247][CANBUS.cpp:160] SendBattUpdate(): Inverter Battery Voltage, Current update via CAN Bus sent.
[ 3257][CANBUS.cpp:182] SendBattUpdate(): Inverter Protection / Alarm Flags via CAN Bus sent.
 

Attachments

  • IMG_4797.png
    IMG_4797.png
    92 KB · Views: 18
Last edited:
Awesome stuff. Now I’m gonna have to dig into that other thread you linked too
How do you like that Nice power supply? I’m assuming it’s a “nice” brand, maybe not though?
 
Awesome stuff. Now I’m gonna have to dig into that other thread you linked too
How do you like that Nice power supply? I’m assuming it’s a “nice” brand, maybe not though?
Project is awesome. Been running and stable for about 48 hours now.

Not sure what brand that power supply is. It works and was cheap. Used to parallel and top balance cells before I discovered active balancing.
 
Last edited:
Still working great but running down a few things in the code:
  • Code is reporting I have 10 batteries to the inverter. No impact just something I want to resolve
  • Using MQTT in Home Assistant, the Pylontech switch has no affect that I can see in charging and discharging
  • Force Charge switch in Home Assistant works and starts charging but gives inverter an under volt error. Once I switch it off inverter error is cleared and force charging continues to 100% - Plan to use this with weather and PV forecasts
  • Complete-Updated code to decrease charge current to get a longer duration charge above 95% SOC for more balance time. All cells now have a delta of .005v. Awesome.
Used mqtt-explorer last night and definitely see data I want to track in HA such as SOC, Voltage, Current and a few others. Will work on that separately.
 
Still working great but running down a few things in the code:
  • Code is reporting I have 10 batteries to the inverter. No impact just something I want to resolve
What CANBus message is that reported in? I was not aware there is such data - certainly not something my Solis uses or reports on.

  • Using MQTT in Home Assistant, the Pylontech switch has no affect that I can see in charging and discharging
Pylontech force charge flag does not work with Solis either - I use the bit of the code that sets the SOC% to an artificially low value to trigger the inverter to charge from grid - has been working well.

  • Force Charge switch in Home Assistant works and starts charging but gives inverter an under volt error. Once I switch it off inverter error is cleared and force charging continues to 100% - Plan to use this with weather and PV forecasts
Could be inverter-specific - guess you'll need to check what voltage the inverter reports as 'under voltage' and possibly lower it - should not matter if your BMS is providing under-voltage protection.

  • Complete-Updated code to decrease charge current to get a longer duration charge above 95% SOC for more balance time. All cells now have a delta of .005v. Awesome.
(y)... I drop my charge down in steps as the SOC increases and it's also mapped depending on cell temperature - if that's of interest, see my postings here...
and here...
 
Thanks for the feedback. For battery count, can’t figure out where it’s coming from. Number has no impact on system use but annoying.

Force charge I need to try under a different condition. I clicked it on when in a discharge mode, unsure if the intent
 
Full week running this project with some minor code tweaks and all good and incredibly stable. Think this is a great CAN solution for DIY batteries for just a few dollars. Also have an esp32 monitoring each bms and sending data to Home Assistant so I can see and alert on specific items/events such as high cell voltage deltas within the packs. Really awesome.
 
Last edited:
Threee weeks running this solution and not a single problem. Victron shunt reporting accurate SOC to 6000xp and charging/discharging with correct parameters. The lower charge current above 95% was key in keeping the batteries balanced which is done by JK BMS (non inverter version).
 
Threee weeks running this solution and not a single problem. Victron shunt reporting accurate SOC to 6000xp and charging/discharging with correct parameters. The lower charge current above 95% was key in keeping the batteries balanced which is done by JK BMS (non inverter version).
awesome!
 
I 100% need this. I’m having the typical issues of SOC with the unit. I’m running AGM batteries and my Victron BMV shows perfect yet the unit shows WAY under. I need to look into setting this up.
 
This looks like a really cool project that i could really get into. One question before I take the plunge.

Will this work the same with 2 x 6000xp’s in parallel? In other words could i just hang the victron shunt off of one inverter?
 
This looks like a really cool project that i could really get into. One question before I take the plunge.

Will this work the same with 2 x 6000xp’s in parallel? In other words could i just hang the victron shunt off of one inverter?
I think in a dual inverter setup using the same battery there is only one CAN connection from battery to primary inverter anyway. Can’t say for sure but seems like it would work.
 
There is one CAN bus connection from the battery to the primary inverter and a cable that connects the primary and secondary inverters.

Thinking out loud - each inverter is connected to the same battery bank. The battery bank is made up of Riuxu server rack batteries connected via bus bars which results in a common negative. So yeh, it should work.

I can get voltages from the existing connection, but state of charge is inaccurate.

I’m thinking this might be a good alternative.
 
The pylontech protocol switch changes the behaviour of the code. With it enabled it uses the modbus flags to tell the inverter to force charge.

Without the pylontech protocol enabled, it doesn't send some flags and uses an alternative way of force charging, which is the sending a false SOC to the inverter saying it's 1% battery.

It always uses pylontech, but just less commands and different control methods for compatiblity.

Any inverter that supports pylontech protocol should work with this software, it wouldn't take much to also support others but i don't have the hardware to implement or test.
 
Still working great but running down a few things in the code:
  • Code is reporting I have 10 batteries to the inverter. No impact just something I want to resolve
  • Using MQTT in Home Assistant, the Pylontech switch has no affect that I can see in charging and discharging
  • Force Charge switch in Home Assistant works and starts charging but gives inverter an under volt error. Once I switch it off inverter error is cleared and force charging continues to 100% - Plan to use this with weather and PV forecasts
  • Complete-Updated code to decrease charge current to get a longer duration charge above 95% SOC for more balance time. All cells now have a delta of .005v. Awesome.
Used mqtt-explorer last night and definitely see data I want to track in HA such as SOC, Voltage, Current and a few others. Will work on that separately.
Code isn't reporting any amount of cells, but it is in the spec to be able to inform the inverter, I suspect that your inverter is defaulting to a lowest value it would accept.

I don't know the settings for your inverter but try disabling pylontech and force charge, and with pylontech and tell me what you see.

The serial output can be increased with a higher debug level, just be aware if you set it to 5 it produces massive amount but might see if it's accepting the CAN data or not.
 
This looks like a really cool project that i could really get into. One question before I take the plunge.

Will this work the same with 2 x 6000xp’s in parallel? In other words could i just hang the victron shunt off of one inverter?
Currently it wouldn't work, CAN Bus has like a master slave relationship, and your 2nd inverter would respond same time as first - every packet gets a response from the inverter.
 
The pylontech protocol switch changes the behaviour of the code. With it enabled it uses the modbus flags to tell the inverter to force charge.

Without the pylontech protocol enabled, it doesn't send some flags and uses an alternative way of force charging, which is the sending a false SOC to the inverter saying it's 1% battery.

It always uses pylontech, but just less commands and different control methods for compatiblity.

Any inverter that supports pylontech protocol should work with this software, it wouldn't take much to also support others but i don't have the hardware to implement or test.
Please tell me more about this... I presently send a falsely low SoC to my SMA sunny island to force it to connect to the grid. Interested in the modbus packets you sending.... I assume they are not sent on canbus, right? or is there a message number for them in CAN?
 
Interested in the modbus packets you sending.... I assume they are not sent on canbus, right? or is there a message number for them in CAN?
This code uses CANBus, not Modbus. CANBus ID's are documented in the code...

PYLON Protocol, messages sent every 1 second.

0x351 � 14 02 74 0E 74 0E CC 01 � Battery voltage + current limits
0x355 � 1A 00 64 00 � State of Health (SOH) / State of Charge (SOC)
0x356 � 4e 13 02 03 04 05 � Voltage / Current / Temp
0x359 � 00 00 00 00 0A 50 4E � Protection & Alarm flags
0x35C � C0 00 � Battery charge request flags
0x35E � 50 59 4C 4F 4E 20 20 20 � Manufacturer name (�PYLON �)
 
Currently it wouldn't work, CAN Bus has like a master slave relationship, and your 2nd inverter would respond same time as first - every packet gets a response from the inverter.
ummm that's not how canbus works..... a packet is sent and every single client on the line that recieved it correctly asserts the CAN-H and CAN-L line. Anyone who didn't decode the packet properly does nothing. So it doesn't matter if more than one client hears and ack's the message / packet.

Carrying this protocol forward... if no one responds by asserting the H-L lines, the sender assumes the packet was not recieved correctly and will typically retransmit. For this reason you must always have at least two on a network.
 
This code uses CANBus, not Modbus. CANBus ID's are documented in the code...

PYLON Protocol, messages sent every 1 second.

0x351 � 14 02 74 0E 74 0E CC 01 � Battery voltage + current limits
0x355 � 1A 00 64 00 � State of Health (SOH) / State of Charge (SOC)
0x356 � 4e 13 02 03 04 05 � Voltage / Current / Temp
0x359 � 00 00 00 00 0A 50 4E � Protection & Alarm flags
0x35C � C0 00 � Battery charge request flags
0x35E � 50 59 4C 4F 4E 20 20 20 � Manufacturer name (�PYLON �)
Thanks Seagal for correcting me, I had modbus on the brain for ages as was designing a fire detection system integration.
 
ummm that's not how canbus works..... a packet is sent and every single client on the line that recieved it correctly asserts the CAN-H and CAN-L line. Anyone who didn't decode the packet properly does nothing. So it doesn't matter if more than one client hears and ack's the message / packet.

Carrying this protocol forward... if no one responds by asserting the H-L lines, the sender assumes the packet was not recieved correctly and will typically retransmit. For this reason you must always have at least two on a network.
The CAN implementation is a specific variant for Battery/Inverter with specific implementation for each battery manufacturer and the inverter has to support each one.

For pylontech (and others but may use different ID's):

The CAN packet format is a 29 bit identifier used in the standard frame format, and the bus transmission rate is 500kbps, pretty much unidirectional other than a "Received packet" response to each packet received, packet ID 305 with 8 bytes of 0x00, only 6 packet ID's are implemented, using User-Defined battery type in Solis Inverters you can reduce the packets down even further.

The packets are sent in a way that every inverter on the bus would receive them and they would take them in, they don't know about each other, there is no way to send to one inverter so then all would reply with ID 305, the software (which I wrote) wouldn't understand the out of packet response.

I expect that the packet ID 305 on the bus and going in to the inverter from another one may cause it to alarm, the inverters aren't the most intelligent at handling the data, I have to be careful with my software otherwise it can hang the task that sends the CAN bus data.

This is why in my opinion it won't work.

I currently haven't seen any batteries or inverters that support parallel operation of CAN, all i've seen is single Battery to Inverter, the inter battery comms are over RS485, PylonTech have implemented paralleling of groups of batteries but one battery is still master, or you have to use there LV Hub, but again single inverter connection.

There are solutions out there where people have implemented parallel connections by receiving and replicating the CAN bus messages to each CAN Connection (completely separate hardware for each), which is what I intend to do in a future version of my software.

Have you yourself paralleled the can bus to multiple inverters and found it to work?
 
Last edited:
The CAN implementation is a specific variant for Battery/Inverter with specific implementation for each battery manufacturer and the inverter has to support each one.

For pylontech (and others but may use different ID's):

The CAN packet format is a 29 bit identifier used in the standard frame format, and the bus transmission rate is 500kbps, pretty much unidirectional other than a "Received packet" response to each packet received, packet ID 305 with 8 bytes of 0x00, only 6 packet ID's are implemented, using User-Defined battery type in Solis Inverters you can reduce the packets down even further.

The packets are sent in a way that every inverter on the bus would receive them and they would take them in, they don't know about each other, there is no way to send to one inverter so then all would reply with ID 305, the software (which I wrote) wouldn't understand the out of packet response.

I expect that the packet ID 305 on the bus and going in to the inverter from another one may cause it to alarm, the inverters aren't the most intelligent at handling the data, I have to be careful with my software otherwise it can hang the task that sends the CAN bus data.

This is why in my opinion it won't work.

I currently haven't seen any batteries or inverters that support parallel operation of CAN, all i've seen is single Battery to Inverter, the inter battery comms are over RS485, PylonTech have implemented paralleling of groups of batteries but one battery is still master, or you have to use there LV Hub, but again single inverter connection.

There are solutions out there where people have implemented parallel connections by receiving and replicating the CAN bus messages to each CAN Connection (completely separate hardware for each), which is what I intend to do in a future version of my software.

Have you yourself paralleled the can bus to multiple inverters and found it to work?
Parallel canbus to multiple inverters is exactly what SMA sunny islands do.

While there can be network segmentation in can bus the packets below 3FF are not gunna be special. They’ll still get the low level ACKs.
 

diy solar

diy solar
Back
Top