EMHASS: An Energy Management for Home Assistant

Thanks, I now did a debugging on Node-Red side till the format looked good and then tried it with EMHASS.
The dayahead optimization is working now.

As I would like to switch over to mpc: Do I always have to use a prediction horizon of 48 if set to 30 mins intervals? As I wrote previously, I do not always have price data for the upcoming 24 hours. My Node-Red flow now only builds the post request for the prediction horizon for which I have data (might be more or less then 24/48) and also only includes solar forecast data for this timeframe as well as the correctly set prediction horizon.
If now running mpc like every 5 minutes, how would I have to change the prediction horizon?
Do I have to include any current power usage information or does EMHASS take it by itself? (docker)
I don’t have a battery and therefore no soc data, is that a problem?

Thanks

You can pick whatever you want as prediction_horizon and whatever you want as optimization_time_step.
The prediction horizon can’t just be lower than 5, other than that pick whatever value you want as long as it is consistent and coherent for what you are trying to achieve.

I you don’t have enough data for a complete 24h day in your forecasts, then just try a lower prediction horizon, say 6h for example. So if your time step is 30min then your prediction horizon is 12.

This is done automatically, you don’t have to pass any data. The add-on will automatically retrieve the load data from the Home Assistant database.

Why this would be a problem? You can perfectly do MPC without a battery.

Thanks for your replies.

Regarding the prediction horizon as you are writing “as long as it is consistent”: Can I set 24 hours (48 if 30 mins) for the time between 14:00 and 24:00 and then gradually decrease is due to the lack of data for the next day till it is again 14:00?

Is there a prediction horizon which you would consider as “too long” for mpc?

Thanks

Yes with some automations you can do that.

No

I set my prediction horizon dynamically in this fashion.

With the Australian energy network each day at around 1230pm they provide the forecast data for the next day until 3am, as a consequence I can have as few as 33 x30 minute forecasts, so I just set prediction horizon on a sliding window.

