Improve calculations of min/max values for AC input/loads gauges

[blammit]

AC gauges should have meaningful minimum and maximum values where possible. This applies to:

• AC gauge and AC loads gauge on Brief page (i.e. top-left and top-right gauges)
• AC gauge and AC loads gauge in Brief side panel (i.e. the two bottom gauges). Note these are combined with DC values if they are available.
• AC gauge in Overview page (i.e. the right-edge vertical gauge for Grid, Shore, etc)
• AC loads gauge in Overview page (i.e. the right-edge vertical gauge for Inverter/Charger box, not yet implemented)

Some questions/complications:

• What to do when no maximum is available (currently in this case, the UI shows the max value seen during runtime)
• Should the min value seen during runtime be used as the minimum gauge value? (This is what gui-v2 uses at present)
• How to indicate progress/maximum value on multi-phase systems, since current design shows a single line for all phases combined
• How to show these values for arc gauges (Brief page) and straight-line gauges (Brief side panel, Overview boxes)? Should they be different?

Some fixes that can be done as a starting point:

• Use CurrentLimit for max value of AC gauge even if showing watts. Also for Overview page (side gauge for Shore, Grid etc)
• Use NominalInverterPower for max value of Loads bar (if only showing AC loads, otherwise use runtime max)
• Use NominalInverterPower for max value of vertical gauge bar for Inverter/Charger overview

Subtasks

There are a number of sub-tasks to be done here, but discussed that it'll be easier to keep it all in this issue instead of making new ones. Here is a list of subtasks:

• General: (DONE)

  • ~Use fixed min/max values from backend~ https://github.com/victronenergy/gui-v2/pull/948
  • ~Add settings page to change /Automax and other configuration values~ https://github.com/victronenergy/gui-v2/pull/981

• Brief page side gauges: (DONE)

  • ~Split AC+DC input arc gauge into separate AC + DC gauges~ https://github.com/victronenergy/gui-v2/pull/929
  • ~Use 3-phase arc gauge for AC input with fixed min/max~ https://github.com/victronenergy/gui-v2/pull/942
  • ~Use 3-phase arc gauge for AC load with fixed max~ https://github.com/victronenergy/gui-v2/pull/942
  • ~Use fixed max for solar gauge~ https://github.com/victronenergy/gui-v2/pull/942

• Overview page: (DONE)

  • ~Use 3-phase bar gauge for AC input with fixed min/max~ https://github.com/victronenergy/gui-v2/pull/950
  • ~Use 3-phase bar gauge for inverter (i.e. AC loads) with fixed max~ https://github.com/victronenergy/gui-v2/pull/950

• Brief page side panel: (DONE)

  • ~Split AC+DC input bar gauge into separate AC + DC gauges~ https://github.com/victronenergy/gui-v2/pull/1037
  • ~Split AC+DC load bar gauge into separate AC + DC gauges~ https://github.com/victronenergy/gui-v2/pull/1037
  • ~Use 3-phase bar gauge for AC input with fixed min/max~ https://github.com/victronenergy/gui-v2/pull/1037
  • ~Use 3-phase bar gauge for AC load with fixed max~ https://github.com/victronenergy/gui-v2/pull/1037

[blammit]

Needs design input for consideration of how to show max for 3-phase systems. Currently in discussion.

[kwindrem]

NominalInverterPower makes sense for the AC output gauge limit only if inverting. If pass thru, it's the AC input current limit equivalent power and when assisting it is the combination of those two values.

The installer may limit this further with a breaker on the output side of the inverter so there should also be a setting for this that provides an alternate maximum that could be less than the value described above.

In addition, many users/installers have requested showing critical and non critical load values separately. For brief and overview, maybe not, but in a drill down they should be shown on separate gauges. Breaker defined limits may apply here also and be different for critical and noncritical.

You say only when showing AC loads. I think AC and DC loads are always separate on the overview page but as I understand it the brief page will combine these. DC load maximums are largely undefined but a system fuse/breaker may define a maximum. This can be a limit for DC loads (overview). Combining AC and DC power for a total number may make sense, but not sure the gauge is meaningful in this case. Maybe the way to address this is add a separate DC gauge. So for example in a 3-phase system there would be 4 gauges one for each AC phase and one for DC.

In general, gauges should show power relative to some real limit. Autoranging the gauge as is done now in places doesn't really provide any useful information. Th purpose of the gauge is to show graphically how close to the system maximum a particular power currently is. This allows the user to realize it's time to reduce load power.

