Optimisation at times exceeds p_nom for deferrable loads

[purcell-lab]

Describe the bug At times the optimisation allocates power levels which are above p_nom for deferrable loads.

To Reproduce

Expected behavior p_deferrable should not exceed p_nom, so in this case it should not exceed 600 W for the 17:00 timesteps.

Then a few minutes later, optimisation is delivering the expected behaviour.

Home Assistant installation type

• Home Assistant Supervised

Your hardware

• OS: Linux
• Architecture: amd64

EMHASS installation type

• Add-on

Additional context deferrable4 (my hot water heat pump) has an additional constraint to complete by sunset, which occurs at the 17:00 timestep.

I suspect the optimisation is allocating additional power to deferrable4 at this point, because it is constrained..

Another set of sub optimal results 5 minutes later:

[purcell-lab]

Another user with the same issue. https://community.home-assistant.io/t/emhass-an-energy-management-for-home-assistant/338126/2528?u=markpurcell

@GeoDerp , can you assist I think there is a logic error in the stop intervals code that it tries to squeeze in all the power required in the time remaining before the stop interval without consideration of the p_nom restriction.

[GeoDerp]

Hey @purcell-lab , Unfortunately im not verse in that area of the EMHASS code. Out of curiosity, What happens if 'def_start_penalty': [] in runtime ?

[sladey]

Maybe related to this issues I am see power allocated to deferrable loads when the def_total_hours runtime param contains zero for that particular def load.

[purcell-lab]

Some discussions in discord https://discord.com/channels/1317814601466773505/1317982438005411902/1330310776514154537

[purcell-lab]

Continuing to be an issue, p_nom is 115200, but with an end_timestep constraint it allocates forecast power levels above p_nom.

[davidusb-geek]

Continuing to be an issue, p_nom is 115200, but with an end_timestep constraint it allocates forecast power levels above p_nom.

So you see this problem when using the end_timestep contraints, without this the nominal power is never exceeded?

[purcell-lab]

This issue only appears with the end_timestamp constraint.

It seems to be it is trying to squeeze in additional power above p_nom in order to complete before the end_timestamp, but oddly you can see from my recent example it allocated double p_nom 23040 W in the 06:00 interval, but then allocated 0 W for the 06:30 interval. Instead it could have allocated 11520 W to both intervals, but it chose not too.

[RafAustralia]

@purcell-lab @davidusb-geek @GeoDerp

Hi all.

Im gonna add my case/experience here. Running Geo’s test version.

Appears like when emhass has long window to plan ev charging. It will slot it in perfectly. As the time passes. Prices change. Emhass starts to readjust and starts charging…. It doesnt go full speed its goes under the limit… eg 16a current allowing 11kw draw but it inly uses 7-9kw. Then it adapts and stops trying to look for better price. While its doing that it realises it has run out of time and final timestamp is near…. It tries to pack double the load (impossible to achieve) into one or two slots. Ends up running out if time and doesnt make it.

Thats just one example.

Second is pool load. Constant 1400w fixed. Needs 7hrs a day. Nothing else.

But if its window narrows or it thinks weather is bad it will attempt to put variable units in constant load. Eg Ive had couple of hrs if planned 8.8kw load which cannot be achieved.

Perhaps there needs to be a fail safe that if by certain time eg when window of pool hrs near to equal with required load emhass just needs to make a call and run with it?

Hope that makes sense?

[RafAustralia]

@purcell-lab @GeoDerp @davidusb-geek

Update on deferrable load for ev - the double up.

Wild guess.

I think however the timestamp may respond with 15min intervals - somewhere in emhass a part of the code still responds as 1hr. Cos as soon as mini has opportunity of scheduling at least minimum 1hr window it schedules correctly and starts charging quicker too.

So I think we changed to timestamps but something is holding it back in scheduling less than 1hr period.

Anyhow. My thoughts.

[RafAustralia]

Hi all. New issue related to this. I have set battery weights last night (that was a fail as they do not seem to stick) but leaving this issue aside it seems to have caused a havoc in my deferrable loads scheduling where these have exceeded their allowed maximum. Eg. Ev is 12000 and pool is 1400 as a deferrable load maximum. EMHASS started showing EV as 72000 and pool as selling negative value of -28016. Nothing worked to rectify the issue. Restarted EMHASS and still nothing. I had to change my EV charging end time stamp by 30min to have all issues correct themselves.
One note: Just to be clear. System was optimal and not infeasible ay any time

Any thoughts would be great.

Pics below

[purcell-lab]

I'm not sure if it would be feasible it would be to set Constraints to ensure that nominal_power_of_deferrable_loads & minimum_power_of_deferrable_loads is honoured during each optimisation run.

As a workaround it might be worth considering error bound checking be performed before publishing the deferrable loads forecasts.