PIP-4048MS and PIP-5048MS inverters

[E85]

Thanks for the swift and helpful reply!

I recommend you use 14S if at all possible. Replacing the capacitors and MOSFETs is a terrible job, and even the replacements would last longer at the lower voltages.

Yes I totally understand, 14S4P is simple I would loose energy capacity off course but if I manage to make (14) 6P blocks then that will give me even 1,3x the capacity of a16S4P battery pack

I recommend you use the LFP version. You can read about the differences here:
http://forums.aeva.asn.au/viewtopic.php ... 332#p64095
Although some of the numbers have changed since then, the main reason for the LFP version is LFP's very flat voltage-versus-SoC curve. LMO isn't mentioned, because I thought it was an obsolete chemistry, but it has a flat curve similar to LFP, although at a voltage about 16/14 times higher.

I see, I had missed that post, it all makes sense to me now.

I will only have to find a suitable windows PC for the flashing then…

Thanks again!

[E85]

The modified PIP-4048MS and PIP-5048MS firmware with the Dynamic Charge Current Control is perfect i my case because I would like to dynamically reduce the charging current when the 123smartBMS sees that a cell is reaching its max voltage.
Just to make sure that I understand the fail-safe function of the dynamic mode correctly, I would need to send a MNCHGC0### command at least once a minute (otherwise it will stop charging)?

[coulomb]

I would need to send a MNCHGC0### command at least once a minute (otherwise it will stop charging)?

Yes. It will behave as if an MNCHGC0500 command has been sent, setting the current limit to zero, except that the clock icon will appear next to the flashing dot. There will be no relay clicks or EEPROM wear associated with this. So if it happens during testing or the like, it's not a problem, charging will merely pause.

[ Edit: I had how the dot and clock icon would or would not flash all wrong. ]

[Ibiza]

Hi gents
wonder if some one can help with an advice!
Can pip 4048ms charge 18650 li-ion batteries? I am building a power wall with 18650 cells.
thanks in advance.

[Walde]

Hi gents
wonder if some one can help with an advice!
Can pip 4048ms charge 18650 li-ion batteries? I am building a power wall with 18650 cells.
thanks in advance.

yes i have a powerwall 18650 setup 14S120P

IMG_20190819_173909.jpg (3.13 MiB) Viewed 5161 times

IMG_20190406_123505.jpg (3.09 MiB) Viewed 5161 times

[Ibiza]

Hi Walde, thanks for your reply. I was thinking if PIP itself can charge 18650. I am trying to avoid spending more money. I need three PCM60Xs.
I have upgraded my inverters with Coloumb's and Weber's patched firmware.

[coulomb]

I was thinking if PIP itself can charge 18650.

Yes.

[Ibiza]

I was thinking if PIP itself can charge 18650.

Yes.

tnx

[weber]

I have moved all posts about PIP repairs and hardware modifications, to the topic that was called
"PIP Inverter Error "error 09" bus soft start failed", which has now been renamed PIP inverter repairs and hardware modifications.

[coulomb]

Frequently Asked Questions

I'm hoping to be able to point readers to these answers to frequently asked questions, to hopefully save typing in the future.

1. Q: Why am I getting low battery warnings? My lithium battery BMS says it's nearly full.
   
   A: These inverter-chargers were developed when lead-acid batteries were the norm. The terminal voltage of such batteries varies considerably with state of charge, and leaving the battery near empty is a really bad thing for this chemistry. Hence the low battery warning and alarm. Unfortunately, the manufacturer neglected to document what triggers and releases the low battery warning. With factory firmware, the low battery warning occurs at 2.0 V above the Low DC Cutoff voltage (setting 29). The low battery warning isn't released until the battery voltage rises to at least 4.0 V above the voltage in setting 29. Many LFP (LiFePO₄) batteries only have a range of about 4 volts from empty to full! That's why the LFP flavour of the patched firmware (but only the LFP flavour, and only if battery type is USE) changes these thresholds from 2.0 V to 0.5 V, and from 4.0 V to 1.0 V (so warning on at setting 29 plus 0.5 V, and warning off at setting 29 plus 1.0 V). Of course, not everyone chooses or even can use patched firmware, so the solution is to change setting 29 to be lower, say 2.0 V less than setting 12. That means you don't have as much protection against low battery voltage, but most LFP batteries have a Battery Management System that will protect against low cell voltage, and hence also low total battery voltage.
   
   
