Axpert Max Charge Current

[iurly]

Hi,

I have two installations where I'd like to tweak the battery charging current for opposite reasons:

Installation A)
Voltronic Axpert Max 7200 + 2x Pylontech US3000C (2x 3.6kWh)
I noticed how the maximum battery charge current is automatically set to 70A (would be 30A if only one battery pack is connected).
Under certain circumstances, I would like to set it to a lower value. The reason for that is that behind the same grid connection I also a have a separate PV system with a grid-tie inverter, whose energy would normally be all given back to grid and I would like the 2 systems to cooperate so to minimize returned energy, especially during cloudy days. In order to do that, I can switch to Utility First where all load power is taken from grid (so from the grid-tie inverter if sufficient) and all PV power is used to charge the batteries. Ideally, I would like to cap the power from grid, but that's just not possible. However, I realized that if I limit charging current though, then the remain PV power can be used to feed the load, thereby accomplishing my goal.
So while I can set it to a lower value, the system automatically switches it back to 70A after a few seconds.
Any idea what would happen if I keep overwriting them every few seconds through some automation?

Installation B)
Voltronic Axpert MAX TWIN 11000-48 + 2x Voltronic LIO II-4810 (2x 5kWh)
Here I noticed how the max charge current is set to 50A which just sounds too low for 10kWh storage, as this means 4 hours to charge at max current, as opposed to the 2 hours of the system above.
Any idea about the reason for such a low value?

So, is there any way to tweak these values? I wouldn't want to switch to User mode where I can set them at will since I believe these values come for a reason -- and there's also the automatic limitation once the charge level reaches certain thresholds.

Thanks!

 

[houseofancients]

Hi,

I have two installations where I'd like to tweak the battery charging current for opposite reasons:

Installation A)
Voltronic Axpert Max 7200 + 2x Pylontech US3000C (2x 3.6kWh)
I noticed how the maximum battery charge current is automatically set to 70A (would be 30A if only one battery pack is connected).
Under certain circumstances, I would like to set it to a lower value. The reason for that is that behind the same grid connection I also a have a separate PV system with a grid-tie inverter, whose energy would normally be all given back to grid and I would like the 2 systems to cooperate so to minimize returned energy, especially during cloudy days. In order to do that, I can switch to Utility First where all load power is taken from grid (so from the grid-tie inverter if sufficient) and all PV power is used to charge the batteries. Ideally, I would like to cap the power from grid, but that's just not possible. However, I realized that if I limit charging current though, then the remain PV power can be used to feed the load, thereby accomplishing my goal.
So while I can set it to a lower value, the system automatically switches it back to 70A after a few seconds.
Any idea what would happen if I keep overwriting them every few seconds through some automation?

Installation B)
Voltronic Axpert MAX TWIN 11000-48 + 2x Voltronic LIO II-4810 (2x 5kWh)
Here I noticed how the max charge current is set to 50A which just sounds too low for 10kWh storage, as this means 4 hours to charge at max current, as opposed to the 2 hours of the system above.
Any idea about the reason for such a low value?

So, is there any way to tweak these values? I wouldn't want to switch to User mode where I can set them at will since I believe these values come for a reason -- and there's also the automatic limitation once the charge level reaches certain thresholds.

Thanks!

only way to tweak this and keep battery comms alive is adapt it at bms level.
i am not sure either pylontech nor the voltronics will allow you to do so.
if the voltronics have a pacebms or seplos onboard , you might be able to use the seplos or sok software, but have no idea what bms they use

 

[wattmatters]

Any idea what would happen if I keep overwriting them every few seconds through some automation?

Your installation A scenario is similar to what I have just set up.

I'm not sure about the impact of adjusting charge parameters that frequently but personally I wouldn't.

In any case you will likely find the Axpert Max's charge current setting can only be adjusted in 10 A increments, so changing them up and down every few seconds likely won't help much given you are working in 500 W steps (assuming a ~50 V battery).

My automations are managed via Home Assistant, with some Node Red and inverter comms and control are done via Solar Assistant.

