9xsolar

Yeah, there was a glitch that was fixed in June (screen overview changes), as well as the mk2 process restarting issues. Hopefully it's better now :-)

2.08 does not have the serial-starter changes to properly detect the mk3-usb.
Let me explain quickly what happened. All those nice things are in 2.08~whatever because it was going to be released as part of 2.08. We were in code freeze and the release would have gone out on the Monday, but then a serious bug was discovered in the code for the ET340 current meter and a fix had to be released quickly. So 2.08 went out as essentially 2.07+bugfixes. In other words, most of the good stuff that is in 2.08~candidates is not in the 2.08 release. It is in the 2.09~candidates.
So what you can do (while booted into the 2.07~26 that you know works, so it is not overwritten), is upgrade to a 2.09 candidate. In fact, if you could do that and let me know I would appreciate it, as I suspect 2.09 will be released very soon after the summer holidays are over (in Europe). :-)

Download the swu file from here. Put it on a usb stick and do an offline update using the gui. Should do the trick :-)
I think you can also set your feed to candidate (instead of release) and update online.

I think an inverter like the Infinisolar or the Goodwe even really shines if you're a non-tinkerer. I mean, not much that can be adjusted, but once properly set up it really just works. The Multiplus can be somewhat overwheming (look at @9xsolar's tribulations on another thread :-) ), and the Axpert needs a little external help (from a BMV and an Rpi), so it does seem as if these two are the rich- and the poor man's tinkerkit respectively.

Yes, the inverter needs a little power of its own, around 200mA in my experience. On my 24V model, it's around 2W at night (when it is in bypass), but my CCGX and the various MPPTs and things all have quiescent draws and it adds up to around 6W total. While the inverter is running, there is always around 20W (once again, 24V model, it will be more for the 48V model, about 35W according to the specs) that's used.
Also, I assume you have the BMV installed? Then the figure it shows is as measured by the BMV, and includes inverter quiescent current plus the MPPTs current, the BMV itself, and anything else you might have on there (how is the Rpi powered?). You're right, it does slowly discharge the battery over night, it takes that power out of the battery rather than the grid. In my experience it accounts for around 0.2% drop in SoC overnight. I can live with that.
Sure. Put this in /etc/cron.d/powerlevels:
00 06 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue 200 00 08 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue 500 00 10 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue 800 00 13 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue 500 00 15 * * * root /usr/bin/dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue 200 First thing to note, times are in UTC, so you have to take into account your time zone. Second, quick crash course in crontab syntax. First 5 columns are minutes, hours, day, month, and day of week (0 == sunday, 6 == saturday). A * is a wildcard, so that means any day/month/year. So the above lines execute at 6AM, 8AM, 10AM, 1PM and 3PM. My timezone is UTC+2, so they really start at 8AM and end at 5PM.  The 6th column is the user that should run the command. Normally you want to run it as some non-root user, but this is just the easiest way to do it (and then you know the security settings for getting to dbus is not going to get in your way), and no real possibility of things going bad so just use root. The rest is the command to run. In my life I've had enough issues with the $PATH not being set as I thought it would, so I always hardcode the path... hence the /usr/bin prefix. And then the rest is the usual stuff...
You can repeat the line as many times as you want. You can set it right down to zero too, which is useful at night. You can adjust many other things (like MinSoc) as well. It really is quite flexible :-)
The dbus command is a little slow because it introspects the bus first to figure out the calling convention, but in this application it's fine.

That should be all you need. There was one version of the CCGX that would charge from the grid if your actual SoC was less than the minimum level configured on the ESS screen. The idea was that if there was a power outage and the batteries went below the minSoC, it would use the grid to get them back to the minSoc and then let solar do the rest. This feature caused problems, so it was removed again. So generally using one of the optimised settings (with or without battery life) is enough to make it not charge using the grid.
There is a force-charge thing too. This activates when it's been too long since the batteries have been fully charged. It's possible that this is what is currently triggering, because it is a new install maybe? I'll see if I can find the dbus-path for that, maybe we can check it and switch it off.
When you plug in a new device, a small bit of software starts up to service that device. When you unplug it, the software hangs around in the hope that it might come back... for some devices going away and coming back is completely normal (for example, the grid meter will go away when there is a power outage). Simply reboot and the duplicates will go away. The "service definitions" are created on a volatile in-memory space so they go away out of necessity when you reboot.