2. Q: Why does my inverter switch from battery to utility (bypass) mode, when the battery voltage isn't near the Back to Utility voltage (setting 12)?
   
   A: There are three parts to this answer. The first part is that when a battery is declared to be weak (it is below the voltage of the Back to Utility setting, setting 12), OR the battery voltage falls to less than 2.0 V above setting 29 (and hence a low battery warning is issued; see the previous question), then the inverter-charger will switch from battery to line (bypass) mode. So make sure that setting 29 is at least 2.0 V lower than setting 12, otherwise setting 12 will be ignored. For similar reasons, ensure that setting 29 is at least 4.0 V lower than setting 13 (unless 13 is FUL). Otherwise, setting 13 will be ignored.
   Secondly, as soon as the inverter output reaches 110% (so 4.4 kW or 5.5 kW, depending on your model), even though your're allowed a 100% overload (i.e. 200% of rated power) for 5 seconds, the firmware will deem the load to be abnormal, and it will switch to utility if available.
   
   Finally, the factory firmware reacts to instantaneous battery voltage, without any compensation for the battery internal resistance. In other words, it ignores perfectly ordinary and somewhat predictable voltage sag under load. This will sometimes cause the inverter to switch to line mode earlier than you expect. Patched firmware with the KettleKomp™ feature does take internal resistance into consideration, compensating for the expected voltage sag. Hence, patched firmware will switch less often to line mode, although only if the load happens to stay under 110% of rated. As an added bonus, most patched firmware will switch to line mode for a minimum of only 2 minutes, compared to a minimum of 10 minutes for factory firmware.
   
   
3. Q: Why can't I change setting 28 (AC output mode)?
   
   A: As it says in the Parallel Guide, "this setting is only available when the inverter is in standby mode (Switch off)". Well, it still takes effect when the switch is on, you just can't change it. But won't the inverter go off if I switch the power off? Maybe. If you have any charge source (PV or AC-in), then it actually won't switch off. But even if you have neither of these, you still have about 30 seconds before the inverter goes dark. So if necessary, navigate to setting 28, then turn off the switch, make the change to SnG (if you have only a single inverter, or to other values as required), press enter to confirm the change, and for good measure press ESC to exit LCD setting mode. You should have plenty of time to do this before the display goes dark and you can't complete the change. If you do miss out for whatever reason, just press the inverter switch back to ON and try again.
   
   
4. Q: How do I get rid of the "HS" on my LC Display?
   
   A: This is telling you it's a parallel MaSter machine. Factory firmware shows "HS" instead of "MS" because their "M" looks even less like a real "M" than their "H", with their 7 segment mapping ("font"). If you have paralleled or three phase machines, this is normal (one will be master, and the others will be slaves showing "SL" in place of "HS or "MS"). But somehow, single machines seem to get stuck with setting 28 (AC output mode) set to PAL (PAraraLlel mode). This should not cause problems, but there have been reports that it does, so it should be corrected, by changing setting 28 to SnG. See the previous question for use of the power switch when changing setting 28.
   
   