For me the question is how quickly does the automation pull the trigger on changing the charge setting (be it to turn on or off the supplemental charging, or to adjust the supplemental charge rate up or down). I have some filters to moderate that. I don't have it respond to instantaneous power flow data, I apply a low-pass filter to it with a 3-minute time constant. That way it's not over reacting just because one cloud passes over or there is some brief peak in load. Plus I don't run the automations at high frequency, about every 1-2 minutes depending on what it is.

I posted last night how it went yesterday, which was a day where my off-grid PV was not going to be able to fill the batteries but supplemental energy from my grid-tied PV system definitely did the trick while grid imports where minimal:

Backup down under

I built a 3-way ATS that automagically selects between Grid, Inverter EPS output and our auto-start genset. Normal operation is grid as we have an on-grid hybrid inverter, if the grid goes off, we transfer to the inverter EPS output and if that goes overload (it's limited to 3kW) or the...

diysolarforum.com

A few posts up from that i describe it a bit more.

Voltronic Axpert MAX TWIN 11000-48 + 2x Voltronic LIO II-4810 (2x 5kWh)
Here I noticed how the max charge current is set to 50A which just sounds too low for 10kWh storage, as this means 4 hours to charge at max current, as opposed to the 2 hours of the system above.
Any idea about the reason for such a low value?

If the default setting is not suitable for the battery you have then it's up to you to set the appropriate max charge current settings. There will be an overall max charge current setting, and a max grid charge current setting.

Voltronic specs say 30 A default and 100 A max:

Voltronic Power Battery LIO II-4810

voltronicpower.com

50 A is circa 2.5 kW into a 10 kWh battery. That's in the order of a 0.25 C charge rate. Personally I prefer to remain within 0.25 C.

 

[iurly]

Your installation A scenario is similar to what I have just set up.

Cool! I thought I'd be the only one in the world with such a weird idea in mind.

I'm not sure about the impact of adjusting charge parameters that frequently but personally I wouldn't.

In any case you will likely find the Axpert Max's charge current setting can only be adjusted in 10 A increments, so changing them up and down every few seconds likely won't help much given you are working in 500 W steps (assuming a ~50 V battery).

True, that's not very fine-grained, but that's still better than nothing. As a rule of thumb, I guess I'd be OK with grid exchanges between [-250W, +250W] with some adjustments to such thresholds depending on what the forecast looks like.

My automations are managed via Home Assistant, with some Node Red and inverter comms and control are done via Solar Assistant.

Yes I'm also using Solar Assistant and Home Assistant. I'm also very familiar with Node-RED, so I initially thought of using it but soon realized Home Assistant would be much easier to use though I'm still struggling a bit understanding its inner workings.

For me the question is how quickly does the automation pull the trigger on changing the charge setting (be it to turn on or off the supplemental charging, or to adjust the supplemental charge rate up or down).

OK so I take it you'd be switching across the following settings (which is what i had in mind):

a) Solar-Utility-Battery
b) Utility-Solar-Battery with battery charging on "Solar Only"
c) Utility-Solar-Battery with battery charging on "Solar+Utility" with 2A Grid charge current
d) Utility-Solar-Battery with battery charging on "Solar+Utility" with 10A Grid charge current
e) Utility-Solar-Battery with battery charging on "Solar+Utility" with 20A Grid charge current
...
is this correct?
With this approach, settings from "b" to "e" work fine as long as the load is lower than the grid-tie PV power, whereas otherwise you'd have to go with "a" and still have the grid-tie system export (potentially) a lot of energy.
Having a chance to limit charge current would let the Axpert work in "b" while still provide contribute to the load.

I have some filters to moderate that. I don't have it respond to instantaneous power flow data, I apply a low-pass filter to it with a 3-minute time constant. That way it's not over reacting just because one cloud passes over or there is some brief peak in load.

Yes I also had the same concerns. Though I wonder, is it really that bad to let the Axpert switch back and forth between SUB and USB?
I mean, in both cases it's operating in bypass mode so it's effectively grid-tied so in principle it looks like something you might want to adjust continuously, though of course I have no idea what that entails in the inner workings of the inverter -- I suppose that might at least increase wear in the non-volatile-memory?

Plus I don't run the automations at high frequency, about every 1-2 minutes depending on what it is.

