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.
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
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.
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
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
Am I wrong with this then? (alpha and beta at the end)
I don’t see an effect here:
{"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}
Yes that’s ok.
An effect on what? What are you expecting?
Sorry you may need to swap them. alpha=1, beta=0 to give priority to the now values.
Crazy plan here tomorrow, in the middle of a heat wave at the tail end of summer.
Optimisation looks pretty standard, charge battery during the day over the midday solar soak, run some deferrable loads in between the gaps and then discharge the battery during the evening peak.
This is where the fun starts our market operator has a cap on export prices of $16/ kWh (yes that isn’t a typo) and the national market runs out of capacity in our heat wave for a 5 hour price spike tomorrow night at the export cap prices and I have just upgraded my battery capacity to 43 kWh to match my solar production.
The EMHASS forecast cost for tomorrow is a credit of over $400!
In reality these high prices will likely collapse during the day, but will probably still end up with one or two 30 minute slot as a price spike. A great use case for the benefit of EMHASS thanks @davidusb .
Great to see it planning those crazy credits! Cheers 
