VRM consumption forecast : feature request

ESS (20kW batteries, 3kWp PV, Quattro)

I am trying to migrate my automations to use the VRM Consumption forecast. Historically I had both PV and consumption forecasts modelled in NodeRed. The goal being to maximise the overnight charge (during a cheap rate window) without needing to donate excess PV back to the grid during the day.

I have migrated to the VRM PV forecast which is working fine and has simplified my NodeRed flows. However I can see some potential problems with the VRM consumption forecast. Whilst it works well if everything is a steady state, it looks like I may need NodeRed overides for the real world.

(1) When on holiday there is a significant, immediate drop in my consumption. In my NodeRed model, I just turn on holiday mode and the forecast model immediately adjusts to the reduced holiday consumption.

(2) For half the year there is a heat pump in my system. It’s consumption is not steady state and I use todays usage to estimate tomorrows consumption.

(3) When the PV model prediction is low for whatever reason, resulting in excess PV during the day (batteries at 100% SoC), my NodeRed automation will dump the excess PV to an immersion. In the VRM consumption forecast, I believe that this will increase the forecast consumption, which in turn could result needing to dump more excess PV on subsequent days (i.e. the dumping to immersion becomes part of my consumption model which I don’t want).

(4) Occasionally it is known that ‘tomorrows’ consumption will be higher than normal. This cannot be handled in a model but I can easily handle in NodeRed as today.

Observation: My optimisations/automations are based on a number of static consumption models.

Suggestion:

Please can you allow a snap-shot of a small number (5?) of the VRM forecast consumption models to be saved and named.

By default, the VRM forecast could be dynamic (as now), but add an option to be static based on a selected saved forecast model.

Actually, may also need to be able to edit a forecast since allowing the VRM to generate a model for holiday consumption would mean needing to be on holiday for 28days (if it’s a 28day rolling average) which isn’t going to happen! Is it possible to generate this consumption model by resetting the consumption forecast, allowing the VRM to run for one day of vacation then saving?

This would address problems #1 and #3.

Still thinking about #2.

Colin

Addendum:
I can see that there are other requests raised regarding Consumption forecasting but I think that the use cases documented here are slightly different. I can see one area of commonality though in a concern about ‘non-typical’ loads increasing the forecast (in my case the use of dumping to the immersion) which is difficult to avoid when a static background consumption cannot be defined/used?

I would be really interested as well, especially for the non-typical loads part (heat pump, ev charger). For historic data, we can make those consumers known in vrm, so it knows the historical consumption of them and can exclude that from the predictions (just a checkbox on the device in vrm to exclude it’s consumption or not). For the future consumption, I think we would get a long way with just posting our own prediction of those loads for each hour ?

Are you only using the vrm forecast now, or overriding things in it ? And if so, what do you do exactly ?

In NodeRed I have a number of very simple static ‘models’ (1) Normal use. This is just my average consumption over a day. It doesn’t change if my overnight charge/PV model is slightly out and I need to dump to the immersion to avoid feedback to the Grid. (2) The equivalent consumption over a holiday. (3) A separate ‘delta’ model for an ASHP that is just based on the previous days ASHP consumption and used as part of my overnight charge algorithm - this is dynamic and as yet I haven’t thought how to migrate it to the VRM consumption forecast (even with changes). My primary EV feed is ‘before’ my Victron system (I am on Octopus Intelligent Go tariff) and the cheap rate charge windows can be dynamically defined by Octopus I didn’t want this interact/impact the Victron system and don’t use the batteries when charging with this. As such, it doesn’t figure in the VRM consumption model (and so doesn’t cause a consumption model problem). I also have another EV charger on the Quattro’s AC OUT2 in case I wanted to top up the EV from the batteries/solar - I’ve only used this once to test but it is intended for the future if I add more batteries and more PV (not modeled).

I have only migrated my overnight charge calculation to be based on the VRM PV and (at home) consumption forecasts and am waiting to see if the impacts of dumping to the immersion causes the consumption forecasts to spiral upwards and need to be reset (if even possible since I can only see the ability to reset the Solar forecasts).