Oh that's very interesting. So they're time-based as opposed to trigger-based?
Do you mind sharing your automations?
I'd be especially interested in knowing how filtering is implemented.

Also, did it ever happen to you that the inverter would ignore some mode change issued through Solar Assistant (no matter if over MQTT or from Solar Assitant's web UI)? I've seen both cases where the setting reported by SolarAssistant would just be left unchanged, and cases where Solar Assistant would report a mode change but the inverter would effectively behave as if the mode change never took place.
Not sure how one could go about debugging such behaviors though.

Thanks a lot for your help!

 

[wattmatters]

Cool! I thought I'd be the only one in the world with such a weird idea in mind.

It's the Pigeon Hole Principle. There are more people with solar PV than there are household scenarios to cater for.

IOW, there's always someone else

Yes I'm also using Solar Assistant and Home Assistant. I'm also very familiar with Node-RED, so I initially thought of using it but soon realized Home Assistant would be much easier to use though I'm still struggling a bit understanding its inner workings.

I am no an IT/comms guy but have managed to get better at making it bend to my will. The newer HA automations UI is easy to use. I also don't mind the way NR works (I just use the NR integration inside HA) as it makes setting up some stuff easier, like doing maths inside automations.

My combination is by no means perfect or optimal, it's just evolved as I have learned more.

OK so I take it you'd be switching across the following settings (which is what i had in mind):

a) Solar-Utility-Battery
b) Utility-Solar-Battery with battery charging on "Solar Only"
c) Utility-Solar-Battery with battery charging on "Solar+Utility" with 2A Grid charge current
d) Utility-Solar-Battery with battery charging on "Solar+Utility" with 10A Grid charge current
e) Utility-Solar-Battery with battery charging on "Solar+Utility" with 20A Grid charge current
...
is this correct?

Yes, except:

- I don't use SUB mode. I am switching between Utility First and SBU modes.
- Not sure what "Utility-Solar-Battery" mode is?
- I don't bother with the 2 A / 100 W step. My grid PV is five times the size of my off-grid PV so it would blow right through the 100 W step very quickly.

Right now as I am typing this my system switched from SBU to Utility First. 7:49 AM.

This is a snapsnot from yesterday to show the system adjusting:

With this approach, settings from "b" to "e" work fine as long as the load is lower than the grid-tie PV power, whereas otherwise you'd have to go with "a" and still have the grid-tie system export (potentially) a lot of energy.
Having a chance to limit charge current would let the Axpert work in "b" while still provide contribute to the load.

That depends I guess on my earlier question about what you mean by Utility-Solar-Battery mode.

Though I wonder, is it really that bad to let the Axpert switch back and forth between SUB and USB?
I mean, in both cases it's operating in bypass mode so it's effectively grid-tied so in principle it looks like something you might want to adjust continuously, though of course I have no idea what that entails in the inner workings of the inverter -- I suppose that might at least increase wear in the non-volatile-memory?

As above, I don't use SUB mode so not sure. In general there is one change in the morning from SBU mode to Utility First mode, and one change later in the day from Utility First mode to SBU mode. Occasionally it will move back and forth once or twice more in a day but not normally.

But the changes in charge current setting take effect pretty quickly and don't seem to involve any hard switching. Just more fan noise!

Oh that's very interesting. So they're time-based as opposed to trigger-based?

Both.

So, e.g. when the grid PV exports reach a set threshold value, an automation to consider adjusting the supplemental charge rate triggers, but it also checks at regular intervals anyway, just to be sure. If I send more than one instruction to change an inverter's operating parameter, I put in a time delay between the instructions.

 

[wattmatters]

Do you mind sharing your automations?
I'd be especially interested in knowing how filtering is implemented.

I can try, although it's a bit of a mash of stuff.

I set mine up with some yaml code in my config.yaml file. Here are a couple of examples, first one is a basic moving average over last five minutes. The second is an exponentially weighted moving average with a time constant of 2 minutes.

