BMS Pylontech BMS/battery emulation [Enhancement]

[dudman]

I'm just setting up 48V lifepo4 with diymbs and Pip-MAX 8KW inverter/charger, which supports Pylontech bms/battery modules. I would like to add if possible BMS Pylontech support much as you have done with Vitron and others gradually.

I've been looking at diybms victron code, and generally seeing how it works, I came across a python example that shows the messages and communication https://github.com/juamiso/PYLON_EMU and I'm guessing would be a good start.

I have the hardware for testing, and of course am willing to tinker

Thanks

[stuartpittaway]

Just to clarify, you would be looking at diybms to emulate a Pylontech battery ?

[dudman]

Yes that right

[stuartpittaway]

Theres another example here.. https://www.setfirelabs.com/green-energy/pylontech-can-reading-can-replication

[PaulSturbo]

Hi, Due to a change of plan caused by supply issues, I have a Sofar hybrid inverter and DIY BMS with the Esp32 controller. I took some comfort from this discussion that there was likely to be a solution to control of my DIY 16s 48v battery. I'm ready to hook things up with the solar side of things up and running. So in a few weeks I'm able to help with testing if any progress has been made with code. I've looked at the code and can see that the Victron can-bus functions pull together the data required for the Pylontech emulation but don't feel confident in having a stab at this myself. Any updates on progress ?

[stuartpittaway]

I've not progressed this at all, yet!

I've been busy getting the latest release out.

If there is suitable documentation, I'm happy to work with you on an experimental release to emulate the pylon battery.

[PaulSturbo]

Hi, [https://github.com/PaulSturbo/DIY-BMS-CAN/blob/main/SEPLOS%20BMS%20CAN%20Protocoll%20V1.0.pdf]() In addition to the setfirelabs info above, I've found a pdf of the Seplos bms can protocol in the attached link. Seplos also emulates the Pylontech.

[stuartpittaway]

Looks like there is a substantial overlap with the Victron CANBUS messages - some are different/new such as 0x359

[PaulSturbo]

Yes, it looks like 0X35e, 351, 355 & 356 are very similar. Looks like 0X359 is a combination of the Victron 0X373-377. What concerned me was sending the CAN ID every second.

[stuartpittaway]

The data is already sent every second to Victron CANBUS, so shouldn't be a problem.

Do you have the BMS connected to CAN/Inverter now?

[PaulSturbo]

I'm a couple of weeks away from finishing the battery and wiring up. It would be interesting to see how the inverter responds to the Victron CAN, but I don't think it would accept the identifier.

[stuartpittaway]

Let me know when you have everything wired up. I've started some skeleton code to provide the user interface in the DIYBMS in this GITHUB branch.

https://github.com/stuartpittaway/diyBMSv4ESP32/tree/pylonbatteryemulation

At the moment, it just spits out a single CAN message for the voltage, we can build on this once you are in a position to test.

[PaulSturbo]

Excellent. I'll crack on with the build.

[PaulSturbo]

The battery is now finished and wired into the inverter.

The latest release of the BMS code was initially loaded and worked fine, communicating over WiFi. All cells healthy, holding 3.29v.

I built a CAN sniffer from a NodeMCU and MC2515_CAN running the example CAN_Recieve sketch from the MCP2515 library. This shows the output for the Victron inverter as follows: Standard ID: 0x351 DLC: 6 Data: 0x44 0x02 0x8A 0x02 0xBC 0x02 Standard ID: 0x370 DLC: 8 Data: 0x44 0x49 0x59 0x42 0x4D 0x53 0x2D 0x30 Standard ID: 0x371 DLC: 8 Data: 0x30 0x43 0x35 0x46 0x41 0x34 0x43 0x00 Standard ID: 0x35A DLC: 8 Data: 0xA8 0x02 0x80 0x00 0x00 0x00 0x00 0x0A Standard ID: 0x35F DLC: 6 Data: 0x00 0x00 0x16 0x13 0x00 0x00 Standard ID: 0x35E DLC: 6 Data: 0x44 0x49 0x59 0x42 0x4D 0x53 Standard ID: 0x356 DLC: 6 Data: 0x95 0x14 0x00 0x00 0x82 0x00 Standard ID: 0x373 DLC: 8 Data: 0xD3 0x0C 0xE9 0x0C 0x1D 0x01 0x1E 0x01 Standard ID: 0x374 DLC: 8 Data: 0x62 0x30 0x20 0x6D 0x38 0x00 0x00 0x00 Standard ID: 0x375 DLC: 8 Data: 0x62 0x30 0x20 0x6D 0x31 0x31 0x00 0x00 Standard ID: 0x377 DLC: 8 Data: 0x62 0x30 0x20 0x6D 0x31 0x00 0x00 0x00 Standard ID: 0x376 DLC: 8 Data: 0x62 0x30 0x20 0x6D 0x30 0x00 0x00 0x00

The skeleton code is now compiled and loaded onto the BMS. The output from the single CAN message is as follows: Standard ID: 0x356 DLC: 6 Data: 0x95 0x14 0x00 0x00 0x82 0x00

The actual voltage at the BMS was 52.69v. Bang on.

So we are ready to take this a stage further.

I have tried to get the inverter to communicate with the BMS. The BMS reported some messages sent then just send errors accumulated. I think that the inverter rejects the BMS unless there is a 0x35E message including the string "PYLON".

[stuartpittaway]

Great.

I've just added in the "PYLON" (along with 3 trailing zero byte characters which some of the sample code seems to use) so try that out and see if it makes a difference?

I think if we drip feed the CAN messages into the inverter until it "wakes up" and responds, we will then have found the minimum data set required for operation.

[PaulSturbo]

Thanks, I'll re-compile and test.

[stuartpittaway]

I've just done the code for the remaining messages, so DIYBMS should now transmit

      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 “)

