12 hours ago, 9xsolar said:

Multiplus 1600 24v 40/16

It's am amazing little inverter that. Has enough oomph to run the important things -- especially if you cook with gas (something I have to remedy) -- and it outperforms other larger inverters when it comes to self-consumption, all that without cycling the batteries to nearly the same extent. Personally, I would still encourage anyone who can afford it to go larger, based on my own experience every time I see the tumble dryer running at 2kw, the inverter running full tilt at around 1300W... and wishing I had just a little more :-) But the 1600VA is not a bad unit. In my experience, it won't do much more than 1300W because your power factor is rarely at unity.

12 hours ago, 9xsolar said:

discharge wattage of 200w (20amps?)

10 amps. At 10 amps with the higher SoC you're going to run with ESS, your batteries will spend most of their life around or above 25V. At 10 ampere, that's 250W. The inverter is 93% efficient at these loads, so 10 amps gets you around 230W. Try it out for a few days, but you could easily go a bit higher, say to 350W. Slower discharge over a longer period gets you better efficiency in the battery (Peukert et al), BUT... the inverter has a constant overhead of around 18W, so the lower you run, the higher the overhead becomes as a percentage of the consumption. In my experience, anything below 150W is a waste of time, you want to run between 200W and 400W.

What I did with my CCGX setup is add a cron job (the unix concept of a scheduled task) that adjusts the maximum discharge at times during the day. At night it is set to 200W. At noon it is set to 1300W. It's not built into the ccgx software... I hacked it on myself... but it's just Linux, it's not rocket science.

12 hours ago, 9xsolar said:

Doess the MPPT 150/70 have an upper limit of 2000w under 24v? Would it hamper upgrade ability down the line?

At 24V it is limited to 2000W, yes. At 48V it can do double that. Are you going for the Vecan model or the vedirect model, ie this one or this one? The second one uses canbus for communications and is not advisable if you want to use the Rpi. The vedirect models however has a limit of maximum 4 in your system (they are working on it), so if you're running a big solar farm you probably want the canbus model :-) Would it hamper upgradability? Usually other things get in your way first, like roof space, arrays not pointing in the same direction, etc, but buying a 48V model usually allows at least that kind of upgrade. Costs extra though, the 12V/24V models are cheaper. You could probably buy two 100/50 models for the same price :-)

Compare the price between one 150/70 and two 150/35 units. Price might be close, and two smaller strings with their own mppt adds not only redundancy but often also a little more power.

12 hours ago, 9xsolar said:

Is the energy meter really required? I don't want to spend more if the Multiplus can indeed take care of not feeding-in on its own. However, if not, will get it. 

It's not required, although I would advise it especially if you're going with the smaller 1600VA model. With the 3000va you could get away without it. Let me explain.

Point 1: The maximum AC current you can push through the multi 1600/24/16 model is 16 ampere, that is around 3.5kw. This is at 230V, if the voltage sags to say 220V or lower, even less.

Point 2: Without the grid meter, the inverter will use its internal current meter to determine how much it is supposed to offset from PV/batteries. The internal current meter only sees current running through the inverter (from input to output, this inverter has only one input and one output).

Conclusion 1: The inverter can only offset loads on the output, ie PV power is only used for loads on the output, and the difference is imported from the grid.

Point 3: You cannot put loads larger than 3.5kw on the output. Water heaters, air conditioners, stoves, vacuum cleaners (mine runs from the inverter, but only just barely), some hair dryers, etc those will all have to go directly on the grid.

Point 4: You will often have surplus PV generation capacity and you will wish you could use that to partially offset the air conditioner or the water heater.

Conclusion 2: Install the external power meter so that you can push current to appliances that are not on the output of the inverter, but still avoid pushing back to the grid.

As an upside, the external meter is also more accurate than the internal shunt. Downside, additional cost of the meter, an RS485 to USB cable, and you have to get a certified electrician to install it in your DB.

12 hours ago, 9xsolar said:

Will 1600 version be enough to be able to overload it with, say total of 1700w when it's grid parallel under ESS?