sensor:
  - platform: filter
    name: "Moving Average Grid Power"
    unique_id: sensor.movingaverage_grid_power
    entity_id: sensor.power_grid_fronius_power_flow_0_http_192_168_0_201
    filters:
      - filter: time_simple_moving_average
        window_size: "00:05"
        precision: 0

  - platform: filter
    name: "EWMA Grid Power"
    unique_id: sensor.ewma_grid_power
    entity_id: sensor.power_grid_fronius_power_flow_0_http_192_168_0_201
    filters:
      - filter: lowpass
        time_constant: 2
        precision: 0

I prefer an EWMA as it is weighted to more recent events, while the time constant is a way to adjust the responsiveness to more recent events.

e.g. here is a comparison on my grid power flow for a three hour period yesterday:
- The actual data (SolarNet Power grid)
- EWMA with 3-min time constant (EWMA-short)
- EWMA with 15-min time constant (EWMA-long)



and zoomed in on shorter time scale:



For now I am using the EWMA with a 3-min time constant as the sensor to assess grid power flow for most automations. Can play with the time constant to make it more or less sensitive to recent changes in actual readings.

For ramping up and down supplemental charge setting, I wait for my EWMA-short value to go below -1000 W (negative value = export to grid) for it to trigger an increase in supplemental charge current setting, while it needs to go above -350 W for a decrease in supplemental charge current setting.

I just use that as my hysteresis bounds. When exports reach 1000 W, I add 500 W of supplemental charging, so that will drop exports back down to 500 W. Meanwhile the EWMA doesn't respond instantly ensuring the system doesn't get into a constant loop of ramping up and down charging too much just in case a lone cloud happens to pass over 10 seconds later.