This is definitely a work in progress!

For the voltage/current limits - use the web interface fields for the victron CVL/CCL/DCL, just ensure you untick "Enable CANBUS BMS communication to Victron devices"

The SOC is only sent if you have a DIYBMS current monitor installed. The battery charge request flags are hardcoded.

[PaulSturbo]

Work in progress but big steps - Many Thanks.

Output from the latest code: Standard ID: 0x351 DLC: 8 Data: 0x44 0x02 0x64 0x00 0x9C 0xFF 0x3F 0x02 Standard ID: 0x356 DLC: 6 Data: 0x94 0x14 0x00 0x00 0x8C 0x00 Standard ID: 0x35E DLC: 8 Data: 0x50 0x59 0x4C 0x4F 0x4E 0x20 0x20 0x20 Standard ID: 0x359 DLC: 8 Data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Standard ID: 0x351 DLC: 8 Data: 0x44 0x02 0x64 0x00 0x9C 0xFF 0x3F 0x02 Standard ID: 0x356 DLC: 6 Data: 0x94 0x14 0x00 0x00 0x8C 0x00 Standard ID: 0x35E DLC: 8 Data: 0x50 0x59 0x4C 0x4F 0x4E 0x20 0x20 0x20 Standard ID: 0x359 DLC: 8 Data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Standard ID: 0x351 DLC: 8 Data: 0x44 0x02 0x64 0x00 0x9C 0xFF 0x3F 0x02 Standard ID: 0x356 DLC: 6 Data: 0x94 0x14 0x00 0x00 0x8C 0x00 Standard ID: 0x35E DLC: 8 Data: 0x50 0x59 0x4C 0x4F 0x4E 0x20 0x20 0x20 Standard ID: 0x359 DLC: 8 Data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Standard ID: 0x351 DLC: 8 Data: 0x44 0x02 0x64 0x00 0x9C 0xFF 0x3F 0x02 Standard ID: 0x356 DLC: 6 Data: 0x93 0x14 0x00 0x00 0x8C 0x00 Standard ID: 0x35E DLC: 8 Data: 0x50 0x59 0x4C 0x4F 0x4E 0x20 0x20 0x20 Standard ID: 0x359 DLC: 8 Data: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Getting a fault at the inverter of "Battery voltage too high"