Let me quickly explain how ESS works. You basically draw a line down the middle of your battery storage, designating one side for backup purpose, and the other side for self-consumption. Say you set this to 80%. Then the top 20% is used for self-consumption and the bottom 80% for backup. Usually you set this value in such a way that a full day of solar can get the batteries back to 100%, in other words, it makes no sense to set it too low.
What ESS then does is attempt to zero the grid meter. It will use as much battery as it can to accomplish this goal, up to one of two possible limits: The inverter's rating, or the "Maximum Inverter Power" setting on the ESS configuration screen. The default setting is to have no limit, so if the inverter is large enough, the default behaviour is to power all your loads from the battery. It will continue to do this until the battery hits the minimum configured state of charge. Then it switches to bypass mode. It won't charge from the grid (unless force-charge is activated).
Don't be confused that on the screen it briefly shows Bypass and then goes back to showing Bulk or Absorption. It shows the "Vebus state", which is the combined state of things. It tells you that it wants to charge, but if there is no PV, it will just sit in that state doing nothing.
Now, imagine you have a few days of cloud cover, so now the battery is left at the minimum configured SoC for a few days. Whenever it is raised above that, the inverter turns on and puts it back to the configured minimum. Not good in the long run for Lead Acid batteries (lithium is better, but also need this to do balancing). So after a few days, the CCGX will turn on force-charge and it will take the batteries to 100%.
I find it simpler to set my ESS setup to "Optimised (without batterylife)", and then on days with lots of cloud cover, I set MinSoC to 100%. That works rather well, the inverter only turns on at 100% SoC, surplus power is fed to the loads, and if the battery drops to 99.9% it switches off again.
Now, some unix commands. If you log into the Rpi, I assume you know how to, then this command will show you what state it is in:
root@raspberrypi2:~# dbus -y com.victronenergy.settings /Settings/CGwacs/BatteryLife/State GetValue If that returns a 6, then ForceCharge is enabled. Normally it will alternate between 2 and 5. The corresponding text label is displayed on the ESS tab next to the "BatteryLife state" label.
Also, the "Keep Batteries Charged" option only works with PV-inverters. It is broken with DC solar chargers. Has been for a while.

Keep in mind that was done by me and I tried to be as impartial as possible. I asked @Chris Hobson just to verify that what I wrote was what I meant (Thanks Chris for the help) Also it should be noted that @The Terrible Triplett arranged through Victron SA for the SCC and we should give that man a Bells for his bravesness. Lastly the guys from SP Powerunits who was kind enough to give the SCC for testing. If you are in the Pretoria area it will be well worth your time to go by them. In the short time that I spoke with them I realised that there is still a massive amount if info that I don't know and I could have saved a fair amount of money have I took the time to chat to them beforehand.
As for the report here is what I came up with:
The System:
My current setup consists of the following:
·         12 x 260 w solar panels set in 3 panels per array
·         8 x 6-GFM-170F batteries
·         Victron BMV 702 Battery Monitor
·         1 Axpert 5000 VA – Firmware 72.80 Loaded
·         Victron 150/35 SCC (Test Unit)
First Method:
I have been testing the two SCC’s over a period days alternating between them to see how they perform under my day to day conditions. Now the consumption on a day to day basis does not stay consistent as this is a running household, but it does give you a reasonable idea as to the performance of the different SCCs.
First is the Axpert on a normal day starting from a 89 % SOC

By the end of the day the the battery monitor showed that the batteries was charged to 99 % and overall there was no real problems that I could see.
 
Second was the Victron SCC also starting on 89 % SOC