5. Q: Can I add more panel power than the inverter-charger is rated for?
   
   A: The short answer is yes, but only a little (15-25% more than rated). Yes, the solar charge controller will only try to use what it needs or can handle, but it's a problem of control. Imagine that you've driven a low powered car all your life, then find yourself behind the wheel of a muscle car. Can you drive it under the speed limit without screeching the tyres? Yes, but you'd better change your driving style. If you drive it as though it was your low powered car, you'll be speeding and screeching because the same pedal movement now results in a lot more action. It's similar with a solar charge controller, except that it has no idea that you've connected a lot more solar power, so when it tries to control the power assuming nominal power or less, when conditions change it will constantly be overshooting and undershooting its power target. Of course, available solar power is constantly changing. Depending on many factors, this could cause your battery distress, or cause it to disconnect if it has a BMS, and the current and voltage surges might damage the solar charge controller or more. The 10-20% figure mentioned is a guess based partly on experience. One Voltronic Power model lists rated PV power at 4000 W, and maximum allowed PV power at 4500 W, an increase over rated of 12.5%. It's certainly attractive to add more panels; that way you get more production in marginal circumstances, such as early or late in the day, in cloudy/shaded conditions, and in winter. Just go easy on the "overclocking" and be aware of the potential problems.
   
   
6. Q: Can I read out the existing firmware from my inverter before I overwrite it with your patched firmware, so I can put it back later if I need to?
   
   A: Alas, no; you'd need special hardware and the password. However, if you want to revert to the factory firmware that a patched firmware is based on, you can always do that. Every patched firmware zip file contains the unpatched file, dsp_original...hex, as well as the patched file, dsp_L...hex . So you can simply:
   • Delete dsp.hex, because it will always be a copy of one of the other .hex files, and you can never be sure which.
   • Copy-and-paste dsp_original...hex and rename the copy to dsp.hex. The reflash tool looks for the fixed name dsp.hex .
   Running the reflash tool again will then reflash with the original factory firmware. You can do the obvious variation of the above to reflash with the patched firmware again if desired.
   
   
7. Q: Why doesn't my inverter charge the battery when I use my generator?
   
   A: Firstly, check that the AC-in icon (sine wave in a circle) is present. If not, there is no AC-in, and you need to check your connections.
   If the AC-in icon is present but flashing, that indicates that the generator's output voltage waveform is of poor quality or the frequency is out of range. Inverter based generators are best, because they generate a near-perfect sine wave whose frequency is set by a quartz crystal, not a mechanical engine with varying loads. Some generators can be made to work by placing a small (200 - 800 W) load on the generator before connecting it to the inverter. That seems to settle down the engine and its speed governor, enough that the inverter may accept the generator power, and start using it to power loads and charge the battery. Once this happens, you can usually disconnect the temporary load.
   
   Check that you have setting 03 (AC input voltage range) set to APL (the default). This gives the inverter the maximum tolerance for generator variability.
   
   If all the above fail, you'll have to either get a different generator, or use an external battery charger (suitable for your battery, e.g. 48 V).
   
   
8. Q: I have a 145 V max PV model. Why doesn't my inverter-charger use any/all of available PV some of the time?
   
   A: I note that the 145 V figure is the absolute, never-exceed maximum. It's not a "let me see if I can squeeze under that limit" thing. At a panel voltage of 145 V, PV power is limited to zero. At 144 V, the power is restricted to 6.7% of maximum. Even at 130 V, where the power is not restricted at all, the solar charge controller seems to run much hotter, and may limit itself due to temperature. PIP-5048MK (Axpert King) models seem to be particularly sensitive to high PV voltage. What this means in practice is that with 72-cell panels (or 144-half-cell panels), which are the most common type as of 2020, you can only wire them 2S (two panels in series). You can wire as many strings of two panels as needed, but as per FAQ 5, don't exceed 10-20% of rated PV power (rated power is now usually 4000 W for 5 kVA models). Wiring 3S (3 panels in series per string) will almost always lead to trouble if you're using 72-cell panels. 60-cell panels can be run in 3S, and will probably work better in 3S than 2S. Remember also that the Voc of a panel is given at standard operating conditions and 25°C; panel voltage typically increases about 7% at 0°C.
   
   This problem is becoming worse as panels become larger and larger in power output. Part of how this is achieved is that the cells output a higher voltage than their predecessors.

