Batrium SMA Sunny Island Integration issue?

[ChrisFullPower]

I am getting to learn about the SMA SI CAN protocol and encodings so I can read what is being passed as well as what ID's I should look at when I dive into the main log output tomorrow.

This may be of some help.....

 

[callmeburton]

yeah I have that downloaded :D was a lot of help that and this site for faster calculations vs doing it all by hand https://cryptii.com/pipes/integer-encoder

 

[callmeburton]

Had the relay trip while I was in the room so I pulled the short set of logs (as they are easier to manage) and looked at them.

Don't see any errors (35A) being thrown ... only active warning (which is always there) is that the temp sensor isn't connected on the SMA SI (why have that if you have a BMS with 5 of them :/ )

SoH (state of health) does go to 0 before relay is tripped ... not sure what that is a measure of and I am also not sure if that just happens when the relay is tripped (meaning the relay tripping causes the SoH to drop to 0 no matter what)

I included the logs pulled for this ... there is a lot of can traffic which I can't find documentation for. The 300-309 series I think is all SMA and the 351-356 is all Batrium to SMA ... rest of them are unknown and I haven't dived into decoding them yet.

Worth noting though, the SMA out CAN traffic is still sending signals when the relay is tripped which tells me it likely isn't a connection issue (aka wire issue, or termination of wire issue) or that probably wouldn't happen?

Ignore the 65535 value for battery current, that is more like -1 - -3, forgot to flip the endian value when making my notes.

 

[callmeburton]

Attaching SMA SI settings, I can't see anything in here which would cause this behavior though but good to be thorough. Can do an examdif vs someone's system where this isn't happening maybe? idk.

 

[callmeburton]

The errors thrown right after the relay shuts off are the Low Battery Modes (bat preservation modes) ... these settings look like they have default values. I looked at the firmware versions, Got (in this order #1 - #4) 7.302, 7.300, 1.004, 1.000 ... not sure what the current firmware version is as it is proving difficult to find on the SMA page.

EDIT: 7.304/7.300 is current
The SMA America site didn't like chrome for some reason, which is odd because Edge which is built off of chrome worked :/

SoH pg 110 in SI Manual
Only when the battery is new does its usable capacity correspond to the capacity specified by the battery manufacturer. As the battery ages and as a result of frequent insufficient charging, the battery's usable capacity may decrease considerably on a permanent or only temporary basis. The battery's state of health (display value "320.01 Soh") is a measurement of the present useable capacity expressed as a percentage relative to the nominal capacity. 100% means that the entire nominal capacity can be used. 50% means that only half of the original nominal battery capacity can be used. The state of health of the battery is determined using a self-adapting procedure which takes several charging cycles to collect accurate and reliable data. The current capacity for the Sunny Island is automatically adjusted downwards for temperatures below < 68°F (20°C) because of the significant drop in the usable capacity of the battery when temperatures fall below the rated temperature. For all lead-acid batteries, the nominal capacity is adjusted by a fixed factor of −0.6%/°F (−1%/°C). For NiCd batteries, a factor of − 0.4%/°F ( − 0.75%/°C) is used.

 

[callmeburton]

Extracted logs for a day or two, over 4 gigs of can traffic. Filtered for events where SoC was 0 then only included 300 series and 35A-F series ID's

Files found here https://docs.google.com/spreadsheets/d/196nEs3jqHcPWhH57wZDHS2x3UqB5Mm1gH-bnVlKV33k/edit?usp=sharing

Isolated 3 events and went forward / back in the records a bit to capture a couple 350+ series (from batrium to SMA) events
For full logs for this run you can DL it here https://drive.google.com/file/d/1hstDQPREjH7B5t0B_WLA3IsS5x5YQ_s6/view?usp=sharing

I modified the ID columns for colors, Green I believe comes from the SMA, Orange comes from Batrium to the SMA

 

[callmeburton]

Looking at these three events.
The highlighted 306 record, first two bits are SoH ... which comes from the SMA SI and read 0 SoH ... The description of this output in the manual says "State of health of the battery received from the external BMS"

This is where it gets odd .. if we look at 355 bit two the SoH is always 100% during these events. :/

BUT the key might be 305, bit set 4, which is SoC received from the external BMS ... which shows 0% before and during the event.

So this means the Batrium is putting out a signal, and the SI for whatever reason isn't getting it for the 1 second events ... ugh ... does this mean I need a RJ45 female to male with some pinouts I can tap into to see the signal reaches the end of the RJ45? I am tapped into the Batrium side of things right now as that is easier for sure >__<

Two thoughts.
1) The cable is somehow bad and somehow only shows this with random disconnects from BMS
2) The cable is fine an the jack is jacked ... somehow only showing this during random disconnects
3) (ok 3 thoughts), both the cable and the jack are fine and the SMA is screwed (somehow only showing this during random events :/ )