By the end of the day the the battery monitor showed again that the batteries was charged to 99 % and overall there was no apparent difference that I could see bet tween the two days.
Second Method:
I then decided to put the two SCCs next to each other and see how they would perform in exactly the same conditions. This meant that I would need to split the system in half having 6 panels on each SCC, and 4 batteries that was discharged to the same level. As my batteries do not get discharged very low at night I also decided to push them lower than what they have ever been discharged in order to give the SCC enough time charge. The batteries were discharged overnight to 70 % SOC and then the whole system was switched off, split and wired to the two SCC. As I only have one BMV I decided that I would not use it for any comparisons as it would only be able to measure the Axpert’s output.
Both the Axpert and the Victron do report battery Volts solar Amps and solar Watts and these readings were compared.
(As a side note when I tested the Victron SCC I did notice that there was a slight difference between the Victron SCC battery volt reading and that of the BMV so there would be some deviation between the two SCC’s , the  Axpert’s readings were very close to the BMV)
EmonCMS was used to log the data from the two SCC and there was no other load on the Axpert.
First graph is the Panels watts outputs from the two SCC.

Panel amp output

Battery Volts

Linear comparison between the Watt output of the two SCC’s

Personal Notes on the tests :
Apart from the one battery bank that took a bit more charge than the other I could not see any real apparent difference between the two SCC’s outputs. It was also noted that the Axpert’s data is not as refined as the Victron’s. The step pattern of the Axpert’s Amp feed indicates  reporting of Amps in whole numbers oppose to Victron more accurate readings in decimals. There was also a small variation in voltage reported by the Axpert and this can either be ascribed to again the coarser scale of its voltage readings or an inability to perfectly maintain absorb or float. Since there is a small amount of variation in the Victron voltage feed and the Axpert Voltage line is nearly linear I suspect that the case  is the former and the scale is too coarse to truly record the voltage. Occasionally it is rounded up or down resulting in peaks and troughs. In my opinion there is no real difference between the two SCC’s outputs as the data confirms it.
Some Extra notes:
Now there could be a host of other tests that one could do to compare the two SCC’s, but I attempted to run them in normal and side by side tests. The only thing that I would like to see is how they would compare under a cloudy day where the SCC would need to adjust as clouds passes over the system but then I would need to run the system in parallel over a time or hope that you time the weather perfectly and then split the system again. As this is a running household and not a test bench site it would be impractical to do so.

One last comment, when you handle the Victron SCC you do feel that there is a big difference between the two units. The Victron feels solid and well built and I would say the Victron would be able to handle a lot more hammering than would the Axpert but considering the price tag I am not prepared to push either one of them but my money would definitely be on the Victron to be on top of that one . 
The Victron gives you a host of options so that you could configure your system to be as automated as possible but it comes at a price.  The Axpert is more of an off grid “Inverter/UPS with a SCC” that does not give you many options so you would need to build your own setup to make it work fairly well within a grid system. In my case I have a remote triggered switch on the Axpert that will switch to grid under certain conditions and the family needs to be constantly aware as to what the system is currently doing before something is switched on or off. Where as if you have a Victron you could setup it up as a grid tie and then there would be no need for checking the system all the time.
Also to consider is the future value of your property. If you have an Axpert, you have had to grow with the system and learnt as you went on. In my case I had to setup up all sorts of things to make the system work. Now if I would like to sell the system with the property will I be able to get a buyer that will be able to understand the system and will he be able to get every thing going again if the R-Pi were to fall over? If not the system would become a liability and not an asset.
All in all money talks and the Axpert gives real good value for money as long as you know what you get and you are happy to live with it else consider saving a bit longer get your baseload lower and maybe consider getting a smaller Victron system. 
Best Regards
Paul
 
 

Update: Got the Multiplus 3000 and the Energy meter.
So far :
Flashed RPI with your latest image; It is booting and have switched it from Ethernet to WiFi. Got the energy meter with sufficient amount of additional cabling, although I'm probably expecting to have excess. Will update the current 2 series 3 parallel MPPT setup to 3 series 2 parallel strings. Will retain 25mm^2 cabling. Total seems to be just a little over 5 meters. Will switch inverter AC-in from current Phase 3 to Phase 1 so ESS can operate on Phase 1. Will disable Phase compensation. Reusing same batteries, have ordered additional 2 for 48v, expecting delivery tomorrow. Electrician coming to setup Energy Meter tomorrow. Will update with more soon!

