Enhancement: SMA Sunny Island

[chron0]

Ahoy, Stuart. Thanks a lot for sharing this BMS and giving us DIYers a nice option to care for our batteries. I couldnt find any issue about "SMA" or "Sunny Island". It is also a very popular off-grid Inverter and would benefit greatly, if diyBMS would support CAN communication so that it can do its job with more control. Is it supported yet at all? If not, I found some other BMS code that could be used (seems to be close to Victron?): https://github.com/Tom-evnut/TeslaBMSV2

[stuartpittaway]

Thanks for the link, CAN does work with the newer controller and is used to communicate with Victron kit.

I couldn't find any documentation on SMA integration, and I also don't have any kit to test with, which makes building an interface a bit difficult.

Do you have any contacts at SMA ?

[chron0]

I think the full CAN protocol doc of them is NDA limited, but I've found this:

When I compare this with teslabms code, it seems victron/SMA seem to be using the same IDs:

https://github.com/Tom-evnut/TeslaBMSV2/blob/c9f6c53e91878b5a219105ede3a8a9533e13000d/TeslaBMSV2.ino#L1713

Unfortunately I dont have a contact to SMA either to get the full protocol, but at least at a first glance at the above excerpt and the teslabms code this seems to be the basics that are needed to get basic minimum communication going.

[stuartpittaway]

Ok, I think it should be easy enough to use the table you provide to transmit the values, but we still have the testing issue to resolve.

Do you know anyone who could test?

[chron0]

I have my cells already here, now it came down to BMS/Inverter choices. I am favoring the Sunny Island but wanted to have an open-source BMS I can use with it. Now that this seems more likely, I'll buy the Sunny Island and hopefully will get PCBs/Parts for the diyBMS which currently seems to be the biggest PITA. Then I can run tests and extend SMA communication capabilities when needed.

[happy5069]

I have a SunnyIsland that I'm willing to use for testing. I have built 16 BMS boards built and downloaded. I

[chron0]

@happy5069: That would be great <3. Are you happy with its performance/configurability/efficiency/reliability? I would assume it should get SOC and base data from diyBMS when you set it to "Victron". As far as I've read, SI makes most of its decision based on SOC % values, so that seems like the most important metric to have.

[chron0]

@stuartpittaway maybe it would make sense to basically copy the victron set 1:1 into an sma class for now that is user selectable. Over time PRs can go into this separate SMA class and change/extend it.

[happy5069]

I have been using SI with lead acid batteries for over 5 years. I wanted to upgrade the lead acid to LiFEPO4 so I ordered a wad of batteries that is when the fun started.

SI has firmware for LiFEPO4 which depends on keep alive messages and current requests being sent to the SI. The SI provides total pack voltage and responds to current requests, but I don't know the actual voltage of the individual cells making up the battery pack. I've been using a raspberry Pi to keep the SI alive by sending messages to the SI and sending SI current requests. The raspberry pi code has to adjust the current requests based on total pack voltage. Currently, I don't have any visibility into the individual cell state. That is where the DIYBMS boards come into the picture necessitating more code to integrate the DIYBMS.

A more practical solution is to marry the SI with the DIYBMS controller to replace my RPi keeping the SI happy and the batteries within their operational limits to provide a totally automated system.

[chron0]

From the above document excerpt i would say that the victron config sends the same mandatory IDs the SI requires. Cell level data will always be the BMS job as well as SOC determination. That also necessitates a bidirectional shunt on diyBMS side for it to keep track of SOC to report to SI.

[happy5069]

I had my son look at the victron_canbus.cpp. As you mentioned the IDs look the same - but there's some detail and logic missing.

  struct data351
  {
    // CVL
    uint16_t chargevoltagelimit;
    // CCL
    int16_t maxchargecurrent;
    // DCL
    int16_t maxdischargecurrent;
    // Not currently used by Victron
    // uint16_t dischargevoltage;
  };

SI will lock out if pack voltage goes above chargevoltagelimit or below dischargevoltage. maxchargecurrent is the amount of current the BMS is requesting and it's the BMS's responsibility to taper this current to avoid exceeding the chargevoltagelimit. As far as we can tell, it doesn't respect maxdischargecurrent - and your only recourse is to tell the inverter to go into standby by sending it a CAN message with ID 0x00F.

[chron0]

I see. I was operating under the assumption that you can set chargevoltagelimit and dischargevoltage as well as maxchargecurrent in SI configuration manually, according to your pack specificiation, so that it doesnt have to rely on BMS leading the way and only really needing SOC % to determine what to do.

Ofc that is only my impression after reading the manual, after 5 years you probably know better in practice, than I do in theory. These IDs would have to be added then to make it work out-of-the-box. A new sma_canbus.cpp based on victron_canbus.cpp would probably be the best point to start.

[happy5069]

it doesn't have to rely on BMS leading the way only really needing SOC % to determine what to do

Yes and no. As you noted, a lot of the logic on the SI hinges on the SOC %. What's missing within the SI is a CC/CV charge controller that uses CVL and CCL as you'd expect, so instead your BMS needs to implement it.

CC is pretty easy - just set maxchargecurrent to CCL until pack voltage reaches a set point (below chargevoltagelimit). CV is more challenging, but you can approximate it with successive CC cycles at lower currents.

[chron0]

I was hoping that 222.13 BatChrgVtgMan would be enough when SI is getting actual SOC values. But thanks for the infos, this will be relevant for me in the future. Hard to imagine/understand that there is no CC/CV in there...

[alex-pass]

Maybe this helps

https://www.rec-bms.com/datasheet/UserManual9R_SMA.pdf

[red0909]

i have the sunny island running with the diy bms in the old code it was possible with the victron canbus settings

now(firmware 2023 02 14) it is possible with the pylontech canbus settings, victron settings are bit buggy now the si does not work with them

i dont know why but every voltage send from the bms to the sunny island the si will make it 1v less so if you want a charge voltage of 56v on the sunny island you have to transmit 57v from bms, looks like a bug in the sunny island. tested with seplos bms same result so its not the diy bms that cause this issue

my sunny island has the actual firmware and is the new 13 model maybe i should ask sma about this

[kommando828]

This 1V drop against the BMS Target V by the Sunny Island is an Off-Grid safety feature, it looks to have been put in place as the Frequency Shifting curtailment of PV output has a lag. With a BMS target of 56.2V and the SI showing as 55.2V I have seen 55.8V before the frequency was over 51htz, only then did the PV output start to be curtailed. When you connect the SI to the Grid the 1V drop disappears, as the Grid is effectively a huge battery the V stays within the BMS limits so the 1V drop is not needed.