I can deal with 1 pretty easy and even test it pretty easily by setting up another cable, granted it wont be shielded

With number 2 though it is trickier to check and likely not too big of an issue IF I use my other SMA as the input for the batrium and then COM out to the current SMA COM in bypassing the port completely.

Not sure what I could do to check number three ... and the only thing I can hope is when the other SMA SI is master and the current one is slave the issue goes away.

 

[callmeburton]

@ChrisFullPower how goes the build?

 

[ChrisFullPower]

It’s up and running! I haven’t had a chance to really sit down and test anything yet but I have noticed a few random dips where Batrium will send out a false reading over their UDP protocol and it will show up in my MQTT logger as a zero reading. I’ll see if I can get a screenshot or something tonight.

 

[callmeburton]

do you have eyes on the raw CAN traffic as well or just UDP at this time?
Good to hear your up and running!

Still noting patterns with the Batrium ... on day 5 of the battery being sub 100% after charging from 50% Soc and resetting the SoC daily after ~6Ah gets into the battery and the SoC reaches 102% and then resets to 100% ... so far I think 30Ah has been put into the battery after it did its bypass resetting of the SoC.

 

[ChrisFullPower]

I have the CAN between the BMS and inverters up and running but I haven't got my PC on the bus yet. Maybe this week sometime?

 

[callmeburton]

Main load shed relay tripped which is very odd ... Batrium not showing any critical events so I will have to pull the SI logs tomorrow. Not sure if I mentioned it but I have the relay for the load shed relay running off the SI battery +/- molex connector to avoid issues with relay 1 tripping all the time ... so it is kind of odd it would trip like it did and it makes me think this wasn't the first time.

Its almost like the SI rebooted or something because the AC power relay on the SI was also tripped and had to reset to the closed position ... Current voltage at the shunt (for my records later) 53.96, cell 3.34/3.37, SoC 100% [batrium values]

 

[callmeburton]

So I was right, the whole SI restarted ... it seems like it lost connection to the BMS, and historically this means the BMS was still transmitting but the SI wasn't getting it :/

Is there a coms card in this thing I can swap out? It seems like a much better test of equipment at this point.

 

[callmeburton]