Also, did it ever happen to you that the inverter would ignore some mode change issued through Solar Assistant (no matter if over MQTT or from Solar Assitant's web UI)? I've seen both cases where the setting reported by SolarAssistant would just be left unchanged, and cases where Solar Assistant would report a mode change but the inverter would effectively behave as if the mode change never took place.

It's always a possibility. So far it's going OK. Reliability of network is important and mine is hardwired - ethernet cable from router to SA RPi and USB cable to the inverter(s).

But for sure one needs to have appropriate fall back settings in the inverter (and BMS if you can adjust those settings) so that the system is safe should automations fail.

Here what the automation looks like in the UI:



and here is what it looks like in yaml (although I never use yaml for it):

alias: CHARGE CONTROL - INCREASE GRID CHARGE CURRENT
description: >-
  Adjusts grid charge current based on available excess PV capacity from
  grid-tied PV system.
trigger:
  - platform: time_pattern
    minutes: /1
  - platform: numeric_state
    entity_id: sensor.ewma_short_grid_power
    below: -1000
condition:
  - condition: state
    entity_id: select.charger_source_priority
    state: Solar and utility simultaneously
  - condition: numeric_state
    entity_id: sensor.ewma_short_grid_power
    below: -1000
  - condition: state
    entity_id: select.output_source_priority
    state: Utility first
action:
  - if:
      - condition: state
        entity_id: select.max_grid_charge_current
        state: "10"
    then:
      - device_id: 0743b897cb13eb74e8412cc7c78f71f3
        domain: select
        entity_id: select.max_grid_charge_current
        type: select_option
        option: "20"
  - if:
      - condition: state
        entity_id: select.max_grid_charge_current
        state: "20"
    then:
      - device_id: 0743b897cb13eb74e8412cc7c78f71f3
        domain: select
        entity_id: select.max_grid_charge_current
        type: select_option
        option: "30"
  - if:
      - condition: state
        entity_id: select.max_grid_charge_current
        state: "30"
    then:
      - device_id: 0743b897cb13eb74e8412cc7c78f71f3
        domain: select
        entity_id: select.max_grid_charge_current
        type: select_option
        option: "40"
mode: single

And I have similar for adjusting charge current back down.

I also have automations to switch charger source priority between Solar Only and Solar and Grid Simultaneously:

e.g. this is the one to turn on supplemental grid charging:



and what it looks like in yaml:

alias: CHARGE CONTROL - ADD SUPPLEMENTAL GRID CHARGING
description: ""
trigger:
  - platform: time_pattern
    minutes: /1
    alias: Check Every Minute
  - platform: numeric_state
    entity_id: sensor.moving_average_grid_power
    below: -750
condition:
  - condition: state
    entity_id: input_boolean.storm_mode
    state: "off"
  - condition: state
    entity_id: input_boolean.supplemental_charging_required
    state: "on"
  - condition: numeric_state
    entity_id: sensor.load_power
    below: 2500
  - condition: not
    conditions:
      - condition: state
        entity_id: select.charger_source_priority
        state: Solar and utility simultaneously
    alias: Check not already Solar + Utility charging
  - condition: numeric_state
    entity_id: sensor.ewma_short_grid_power
    below: -750
action:
  - device_id: 0743b897cb13eb74e8412cc7c78f71f3
    domain: select
    entity_id: select.max_grid_charge_current
    type: select_option
    option: "10"
  - delay:
      hours: 0
      minutes: 0
      seconds: 20
      milliseconds: 0
  - device_id: 0743b897cb13eb74e8412cc7c78f71f3
    domain: select
    entity_id: select.charger_source_priority
    type: select_option
    option: Solar and utility simultaneously
mode: queued
max: 2

Hopefully you get the idea.

I am not a programmer so I just fiddled and diddled until I got a combination I think works. I keep refining as I go.

I started with a simple automation. Then I would add another layer to account for something else or to modify its behaviour. I'm still doing it.

 

[iurly]

- I don't bother with the 2 A / 100 W step. My grid PV is five times the size of my off-grid PV so it would blow right through the 100 W step very quickly.

Oh in my case the grid PV is just about 60% the size of the off-grid PV. So that kind of requires some fine-tuning

With this approach, settings from "b" to "e" work fine as long as the load is lower than the grid-tie PV power, whereas otherwise you'd have to go with "a" and still have the grid-tie system export (potentially) a lot of energy.
Having a chance to limit charge current would let the Axpert work in "b" while still provide contribute to the load.

That depends I guess on my earlier question about what you mean by Utility-Solar-Battery mode.

Utilty-Solar-Battery mode is the setting "USB" on the display, i.e. what SolarAssistant calls "Utility First".

So if I get this right, given the size of your off-grid PV, its production would normally be sufficient to power the entire household, and you might even draw additional power to charge the batteries.
In my case this is not always true, because there are circumstance where for instance:
- house consumption is 2.5kW
- grid-tie PV production is 1.5kW
- off-grid PV production is 2kW
so my options are currently:
a) Solar/Utility/Batter where 2kW is provided by the off-grid inverter, 500W are drawn from the grid-tie inverter and 1kW is exported to grid (batteries not charged)
b) Utility first, where 1.5kW provided by the grid-tie inverter, 1kW imported from grid, and 2kW off-grid production is used to charge batteries

if I were able to limit charge current to 20A (1kW) then I could use that spare 1kW to charge the batteries while still not importing.

