I have a somewhat improved version of this by now. This applies a single pole low pass filter to keep track of the available PV. This code works fairly well if your SoC is high and you want to keep it fairly high. It oscillates a bit if your SoC is below 80% and there is lots of PV available. On a good sunny day, I might run this code only in the afternoon, leaving the power limit unrestricted in the morning and drawing down a bit on the batteries. This code then ensures that it recharges in the afternoon and only the surplus goes to loads.

#!/usr/bin/python -u

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

MAXDISCHARGE = 1000
INCREMENT = 20
INTERVAL = 60000
OMEGA = (2 * pi)/100

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(callback, key, v):
    state[key] = value = unwrap_dbus_value(v["Value"])
    if callback is not None:
        callback(value)

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

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

    if callback is not None:
        callback(value)

    # And track it
    conn.add_signal_receiver(partial(set_state, callback, 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/INCREMENT)*INCREMENT

def _track_filter(key, value):
    p = state.get(key, 0)
    state[key] = p + (value - p)*OMEGA if p > 0 else value

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/BatteryLife/MinimumSocLimit", "minsoc")
    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", partial(_track_filter, "smoothpower"))
    track(conn, "com.victronenergy.system",
                "/Ac/Consumption/L1/Power", "consumption")

    # Periodic work
    def _adjust():
        logger.info("V: %.2f, SP: %.2f, P: %.2f, A: %.2f, C: %.2f",
                state.voltage, state.smoothpower, state.power,
                state.discharge, state.consumption)
        if state.voltage + 1.4 < state.target:
            # Voltage is low, then bring the power down to 85% of pv
            level = _round(state.smoothpower * 0.85)
            if level < 100: level = 0
            if level < state.discharge:
                logger.info("Updating power level to %d", level)
                set_power(conn, level)
        elif state.voltage + 0.3 > 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 = max(state.smoothpower, state.discharge+INCREMENT)
                level = min(_round(level), MAXDISCHARGE)
                if level > state.discharge:
                    logger.info("Updating power level to %d", level)
                    set_power(conn, level)
        return True
    _adjust()
    gobject.timeout_add(INTERVAL, _adjust)

    gobject.MainLoop().run()


if __name__ == "__main__":
    main()

 

@plonkster  - I've updated the venus image to version 2.08 (directly via venus, no manual flash) and since then, Multi has disappeared from venus. I've rebooted Multi, tried disconnecting all the cables and connecting one at a time.

Energy meter, MPPT and BMV are the only ones connecting.

Should I upgrade the firmware for the Multi? I've upgraded the firmware of the MPPT from 1.23 to the latest via bluetooth; obviously can't do that to the Multi.. any assistance appreciated. Thanks!

Edit: Rolled back firmware to 2.07~26 and Multi connects immediately. Super awesome to have backup firmware within venus, super helpful!

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.

Bingo - works in release candidate v2.09~3

I've had some issues with the previous firmware, like randomly the screen view (?) changes to the default one randomly throughout the day as if the venus hardware itself was restarted (which is wasn't). Plus, Multi and the MPPT will constantly disconnect and reconnect randomly throughout the day... nothing serious, but still concerning.

Hope this firmware works better haha.

1 minute ago, 9xsolar said:

I've had some issues with the previous firmware, like randomly the screen view (?) changes to the default one randomly throughout the day as if the venus hardware itself was restarted (which is wasn't). Plus, Multi and the MPPT will constantly disconnect and reconnect randomly throughout the day... nothing serious, but still concerning.

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

Watch it for me please and check that the inverter doesnt go awol every now and then. I have another report similar to yours, also on a 48/3000. The 48/5000 is fine though.

So far so good, I have not seen any weird behaviors so far.

Edit : Started monitoring w/ your script - so far so good too! I've changed the default 60s to 5s as I felt more updates the better as the clouds here are wrecking havoc.

On 8/23/2017 at 10:15 AM, 9xsolar said:

Edit : Started monitoring w/ your script - so far so good too! I've changed the default 60s to 5s as I felt more updates the better as the clouds here are wrecking havoc.

I prefer the longer interval because every time you change that setting it is persisted to localsettings and written to /data/conf/settings.xml. What I really want is a kind of volatile path on dbus that I can write to that isn't stored on flash, and that goes away when you stop the software. It's not hard to do, but I want to discuss the idea with the maintainer of the software first.

On 8/31/2017 at 3:14 AM, plonkster said:

I prefer the longer interval because every time you change that setting it is persisted to localsettings and written to /data/conf/settings.xml.