Well, the pros is that it can pretty much do anything you want. The cons is that it costs three times as much as an axpert and at least 50% more than its natural competitor (the Infini), and sometimes there are specialised things that might not be fully supported and might be stuck behind other more pressing matters, so it might take a while to get it fixed.
I made a little comparison some time ago -- I have to say again that the Multiplus is NOT in the same class as the Axpert -- but since people insist on doing the comparison, here it is. I kept it back because this is often a sensitive matter.
Not in the same class:
  - Multiplus is a hybrid inverter, Axpert is off-grid plus changeover switch.
Quality of construction
  - Multi is IP21, Axpert is IP20. A draw.
  - Multi has thick alumium case.
  - All screws have pre-cut thread on the Multi. All screws are stainless.
  - Multi fan blows the right way (up), Axpert fans blow the wrong way (down).
Electronics and electrical
  - Axpert has 63V capacitors on DC bus, too little margin for a 48V bank.
  - Input voltage range, Axpert has trouble on the top side, capped at 60V.
  - High idle current (about 25% more than the Multi). Multi has AES mode that
    further reduces consumption without having to use Search mode.
  - Earth: Multi comes with a built-in bonding relay that makes a SANS
    compliant install easy. Axpert needs an external relay unit and is only
    supported in some firmware versions (See Firmware observations below).
  - No proper SoC (state of charge) measurement on the Axpert. Most users add
    A Victron BMV to their system to get this. Multi has good SoC measurement
    included but it only works if you use the AC-charger or a BlueSolar MPPT
    with the CCGX/Venus-GX to handle communication.
  - Axpert SCC (solar charge controller) has a tendency to overshoot and is
    slow to find the power point after a load change.
  - Actual failure reports (on the internet) seems to indicate that the Multi
    is more reliable.
Software and firmware
  - The software that ships with the Axpert is limited. There is no official
    monitoring support and most users use PVoutput.org or emoncms. This is to
    be expected as Voltronic is an OEM manufacturer. The Multiplus has
    extensive software support from the manufacturer and free access to the VRM
    site for monitoring.
  - All Victron equipment integrates seamlessly with the CCGX to provide
    control and monitoring. Similar Axpert functionality provided by community
    projects.
  - All the firmware for the Multi is in one place. Axpert firmware is often
    hosted and maintained by third parties and it isn't always clear if the
    firmware will work on your equipment. Again, this could be due to the
    manufacturer being OEM.
  - The multiplus has an extremely powerful assistant-stack that allows
    additional functionality to be enabled when needed. When used in a
    grid-fallback fashion -- configured to behave like an Axpert set to SBU
    -- you have more control over when switching happens. You can tune for
    short-duration loads.
Support and Warranty
  - Multiplus 5-year warranty, Axpert has maybe two years, it is unclear.
  - Victron support is responsive and very good, Voltronic, as pointed out
    before, is an OE manufacturer, support is provided by someone else and
    often very poor.
  - To be fair, Voltronic does appear to be listening: They uprated the
    capacitors and MOSFETs in the 2017 model.
Value for money
  - The Axpert comes with a built-in MPPT, with the Multi this is external and
    costs extra.
  - The Axpert provides parallel capability for very little money.
  - The Multi costs 2.5 times more than the Axpert (and that excludes the
    MPPT).
  - When all is said and done, a price comparison really ought to be made
    against the Infinisolar which is also a hybrid. Then the difference
    is less stark.
The hub systems are deprecated, they are replaced by ESS in most cases (there are a few documented exceptions). I think the hub-2 setup (grid-tied inverters on the output of the inverter) is more common than what was formerly called hub-1 (PV is injected on the DB bus using MPPT charge controllers), but I run a hub-1 setup (or ESS with MPPTs doing the power injection).