> Also, did it ever happen to you that the inverter would ignore some mode change issued through Solar Assistant (no matter if over MQTT
> or from Solar Assitant's web UI)? I've seen both cases where the setting reported by SolarAssistant would just be left unchanged,
> and cases where Solar Assistant would report a mode change but the inverter would effectively behave as if the mode change never took place.

It's always a possibility. So far it's going OK. Reliability of network is important and mine is hardwired - ethernet cable from router to SA RPi and USB cable to the inverter(s).

So is mine, everything hardwired.
Notice I've also experienced the same kind of unreliability also when using SolarAssistant's web UI (i.e. not through HomeAssistant / MQTT) for instance when trying to switch modes from/to "Utility First" by pressing the button.
As far as I can recall, in that case the web UI would just report the previous state instead after reloading.

Hopefully you get the idea.

Yes, thank you so much! What is STORM MODE?

Also, one more question. IIRC in your post you also mentioned using solcast API, could you please elaborate a bit more?
I was thinking how having an estimate of how much energy could be available throughout the rest of day might perhaps make a difference when deciding e.g. whether to import 500W vs letting 1kW go (exported):
- if the sky is bound to clear up over the course of the day I better let it go
- if the weather is getting worse I might as well grab that 1kW while I can

I know for a fact that the capacity I have installed (~6kWh) won't get me through the night in any case, so whatever energy I can store into the batteries before sunset will be used no matter what. So I'm striving for getting 100% before sunset.
On the other hand though, importing energy in the morning just to get the battery full at 2pm instead of 4pm does not make any sense.

Any thoughts?
Thanks again!

 

[wattmatters]

So if I get this right, given the size of your off-grid PV, its production would normally be sufficient to power the entire household, and you might even draw additional power to charge the batteries.

FTFY

My grid PV is 11 kW, off-grid 2.2 kW.
Yes, home runs from grid PV during the day, while the small off-grid PV is dedicated to battery charging duties. I plan at some stage to increase the off-grid PV capacity but no rush on that given the grid PV I have. I need other things to happen (a chimney removal) to make that roof space available.

In my case

Oh for sure, this is all "YMMV" territory because each home and set up is unique.

Notice I've also experienced the same kind of unreliability also when using SolarAssistant's web UI (i.e. not through HomeAssistant / MQTT) for instance when trying to switch modes from/to "Utility First" by pressing the button.

Mine's been pretty good but I would rarely use SA controls directly or manually, most of it is automated through HA.

I made some tweaks to the supplemental charging automations the other day as I noticed some behaviour I thought sub-optimal. Always keeping an eye on how it performs, and as the days, weeks and year rolls on different scenarios crop up which I may not have anticipated, so I modify if it makes sense to.

Yes, thank you so much! What is STORM MODE?

The idea is to be prepared for grid outages.

History here is when there's a decent storm there's about a 50:50 chance of a grid outage. So better to start with a full battery where feasible.

So I have set up an automation option in HA which, if I invoke it, makes changes to the automations. I have a "Storm Mode" helper, just a boolean which for now can be manually triggered.

When active it disables all the regular inverter automations for switching load source priority and supplemental charging management and places the inverter in Utility First mode, prioritises charging the battery, initially from available solar PV, and/or from off-peak electricity. For now I think of that as Level 1 Storm Mode.

I haven't set a "Level 2" yet but that would be the same except the instruction would be to charge the battery NOW no matter whether it's peak, shoulder or off-peak tariff, just get 'er filled up as fast as sensible.

I have 20 kWh of backup reserve with my lead acid bank anyway so it's less critical but always nice to know you are starting with as full a battery as possible should the grid go down.

I may in future consider integration of official storm warnings into the system. I know it's already possible with bushfire alerts. In general though we know when a bad one is headed our way.

NSW Rural Fire Service Incidents

Instructions on how to integrate the NSW Rural Fire Service Incidents feed into Home Assistant.

www.home-assistant.io

Also, one more question. IIRC in your post you also mentioned using solcast API, could you please elaborate a bit more?

It's a PV output forecasting tool which can be integrated into HA, very handy for doing all the sorts of things you speak of. Its main business is detailed automated forecasts for solar PV farms and is quite sophisticated. They provide a free account for geeks like us to use, limited to 10 API calls/day (I have 50 free calls/day as I was an early account holder).

Solcast | Solar Api and Solar Weather Forecasting Tool

Created using a global fleet of weather satellites. Independently validated. Free to try. Access our data in just a few minutes with the Solcast API Toolkit.

solcast.com

Home Assistant integration:

GitHub - oziee/ha-solcast-solar: Solcast Integration for Home Assistant

Solcast Integration for Home Assistant. Contribute to oziee/ha-solcast-solar development by creating an account on GitHub.

github.com

Home Assistant also has a built in PV forecast tool, so you can choose that as well:

Forecast.Solar

Instructions on how to integrate Forecast.Solar within Home Assistant.

www.home-assistant.io

 

[wattmatters]

I know for a fact that the capacity I have installed (~6kWh) won't get me through the night in any case, so whatever energy I can store into the batteries before sunset will be used no matter what. So I'm striving for getting 100% before sunset.

If your grid energy is charged time of use, then getting through peak tariff period is the main thing.

On the other hand though, importing energy in the morning just to get the battery full at 2pm instead of 4pm does not make any sense.

Indeed, so having reliable forecasting is helpful so you know when is sensible to begin charging. With these things you try an automation, and then tweak it as you learn.