I think the really important gauge in the AC chain is that for the inverter. This represents a limit that if exceeded will result in power interruption. AC Input power manages itself so the gauge is simply an indicator relate input power. The take-away is that if you are close to this maximum, you know the system will begin drawing power from the batteries. AC load power on its own will indicate a potential overload but this will be almost the same (relatively) as is shown on the inverter gauge. But if the AC output side power is limited by external breaker, then this value could be important as exceeding the maximum would result in a breaker trip but with the rest of the system working properly.

In GuiMods I did NOT include contributions from PV inverters in my AC loads limits and gauge value but probably should. Also in GuiMods, I did show grid feed-in power on the AC input gauge. So zero power on that gauge is not at the left (or bottom in the case of your side gauges).

[kwindrem]

Oh yes, the inverter gauge has a "consuming" range as well as in when it is charging the battery. The "supplying" range is when the inverter is feeding power to the loads. "supplying" and "consuming" are from the AC input perspective as I did in GuiMods. I think grid feed-in from a PV Inverter on the inverter output might also confuse things (that is show a consuming value).

It would also be possible to base the gauge on DC power in and out. That would probably avoid the PV inverter to grid issue.

I do find power in the consuming range (AC input perspective) somewhat confusing but it does make sense if you know the perspective of the gauge. And it does provide a complete picture of where power is going. It would be odd to show AC consumption on the AC input tile and none (or less) on the AC output tile and no power shown on the inverter. The only way I can see making this crystal clear is to show the inverter and charger as separate entities each having a gauge.

[blammit]

Thanks for the feedback @kwindrem, perhaps @jepefe will find this useful when we work out how to handle all of these aspects in the UI.

[jepefe]

What to do when no maximum is available (currently in this case, the UI shows the max value seen during runtime )

Show max during runtime, but then no warning color. This situation is unlikely to happen, but if it does please let me know which product and we'll try to fix that.

When AC and DC are combined, the gauge will only represent the AC power since there is no way to determine maximum DC value. There is a charge current limit setting in DVCC but that only applies to some Victron products and it is intended to limit the battery charge and does not apply for this purpose.

Should the min value seen during runtime be used as the minimum gauge value? (This is what gui-v2 uses at present)

Minimum is usually 0, but in case of feeding back energy to the grid the number becomes negative. When feeding back to the grid minimum equals to the current limit but negative.

There is user setting that can set the max feedin power which in practice it is the minimum value for the ac input, com.victronenergy.settings/Settings/CGwac/MaxFeedInPower if this is set to -1 then there is no limit so input current limit should be used, if it is set to >0 then you can use it as the minimum value. Please note that it is stored as a positive value.

I discussed this with Serj over the phone and he will provide a design. The idea is that when value is negative the filled area stars from the top of the arc, and perhaps a light color change.

How to indicate progress/maximum value on multi-phase systems, since current design shows a single line for all phases combined. How to show these values for arc gauges (Brief page) and straight-line gauges (Brief side panel, Overview boxes)? Should they be different?

Serj will bring us a solution for this. Idea is to make the line a multi segments line with slight color differences between phases and all together builds up the total line. This is a good improvement because the user will get an idea of usage of each phase in a glance.

Some fixes that can be done as a starting point:

Use CurrentLimit for max value of AC gauge even if showing watts. Also for Overview page (side gauge for Shore, Grid etc) This should work with the exception of grid parallel systems (systems with grid meter). The AC input limit applies to the power that crosses the multi AC In, but in parallel systems it only happens when charging the battery and to feed the loads connected to the inverter output (Critical).