New new new findings ... Since I had a chance to download the logs I am now comparing when my NAS stopped responding (meaning it shut off) vs the SI evt logs ... Every time the SI did the behavior above 0__0 ... ugh (https://diysolarforum.com/threads/sma-sunny-island-turning-off-nas.60821/ )

@ChrisFullPower have any issues with yours so far?

@Hedges ever hear about issues with coms being lost on these units when the coms were proven to be sent at the time they are lost?

 

[Hedges]

The NAS disconnect issue I thought was AC dropout during grid switching. Did you find any logs indicating load-shed occurred? I remember some other thread where load-shed momentarily happened.

I haven't dug into SI comms much, and I see SMA Sunny Island CAN Protocol is for European model communications with BMS (different batteries supports vs. US model.)

I've used ComSync between multiple Sunny Islands and a Sunny Island Charger SIC40. That gets terminators both ends.

I've used RS485 adapter and ComSMA to put older Sunny Boy in offgrid condition for backup mode, and to connect Sunny Boy Control or Sunny WebBox. That also needs terminators at both ends, and what the documentation doesn't make clear is that pull up/down are also required somewhere. Sunny Boy Control and WebBox provide pull up/down, but without them connected pull up/down would be missing so data +/- sit at same voltage. Some of the Sunny Boy have headers which can be populated to connect the pull up/down resistors (in addition to a terminating resistor.)

On RS485 I've watched signals from Sunny Boy Control getting data from Sunny Boy. What I've never been able to trigger on and observe is the on/off grid signal from Sunny Island. Anybody know about that?

The need for Precharge resistor, which has been discussed elsewhere, is not mentioned in SI manual. But I see it in SMA Sunny Island CAN Protocol manual.

From reading this thread it appears a message from Batrium causes SI to believe state of health is zero, causing load shed. Usually I would be looking for poor signal integrity. Use a scope if you have one. Resistor termination (and pull-up if used), some wires disconnected, noisy ground (differential is supposed to help avoid), coupling to other wires (is comm wire next to power wires?)

If all other communication seems robust (and you wouldn't know without checking other data if it didn't cause visible behavior changes), then I' suspect the data coming from Batrium. Have you figured out what data goes into creating SoH figure? I see SI refers to some legacy algorithm for lead-acid; maybe that algorithm reacts badly to data from BMS.

 

[callmeburton]

The NAS disconnect issue I thought was AC dropout during grid switching. Did you find any logs indicating load-shed occurred? I remember some other thread where load-shed momentarily happened.

My SI load sheds like 6 times a day via relay1, which is why my actual load shed relay is no longer connected to it. Every time is because of BMS timeout. That said I monitored the traffic at those times and the BMS was transmitting, so far as I could tell since I could see SI and BMS traffic at the same time in the CAN logs, during an "event" ...

This time though the whole SI restarted ... it wasn't a load shed even but rater BMS lost contact event which triggered an autostart in the logs ... this has happened every time the NAS restarted according to my logs.

The need for Precharge resistor, which has been discussed elsewhere, is not mentioned in SI manual. But I see it in SMA Sunny Island CAN Protocol manual.

This is built into the BMS board, I verified it when I was in the process of adding one.

), some wires disconnected, noisy ground (differential is supposed to help avoid), coupling to other wires (is comm wire next to power wires?)

I have had the COMS in the load center passing AC at 90 degrees and DC in parallel at times. BUT as part of my experiment I have had it out of the load center completely and going straight into the face of the SI to avoid that issue. This cable is double shielded and has the ground wire connected on the BMS.

Have you figured out what data goes into creating SoH figure?

I think I found what this was in the past but I can't recall off the top of my head. All required COMS and some extra COMS options are created from the BMS looking at the raw CAN logs vs the CAN BUS SI documentation

The SI has terminators for COMs in two or three ports, forget which but they came that way second hand. This was previously used with AGM bank.

 

[Hedges]

Shields block electrostatic coupling from voltage of other wires if grounded at one end (or both).
They only block coupling from currents if grounded at both ends.
DC of course can have sharp transient edges.

Locating cable far away for testing would eliminate most of that.
Currents flowing through ground, causing offset or coupling, would not be avoided by doing this.

What else ties the boxes together? If just conduit that also carries current (or regardless), you could check at least with DMM for AC or DC between boxes. Long shot; communication issues related to firmware is usually the most likely, if signal integrity is good.


We would like SoC and SoH figures to be reasonably low-pass filtered so they don't react to impossible instantaneous changes.

 

[callmeburton]

Shields block electrostatic coupling from voltage of other wires if grounded at one end (or both).
They only block coupling from currents if grounded at both ends.

Interesting, I didn't realize this but it 100% makes sense why this would be the case. I know I can semi-easily ground one end of this cable at the BMS ... the other end at the SI will be a little trickier ... will likely have to peal the cable back, expose the shielding, wrap and bond another wire to it, then bond that to the "grounding" pin.

Locating cable far away for testing would eliminate most of that.