2.07 proper will be released on Monday... very likely. But it's probably going to be exactly the same as the 2.07~26 release candidate I built last night, so it's a good one to go with.
3kva at 48V... well what you do is work out the same sum at 42V, worst case scenario where the batteries are at a fairly low SoC and the voltage is sagging, then 3000/42 = 70 ampere. You want less than a 1% drop, once again lets take worst case scenario where batteries are at the bottom, lets say 40V to make the math easy, that's 0.4V. Then you need a total resistance lower than 0.4/70 = 0.006 Ω, or 6mΩ.
25mm^2 cable has a resistance of 0.8mΩ per meter, so up to 7 meters and you're still within the 1% spec. As I said, ideally you want to stick to <0.3V, so up to 5 meters of 25mm^2 will be fine. Otherwise go with 35mm^2.
Also keep in mind that at 0.4V drop at 70A, you're doing 30 watts of power dissipation over the length of that 7 meter cable, so it will be warm to the touch... :-)
Note: I edited the math above, I made a mistake.
Snake oil. There is no way a desulphator is going to work while it is in-circuit. These things work by using some kind of high frequency pulsing, and inverters and other electronics specifically don't want that kind of DC ripple. There is a possible case to be made for using a desulphator on a disconnected battery, but in circuit,.. don't bother. The best thing to do is to periodically do a full charge up to the point where your charging current drops to below 1% of the rated amp-hours of the battery, a kind of supercharge.

Another thing I just remembered, there are some tolerances built into some of the algorithms to deal with the small voltage differences, and as I recall this is limited to around 0.3V. If you have a drop bigger than that over a length of cable, you should expect weird things to happen.

If you want to do phase compensation, then sadly you will need the more expensive EM24 meter, the ET112 is only for single phase :-(
Yes, until last night that was the newest Rpi release. I didn't make any more Rpi releases since April because 1) there was nothing new that urgently needed releasing, and 2) we did a lot of work to get the Rpi code into the main branch so releases can be built by Victron's build server instead of my laptop. But yesterday I realised that people are discovering the slightly broken Rpi builds on their own and they try to use them, so I made another 2.07 build. The 2.05 build is good for now, but the new one auto-detects the attached hardware much MUCH faster.
Yes. The funny thing is I found the answer to that conundrum in the commit logs of the source control repo (not documented anywhere else I could find). The trouble was that the bootloader wants to attach to a serial terminal, but on the rpi3 the developers decided that by default the uart will be attached to bluetooth, so no boot console! So there is a special compile-time configuration setting that tells u-boot to work without a serial terminal, and that's what I used for a while. So we had to maintain two bootloaders. Thankfully the rpi loader makes it easy to use different loaders, but then... something went wrong and the rpi3 loader stopped working in the January 2017 release. Around this time I discovered that if I load the right device overlay before invoking u-boot, I can restore the rpi2 configuration and make the two versions work the same, so since earlier this year there is now only one bootloader.
If anybody ever wants to use the onboard bluetooth, they are going to have a REALLY hard time... but that is a bridge to cross some other time :-)
24V is a good compromise, especially with ESS. Victron also makes a 5kva 24V unit but I think that pushes things a bit, 3kva really is about the limit you can do with 24V.
35mm^2 will be better. I have 35 on my 1600va inverter, but I have a fairly long run (8 meters total) and over that distance there is a detectable voltage drop at full power. This has the interesting side effect that my voltage measured by the bmv (which is measured at the shunt at the batteries) and the voltage seen by the inverter (the vebus voltage) differs by a few millivolts at full power... and this is with 35! TTT will tell you to go one bigger than that even, but 50mm^2 is rather costly, so 35 with short runs will probably be okay.
If their age isn't too different (6 months to a year, does depend on battery quality as well) and you use a balancer, you can theoretically get away with it. I've never tried it and the solar gospel says not to... but as I understand things you could probably get away with it. The only issue I see is that under discharge, there will be a imbalance between batteries (the voltage will sag more on the older batteries). The imbalance is resolved while charging (by the balancer) but not while discharging. This is not going to be a problem for the most part, except at the very bottom (batteries are nearing empty)... then it is possible that one cell in the weakest battery is at 1.25V while the overall voltage of the string is still high enough to keep the inverter going... thereby leading to damage to that one cell. The exact issue you get with lithium batteries... except with lithium batteries the BMS monitors for this, actively balance for it if so equipped, and shuts down the pack if it can't.
In other words, if you decide to do that, set a slightly higher minimum disconnect voltage.