For AC Input values use system Ac/ActiveIn/L1/* For maximum AC In, you can use current limit as you propose, but for grid parallel systems there is no actual limit so use current limit as a base and update with the runtime max seen value when it goes above the input current limit.

Use NominalInverterPower for max value of Loads bar (if only showing AC loads, otherwise use runtime max)

That is good. But same as in the previous point we have the grid parallel system exception.

The value for AC output gauge should be "/Ac/ConsumptionOnOutput" + "/Ac/ConsumptionOnInput". For the max value we can use NominalInverterPower as a base and update it with the runtime max seen value ("/Ac/ConsumptionOnOutput" + "/Ac/ConsumptionOnInput").

Use NominalInverterPower for max value of vertical gauge bar for Inverter/Charger overview

Yes, this is correct.

@blammit

[jepefe]

Thanks Kevin.

I agree that auto ranging is not a good thing. For AC we need to deal with it for grid parallel systems a solution for this will come in the future.

All the PV will be shown in the PV gauge for both inverter and chargers.

[kwindrem]

Above, I see the idea is to use a negative value of input current limit for feed-in. There should be a value somewhere which is the limit to the feed-in. It might be in ESS or some other place.

Regarding the gauge filling in from top to bottom for feed-in: This will most likely cause the gauge to bounce back and forth between fill from bottom and fill from top as loads change. Also, one let feeding to grid and another consuming might get very confusing.

While it makes the active portion of the gauge smaller, GuiMods allowed for a "consumption" and a "supplying" area of the gauge, offsetting the zero point. AC input, inverter and battery are the common cases for a gauge that shows both consumed and supplied power.

BTW, the max charging current is the "conusuming" limit for the inverter/charger.

[jepefe]

Above, I see the idea is to use a negative value of input current limit for feed-in. There should be a value somewhere which is the limit to the feed-in. It might be in ESS or some other place.

Good one, I updated the comment, thanks.

Regarding the gauge filling in from top to bottom for feed-in: This will most likely cause the gauge to bounce back and forth between fill from bottom and fill from top as loads change. Also, one let feeding to grid and another consuming might get very confusing.

It is just an idea, our designer is taking a look to this, I'm sure he will provide a good solution, not necessarily the proposed one. Anyway a good threshold will soften these possible bounces, also the value changes in the gauges are animated that also helps.

[blammit]

@jepefe Great, thanks for the detailed clarifications. Looking forward to seeing Serj's design as well.

Show max during runtime, but then no warning color. This situation is unlikely to happen, but if it does please let me know which product and we'll try to fix that.

I was thinking of the com.victronenergy.<grid|genset> services here, which don't have a /CurrentLimit, which leads to the next point below:

For maximum AC In, you can use current limit as you propose, but for grid parallel systems there is no actual limit so use current limit as a base and update with the runtime max seen value when it goes above the input current limit.

Are you referring to com.victronenergy.<grid|genset> services here? Those do not have any /CurrentLimit value at all, so I am wondering what you mean by "use current limit as a base"?

[kwindrem]

Having the gauge maximum track the peak value detected isn't going to provide any useful information. What if that peak resulted in a momentary overload? If so, that's a value we need to ignore when showing current power relative to a system maximum.

I don't see any way around having a value manually set by the installer for some (most?) gauges.

The inverter/charger maximums (supply and consume) are known values from the spec sheets (maximum inverter power, maximum charger power).

There may be available values for battery max charge and discharge.

PV charger power could be based on model however a more useful value is the system designer's target maximum production. So a manually set value. Same for alternator, wind, etc.

PV inverters on the input and output side of the inverter complicate things significantly, so again a manually set maximum may be best.

Yes, that's a lot of values to program during system commissioning but will provide stable and meaningful gauge display. I think about half of the people that use GuiMods program values which is needed to make the gauges appear.

I think the "autoranging" idea would be an acceptable fallback if the gauge limits aren't set up and suitable limits can't be extracted from the devices.

[blammit]

Serj has provided designs for this now. Removing "blocked" label.

[chriadam]

Unblocked. Medium priority. Definitely needed for 1.0.0.

[blammit]

Actually, there are still some design finalizations to be made, as discussed in slack regarding the “AC bar logic and visualisation" proposal in the design meeting. We should wait for that before making these changes. Adding "blocked" and "design" labels.

[mpvader]

Discussed today:

• Rein is nearly finished, two more things need doing: (1) have two maxima for consumptions, one when grid connected and one when running on the inverter. Perhaps something special when running on the generator as well - Jesus will look into that and instruct Rein. (2) Izak needs to review.
• Implementation in gui-v2 can start, since above changes are in systemcalc only, don't change the API and thus don't affect gui-v2. When they run out of work, gui-v2 team will ask Rein who can then install a pre-release version somewhere.

[ReinvdZee]

have two maxima for consumptions, one when grid connected and one when running on the inverter.

I've implemented this and added an Automax setting, see here for some details.

~Still needs to be reviewed.~

UPDATE: Changes are reviewed and put on the todo. If required, I can install the changes to a GX device somewhere for testing.

[jpetrell]

I haven't been part of the original discussions, but am now trying to grasp my head around the topic as I need to review Bea's changes.

Some observations, probably overlapping on what has already been discussed by others:

• The gauges look cool, but the min/max limits have so far seemed a bit arbitrary and there hasn't really been any way for the user to see what the limits are or control them (I guess that will now change?)
• Feels that defining sensible min/max limits would require qualitative understanding the installation/configuration and the user expectations. E.g. solar range could somehow be based on the the average maximum and minimum within the given month and day time.
• If the range is defined dynamically it only takes one unwanted outlier measurement to mess up the scale
• If the range is defined dynamically and the inputs and outputs stay pretty consistent, small changes in absolute values can became disproportionally large relative changes in the gauge due to the max and min limits being very close to each other
• The Brief page is gradually growing in complexity (e.g. with own gauge for each phase there are now more gauges than respective quantity labels), and you cannot tap those gauges to get more info. You can scroll to the Overview page, but then need to mentally map what you saw on the Brief page to different presentation on the Overview page
• How do we clearly indicate to the user how the range is determined
• How do we keep the setup and configuration options clear and simple (there are dozens of different gauges)

[kwindrem]

Minimum values should be zero unless there is a "negative maximum". Shifting the minimum value displayed away from zero eliminates any ability for the gauge to display anything useful.

I'm still recommending not determining the max value automatically. Max values shoud be set during system design/commissioning. If the max is not set, don't show the gauge at all.

Multiple phases don't need completely separate gauges. Combine the bars close together and show on the same scale for all phases. Re: GuiMods

[mpvader]

As discussed this morning, with Bea and Joona,

• Joona his concerns have all been answered. Part of the answer is that there will be, in v1.0.0, a settings page that allows the user to disable auto-ranging as well as modify any of the min and max values
• Changes to the Brief page as well as Overview page are in review.
• Remaining for implementation by Bea are the side panel on the brief page (Low prio! If need be we can even leave that out of v1.0.0), and the settings page.

@kwindrem, to answer you:

Minimum values should be zero unless there is a "negative maximum". Shifting the minimum value displayed away from zero eliminates any ability for the gauge to display anything useful.

No need to worry about this

I'm still recommending not determining the max value automatically. Max values shoud be set during system design/commissioning. If the max is not set, don't show the gauge at all.

We’re going to stick to our plan: by default we enable auto-ranging, and users that don’t want that can disable it.

Multiple phases don't need completely separate gauges. Combine the bars close together and show on the same scale for all phases. Re: GuiMods

indeed. And we’re not giving them individual gauges or maxima or minima.

Pls await whats coming now, and lets stop discussing for now. There is a plan, we’re implementing that, and thereafter see further.

[kwindrem]

mpvader: all sounds good. Thank you for taking the time to explain the plan here.

blammit: Thank you for confirming there will be a gauge for inverter/charger. AC load values are not really correct for that gauge. Any contribution from the AC input needs to be subtracted from the AC load values. Max for this gauge can be taken from a table of inverter/charger models (or hand entered as is done it GuiMods). If AC input and/or AC load values are provided by external metering and there are PV inverters also contributing power, these also need to be factored in.

Consider the situation where all AC load power is being provided by the AC input. In this case, the inverter/charger core is not producing any power. So the inverter/charger gauge should show zero.

A simpler way to do get a current value for the inverter/charger gauge would be to look at DC power consumed by the inverter/charger. DC and AC inverter/charger core powers should differ only by an efficiency factor.

[mpvader]

@blammit , above comment by Kevin is probably best looked at by Jesus; lets discuss tmrw

[blammit]

The scope of this task is scattered throughout this issue and elsewhere, so I've added a list of sub-tasks to the issue description to try to make this more clear.

[mpvader]

@kwindrem , you wrote:

having a gauge for inverter/charger

and then a lot more :)

Its understood, and is being worked on, but not here in this issue and not by Bea. This issue is about implementing a plan that is finished and that we're not going to change - further discussion here will delay v1 release and I don't want that.

Wrt the plan on inverter/charger gauge and showing user how close he is to overload: I'll make sure to show our plan to you once its there; pls stop further comments in this issue - thanks.

[blammit]

Note: I am checking with @ReinvdZee about where the UI should fetch the relevant values from. E.g. for max AC consumption, should the Brief and Overview page use com.victronenergy.system/Ac/Consumption/Current/Max, or the related localsettings value in com.victronenergy.settings/Settings/Gui/Gauges/NoAcIn/Consumption/Current/Max?

[blammit]

See https://github.com/victronenergy/gui-v2/pull/981 for further discussions and feedback about the settings page for changing the min/max values.

[ReinvdZee]

I've also updated the design doc with the gauge limits.

[blammit]

I've merged https://github.com/victronenergy/gui-v2/pull/1037, which updates the side panel to use the fixed min/max ranges.

These other PRs were previously merged to fix some issues on the settings page: https://github.com/victronenergy/gui-v2/pull/1042 https://github.com/victronenergy/gui-v2/pull/1043

So now this task can be closed as done. 🥳