In the inverter or the RPI? In case of former, am I theoretically reducing the lifespan of the flash inside the inverter by too many read/writes? Should I be worried?

Also, my batteries never reach float (usually they'll just be in Absorption for a few hours) and then sun will be down by then, and the cycle repeats. Should I make sure they float more often? Can we make adjustments to your script so that the batteries are being fed whatever they want to eat, and only the remaining gets sent to load? Any tips appreciated

 

 

The firmware has been amazing, the overview screen never defaulted; and more importantly, neither the MPPT or the inverter disconnected from the RPI even once!

4 hours ago, 9xsolar said:

In the inverter or the RPI? In case of former, am I theoretically reducing the lifespan of the flash inside the inverter by too many read/writes? Should I be worried?

I mean on the Rpi. In my case the code runs on a real CCGX, with internal eMMC (like an sdcard, but onboard). While it is incredibly unlikely that you'll wear out the flash in any meaningfully short period of time, and the original software writes log output to the files all the time anyway, but there is still something in the back of my head that won't let me go overboard.

But... the inverter also doesn't adjust very fast, so 5 seconds is probably the lowest number that even makes sense. The adjustment loop inside the software only fires once a second anyway.

The issue with the inverter occasionally disconnecting: That turned out to be something specific to BMS systems that communicate a max discharge current that is higher than what the inverter could handle, and that condition wasn't properly checked for and caused the software to restart.

@plonkster

Just to update and a few questions - the system has been working pretty good so far. I only had to intervene to make adjustments to the temperature sensor; it seems to be causing too many errors (only happened a few times so far) and whenever I just move the cable a little bit on the battery, it goes back to normal.

Now that rainy season is approaching - I tried to make the battery stay at 100% and use solar only directly. I noticed that when the batteries are floating yesterday, they still go back into the Bulk state the next morning, and Absorption state, and so on. Why can't they stay in Float when they're not used?

I feel like I'm putting in too much into an already full battery. Any tips appreciated - thanks :)

Also, we have Grid-tie getting popular here and I might have the option of enabling this (although I'm not 100% sure if I should, too much bureaucracy) - what do you think theoretically, the amount of power I can feed back into the grid with my MultiPlus? Is it going to be 2200w or perhaps much higher?

1 hour ago, 9xsolar said:

they still go back into the Bulk state the next morning

If you set the ESS mode to "Keep Batteries Charged" and you turn on the new DVCC feature (under Settings -> System Setup), then the batteries will be kept full and the surplus PV will be used to power the loads. The charger state will then remain in Float and continue the next day. If you run in one of the other modes, and the battery voltage drops sufficiently over night, it will go back into Bulk. But even that is not too bad: Victron uses an adaptive charge algorithm where the absorption time is determined from how long the bulk phase was. If the bulk phase is really short (ie it reaches the absorption voltage quickly), then it won't stay in absorption very long. So there isn't too much danger of putting too much into a battery that is already full.

1 hour ago, 9xsolar said:

what do you think theoretically, the amount of power I can feed back into the grid with my MultiPlus? Is it going to be 2200w or perhaps much higher?

If I recall it is a 3kva? When running grid-interactive the Multi is limited to 80% nominal, so the theoretical max is 2400W.

For the benefit of others: The 3kva rating is a peak value. It can do this continuously for long periods, typically hours, depending on ambient temperature (a result from Turkey suggests that at -10 °C it can essentially do it indefinitely), but will eventually shut down to high temperature. Because grid-interactive operation is generally continuous, it is therefore limited to 80%. So you might say that off-grid it is a 3kva inverter, and grid-tied it is 2.4kva :-)

On 2018/08/13 at 4:32 PM, plonkster said:

If you set the ESS mode to "Keep Batteries Charged" and you turn on the new DVCC feature (under Settings -> System Setup), then the batteries will be kept full and the surplus PV will be used to power the loads.

I don't have the DVCC feature - looks like I need to spend some time upgrading the firmware of Inverter, MPPT, Battery monitor(?) along with my PI. It's been quite a while. I'm on 2.09~03.

On 2018/08/13 at 4:32 PM, plonkster said:

If I recall it is a 3kva? When running grid-interactive the Multi is limited to 80% nominal, so the theoretical max is 2400W.

For the benefit of others: The 3kva rating is a peak value. It can do this continuously for long periods, typically hours, depending on ambient temperature (a result from Turkey suggests that at -10 °C it can essentially do it indefinitely), but will eventually shut down to high temperature. Because grid-interactive operation is generally continuous, it is therefore limited to 80%. So you might say that off-grid it is a 3kva inverter, and grid-tied it is 2.4kva :-)