Sadly yes. In version 2.03 of the CCGX firmware the developer briefly had a feature in where you set the "maximum discharge current" and the software would include the PV power in the calculation and ensure that the battery discharge was no more than this value AFTER PV production was already subtracted. So if you set this value to 200W, and you had PV of 1000W at the same time, it would allow a total inverter power value of 1200W. This feature caused problems. I can explain if you are interested but the short version is that it is difficult to estimate the available power. So the feature was removed and the old behaviour was restored, where you set the "maximum inverter power". So if it is set to 350W, then the inverter will use the grid for the remainder. That's why I use the cron job to set values that more or less follow a normal solar day. It's not perfect (and one day I'll figure it out), but for now that works for me. If there is slightly less sun that day, the SoC limit saves you on the bottom end.
See this image. If you don't use the grid meter, then solar can only power loads on the orange line marked "Critical loads". If you don't have enough PV, the remainder is taken from the grid, but if you have a surplus of PV, that power will be wasted. The internal current meter inside the inverter is on the input of the inverter, so it will attempt to zero the input.
If you use the grid meter, as in the picture below, then surplus PV can be used to power loads on the dark blue line marked "Loads", but it will aim to keep the meter (marked "Wired AC sensor") at zero, so it will avoid feedback.
Now, because you can't have loads larger than 3.5kw on the orange line, I suggest that you get the current meter so that you can put those loads on the blue line and still use PV for them.

Inverter-AC unit might work, conventional AC will overload it. The starting torque of even a modest 9000 btu unit is well over 4kw.
The multi can balance out the power on another phase and attempt to make the combined power zero, but then it must be on phase 1. There is a "phase compensation" switch on the CCGX that you switch on if you want this. I don't know too much about this kind of setup unfortunately.
Venus is based off OpenEmbedded. The RPI image is built from the same code base as is used for the CCGX and the Venus-GX (aka the beaglebone black). Btw, I made a new release earlier tonight, version 2.07~26. This is by far the best one so far, you may want to try it.
Yes, there are debian/raspbian packages with the same software, but they lag behind and isn't that well sorted, and we decided not to spend too much time on them because we prefer that people use the image. Easier to maintain. Root access is easy. On the Pi I already provide a root shell straight on the first virtual terminal, so plug in a keyboard and screen and it works. You can type "ip addr ls" at that shell to find the ip address, then browse to that address with a browser. Under Settings->General there is a switch you switch on to get ssh. Then simply set a root password using the passwd command (as always) and you're done, you have ssh access.
You can also connect a ttl/serial interface to the UART pins on the pi, pins 6, 8 and 10. This is what I use most of the time.

 
There is a Zigbee solution but that is going to cost a lot of money. RS485 is meant for long cables, just put in a long cable? See the Victron website for the ZigBee "wireless AC sensor" solution.
Well, the downside is that it isn't 48V of course :-) The usual downsides apply, higher current, thicker cables. Personally I don't think there is that big a downside to using 24V when your aim is specifically to do self-consumption with ESS. It should also be noted that the Victron-branded lithium cells are either 12.8V or 25.6V, and you need much less batteries for an ESS setup if you go with the lower voltage setup. That is a small advantage in my opinion. This is where I'm going with mine, I'm saving up for a nice 24V NCA battery. They are 5kwh each, so I really need only one, so the fact that the voltage match with only one is a plus far as I'm concerned.
But... you are now at the same place I was in 2013. You know 48V is better... but you might be able to get away with 24V :-)

What's your use case. What problem are you trying to solve? That's what I like about the ESS webinar, it starts out right there with the different systems, 1) No grid available, 2) grid available but unstable, 3) stable grid available but frequent failures, 4) stable grid. ESS works well with the last two options, which is where South Africa is in most areas.
You'll have to make a call based on what percentage of the day the grid is unstable. If it only does so in peak times, for example, a few hours a day, then maybe it will work?
Time to collect more data, me thinks? Get the CG ET112 meter so long, with the RS485 cable and let an Rpi running Venus log your grid values for you. Then you get frequency, voltage and consumption values :-)

When running grid-fallback it can't run as a hybrid, unfortunately.
Watch the ESS webinar to get more info on that.