Looks like some of the settings in 0x351 may be incorrect but I can't find a way of changing them.

0x356 & 0x35E look OK.

0x359 does not seem to be outputting any data.

0x355 not outputting as expected (No Shunt).

0x35C not showing up.

If we can fix 0x351, I think we may be with a chance.

Thanks again.

[PaulSturbo]

A minor issue was that I had problems with the CAN Sniffer. After re-loading the sniffer code, checking connections and swapping components it still would not work. Power cycled the BMS and there it was.

[stuartpittaway]

The "Battery Voltage Too High" - this is driven from the "rules" in DIYBMS is the rule "Pack over voltage (mV)" active (in green) ? This is part of the 0x359 message

The 0x351 outputs fields in this sequence...

    uint16_t battery_charge_voltage;
    // positive number
    int16_t battery_charge_current_limit;
    // negative number
    int16_t battery_discharge_current_limit;
    uint16_t battery_discharge_voltage;

which I believe matches the documents I've seen. All the code is in "pylon_canbus.cpp"

I've added some 20ms delays between the messages - its possible that you are not logging them quickly enough so they are getting lost.

[stuartpittaway]

Hi @PaulSturbo made another small tweak to the "battery_discharge_voltage" which may fix the issue you saw.

Can you try this on again?

[PaulSturbo]

Thanks Stuart,

I now have the inverter talking to the BMS. I can see changes at the inverter display that can only come from the BMS, such as pack voltage and module temps. Success so far.

The inverter shows the battery is connected when I switch it on but will fail to start charging and goes into fault mode. This restores when I disconnect the battery at the breaker.

In considering the next steps last night I decided to try "battery_discharge_voltage at "-100". At least we are thinking along the same lines :) It did not work but now shows a fault undocumented by Sofar, ID123.

I will try at "-50" as you suggest, assuming that that is the only change you have made in the code. However, the BMS is still outputting a string of zeros on the 0x359 string and the inverter settings are not updating, which I think is the cause of the current issues.

[stuartpittaway]

Ok, I'm sending the error codes/bits based on the current state of the controller. Is it those which trip the fault/error state on the inverter?

[stuartpittaway]

In regards to the 0x359 message - the first four bytes should be zeros - indicating that no errors exist.

Byte 5 and 6 are not used (according to the various documents) however, the examples do show bytes as "0A 50" rather than zero.

The last byte, "Address of packs in parallel" I thought would be fine at zero - does this need to be something else?

Just a thought - am I reading "Quantity of packs in parallel" incorrectly - is this the number of cells in DIYBMS terminology?

[stuartpittaway]

This document also seems to contain a different CANBUS packet format - perhaps this is an old version? https://www.studocu.com/row/document/abasyn-university/electronics-engineering/can-bus-protocol-pylon-low-voltage-v1/17205338

This code also appears to emulate PYLON battery, which also seems to match the document linked above. https://github.com/Tom-evnut/BMWI3BMS/blob/master/BMWI3BMS.ino

[PaulSturbo]

In regards to the 0x359 message - the first four bytes should be zeros - indicating that no errors exist.

Byte 5 and 6 are not used (according to the various documents) however, the examples do show bytes as "0A 50" rather than zero.

The last byte, "Address of packs in parallel" I thought would be fine at zero - does this need to be something else?

Just a thought - am I reading "Quantity of packs in parallel" incorrectly - is this the number of cells in DIYBMS terminology?

I'm now inclined to think that 0x359 is not the issue although it may be worth checking if bytes 5 & 6 need to show "0A 50". Interestingly, the earlier Setfirelabs post shows byte 7 populated as follows: "Standard ID: 0x359 DLC: 7 Data: 0x00 0x00 0x00 0x00 0x04 0x50 0x4E"

I would read "packs in parallel" as being the number of battery packs rather than cells, in this case 1.

[stuartpittaway]