It won't allow you to overload it while the grid is available (why would you want do to that when the grid is there?). In fact, due to power factor and issues like that, you will see it top out at around 1300W. When the grid is unavailable, it will run at higher power levels for short periods of time (period depends on how much it is overloaded) while it flashes the red LED at you, but eventually it will shut down. It also makes the most horrible noise while you do that! :-)

It sounds to me like you need to perhaps consider the 2000VA model :-)

Fortunately, our electric usage doesn't mend well with food preparation. Everything's on gas - except for some exhaust here and there, which isn't connected to the inverter circuit yet.

13 hours ago, plonkster said:

What I did with my CCGX setup is add a cron job (the unix concept of a scheduled task) that adjusts the maximum discharge at times during the day. At night it is set to 200W. At noon it is set to 1300W. It's not built into the ccgx software... I hacked it on myself... but it's just Linux, it's not rocket science.

Does that mean that with a limit discharge setup (350w for ex), and solar is shining, the inverter will prefer Grid other than bringing in more solar? (i.e batteries in float) without the cron job running to make sure it resets during the day? Curious.

13 hours ago, plonkster said:

Are you going for the Vecan model or the vedirect model, ie this one or this one? The second one uses canbus for communications and is not advisable if you want to use the Rpi.

Not sure if I haven't mentioned, but I already do have the 150/70 vedirect model :-)

That helped a lot with production, 600w to 1200w compared to the PWM inside the inverter. I went with it as it supported both 24v and 48v.

13 hours ago, plonkster said:

Conclusion 1: The inverter can only offset loads on the output, ie PV power is only used for loads on the output, and the difference is imported from the grid.

Conclusion 2: Install the external power meter so that you can push current to appliances that are not on the output of the inverter, but still avoid pushing back to the grid.

Woah, you've lost me somewhere there. The meter is used to determine if other applications which aren't connected to the inverter require power other than ones connected already? So, the feed-in part is technically just powering the other things in the house and not feeding back to the grid, is it?

If that's the case, how the heck does that work? I have 3 phase connection, the inverter (current one) is on one phase, while some applications are distributed to the other phases. When there's excess solar, and if the meter (if installed before the phases(?)) is getting power from grid for other applications, then the inverter will feed-in to support that? If that's the case, my mind just blew as I was thinking of the meter being present just before the Grid connection to the inverter, so I was like, why would I need a meter there when the inverter will tell me how much I've used anyway.... lol.

If that's indeed the case, then my choice of the inverter would still be the same as all my objective was to make sure I utilize 100% of solar and my current setup doesn't let me do that unless I add excess amount of loads and calculate how much the MPPT can still extract.

The only reason why I talked about grid-parallel was because I was thinking of connecting the air con directly to the inverter and hoping it working on ESS with grid supporting the excess load. Excess load here being the air con.

But, will this setup make sure I don't feedback to the grid? I'm not sure how running electricity the other way around within the house won't make it leak outside? Sorry, layman talking electric here... I can talk linux things all day, but this just crossed a new dimension.

Some unimportant questions as my mind is still blown from above ..

• RPI venus seems to be its own image, and when I ssh into it, it seems to be a custom venus environment. Is there any other setup that runs on top of, say, Ubuntu with direct root ssh access?
• My phase panel (or DB..) is on the other side of the house. The inverter/rpi would be on the opposite side. Is there a wifi solution to connecting the meter with the rpi?
• Are there any downsides if I wish to get the 3000 Multiplus but in 24v? Pricing here is same for either, 24v and 48v of same price in any range.

Now I'm back to the drawing board to figure out how to do this!

I'm sorry for asking so many questions, but you've just opened my eyes to something very shiny and my brain is on a roll and figuring out where to store the excess light. :XD

40 minutes ago, 9xsolar said:

Does that mean that with a limit discharge setup (350w for ex), and solar is shining, the inverter will prefer Grid other than bringing in more solar? (i.e batteries in float) without the cron job running to make sure it resets during the day? Curious.

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.

40 minutes ago, 9xsolar said:

The meter is used to determine if other applications which aren't connected to the inverter require power other than ones connected already?

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.