prediction_horizon:{{min(48,
          (state_attr('sensor.amber_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list|length)+1)

The map(attribute function is just an easy way for me to create an list of feed_in_forecasts.

The list filter converts the list into something readable.

The length filter counts how many elements are in the list (so in my case between 33-48)

The +1 is because I also inject the current feed_in price at the start of the list for the mpc call.

prod_price_forecast\":{{(
          ([states('sensor.amber_feed_in_price')|float(0)] +
          state_attr('sensor.amber_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list)[:48]) 
          }}

I find debugging the yaml with filters like this really complex, so recommend you don’t try and put this in your mpc call immediately. Work in the developer tools template section and gradually build up the sequence of filters.

Then I build a curl command line in developer tools template a can call from the CLI, then I build an mpc shell command I can put into my configuration.

I find I need to build things one step at a time to ensure it works.

I’ve just released a new version of the add-on that should survive any restarts. The data from previous optimizations should be there after the restart.

Also at the first startup of the add-on I removed the example optimization results file, so nothing will be shown on the GUI until a new optimization is launched.

Please test and give a feedback if it works. Tested on the development environment and works well. It is just making use of the /data folder that is persistent for add-ons.

1 Like

Thanks, I did this with Node-Red and also have it dynamically calculate the prediction_horzion which seems to work.
What is strange is that it does not take the correct pv production value from my call.
When I do:
{"pv_power_forecast": [1576.8500000000001,1738.15,1912.35,2003.1500000000003,2073.5,1931.1499999999999,1923.5500000000002,1829.05,1601.3,1295.4,1024.05,725.7,338,48,3.15,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], "prod_price_forecast": [0.18243600000000001,0.18243600000000001,0.15395999999999999,0.15395999999999999,0.148716,0.148716,0.15366,0.15366,0.133968,0.133968,0.141876,0.141876,0.148404,0.148404,0.157776,0.157776,0.19218,0.19218,0.200616,0.200616,0.19055999999999998,0.19055999999999998,0.188904,0.188904,0.178524,0.178524,0.164628,0.164628,0.15384,0.15384], "prediction_horizon":30}

It sets a different value for now (10:00):

The other ones seem to be ok.
Why is that?

As you say you are importing the values for the current hour also: As there anything different in my call? The first values are also for now in mine.

Thanks

If you are including current values you need to set the timestamp rounding to first.

I did set “first” now but it still shows some different values. Seems to me that it takes the data from the PV power sensor. The question is if this makes sense. The power sensor shows the currently “produced” kwh, not something for the specified interval (in my case 30 minutes).

Have you set the alpha and beta values?

https://emhass.readthedocs.io/en/latest/forecasts.html#now-current-values-in-forecasts

I use alpha:0, beta:1 as my current power value is more representative of my consumption in the current time slot, rather than what was happening 24 hrs ago.

A better value maybe the average power over last 15 / 30 minutes.

The pv_power_forecast field is expecting power forecasts (not energy) so you don’t need to worry about the size of the timeslot.

Thanks, I’ll try that.

Would I just set alpha and beta in the call like this?:
{"pv_power_forecast": [1449.6,527.4,421.95,311.40000000000003,280.75,247.25,187,80.19999999999999,34.1,3.25,0,0,0,0,0,0,0,0,0,0,0,0,0,0], "prod_price_forecast": [0.197772,0.197772,0.20178,0.20178,0.199596,0.199596,0.20890799999999998,0.20890799999999998,0.204132,0.204132,0.20418,0.20418,0.218592,0.218592,0.19314,0.19314,0.18082800000000002,0.18082800000000002,0.16700399999999999,0.16700399999999999,0.15874799999999997,0.15874799999999997,0.126312,0.126312], "prediction_horizon":24, "alpha":0, "beta":1}

Or do I need to set something like --runtimeparameters?

Would you directly import this as some different attribute and ignore alpha&beta then? The sensor itself woudln’t be a problem as a template sensor in HA.

This new release fixed a bunch of bugs using paths and properly saving the needed data to survive a HA or add-on restart.
Now you should be able to find the latest results from the optimization in a CSV file on the \share folder. This file allow us to reload the latest results without the need to relaunch an optimization again after a restart.

1 Like

I have a question. If I have a deferable load like Hot Water Heater. If first day there is bad solar It will pick the cheapest hours for the first day and when I run it next nigth and the upcoming day has good solar then it will be a long time between the heating for the hotwater and sometimes after changing to emhass I have noticed cold water cause of this. Is it possible to set maximum time that the deferable load can be off in any way?

Mabey we could add a parameter to longest time off? if longest time off is over 14 hours it should pick another time?

You could achieve something similar to what you want by using the MPC controller option.
For each MPC control horizon period you optimize the water heater usage for that block and given the iterative nature of MPC then you can achieve that objective of not too much time span between water heater functioning periods.

Can someone help me with an example on this?

Sure: https://emhass.readthedocs.io/en/latest/forecasts.html#example-using-solcast-forecast-amber-prices

1 Like

Hi! I’m now also setting the deferrable load hours via the mpc call. This results in a lot of very short terms where the heat pump is running which is not good for its health. Besides the option to run all those hours in one block, is it possible to set something like a minimum runtime?
Thanks!

You could just set MPC to a low frequency execution, say every 6h and also use the parameter set_def_constant to obtain just one on/off cycle of your deferrable load for each MPC block.

I’m running it every five minutes to have the newest live consumption data and to have the newest pv forecast. Is there any other way to achieve this?
Can you also maybe tell me where I should put the alpha and beta values mentioned by @markpurcell ( see EMHASS: An Energy Management for Home Assistant - #354 by smi)Thanks

Alpha and beta are passed as parameters in the shell command. Explained here: https://emhass.readthedocs.io/en/latest/forecasts.html#now-current-values-in-forecasts