[ Edit Q4: There have been reports of strange problems going away when a single machine is put back to SnG AC output mode. ]
[ Edit Q2: determined → declared ]
[ Edit Q1: added "and only if battery type is USE" ]
[ Edit by weber: Moved anchors up so the question doesn't get cut off. Added blank lines between paragraphs. ]
[ Edit Q5: 10-20% oversize → 15-25% oversize ]

[Prajna]

Well I have to say, it's taken me several days to read all the posts on this thread but, man, it is packed with fabulous information. Hats off to Coulomb, Weber and the rest of you guys!

My first post on the forum. I came here looking for information on communicating with these and similar Voltronic Inverter/chargers since a friend bought one recently and I was disgusted at the WatchPower software and wanted to write something more useful.

So I have begun developing an app in node.js and electron ('coz I mostly do web development and like to write javascript). So far I have the general scaffolding there to execute protocol's query commands and many of the undocumented ones. The system is about 10km away and I don't have transport so testing is a bit slow and I was struggling initially to communicate with it at all. On my last visit I managed to get a (NAKss back from the device, so hopefully I'm getting somewhere.

For anyone interested, development is at http://github.com/prajna-pranab/converse

@coulomb , The modes listed below seem to be different to those in the QMOD query. Do you know what the other modes are and what codes they use for them?

Also the status bitfield (probably ascii bytefield) doesn't seem right. As I understand it the protocol uses ascii digits '0' and '1' to represent fields like this (as, for example in the QPIWS query). If that is so then your Status field description doesn't make a lot of sense to me. You seem to have two bit 7s and no bit 1 or 6. Can you clarify it for me please.

Inverter mode as pic 99 (e.g. battery mode = 03, line mode = 04, fault mode = 06)

...

Status: pic 999
   Bit 2: load relay on
   Bit 3: inverter relay on
   Bit 7: AC input relay (N side) on
   Bit 5: battery mode
   Bit 7: Line mode

btw, I found a whole list of commands by decompiling WatchPower. I can post them if you don't have them already.

[paulvk]

Prajna have you the communication protocol PDF file , also if you have the internet at both places you can use the HLK RM04 to connect to the inverters.
I have ATMEL AVR here talking to my inverters showing what watch power does but on two LCD screens.
Regards Paul

[Prajna]

Hi Paul, sure I have a number of different versions of the protocol file. It's a bit like standards: there are so many to choose from and none are standard It seems much of the protocol is undocumented and the different versions are incompatible. For instance the MPPT-3000 Standard RS232 communication Protocol returns quite different information in response to a QPIWS query than earlier versions. Decompiling WatchPower it seems they do a lot of checking to see what the model of the device is and send different commands or interpret the responses differently depending on the model. I would have thought a close analysis of WatchPower, using something like http://www.decompiler.com/, would pay dividends in terms of identifying undocumented commands and discovering the different models and how they are identified by the software.

I will get round to setting up remote coms for the system but for now I'm just plugging into the inverter RS232.

Thanks for the reply.

[coulomb]

My first post on the forum.

Welcome.

On my last visit I managed to get a (NAKss back from the device, so hopefully I'm getting somewhere.

Well, you have communications happening, to and from. But you might not be getting the CRCs correct, etc.

@coulomb , The modes listed below seem to be different to those in the QMOD query. Do you know what the other modes are and what codes they use for them?

This is the variable bPVMode. It values are
0 Power on mode. QMOD reports P.
2 Standby mode. QMOD reports S.
3 Battery mode. QMOD reports B.
4 Line mode (BYPASS displayed). QMOD reports L or S if main switch is off.
5 Bypass mode (like line mode, but the bus voltage is too high). QMOD reports L.
6 Fault mode. QMOD reports F.
7 Shutdown mode. QMOD reports D.

Also the status bitfield (probably ascii bytefield) doesn't seem right. As I understand it the protocol uses ascii digits '0' and '1' to represent fields like this (as, for example in the QPIWS query). If that is so then your Status field description doesn't make a lot of sense to me. You seem to have two bit 7s and no bit 1 or 6. Can you clarify it for me please.

Oops! Sorry, typo:

Status: pic 999
   Bit 2: load relay on
   Bit 3: inverter relay on
   Bit 7: AC input relay (N side) on
   Bit 5: battery mode
   Bit 6: Line mode

The last one should have read bit 6. Edited now.

btw, I found a whole list of commands by decompiling WatchPower. I can post them if you don't have them already.

I have a fairly complete idea of commands, thanks. I'd prefer that you didn't post a list of all that you know, because some of them are dangerous, and it's best if people didn't fiddle with them indiscriminately. I nearly published all I know at one point, and decided against it. Despite my usual support for open dialogue about these things.

[Prajna]

This is the variable bPVMode. It values are
0 Power on mode. QMOD reports P.
2 Standby mode. QMOD reports S.
3 Battery mode. QMOD reports B.
4 Line mode (BYPASS displayed). QMOD reports L or S if main switch is off.
5 Bypass mode (like line mode, but the bus voltage is too high). QMOD reports L.
6 Fault mode. QMOD reports F.
7 Shutdown mode. QMOD reports D.

That clarifies things, Coulomb, thank you.

Is status bit 1 reserved? bit 4?

Edited to add: coms, still difficult. I think the crc calculation is ok, I'll just have to figure out how to use nodejs.serialports correctly. I got better data back last time I visited than today. Best I managed today was a '(', not even a NAK. Oh well, onwards and stuff.

[coulomb]

As I understand it the protocol uses ascii digits '0' and '1' to represent fields like this (as, for example in the QPIWS query). If that is so then your Status field description doesn't make a lot of sense to me. Can you clarify it for me please.

Sorry, I forgot to address this part of your post. Those fields aren't intended to use the same conventions. I know that seems inconsistent and confusing, but I basically pasted the status field descriptions from my reverse engineering comments for that variable. I have reasons to maintain the usual bit numbering for that variable (e.g. bit 0 is the Least Significant Bit), since there are instructions that use that access that word and use that bit numbering.

Think of it this way: the status field comes from an actual word in memory; these are conventionally numbered 15 (MSB) to 0 (LSB). There are other command result fields that display as arbitrarily long strings of zeroes and ones, but don't come from one variable, so it's easier to number the bits more naturally for humans, starting from one at the left.

[Prajna]

Thanks for spotting that, Coulomb. I'm still confused about the status field though. You say it is in the format '999'. To me that suggests we can have 3 values (or flags) expressed as ascii 0s or 1s. So you are working from the raw word in the firmware (16 bits?) but how does that get packed into a 3 byte response?

[coulomb]

how does that get packed into a 3 byte response?

As a decimal number. For example, 012 = 8 + 4 = 2³ + 2², so bits 3 and 2 are set (inverter and load relays are on respectively, everything else is off).
Or 012 = 0000 1100 in binary, again with bits 3 and 2 set.

Or as Weber emailed me; perhaps I should have taken his suggestion:

Status: pic 999
004: load relay on
008: inverter relay on
032: battery mode
064: Line mode
128: AC input relay (N side) on
Any of these may be added together

[Prajna]

Excellent. Thanks Coulomb. All clear now. QFLAG gave me a few problems too but I figured it out eventually by looking at the actual response from the system and rereading the protocol. Boy do they go strange and inconsistent ways of doing things!

[paulvk]

I have got myself a couple of Nextion https://nextion.tech/ displays and am going to try and make touch screen remote panel for the inverters with the atmel AVR sending code to the display and inverter , I already have the AVRs interrogating the inverter as can be seen on an earlier post but with the Nextion things like gauges , sliders , buttons , text boxes and pictures can be added even animation with the enhanced version. If some one has the skill to alter the libraries for the Nextion GUI the avr may not be needed just a RS232 buffer chip as the display is 5v rs232.
Regards Paul

[Wulfee]

Hi, newly joined member here. This seems to be the place to find information when it comes to MPP Solar inverters.

So I've got my brand new 5048MS(64) sitting in front of me. It's a nice bit of kit. So far I've wired it up to one of my L-Ion batteries and the mains and had a little play. I've connected it to my Pi and using some python code managed to change settings and such.

Initially I am not going to attach any solar panels to it. I want to make it charge from the grid at night when I get cheap rate and then use the battery to power loads during the day till it runs out and then have it switch over to grid pass through. I have a Pi running 24/7 and I've got this basically working by changing the PCP (I think it was) value to make it start and stop charging at the times I want.

The next step is to make it charge from the grid during the day when I am exporting from my other solar inverter. I know how much I would need to ask it to charge (this is changing from moment to moment depending on weather and loads in the house). I would need to adjust the charge value every 15 seconds or so to values between 0 amps and the units max (30 amps I think). From what I understand from reading this forum I am going to need to flash my unit with new firmware in order to be able to achieve this?

Does the updated firmware also provide any benefits when it comes to using L-Ion based batteries (such as making the little battery indicator on the display give a more accurate representation of SOC)?

[coulomb]

Hi, newly joined member here.

Welcome to the forum.

This seems to be the place to find information when it comes to MPP Solar inverters.

We like to think so .

I know how much I would need to ask it to charge (this is changing from moment to moment depending on weather and loads in the house). I would need to adjust the charge value every 15 seconds or so to values between 0 amps and the units max (30 amps I think). From what I understand from reading this forum I am going to need to flash my unit with new firmware in order to be able to achieve this?

You can in theory use the standard firmware, but it will limit you to very coarse steps (like multiples of 10 A, with a special exception for 2 A), and it will wear the EEPROM in your machine. I think we concluded that the EEPROM wear should be fine, but it seems silly to do it. The other thing is that every time you change any charge related limit, the solar charge controller gets reset, so you lose about 30 seconds of charging. So: really the standard firmware is impractical.

There is a slight hassle, however. We only modify the total charge current limit command, not the utility charge current limit command. So when you eventually have PV connected, you'll have to figure out how much PV power is coming in, convert it to a battery current, and adjust the total charge current limit to be that plus what you calculate you have from your grid connected inverter. Hopefully this won't be too hard.

Please check that your present firmware is 72.20 or thereabouts. If so, you can update to 72.20e patched firmware.

Does the updated firmware also provide any benefits when it comes to using L-Ion based batteries (such as making the little battery indicator on the display give a more accurate representation of SOC)?

It has some other benefits, and it improves the SOC meter, but it's still not doing coulomb counting. So it's still voltage based, but with LFP voltages in mind, and compensated for loads and/or charging. It also has several thresholds changed to be much more LFP-friendly. Is your battery LFP (LiFePO₄), or other Lithium Ion?

There are also the fixes for the premature float bugs, AussieView™, KettleKomp™, improved "font", etc.

[Wulfee]

Please check that your present firmware is 72.20 or thereabouts. If so, you can update to 72.20e patched firmware.

My current firmware is 72.30, that should be ok?

Is your battery LFP (LiFePO₄), or other Lithium Ion?

It's home made Lithium Ion. From what I was reading it looks the the non LiFePO4 firmware is better for that?

There is a slight hassle, however. We only modify the total charge current limit command, not the utility charge current limit command.

So if I don't connect any solar panels to it, does that mean I won't be able to get it to charge from the grid at the rate I want?

Thanks for the responses.

[coulomb]

My current firmware is 72.30, that should be ok?

Yes, that should be fine. You will miss out on whatever improvements (hopefully!) are in 72.30 but not in 72.20, but in my experience these are quite minor.

Is your battery LFP (LiFePO₄), or other Lithium Ion?

It's home made Lithium Ion.

That doesn't completely answer the question. You might be making a home-make LFP battery. What is the nominal voltage of your cells? If around 3.2 V, then it's LFP. If 3.6 V or more, it's not LFP.

From what I was reading it looks the the non LiFePO4 firmware is better for that?

Assuming it's a 3.7 V per cell chemistry, then yes, you need the LC flavour of the patched firmware. The only difference is a handful of voltage thresholds, but it's important to choose the correct flavour.

So if I don't connect any solar panels to it, does that mean I won't be able to get it to charge from the grid at the rate I want?

Not at all. The command we've altered with the ability to specify any total charge current (to one amp resolution) is the MNCHGC command. It specifies the present total charge current limit (PV plus utility charging). So with no PV charging, all your charging will be utility charging. So effectively, you're setting the utility charging limit, since PV charging will always be zero. So that's perfect for your needs right now.

As an example, suppose you have enough grid connected solar power to charge the battery at 23 A. You'd set the dynamic charge current to 23 A with a command of MNCHGC0523. Now suppose that you also have 10 A (battery side) of PV charge current. That same limit of 23 A will really restrict you to 13 A of utility charging. But all you have to do is use another command to find out how much PV charge current there is, and add it to the 23 A you want for utility charging. So you'd set the total current limit to 33 A, with a MNCHGC0533 command. The inverter knows to prioritise PV charge current over utility charge current, so it will figure out that the present set points should be 10 A for PV charging and 23 A for utility charging.

Actually, as I write this, I see a problem. When you measure 10 A of PV charge current, it does not mean that only 10 A is available, just that it figured out 10 A as the correct value based on the combination of availability and the settings last time it figured this out. For example, it might be able to charge at 20 A from PV, if only you had specified a larger limit. So you might need to have some sort of outer feedback loop, that guesses a current limit, measures how much utility charging results, and adjust the guess accordingly for next time. It might be possible to guess the PV charge current based on the known grid-connect charge power; you would expect that there would be an approximate constant of proportionality. Or, you might choose to put all your PV panels on your existing grid connected inverter, just to simplify things.

Thinking about this a little more, it might not be a problem at all. Let's take the example again of 23 A of utility charging, and 10 A of PV charging. You have the limit set at 33 A. Let's say the sun comes out from a light cloud, allowing about 10% more PV power. So now you have 12 A available from PV, and 25 A from utility. You only update the limit every 15 seconds (say), so at the end of that period, you have 12 A of PV charging and only 21 A of utility charging. The extra PV charge current has "robbed" the system of 2 A of utility charging. But next cycle, you set the limit to 12+25 = 37 A, and all is well again.

The main problem might be when the available solar power changes a lot. Let's say there is bad cloud, and you have 3 A of PV charging and 5 A of utility charging. Limit is 8 A. The sun comes out from behind a cloud, and suddenly there is 20 A of PV available (but you don't know that yet), and 30 A of utility charging. You'll get 8 A of PV charging at the end of this cycle, and no utility charging. You will set the limit to 8+30 = 38 A, which will result in 20 A of PV and 18 A of utility charging. You'll miss out on 30-18 = 12 A of utility charging. By the start of the next cycle, the cloud edge effect is gone, and you have 15 A of PV available (you do know this now, since the PV emasurement isn't "clipped" by the limit), and 25 A of utility charging. So you set the limit to 15+25 = 40 A, and end up with 15 A of PV and 40-15 = 25 A of utility charging. [ Edit: in other words, this cycle is exactly correct, and the effect of the sudden jump has already gone. ] So you end up with one period of sub-optimal performance, and only when the present limit is lower than the available PV power (which I'd say would be quite rare).

[Wulfee]

That doesn't completely answer the question. You might be making a home-make LFP battery. What is the nominal voltage of your cells? If around 3.2 V, then it's LFP. If 3.6 V or more, it's not LFP.

It's definitely Lithium Ion (not Lithium Iron Phosphate) so 3.7v per cell.

you need the LC flavour of the patched firmware. The only difference is a handful of voltage thresholds

So does the LC flavour give a more realistic battery % indicator for Lithium Ion batteries on the front display?

Not at all. The command we've altered with the ability to specify any total charge current (to one amp resolution) is the MNCHGC command. It specifies the present total charge current limit (PV plus utility charging). So with no PV charging, all your charging will be utility charging. So effectively, you're setting the utility charging limit, since PV charging will always be zero. So that's perfect for your needs right now.

Great. I may never connect solar panels to it as I already have 3 other grid connected inverters for that. So would I set the utility charging value to max (30A) and then control the actual utility charge level with the MNCHGC command? If so then that make sense to me.

How risky is it to update the firmware? I understand you can completely brick the inverter if it goes wrong?

Thanks again for the responses.