Right now the cable comes straight out, at least 4" from power sources, from the load center and loops back up to the SI where it goes straight in through the face (which isn't attached) into the COMs port. At what distances I wonder do I need shielding and is having my BMS inside the load center a bad idea without shielding it.

What else ties the boxes together?

The SI and the Load center are bonded, nothing else physically attaching the two boxes. EDIT: Just looked at the boxes, it seems "ground" from AC1/AC2 are the only things boned, not the case of the SI or the "ground" at the battery terminal.

The LC is bonded to the transfer switch which is bonded to the Load panel which is bonded to neutral.

When I am using the SI as the primary grid manager AC2 is fed through the Load Panel (LP) from the Grid, and the SI provides power to the transfer switch loads.
When the SI is OFF the transfer switch is powered by their original circuits from the grid at the LP

you could check at least with DMM for AC or DC between boxes

I will double check this when I ground the cable. I believe before I hooked everything up I checked continuity between all sources and the bonded boxes and didn't find anything that shouldn't be bonded.

We would like SoC and SoH figures to be reasonably low-pass filtered so they don't react to impossible instantaneous changes.

I don't think there are any adjustments i can make at the BMS to change how this information is transfered to the SI ... I only know other people with SI's use this BMS.

Just updated firmware / software, it was only one version off ... I was excited a little as the change logs for the software (as it had an update as well) indicate ramp down targets now being available for "some" inverters ... don't think SMA was on that list because nothing changed with the ramp targets screen.

 

[Hedges]

Interesting, I didn't realize this but it 100% makes sense why this would be the case. I know I can semi-easily ground one end of this cable at the BMS ... the other end at the SI will be a little trickier ... will likely have to peal the cable back, expose the shielding, wrap and bond another wire to it, then bond that to the "grounding" pin.

Ideal shielding is continuous around outside of connector. Pigtail works at lower frequencies, leaks at intermediate, is effective antenna when loop is 1/2 wavelength.

EM fields would couple differential mode into a wire separated at a distance from its return, or common mode into a twisted pair. Less than perfect symmetry in terminations and circuitry converts common mode to differential. Shielding reduces coupling into the wires. There are graphs showing attenuation vs. frequency for various types of twisting and shielding of Ethernet cable. Two layers of shielding provides further attenuation.

This approach is used extensively in systems which have to be hardened, and test labs inject interference, often with clamp transformers. The spec call out an upper limit on current which came from field tests with a wire fed into 50 ohm instruments. I disagree with that lab test limit because in practice shields do not have 50 ohm terminations. If field tests had used clamp current pickup rather than 50 ohm instrument, the measurements would have been different.

Interference happens, and error detection/correction improve results. We had a "Proflnet" system providing shutdown based on alarms and watchdog. It was routed in a lower grade Ethernet cable than specified for the length, parallel to power cables. During power line transients the shutdown tripped, even though no Ethernet errors occurred. Ethernet has more levels of software correction than Proflnet, which only used hardware layer of Ethernet. Replacement of cable with proper degree of shielding (except for allowed unshielded patch cords at end) eliminated the upset.

But since only certain messages are being lost in your case, I suspect firmware not interference.

Right now the cable comes straight out, at least 4" from power sources, from the load center and loops back up to the SI where it goes straight in through the face (which isn't attached) into the COMs port. At what distances I wonder do I need shielding and is having my BMS inside the load center a bad idea without shielding it.

Should be good enough if power is twisted. Separate power wires would project field to a distance.

The SI and the Load center are bonded, nothing else physically attaching the two boxes. EDIT: Just looked at the boxes, it seems "ground" from AC1/AC2 are the only things boned, not the case of the SI or the "ground" at the battery terminal.

I think SI and other chassis, including any boxes SI communicates with like a BMS or lithium battery which has metal chassis or ground terminal ought to be bonded together. But what you don't want is significant current in ground wires; that would induce common mode voltage in signals. And you don't want ground to be signal reference for a single-ended signal because then voltage offset in ground is seen as signal.