Ok, I've made those changes, see how it goes. Hopefully this fixes the battery being offline when powered on.

[PaulSturbo]

This document also seems to contain a different CANBUS packet format - perhaps this is an old version? https://www.studocu.com/row/document/abasyn-university/electronics-engineering/can-bus-protocol-pylon-low-voltage-v1/17205338

This code also appears to emulate PYLON battery, which also seems to match the document linked above. https://github.com/Tom-evnut/BMWI3BMS/blob/master/BMWI3BMS.ino

That looks like an early CAN spec from Pylontech.

I'm struggling to read the Tom-evnut code. I haven't read C since teaching myself MS-DOS C programming in the 80s. However, one thing that I've noticed is that he does not make the 0x351 Discharge Current Limit a negative number. This is not being changed at the Inverter when changed in the BMS. The Charge Current limit does change.

Also, I had a look to see what would happen if I sent the Victron CAN to the Inverter. To my surprise it read it, set the batttery to Generic Lythium as "DIYBMS8" and correctly set the Charge and Discharge Current Limits. Same faults reported when I switched on the battery.

The Victron_canbus code includes many of the same functions, but not 0x359. Does this point us back to looking at 0x359?

Just seen your latest post, I'll try the new code after lunch.

[PaulSturbo]

Another observation from running the Victron CAN, I could see both send and recieve message counts on the display whereas with the Pylon code I only see send message counts. Just wondered if that is significant?

[stuartpittaway]

Another observation from running the Victron CAN, I could see both send and recieve message counts on the display whereas with the Pylon code I only see send message counts. Just wondered if that is significant?

Ah, my mistake on that one, it should work okay now (just checked in)

[PaulSturbo]

No joy I'm afraid.

Tried a few code changes.

all in pylon_canbus.cpp: Re-instated line 80: data.battery_discharge_voltage = data.battery_charge_voltage - 50;