40 minutes ago, 9xsolar said:

connecting the air con directly to the inverter and hoping it working on ESS

Inverter-AC unit might work, conventional AC will overload it. The starting torque of even a modest 9000 btu unit is well over 4kw.

40 minutes ago, 9xsolar said:

3 phase connection

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.

40 minutes ago, 9xsolar said:

RPI venus seems to be its own image, and when I ssh into it, it seems to be a custom venus environment. Is there any other setup that runs on top of, say, Ubuntu with direct root ssh access?

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.

 

40 minutes ago, 9xsolar said:

Is there a wifi solution to connecting the meter with the rpi?

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.

40 minutes ago, 9xsolar said:

Are there any downsides if I wish to get the 3000 Multiplus but in 24v?

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

Amazing, thanks for all the information! I will get the energy meter setup as soon as possible. This three phase thing might be tricky, but if that's the case, I'll just disable the two phases as only 1 or 2 applications are on different phases - will experiment with this and report back!

I'll just do a long wire run, this is going to be very interesting.

I'm using version 2.05 which I found from here : https://groups.google.com/forum/m/#!topic/victron-dev-venus/lgw94GJb054 - haven't been able to connect with the MPPT and BMW as I'm running short of power cable near the inverter, haha.

Does the latest one have the boot fixed for the RPI3?

I really want to go 48v, but these things are very hard to ignore in my case :

• Already have 24v, 2 batteries less than 5 months old. Ditching them as seconds is a loss.
• 24v system with 6v batteries are possible in the future, maybe even 2v if space allows... so, in terms of better backup per se, that's still possible.
• Wiring would be thicker, is 25mmsq I'm using now OK?

I could go 48v if I can use the existing batteries, which means buying 2 more of the same variety and they're c20 rated. But, considering I already have the MPPT 150/70, I don't know. Simple question would be, can I series connect 2 new batteries with 2 old batteries and expect them to work properly? I'll definitely have a HA02 in between. 

Thanks again for your feedback so far, really appreciated.

9 hours ago, 9xsolar said:

This three phase thing might be tricky,

If you want to do phase compensation, then sadly you will need the more expensive EM24 meter, the ET112 is only for single phase :-(

9 hours ago, 9xsolar said:

I'm using version 2.05 which I found from here : https://groups.google.com/forum/m/#!topic/victron-dev-venus/lgw94GJb054 -

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.

9 hours ago, 9xsolar said:

Does the latest one have the boot fixed for the RPI3?

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

9 hours ago, 9xsolar said:

I really want to go 48v, but these things are very hard to ignore in my case :

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.

9 hours ago, 9xsolar said:

Wiring would be thicker, is 25mmsq I'm using now OK?

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.

9 hours ago, 9xsolar said:

can I series connect 2 new batteries with 2 old batteries and expect them to work properly?

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.

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.

1 hour ago, plonkster said:

If you want to do phase compensation, then sadly you will need the more expensive EM24 meter, the ET112 is only for single phase :-(

Yep, just was in touch with the Victron distributor here, will be getting EM24.

1 hour ago, plonkster said:

The 2.05 build is good for now, but the new one auto-detects the attached hardware much MUCH faster.

Good to know you've fixed the boot issue! Will install the new one once I get hold of a power cable. Update soon!

1 hour ago, plonkster said:

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.

Will 25mm^2 be OK for 48v? :-)

1 hour ago, plonkster said:

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.

In other words, if you decide to do that, set a slightly higher minimum disconnect voltage.

I've decided to get the same batteries and setup for a 48v. Both the batteries are less than 6 months old, and there's been a HA01 for most of their lifetime so I'm hoping they'll cope well. In any case, I'll also add a desulfator (battery extra http://www.recovermybatteries.com/ex01-12-48-200.html) to the mix and hope for the best.

This will also allow me to increase the discharge wattage to maybe around 500w

1 hour ago, 9xsolar said:

Good to know you've fixed the boot issue! Will install the new one once I get hold of a power cable. Update soon!

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.

1 hour ago, 9xsolar said:

Will 25mm^2 be OK for 48v? :-)

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.