Thanks. But if I understand it correctly, it's still a lot low if we compare it to Fronius (at least in the price point). If I for some reason get Fronius in the future, will it work when there's a power outage when paired with Victron?

Edited August 15, 20187 yr by 9xsolar

3 hours ago, 9xsolar said:

I'm on 2.09~03

That's ancient. Try the latest 2.20 candidate. It is very close to release. Best course of action would be to get a new sdcard and keep the old one in case. Partitions got resized, kernels were upgraded, and the device tree overlays changed, so an in-place update is not possible. You have to flash a new one from the zip file on the website.

3 hours ago, 9xsolar said:

If I for some reason get Fronius in the future, will it work when there's a power outage when paired with Victron?

If you put it on the output of the Multi, then it works. It is not as stable as a DC charger though, it unavoidably tends to disconnect and restart on large load changes.

Thanks again - I've updated everything and have enabled DVCC and 'Keep batteries charged'.

However, that doesn't seem to use the excess solar available. Instead, it only uses the exact amount required to float/absorb the batteries. When I use 'Optimized with battery life' I can see the solar power increase drastically (200w to over 700w). Is this normal?

Edit: Inverter keeps changing from 'float' to 'discharging' constantly (and I can see battery discharge for a few secs and charge again whenever I use the script above).

Edited August 16, 20187 yr by 9xsolar

4 hours ago, 9xsolar said:

However, that doesn't seem to use the excess solar available.

Did you upgrade the firmware on the inverter? You must have firmware 418 and above (if I recall), but much better to install the latest (somewhere around 430 at the moment). Without that you cannot power your loads with the excess.

1 hour ago, plonkster said:

Did you upgrade the firmware on the inverter? You must have firmware 418 and above (if I recall), but much better to install the latest (somewhere around 430 at the moment). Without that you cannot power your loads with the excess.

Yes, I updated the inverter to 430 (with ESS Assistant). Here's the exact steps I did:

1. Update MPPT to latest (via Victron bluetooth) (reconnected to old RPI SDCARD after update and it worked)
2. Attempt to update Battery monitor (no update)
3. Disconnected inverter from old RPI SDCARD
4. Updated inverter to 430 after backup, and reconfigured using VEConfig - also added back ESS assistant
5. Replaced the SDCARD with latest image you linked, added ssh, updated wifi, etc
6. Connected everything to new image on RPI

Now, I have  :

• DVCC enabled / STS shared temperature sense enabled
• Mode - Keep batteries charged
• Grid Meter Installed (yes)

With this, the inverter only floats the batteries using very little solar. When I move back to Optimized, it uses all available solar. I use this mode in combination with your script above in order to use the additional solar available with 100% SOC (float).

However, this is no longer stable unlike before, as the inverter constantly moves from "float" to "discharging". Granted, there's way too much cloud movement today, but I haven't seen this behavior before.

 

Added screenshot (shows discharging issue) whilst using the script.

Screenshot that shows excess energy not being used when using "Keep batteries charged".

Both taken at same time, so you can see difference in power.

Edit. I now see a weird 'ESS #7' in the image below, any idea what that is?

 

Edited August 16, 20187 yr by 9xsolar

1 hour ago, 9xsolar said:

reconfigured using VEConfig - also added back ESS assistant

Do you have the latest ESS assistant loaded? Usually when you start veconfigure and there is a new version (or new assistants) it will offer to update it for you. Older ESS versions will not have the features needed for this.

 

1 hour ago, 9xsolar said:

constantly moves from "float" to "discharging".

In the past it only showed the charger state, so it would be stuck on "float". Now we attempt to show a bit more of what is really going on. So the behaviour didn't change, the display did. This is entirely normal.

1 hour ago, 9xsolar said:

Edit. I now see a weird 'ESS #7' in the image below, any idea what that is?

ESS codes. Not enough space on the screen to show everything, but #1 and #2 means the SOC is low, #3 and #4 has to do with BMS signals, and #5 is slow charge, #6 means the user set the max charge power to zero, and #7 means the user set the max discharge power to zero. Basically, those codes tell you why the system is not discharging, because that's one of the most common support questions: Why doesn't it work!?

In your case it probably shows #7 because the script shut it down. The script uses the same user setting as the GUI.

One final thing to try: I've seen this before and I still don't know why it happens. The solar charger is supposed to charge at a higher voltage (about 0.4V) than the Multi. For some reason this doesn't always happen. The only way I know to fix it is to shut everything down, remove the DC power from the inverter, and then restore everything again. In your picture, it looks like its charging from the grid and the solar chargers are being pushed down.