The second output is connected to the inverter output while the grid is available. It might as well be connected directly to the grid.
There's a heap of things to explain here, for example in the inverter programming (this is on the inverter itself, no CCGX required) you can configure it to ignore the ac input, to pretend it is not there. In some setups we use this to force the inverter to run from PV/batteries, for example, we might configure it so that it uses the battery down to a specific depth of discharge, or as long as the load stays below some limit. I'm mentioning this only to point out that even in this case, where the grid is available but you force self-consumption, it will still take output 2 down (as far as I know). So literally output 2 is only on when the grid is on, which I pointed out earlier isn't incredibly useful outside the use case it is designed for: PowerAssist.
PowerAssist was a Victron first, as I explained, that helps a boat/yacht/barge or RV that's stuck in some backwater harbour/caravan park with a weak AC supply by extracting the difference from the batteries. It will do PowerAssist even for loads on output 2. But PowerAssist is where you help a weak grid with the batteries. What you want to do is help the batteries with the grid, but your grid connection appears to be unstable (rather than weak).
On my inverter I only have one output, and I don't miss the other one at all. Cause this ain't a boat. Well... in a good rainy year the earth gets so soggy that I sometimes joke and say the house floats on a pool of thick mud... but other than that, it is not a boat :-)

I tend to agree. I get the feeling he wants to rectify the 24V mistake at the same time, which is a good move if you can afford it. But to do that, you would have to invest in new inverter hardware at the same time.
My gut feeling is also to stick with what you have hardware wise (at least in the short term) and get a better battery, but if you want to buy the batteries so that a future upgrade to 48V is possible, then it's going to mean two strings, which of course is once again not the preferred way. Unfortunately a balancer is not going to fix problems with charge distribution between two parallel strings. It can however buy you a few months of time of you go this way, so I would not write it off immediately.
It all depends on your budget. If you can afford Lithium batteries, even buying a small one now (2kwh) with the option of extending it later could be beneficial, but Li batteries go with complex BMS systems that often use canbus communication and since you already indicated that you want to avoid the cost of the CCGX... you're probably looking at lead acid.

Hello 9xsolar, 
I am surprised that you didn't get support from Flin as typically they are known to provide good support. I am connected with people at Flin Energy. Can you send by PM your name and serial number of inverter? I will forward the info and get someone from their side to contact you.
fyi, your battery cables seem to be too thin to carry up to 100 Amps current. You are likely having good amounnt of losses with those cables. 