1 hour ago, 9xsolar said:

desulfator

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.

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... :-)

Roger that!

Snake oil. There is no way a desulphator is going to work while it is in-circuit

I already have the desulfator, and there are some questionable videos out there :https://www.youtube.com/watch?v=zityJFXJEEs

Got it for someone else who doesn't want it anymore, so I guess worth a try at least? Also got the HA02 this evening.

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!

16 hours ago, 9xsolar said:

Will update with more soon!

Awesome stuff. Looking forward. And pics or it didn't happen.

On 6/20/2017 at 0:22 PM, plonkster said:

Awesome stuff. Looking forward. And pics or it didn't happen.

You asked, I shall deliver.

Completed install just now.

Took some time to figure out how to install ESS assistant, I was trying to change settings on VEConfig and was scratching my head on why it doesn't change or save. Then realized I need to send the settings back instead of expecting it to save on its own, haha.

RPI venus setup :

Now, I'm scratching my head as to how the hell do I get the inverter to stop using the batteries and rely on grid? When I change the discharge battery soc to 100%, it doesn't discharge. But by doing so, the PV charger dials down and I don't get anything out of it. Help?

EDIT > Changed Grid Setpoint value from 50w to 850w and everything looks OK so far! However, how do I stop from charging the batteries using Grid? I only want to charge them using solar.

BatteryLife is set to self consumption but I was assuming it will help.

Also, I changed the port and added an usb extension, but that spawned multiple devices on venus which I'm unable to remove? How do I remove them?

Thank you so much for your help so far!

2 hours ago, 9xsolar said:

BatteryLife is set to self consumption but I was assuming it will help.

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.

2 hours ago, 9xsolar said:

Also, I changed the port and added an usb extension, but that spawned multiple devices on venus which I'm unable to remove? How do I remove them?

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.

After fiddling with settings such as these >

• MinSoC @ 80%
• Limit Inverter Power to ON
• Max Inverter Power @ 350w

The Inverter started to utilize the exact battery settings and supposedly does the balancing act :

 

After reaching 80% it seemed to have correctly started utilizing Grid more, although I'm not sure if this battery usage is fair (i.e randomly uses 80/40/20w as shown below), is that like a float charge and is it important? I thought it will completely stop battery usage, not trickle use it. Or is that the usage requirement for the inverter itself?

Finally, since I have enabled Max Inverter Power - could you share me your snippet/cronjob so I can set something similarly? Otherwise I guess even in the morning the max I'd get out of my panels is 350w haha.

6 hours ago, plonkster said:

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.

I got '2' - but that's after I fiddled and got the inverter to stop charging. Will this value change on its own?

Also, here's the ideal setup I'm looking for >

• Don't use battery in the morning whenever there's PV available. When PV is missing once in a while, take the requirement from Grid first and not battery.
• Charge battery from PV only. i.e loads get second preference.

I realize that my first requirement is kinda vague, and hence we setup for the top 20% (i.e discharge SOC 80%) to use whenever there's shortage etc. I thought, in ideal world, I'll use this 20% in the evening when there is no PV whatsoever.

6 minutes ago, 9xsolar said:

usage requirement for the inverter itself?

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.

12 minutes ago, 9xsolar said:

could you share me your snippet/cronjob so I can set something similarly?

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.

39 minutes ago, 9xsolar said:

I got '2' - but that's after I fiddled and got the inverter to stop charging. Will this value change on its own?

 

2 is "Default", that's when everything is fine, actual SoC is greater than MinSoC, and it's doing self-consumption.

If your actual SoC is less than the MinSoc, then the state will change to 5. It switches back to 2 once it's been charged above MinSoc, then the inverter will turn on and self-consumption will start again.

There is a feedbackDisabled variable in the code that gets set to True if either the battery is too low or there is no solar charger in the system. This variable (despite what it sounds like) actually controls whether the inverter connects to the grid or not. When it is false (feedback enabled) the inverter is connected to the grid and it will be on (even if it is told to push back nothing), so the full 35W of quiescent current will be drawn at the least. When it is true (feedback disabled), the inverter disconnects from the grid and it goes into pure bypass mode, which draws very little power. On my inverter, around 2W as I said. On yours I would expect around 4W. At night it should drop into this low-power mode.