You can verify that it is working by accessing the solar charger from the device list on the gui, and looking at the Networked Operation section. It should show a charge voltage higher than the one you set in veconfigure. During bulk it will be several volts higher, and during absorb and float it should be 0.4V higher (assuming a 48V system). If not, then that is what you need to figure out.

 

On 2018/08/16 at 5:01 PM, plonkster said:

Do you have the latest ESS assistant loaded? Usually when you start veconfigure and there is a new version (or new assistants) it will offer to update it for you. Older ESS versions will not have the features needed for this.

I can confirm Assistant loaded (ESS) is up-to date.

On 2018/08/16 at 5:01 PM, plonkster said:

In the past it only showed the charger state, so it would be stuck on "float". Now we attempt to show a bit more of what is really going on. So the behaviour didn't change, the display did. This is entirely normal.

Gotcha - I also see that the wattage displayed (especially for Grid meter) are 1s delayed. L1/L2/L3 values below the main value appears faster than the global value. Just nitpicking as this didn't happen before too.

On 2018/08/16 at 5:01 PM, plonkster said:

ESS codes. Not enough space on the screen to show everything, but #1 and #2 means the SOC is low, #3 and #4 has to do with BMS signals, and #5 is slow charge, #6 means the user set the max charge power to zero, and #7 means the user set the max discharge power to zero. Basically, those codes tell you why the system is not discharging, because that's one of the most common support questions: Why doesn't it work!?

In your case it probably shows #7 because the script shut it down. The script uses the same user setting as the GUI.

Thanks, that explains number 7.

On 2018/08/16 at 5:01 PM, plonkster said:

One final thing to try: I've seen this before and I still don't know why it happens. The solar charger is supposed to charge at a higher voltage (about 0.4V) than the Multi. For some reason this doesn't always happen. The only way I know to fix it is to shut everything down, remove the DC power from the inverter, and then restore everything again. In your picture, it looks like its charging from the grid and the solar chargers are being pushed down.

 

I tried to power cycle everything (including the MPPT) and had no effect on this. In addition, I see that the MPPT flashes "absorption" orange LED in-between the blue "float" LED that flashes in accordance to "being in control of ESS". I haven't seen this before, and this happens to be at the same time when I see "discharging" happening as PV power drops. I've noticed this to drop even when there's no change of sun (i.e no cloud). Got one more customer in the link below who mentioned it too :

https://www.victronenergy.com/live/ess:ess_mode_2_and_3 (had to attach screenshot as Disqus doesn't allow linking by comment)

I also double checked the values in VEConfigure and they're lower than what's in the MPPT settings.

For now, I have disabled DVCC and will try to monitor tomorrow to see how it works.

If you can't get it working, send me your email address via private message and I'll get someone from 3rd level support to contact you.

Alright, I resetup everything from scratch again and now the Multi doesn't support loads at all (not even from the battery) and no matter what limit I put in RPI for discharge it doesn't do anything. Also, now the voltages are different.

(screenshot below with no limits on discharge, and plenty of sun and yet nothing's happening)

Here's the networked operation charge voltage from the MPPT :

Setting from VEConfig :

DVCC is enabled right now. I will pm you my email.

Edit ----------------------

Reverted back to my old SDCARD for the time being and everything works as intended (with your script)

Edited August 18, 20187 yr by 9xsolar

On 2018/08/16 at 6:27 AM, 9xsolar said:

However, that doesn't seem to use the excess solar available.

I have the same. Moment I switch on Keep Batteries Charged, the MPPT's pull back and very little power is given back to the loads.

Working through this thread, lets see if it now is working, once the batts are charged.

If you have DVCC enabled, then the solar chargers should be set to 0.2V (or 0.4V for 48V) higher than the Multi, and the Multi will push the overvoltage into the grid. However... this depends on the calibration of the various bits and pieces, as well as voltage drops over cables and many other factors, and ever since SVS (shared voltage sense) was dropped, it seems 0.4V just isn't enough. So... two options. Wait for it to be fixed... or...

root your ccgx and ssh to it. Then run:

dbus -y com.victronenergy.system /Debug/BatteryOperationalLimits/SolarVoltageOffset SetValue 0.2

That raises the offset by another 0.2V. If that solves it, then its this offset issue.

On 2017/06/10 at 12:16 AM, plonkster said:

where you set the "maximum inverter power". So if it is set to 350W, then the inverter will use the grid for the remainder.

Goal is to use ALL the solar power for the loads, batts for power failures only.

Would this make sense?
Array size is 1330w.
Set Max Inverter Power at 1330w - now the inverter will use all the solar power first, then supplement from the grid.