Took the minus signs off the discharge current limit, lines 62, 69, 76: { ESP_LOGW(TAG, "active_errors=%u", number_of_active_errors); // Error condition data.battery_charge_voltage = mysettings.cvl[VictronDVCC::ControllerError]; data.battery_charge_current_limit = mysettings.ccl[VictronDVCC::ControllerError]; data.battery_discharge_current_limit = mysettings.dcl[VictronDVCC::ControllerError]; } else if (rules.numberOfBalancingModules > 0) { // Balancing data.battery_charge_voltage = mysettings.cvl[VictronDVCC::Balance]; data.battery_charge_current_limit = mysettings.ccl[VictronDVCC::Balance]; data.battery_discharge_current_limit = mysettings.dcl[VictronDVCC::Balance]; } else { // Default - normal behaviour data.battery_charge_voltage = mysettings.cvl[VictronDVCC::Default]; data.battery_charge_current_limit = mysettings.ccl[VictronDVCC::Default]; data.battery_discharge_current_limit = mysettings.dcl[VictronDVCC::Default]; } This had a positive impact - inverter correctly showing current limits.

Change number of packs to 4 in line 160: data.byte4=4; The inverter now shows 296Ah rating of the battery so that it thinks it has 4 Pylontech US3000 packs (4 * 74Ah). My pack is 280Ah Eve Lifepo4 16s setup.

On battery switch on the inverter see a change, goes into a checking state, starts to charge the battery from the excess solar, then goes into a fault, returns to checking mode and starts again.

[stuartpittaway]

I wonder if it's a timing issue, perhaps reduce the delays?

Additionally the SOC message isn't running without the current monitor, so perhaps fake that for now and see what happens?

[PaulSturbo]

I've added some code to give 60% SOC and 100% SOH. It's working as the SOC shows up on the inverter.

No joy. The inverter shows an alarm led and issues a ID05 fault the moment I switch the breaker on. The alarm clears but re-appears once the inverter starts to charge/discharge. Another ID05 fault is registered in the event list.

ID05 is "battery voltage too high".

The battery voltage is 52.7v and the max setting is 57v so I don't understand what's happening. If it was "battery too low" then it could be attributed to in-rush. I monitored the voltage at the breaker and there was no voltage variation whilst it went through a cycle.

Any ideas?

[stuartpittaway]

Is it a scaling issue? Are we passing 5.27 rather than 52.7 for example?

[stuartpittaway]

Have you had chance to play today?

Are you logging the CAN messages when the fault occurs on the inverter? Can you check the DIYBMS isn't sending a fault code in the 0x359 message (should be zeros in first 4 bytes)

[PaulSturbo]

I've not stopped playing :)

I've been going around in circles trying different setups on the CAN and am confident that the BMS is working as it should. Using both the Pylon and Victron Can options, the BMS Correctly registers the settings sent.

The inverter continues to show error code ID05 whenever I switch the battery MCB on and also when the internal relays of the BMS connect.

The inverter has a Emergency Power System that supplies 230v AC through a seperate connection. I have a breaker and socket connected to it. If I disconnect the mains, it automatically switches over the the EPS load.

I have a 500w heater connected to the EPS load. Under EPS operation, the PV charges the battery and supplies load to the heater. If I disconnect the PV, the battery supplies the heater. So I am seeing bothe chargeing and discharging of the battery under EPS.

Switch on the mains and the fault occurs. This is the same when using Pylon or Victron settings. I don't think this is a BMS issue.

The Sofar manual explains ID05 as follows: "Description - The battery voltage is too high Solution - If the alarm ocurrs occaisionally, wait a while to see if the problem is solved. If the alarm ocurrs frequently, check whether the battery overvoltage setting is inconsistent with the battery specification."

So even Sofar do not really understand ID05!

The Over voltage protection is set at 59v, it defaults to 1v higher than the maximum battery voltage of 58v. So should not be an issue with the battery sitting at 53v.

I'm currently using the EPS mode and heater to take some volts out of the battery to see if that helps. The EPS has a safety buffer of 10% which may explain why that works but not with the grid.

I respect your query regarding the fault, it does not ocurr on receipt of the CAN messages, only when the breaker of relays close.

I'll update when I have something positive to tell you. Next on the list to try is to take a cell out of the battery.

[stuartpittaway]

Which inverter is it you are using? I've been looking at the ME3000SP - I'm in the UK, where are you?

[PaulSturbo]

Mines a HYD-5000ES. I believe it uses the same software as the ME3000

I'm in North Northants, not far from you.

[stuartpittaway]

Assume that you have checked the battery voltage at the terminals on the inverter with a multimeter, just to check they are not drifting over 58.0V.

Where did you get your cells from?

[PaulSturbo]

No upward drift at the terminals.

I got the cells from Shenzen Basen on Alibaba. They had UK stock at the time so got them within a few days of ordering. EVE LF280K cells.

[stuartpittaway]

Well done on UK stock of cells, I'm trying to get hold of some myself.

[PaulSturbo]

I dealt with this guy direct:

Basen Alex alexchen@basengroup.com

[PaulSturbo]

Latest:

I've not got very far with this so have emailed the manufacturer. They responded very quickly andremotely updated the firmware overnight. Still no improvement so they have escalated the issue.

In the meantime I need to temporarily add a SOC calculation. I appreciate that this is a complicated issue but a simple linear algorythm should at least feed the Inverter with something reasonably accurate where it matters, at the top and bottom of the battery voltage range. So here goes:

In 0x355, added a couple of variable: uint16_t numberofmodulesok; uint16_t voltage;

Then within an else after the if check for the controller: data.numberofmodulesok = mysettings.totalNumberOfSeriesModules; data.voltage = rules.highestPackVoltage / 10; data.stateofchargevalue = 100 * ((data.voltage * 1000) - rules.lowestCellVoltage) / (rules.highestCellVoltage - rules.lowestCellVoltage);

It did not work, no surprises. Any chance you could check the variable I've used and the conversion factors.

Thanks

[stuartpittaway]

Could you just hard code a value? How does the inverter use this SOC?

With LIFEPO4 cells, the voltage is very "flat" so not very easy to use that as a SOC indicator.

[PaulSturbo]

I currently have it hard coded at 60%. The inverter will error if the SOC is less than 1 - DOD.

With the manufacturer able to monitor remotely, they may be able to see that the value is currently static and smell a rat.

[stuartpittaway]

What value is the depth of discharge (DOD) - is that configurable in the inverter ?

You could do some silly calc like..

data.stateofchargevalue = min((uint16_t)100,(uint16_t)((100/3.65)*(rules.highestPackVoltage/mysettings.totalNumberOfSeriesModules)));

Assuming the max. cell voltage is 3.65V

[PaulSturbo]

Thanks for that.

Say I wanted to substitute the 3.65 with a variable set in Rules, what would be the correct variable?

[stuartpittaway]

There isn't really anything suitable for this, it's purely a hack. The only way to get soc is to use the current monitor.

Otherwise you might as well just hardcode it to 100.

[PaulSturbo]

Update:

We now have the battery connected to the inverter and correctly charging/discharging depending on demand/surplus solar.

It took a lot of sorting out. Sofar started asking questions about the batteries and BMS so I was uanble to respond and was back on my own.

My eldest son, who did all the soldering on the BMS and knows about these things had bad Covid the last couple of weeks so was initially unable to assist. Once he was fit again he was able to help.

Long and short of it, the problem with connecting the battery to the inverter without causing a battery over voltage error at the inverter was due to the BMS power supply. I had taken a supply from 8 of the cells, battery positive and the negative from halfway down the pack giving around 26v which I put through a buck converter to give 5 volts at the BMS.

Not entirely sure of the technicalities but this was causing a ground connection at the battery when it needs to be floating. Could this be due to the BMS negative offset or CAN low???

Anyway, fitted a ground isolated mains fed 9v power supply feeding the buck converter and away it went. This was a great relief.

Initially we set it up as the default (lead-acid) battery, then tried the CAN connected, Pylontech emulation. It worked but it did not seem to respond to the protection. We raised the battery low voltage setting at the BMS above the actual, the inverter got the message over CAN 0x359 string, lit the alarm led but carried on discharging from the battery.

It seems that the inverter bases all battery control on the SOC. I have lowered the DOD setting in the inverter and observed it stop discharging.

Due to the lack of a current monitor and accurate SOC we have reverted to default (lead acid) battery control. The inverter does a pretty good job on its own of estimating the SOC so far so good.

Next job is to fit a current monitor.

For the record, I made a few small changes to pylon_canbus.cpp as follows:

0x351: Removed minus signs on one of the limits. Looks like the original code has been updated already. Reinstated Line83, "data.battery_discharge_voltage = data.battery_charge_voltage + 10; still not sure what that does.

0x359: Lines 143 to 146, swapped "under" and "over" around. Tested as now correct as mentioned above. Line 165, Changed to "data.byte4=4;", representing 4 Pylon battery packs causing the inverter to calculate battery capacity to 296Ah, close to my 280Ah. I think that the inverter may use this value in the SOC calc. I can confirm that data.byte5 & 6, "P" & "N" are the "magic string" that the battery is a Pylontech. The string "PYLON" in 0x35e is not significant as we thought.

0x355: For the record, I developed a SOC calc that reports a resonable value: data.stateofchargevalue = min((uint16_t)100,(uint16_t)(100/(3.5 - 3.0)*(((rules.highestPackVoltage/10)/mysettings.totalNumberOfSeriesModules)-3.0))); This gives 100% at 3.5v, 0% at 3.0v.

I'll get a current monitor sorted and report back.

[stuartpittaway]

Great progress report, good to hear.

Natively the DIYBMS doesn't have any way to switch off the battery in an over voltage/over current situation - are you planning to install fuses/breakers between the battery and the inverter ?

[PaulSturbo]

I'm not planning any additional equipment. The inverter will handle all that itself.

Looks like I might be waiting a long while for the current monitor components. Do you know of any supplies of the INA228 and the ADM2483?