Any electrical circuit should be bonded to ground at just one place so no current flows in ground from another location. AC has neutral/ground bond usually at utility service entrance. Elsewhere, EMI filters have capacitors from line and neutral to ground. RF or switching noise currents do get coupled into ground. Filter capacitors are of a size such that 60 Hz causes about 0.1 mA to 2 mA or so to flow in ground, not a problem for most applications.

Ethernet RJ45 jacks have center-tapped transformers coupled to ground, and shielded cables connect to ground. The fact Ethernet signals reference ground at both ends might induce some common-mode, but balanced transformers reject most such interference. (A common design error in circuits and PCB is to connect PCB reference plane to Ethernet; it then radiates noise.)

RS485 is not transformer isolated. It has a "ground" or reference wire, and differential data lines. It rejects a certain amount of common mode, but only between positive and negative rails of the ICs. If boxes at both ends in a factory floor environment had reference bonded to noisy ground I would expect problems.

I think AC1 "ground", AC2 "ground" are connected together an to case. I think battery "ground" is connected to case. (AC1 "neutral" and AC2 "neutral" are connected together."

SMA doesn't require battery to be grounded but allows either positive or negative ground. I think NEC requires this voltage of battery to be grounded. I think running a battery wire of sufficient size from battery negative to SI battery "ground" is the way to clear a fuse on battery positive in the event of positive side shorting to case.

The LC is bonded to the transfer switch which is bonded to the Load panel which is bonded to neutral.

When I am using the SI as the primary grid manager AC2 is fed through the Load Panel (LP) from the Grid, and the SI provides power to the transfer switch loads.
When the SI is OFF the transfer switch is powered by their original circuits from the grid at the LP

This is why I would be inclined to route ground both ways, if that makes a loop so be it.

I will double check this when I ground the cable. I believe before I hooked everything up I checked continuity between all sources and the bonded boxes and didn't find anything that shouldn't be bonded.

You can check for DC resistance, and when powered check for AC and DC voltage. DMM probably on responds up to a couple kHz.

I don't think there are any adjustments i can make at the BMS to change how this information is transfered to the SI ... I only know other people with SI's use this BMS.

Maybe SI algorithm processes multiple parameters in such a way that when certain parameters are received it computes zero, then recomputes as more is received? Ideally SMA with a debugger would monitor state and when zero is seen, go back and determine how that happened. More difficult to do externally. On/off grid switching of "backup" was only one input signal and a couple parameters & functions affected, so I could readily determine what their bug was and SMA confirmed by reviewing firmware.

Just updated firmware / software, it was only one version off ... I was excited a little as the change logs for the software (as it had an update as well) indicate ramp down targets now being available for "some" inverters ... don't think SMA was on that list because nothing changed with the ramp targets screen.

 

[yokayzn]

Had the relay trip while I was in the room so I pulled the short set of logs (as they are easier to manage) and looked at them.

Don't see any errors (35A) being thrown ... only active warning (which is always there) is that the temp sensor isn't connected on the SMA SI (why have that if you have a BMS with 5 of them :/ )

SoH (state of health) does go to 0 before relay is tripped ... not sure what that is a measure of and I am also not sure if that just happens when the relay is tripped (meaning the relay tripping causes the SoH to drop to 0 no matter what)

I included the logs pulled for this ... there is a lot of can traffic which I can't find documentation for. The 300-309 series I think is all SMA and the 351-356 is all Batrium to SMA ... rest of them are unknown and I haven't dived into decoding them yet.

Worth noting though, the SMA out CAN traffic is still sending signals when the relay is tripped which tells me it likely isn't a connection issue (aka wire issue, or termination of wire issue) or that probably wouldn't happen?

Ignore the 65535 value for battery current, that is more like -1 - -3, forgot to flip the endian value when making my notes.

View attachment 138824

in your CAN dump, I noticed you received CAN identifier 0x10 & 0x70 for some time and then the identifiers changed to 0x305,306 etc. Can you please let me know what config changed to start receiving the expected CAN data (as per SMA data sheet)

 

[callmeburton]

in your CAN dump, I noticed you received CAN identifier 0x10 & 0x70 for some time and then the identifiers changed to 0x305,306 etc. Can you please let me know what config changed to start receiving the expected CAN data (as per SMA data sheet)

are you asking about the SI, the BMS, or the CAN READER ?
I think the BMS and SI output the traffic they are programmed for.

I didn't have to change settings on the CAN READER to see different parts of the traffic / signal ... it is mainly like a firehose of information. I filtered this out when I made other spreadsheets to illustrate the issues as I didn't think the 0x10 / 0x70 was part of the SI / BMS communications as it wasn't documented as such in the CAN Manual.

 

[callmeburton]

It’s up and running! I haven’t had a chance to really sit down and test anything yet but I have noticed a few random dips where Batrium will send out a false reading over their UDP protocol and it will show up in my MQTT logger as a zero reading. I’ll see if I can get a screenshot or something tonight.

Chris you ever get this hammered out?

I am still getting the unit cycling the relay as well as occasionally restarting ... thankfully, and ironically, I have important stuff on a external BMS now so when this happens I retain my internet connection for example.

Was trying to figure out what "third" device I need to COMM to the SMA SI since it has a lithium battery attached that wouldn't throw false readings and simply use the Batrium as a BMS monitor which controls a master relay.

 

[callmeburton]

UPDATE, and new issues:
So this system was decommissioned and setup in its new home as a slave unit to another master for my offgrid house build. I haven't had any restart issues I can recall since installing the BMS with the new unit, the master, receiving the signal.

BUT ... have some odd issues with the SI not listening to the BMS request for charging amps. The BMS will currently call for 20 amps, the SI will provide 20amps then quickly ramp up to 60+then back down to 20amps. During this time the BMS might cut off charging because cells are being over loaded with excess voltage. Then the process would repeat, the BMS calls for amps, the SI exceeds amps required, and the BMS cuts off charging. I believe this is limiting the amount I can charge my batteries in a day.

Hedges suggested the SI is dumping excess amps into the batteries and that might be the case but idk how to "fix" this problem. I have a SB setup with 12.5kW of PV and it has maxed out previously at 7.5kW AC in the past when I was observing it. The pattern I mentioned above typically happens after a larger load, like 1500-3000w, is placed on the system and the SI pulls from the batteries to facilitate the load request. When the load request is done the BMS's request for its 20 amps is met and exceeded.

 

[Hedges]

How many amps is the BMS configured to accept? (that was the issue another forum member just solved; it was limiting charging because BMS set to 25A from factory. He increased that to hit desired charge rate.) Maybe BMS has to be set to allow your maximum load dump.

How large a battery?
SMA recommends various size batteries depending on Sunny Island system size. For split-phase (2x SI), they recommend 5x BYD LV Flex, which I think is 25kWh.

https://files.sma.de/downloads/SI-LiIon-TI-en-48.pdf

You're having problems with relatively small load dump, no more than 3kW.
I figure lithium always had to be kept below full, leaving headroom for load dump in AC coupled systems.

 

[callmeburton]

How many amps is the BMS configured to accept?

I can adjust it to do whatever amps I want it to. I had it at 112 if under 80%, then 40, then 35, now 20.
The BMS isn't cutting off because of the amps though it is because the cell voltage for one or more cells is too high. When it was set to 112 I would have 6 or so cells screaming at the BMS to shut the charging off vs the 1 now with it set to 20.

When I had it set to 35 the peak load from the SI was 70 amps when it ramped up at the start.

How large a battery?

Way undersized. 280Ah right now. We are looking to add 2 more that size though as I don't think the single one will be enough for when we want to live here. Had one day the battery got down to 24% with our "normal" construction loads after a couple days of clouds / rain / snow etc.

SMA recommends various size batteries depending on Sunny Island system size.

I thought the sizing was based on the KW at the array? So a ~13kW array would at minimal need 1300Ah of battery which would be 5 of my 280ah batteries if I recall correctly.

https://files.sma.de/downloads/SI-LiIon-TI-en-48.pdf

I will read through this really quick. Thanks