Morning @9xsolar
You have purchased an independent SCC so you should have solved a weakness of the Axpert, namely its tendency to overshoot. 
Further purchases of inverter hardware is not going solve your dilemma. Batteries unfortunately is where you have to spend your money. Depending on how hard you have used your batteries you may need to purchase 4 batteries and resell the 2 you have as seconds. You need to accurately determine you over night draw and have 200% of that watthour value in batteries (battery string voltage x Ah) This will give you a maximum of a 50% DOD. At discharge levels higher than this your batteries will be very short lived.
Make sure you understand the risks of parallel battery strings (read SuperDIY's guide in the download section).  

I can sort of answer all the questions together. When the inverter is in ESS mode, the distinction between input and output largely disappears. The transfer switch closes and the input is latched to the output, whatever the inverter pushes back goes to the output as much as the input. If there is a power outage at this point, the transfer switch opens (disconnecting the input from the output) and the inverter drives only the output.
In ESS mode, various algorithms control how much energy it pushes back. The basic idea is that you want to use no grid electricity, as in zero. If there isn't enough PV power, then the difference comes from the batteries (it doesn't care what side of the inverter you have the load connected to, since it doesn't distinguish). The idea is better self-consumption, when there is too little sun, you take the difference from the battery. When there is more sunshine, you recharge the batteries. The whole time it will try to keep the grid at zero. You can however configure an inverter maximum, so that it will only attempt to do this up to a certain maximum.
In order to zero the grid input, it needs to know how much is being imported, and for this it can use one of two methods. One method is an external grid meter, which you mount right after your main switch before any other circuit in the house. This means you can even push energy back to loads that are NOT connected to one of the outputs, but it will still avoid grid feedback by attempting to hit zero at the meter.
But you can also use the internal current sensor inside te inverter. This is on the input side, the Multi cannot distinguish between current on first and second output, only current on the input. If it uses the internal current sensor, the effect would be that nothing is ever fed back from the input.
But you also have to remember that the inverter plays catchup. In a modern home, loads aren't steady, they vary all the time. Both the inverter and the prepaid meter work on a sort of average over a small time window to determine the exact power flow. The result: when the inverter aims for zero, it sort of hovers around it, sometimes pushing back a little, other times drawing a little, more or less evening out at zero. This isn't too much of a problem with dumb meters that can't sense the direction of flow. It is a problem with meters that trip when there is reverse flow.
So one final thing: Currently, in Venus, there is no way to limit the feedback strictly to what is available from PV. There is a long and complex reason for this that has to do with how difficult it is to estimate the amount of available PV. It is not a big problem though. I deal with it my setting a high SoC limit, say 95%, and then also setting a maximum discharge limit of between C10 and C5. So it sometimes discharges the battery a bit to offset the hot water cylinder... and I'm okay with that, that's what self-consumption is about. It will only use the top 5% of the battery... which is negligible.
What should also be clear after this epic I just wrote, is that ESS works much better with Lithium Ion batteries.

I doubt any supplier will help you out, some might offer to sell you more and/or better batteries, at best. Caveat Emptor as they say in Latin. Lead batteries usually don't want to discharge at more than C5 for short intervals, or C10 for longer intervals. This means 850W for short periods and 400 Watt for longer periods. Even though they are capable of 4800wh, they really don't want to release all of that in one hour (C1), they prefer to do it over 5 hours or longer (C5-C10), and ideally over 20 hours (C20).
That output is fairly useless in an off-grid scenario. The reason why it is there is so that loads that you don't want to discharge the battery can still benefit from the automatic transfer switch in the device. This is especially useful with the Quattro, which has two inputs as well: One for the grid and one for the generator. The second output will be live whenever one of the inputs have power on it. In addition, when you run grid-interactive (ESS, or PowerAssist), loads on the second output can benefit from PV power or battery assistance. The scenario where you would use this is your typical yacht or campervan: Your shore connection can only manage 16 ampere, but you need 20 for short periods to handle the air conditioner. The air conditioner might be on the second output, but the inverter can still do PowerAssist to provide the missing 4 ampere to loads on the second output. Similarly, with ESS (energy storage system), loads on the second output will be powered from PV/battery as long as the grid is there (up to the configured maximum), but once the grid goes out so does the second output.
This is implemented in the CCGX software (called Venus, it's just Linux under the skin). To do this, it must run grid-interactive, what is called ESS mode. You have to carefully check local regulations for the grid-connecting of embedded generators, additional anti-islanding might be required.
Long story short, yes the Multi can do this. I do this in the evening, my Multi only takes 250W from the batteries (ie 10A, around the C20 rate) and the rest from the grid.
Yes, two ways. If all the loads are on the inverter output, you configure the CCGX to run "without grid meter" and it will use the internal current sensor in the inverter and avoid feedback. You can also mount a separate current meter, and the software will always adjust the power so it never feeds back. Victron currently uses the Carlo Gavazzi ET112 meter for that, which at 76 Euro is affordable enough. You will need a USB->RS485 cable as well to connect the meter to the CCGX/Rpi.
The Rpi changes isn't yet fully in the official release (I can help you in the mean time, though it should be done by the time you get there), but there are some changes for automatic detection of hardware that makes this work out of the box. In a full ESS setup, you need the modbus meter (the CG ET112 I referred to above), the RS485 USB cable, one or more vedirect-usb cables (for the BMV and the MPPTs), and the mk3-usb dongle. For a minimal setup you will need at least the mk3 and one vedirect-usb cable (for the BMV).
In grid interactive mode (aka ESS) you are limited only by the transfer-switch capacity of the inverter. So if you have the 48/3000/35 model, that's 48V, 3000VA, 35 ampere. 35A at 230V is around 8kva. So that would be the limit while the grid is around. Without the grid, you can do 3kva continuous and up to 6kva surge (for about a second).