Oh, one final trick. If you want to drop the inverter into bypass mode manually, all you need to do is stop the hub4control service. The inverter will go into bypass within 60 seconds. This command:

svc -d /service/hub4control

To turn it back on, bring it back up again:

svc -u /service/hub4control

You can schedule this command to run at say 7PM to ensure it is down for the night, and then bring it up again tomorrow at 6AM. Or something. I'm not sure when the sun rises and sets in India, but I will guess it's closer to what we have in South Africa than in Europe (where in summer it rises at 6AM and only sets at 11PM, for example :-) ).

43 minutes ago, plonkster said:

Oh, one final trick. If you want to drop the inverter into bypass mode manually, all you need to do is stop the hub4control service. The inverter will go into bypass within 60 seconds.

This still ensures the Inverter continues to run, except it will be in bypass mode and is ready to kick-in when the Grid fails, right?

1 hour ago, plonkster said:

 

2 is "Default", that's when everything is fine, actual SoC is greater than MinSoC, and it's doing self-consumption.

If your actual SoC is less than the MinSoc, then the state will change to 5. It switches back to 2 once it's been charged above MinSoc, then the inverter will turn on and self-consumption will start again.

I think I may have triggered that as I was messing around the SoC levels. In that case, the Min Discharge SoC if set to 80%, means if it drops less than that (let's say, Grid failure) and then Grid comes back, the inverter will charge to 80% and then leave it alone? Is that how it works? What if I don't want the inverter to charge anything at that level, and only want it to interfere at the Sustain level?

Edit> You've talked about it just before, I misread!

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.

What if the Min Discharge SoC is 100% - will that trigger the MPPT to power down? Because at some point in my tinkering, the MPPT went all the way down to 0W. I don't remember if it was when I had it on 100%.

54 minutes ago, 9xsolar said:

What if the Min Discharge SoC is 100%

I've never done this with BatteryLife turned on, only without BL. When MinSoc is set to 100%, nothing is fed back until the batteries reach 100%. This means some power is lost (eg, if you have 500W incoming but the batteries only need 100W to charge, the 400W will simply be lost). Once it reaches 100% SoC, the inverter turns on and it does the usual thing, feeds back as much as it can up to the limits. If the battery level drops below 100%, the inverter turns off until it reaches 100% again. Because the BMV measures in 0.1% steps, it means the batteries hover between 99.9% and 100%.

I prefer not to let it flip back and forth like that, so I'd rather reduce the inverter power limit a little for better balance, or I set MinSoC to 95%. Also, I set MinSoc to 100% only during prolonged periods of cloudy weather. In winter I set it to 95%, and in summer to 85%. It is better to use a lower limit, because lead acid batteries are really inefficient at recharging at such high levels of charge.

In short, yes you can set MinSoC to 100% and it works as it should.

The setting that throttles the MPPTs down to almost zero is "Keep Batteries Charged". As I mentioned earlier, this setting doesn't work properly with DC chargers. It is a known bug that doesn't have a terribly high priority at the moment, especially since it's supposed to work pretty much like when you use Optimised with minSoC=100%.

Finally, there is something I've been meaning to do for ages: Estimate the available Solar PV and auto-adjust the discharge limit so it follows the sun. The idea I have in mind is similar to how the TCP/IP protocol finds the congestion point of a connection, using the vebus voltage as a goal. I lack the time to do it :-)

1 hour ago, 9xsolar said:

This still ensures the Inverter continues to run, except it will be in bypass mode and is ready to kick-in when the Grid fails, right?

Forgot to answer this. First off, the old name for ESS was hub4, which is why the service is called hub4control. There is a safety feature in the Multi, if it doesn't receive communications from the CCGX for 60 seconds it goes into bypass mode. This is so that the inverter stops pushing back if the control software crashes for any reason.

When you stop hub4control, you're using this feature to put the inverter into bypass mode. The inverter still behaves like a UPS though, if the power fails, it will power all the critical loads. It won't recharge the batteries though (unless you manually select "Keep Batteries Charged", which will turn on the AC charger).

On 6/22/2017 at 2:44 AM, plonkster said:

Finally, there is something I've been meaning to do for ages: Estimate the available Solar PV and auto-adjust the discharge limit so it follows the sun. The idea I have in mind is similar to how the TCP/IP protocol finds the congestion point of a connection, using the vebus voltage as a goal. I lack the time to do it :-)

That would be something that will make this perfect!

Right now, I'm finding that as long as I keep the battery charging in Bulk, the MPPTs are maxed - things get tricky once they enter Absorption or Float in which case I manually change the Max Inverter power to keep things balanced.

It seems I'm just too paranoid to use batteries above their C20 rate, and the ability to maintain battery + grid in parallel is something that I absolutely love so far.

Week long data:

58 minutes ago, 9xsolar said:

That would be something that will make this perfect!

We had it for a short time period, it was in version 1.0.6 of hub4control. When calculating the amount of power to push back, it would add the power that is presently coming from PV, so that your discharge power always followed the available PV. But there was a problem with it, which can be illustrated by explaining what happens when you set the maximum discharge to zero.

When you set MaxDischarge to zero, it means you want the PV power to be passed to the output, but not anything from the batteries. The GridAssist function on the inverter operates on the AC side, so when you instruct it to feed back 500W of energy (for argument's sake), then you're going to end up drawing around 540W on the DC side. When your PV is AC-connected (via a gti) the math is easy, but when it is DC-connected via an MPPT, an estimate has to be made. The code simply assumes a discharge efficiency of 90%, so when there is 500W of incoming PV, it will feed back 450W on the AC side. Sounds simple enough? Well, trouble is it's an oversimplification. The inverter isn't always 90% efficient, sometimes it's better, sometimes it is worse. The different inverters in the range also aren't the same, they differ slightly. But even if you were to better estimate the efficiency, there is still a problem.

The problem is this: If you overestimate the efficiency (which is what happened, it actually does worse than 90% at lower loads, which is a LOT of the time), then it ends up using power from the battery to make up the difference, so it slowly discharges the battery at a few watts while it is supposedly running balanced. On the other hand, if you underestimate it, you will end up slowly charging the battery, and as the battery reaches higher levels of charge, it will accept less current causing the MPPTs to throttle back... but since you use the available PV number reported by the MPPTs to do your math, this will cause a death-spiral whereby the inverter continually pulls back, causing more current to go towards charging, causing the MPPTs to pull back even more, repeat until no power is pushed back. So overestimating is definitely the better option... but that's bad for the batteries if you do it every day.

Of course it is not a problem if you have enough PV so that there is always a period in the day when the batteries get enough charge, but it turned out (at my house) that the wife is very good at using everything that is coming in (and more) during the day... so I actually ended up with batteries that were being damaged slowly.

The solution as I see it, is to better estimate the inverter efficiency by adding a feedback loop: If you're at MinSoC but the battery voltage is lower than absorption, then you're feeding back too much... adjust the inverter efficiency downward. If you're at absorption voltage, then adjust inverter efficiency upward slightly. What should happen is that the efficiency should approach (via binary search) a point that is just under the actual efficiency.

Okay, I had a go at making a control loop to make it follow the sun, and since we have cloud cover today, it seems to work well enough. It still has too many magic values in it, and I would prefer to adjust some kind of volatile setting rather than a setting (because settings are persisted to flash), but that's for next time. This is python.

A bit of explanation. It asks vebus what the voltage is that the batteries ought to be at. Depending on what state it is in, this will return the absorption or float voltage. Then it checks if the current voltage is either 2V below that, or within 0.2V of that target voltage. If on the high end, it increases the discharge current by 50W. If on the low end (2V below), it decreases the discharge current to 85% of the current recorded PV power.

The reason for using 85%, is that is slightly below the worst efficiency of my particular inverter, so as a backoff setting this always ensures that we start charging slowly. The margin at the top end (0.2V) is simply to allow a small window for detecting "near-target" conditions, and using 2V is just to make the window large enough so we don't adjust too frequently. On a 48V bank I'd expect you can even push it up to 4V.

Finally, this thing runs once a minute.

If you're not familiar with running python code, let me know :-)

#!/usr/bin/python -u

import sys, os
import logging
from functools import partial
from collections import Mapping
import dbus
from dbus.mainloop.glib import DBusGMainLoop
import gobject

MAXDISCHARGE=1000

logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)

class smart_dict(dict):
    """ Dictionary that can be accessed via attributes. """
    def __getattr__(self, k):
        try:
            v = self[k]
            if isinstance(v, Mapping):
                return self.__class__(v)
            return v
        except KeyError:
            raise AttributeError(k)
    def __setattr__(self, k, v):
        self[k] = v

state = smart_dict()

dbus_int_types = (dbus.Int32, dbus.UInt32, dbus.Byte, dbus.Int16, dbus.UInt16,
        dbus.UInt32, dbus.Int64, dbus.UInt64)

def unwrap_dbus_value(val):
    """Converts D-Bus values back to the original type. For example if val is
       of type DBus.Double, a float will be returned."""
    if isinstance(val, dbus_int_types):
        return int(val)
    if isinstance(val, dbus.Double):
        return float(val)
    return val

def set_state(key, v):
    state[key] = unwrap_dbus_value(v["Value"])

def query(conn, service, path):
    return conn.call_blocking(service, path, None, "GetValue", '', [])

def track(conn, service, path, target):
    # Initialise state
    state[target] = unwrap_dbus_value(query(conn, service, path))

    # And track it
    conn.add_signal_receiver(partial(set_state, target),
            dbus_interface='com.victronenergy.BusItem',
            signal_name='PropertiesChanged',
            path=path,
            bus_name=service)

def set_power(conn, v):
    conn.get_object("com.victronenergy.settings",
            "/Settings/CGwacs/MaxDischargePower").SetValue(v)

def _round(v):
    return int(v/50)*50

def main():
    logging.basicConfig(level=logging.INFO)

    DBusGMainLoop(set_as_default=True)
    conn = dbus.SystemBus()

    # Find vebus service
    vebus = str(query(conn, "com.victronenergy.system", "/VebusService"))
    logger.info("Found vebus at %s", vebus)

    # Track some values
    track(conn, vebus, "/Hub/ChargeVoltage", "target")
    track(conn, "com.victronenergy.settings",
                "/Settings/CGwacs/MaxDischargePower", "discharge")
    track(conn, "com.victronenergy.system", "/Dc/Battery/Voltage", "voltage")
    track(conn, "com.victronenergy.system", "/Dc/Pv/Power", "power")
    track(conn, "com.victronenergy.system",
                "/Ac/Consumption/L1/Power", "consumption")

    # Periodic work
    def _adjust():
        logger.info("V: %s, P: %s A: %s C: %s", state.voltage, state.power,
                state.discharge, state.consumption)
        if state.voltage + 2 < state.target:
            # Voltage is low, then bring the power down to 85% of pv
            level = _round(state.power * 0.85)
            if level < state.discharge:
                logger.info("Updating power level to %d", level)
                set_power(conn, level)
        elif state.voltage + 0.2 > state.target:
            # Voltage is high
            # Evaluate whether we should increase inverter power
            # Don't adjust downward, only adjust upward of there is room.
            if state.discharge < MAXDISCHARGE and state.consumption > state.discharge:

                level = _round(min(state.discharge+50, MAXDISCHARGE))
                if level > state.discharge:
                    logger.info("Updating power level to %d", level)
                    set_power(conn, level)
        return True
    _adjust()
    gobject.timeout_add(60000, _adjust)

    gobject.MainLoop().run()


if __name__ == "__main__":
    main()

 

Sorry for the rather long delay! Haven't been in the country and couldn't do this remotely ;(

Will experiment and get back - unfortunately the weather has not been so kind lately and I'm barely charging the top 20% battery usage these days.