No problem. Like I said we can discuss it on github and probably a proof of concept on simple Python scripts is a good idea before adding to the final code.
I’ll have a look to that paper. Don’t worry I’ve access to IEEE. At a first glance it doesn’t treat the LP problem. But 'll have a better look.
The paper from Langer et al is not old (2020) and it provides the complete linear programming model formulation for heat pumps.
I have two air to water heat pumps for domestic hot water (600 W load) and pool heating (three phase 5 kW load) that I am optimising with EMHASS.
I find both of them work fairly well with EMHASS.
Domestic hot water
My 300l system needs to run for about 2 hours per day consuming about 2 kWh to maintain our device. By default it heats to 61°C, but I also have an SG Ready relay (controlled by Shelly) that superheats to 65°C.
Ideally this would run twice, once at the start of the solar day and once the end of the solar day to get me through the night, I have this programmed in EMHASS to run over a non continuous 6 hour window:
Three phase pool heater
I really just run this on an pure low cost basis. I set the def_hours based on the number of hours that the price forecast is extremely_low (< 5¢/ kWh), EMHASS then schedules this along with my other loads and it works quite well.
I don’t think there is much to be improved for air to water heatpumps optimisation, maybe hydronic heating could be a use case that would benefit from modelling.
HVAC
My biggest challenge with heat pump optimisation is my HVAC system. Currently we are still having warm days so there is reasonable alignment between the hottest part of the day and the highest solar production.
I schedule def_hours based on the number of hours the weather forecast is over a user defined set point, I have this set as a continuous load that can take values between 0-4 kW, whilst I cannot control power directly my automation adjusts the set point up and down to increase and decrease power consumption:
This works reasonably well as you can see from the scheduling although there could be some improvements.
You can see the scheduling of the HVAC is start / stop switching the system from 0 to 4000W in adjacent time slots, I would much prefer an average approach of maybe 2.5 kW over three adjacent time slots.
I would like the ability to ‘supercool’ when cheap energy is bountiful, covering periods just before a price spike. I’m my graphic above supercooling from 3-4pm would be ideal utilisation of cheap energy.
Of course the actual power consumption of my HVAC isn’t always the same as the deferrable loads forecast, as it is a function of external temp and setpoint.
Finally in the late afternoon window, after 4pm, I generally have a ongoing need for cooling, but if course EMHASS doesn’t schedule over that expensive period. I find I generally just manually switch on my HVAC during these periods.
Winter scheduling for heating doesn’t align with Solar production, so I generally turn off EMHASS HVAC scheduling over winter and just have that appear in my household load forecast for subsequent days.
Very cool. I think the general advantage of modelling the heatpump would be the ability to look ahead, temperature wise. Together with temperature forecasts this could help you plan the cycles more efficiently. But ofcourse, we need some practical evidence first before we can make any conclusions.
Possibly something like a user defined power forecast for individual loads that could be injected into the optimisation model could be useful.
I know what the forecast external temperature profile is for tomorrow.
A simple power model would be 1kW per degree over say 24°C to a maximum of 4kW and maybe an additional 1kW at 3pm, as my buy price increases at 4pm. So with a one hour time slot the desired power profile for tomorrow would be:
Temp: [22,24,25,26,27,26,26,26,25,24,22,21,20,20]
Power:[ 0, 0, 1, 2, 3, 2, 2, 3, 2, 1, 0, 0, 0, 0]
EMHASS could then use this as another fixed constraint to optimise against.
Providing this and using it as an additional constraint can be an option. But this means that you know that model of Temp vs Power consumption.
Another option is to model that based on the Temp and some parameters that are characteristic of the thermal behavior of your house, and to do all this inside EMHASS.
The other goal that I have in mind is that this should be useful to simplify the control of the heat pump. So you will need to provide the Temp forecast and EMHASS will be able to give the optimal temperature setting for your heat pump. Mark, do you think that this approach can be useful? I currently don’t have a heat pump so it is not very clear to me what will be the easiest variables to interface with.
The easiest values to get from a typical home would be:
. External temperature (either sensor or cloud based)
. Internal temperature (sensor)
. Desired set point (input number)
. HVAC actual power consumption (sensor or estimate)
Trying to match power consumption to a set point is difficult.
Some HVAC systems have a Demand Response Enabled Device interface which gives control over power consumption (0, 50, 75, 100) % options which would be ideal. Controlling Air conditioner using Demand Enabled Response Device per AS/NZS 4755
Whilst that gives more control the simpler way is to change the temperature set point, via a simple lookup table.
Desired internal temp 24 °C, increase power in 25% intervals for 25, 26, 27, 28 °C external temp.
The fixed power profile can be utilised in other use cases so could be worthwhile and I would imagine relatively simple to include.
A LP modelling of HVAC performance would be a welcome, but advanced, feature for EMHASS.
We could use data about house temperature characteristics as input to the model. For example, knowledge about insulation can make a huge difference in house thermal demands when it’s freezing outside. What would be even more amazing is if we could discover these model parameters from data via machinelearning. Kind of like how a smart house thermostat learns your thermal profile over time.
Hello, just wondering but have you heard about Energy Flexibility Interface? (EFI) EFI - Energy Flexibility Interface
David,
I have had some time to experiment with the ML module over the weekend.
I now have ML models for my buy/ sell prices, which is quite exciting.
Thanks for this extension.
2023-04-23 12:40:41,646 - web_server - INFO - >> Performing a machine learning forecast model fit...
2023-04-23 12:40:41,649 - web_server - INFO - Performing a forecast model fit for price_forecast
2023-04-23 12:40:41,669 - web_server - INFO - Training a KNeighborsRegressor model
2023-04-23 12:40:41,720 - web_server - INFO - Elapsed time for model fit: 0.05129742622375488
2023-04-23 12:40:42,042 - web_server - INFO - Prediction R2 score of fitted model on test data: 0.4393118941478219
2023-04-23 12:40:44,704 - web_server - INFO - Setting up needed data
2023-04-23 12:40:44,711 - web_server - INFO - Retrieve hass get data method initiated...
2023-04-23 12:40:45,562 - web_server - INFO - >> Performing a machine learning forecast model fit...
2023-04-23 12:40:45,565 - web_server - INFO - Performing a forecast model fit for price_forecast
2023-04-23 12:40:45,589 - web_server - INFO - Training a KNeighborsRegressor model
2023-04-23 12:40:45,610 - web_server - INFO - Elapsed time for model fit: 0.02150583267211914
2023-04-23 12:40:45,865 - web_server - INFO - Prediction R2 score of fitted model on test data: 0.4393118941478219
2023-04-23 12:40:45,872 - web_server - INFO - Performing simple backtesting of fitted model
2023-04-23 12:40:46,799 - web_server - INFO - Elapsed backtesting time: 0.9260625839233398
2023-04-23 12:40:46,799 - web_server - INFO - Backtest R2 score: 0.9048172716630719
That’s really nice!
That was the goal of the custom ML model, you can actually build a forecast of whatever sensor you have in HA, provided that it have enough data and that it is stationary.
Prod price and load cost are good examples. What it would be nice now is that you compare those results with the real forecast obtained from your provider. I don’t expect that we can obtain much better results for prices or weather forecasts, because typically forecasts provider will be using very complex models. In the case of weather forecasts they are a combination of satellite and/or radar data along with deep neural networks and the such. Here we are using more simple (but efficient) ML models.
The real deal with this ML module was the need for a better load power forecast model. And it works really well for that.
One thing that I will add in the future is the possibility to pass exogenous data for training and prediction. For example train a model to forecast the load power based on the historical values of the load power itself and other additional data as the outdoor temperature, humidity, house occupancy, etc. The main issue to this is that you will have to provide future estimates of those exogenous data. For weather data those estimates are easy to obtain. But for other types of data such as occupancy you will have to build them yourself and in that case we can use the emhass custom ML model approach. That can be interesting to evaluate with the issue of error propagating along those different forecast models.
Thanks for these inputs. I’m still evaluating if it worths the effort.
This is very interesting and it is a great idea to try to standardize interfaces and communication protocols.
There is a similar effort in the multi physics simulation world using FMI/FMU models.
Unfortunately for this EFI effort it seems quite dead. The last update to the github was 6 years ago and I couldn’t find a lot of information and documentation.
This seems like a very powerful tool thanks for sharing.
I am on amber, but don’t yet have solar or a battery. I am wanting to setup rules (either in node red or this tool) to look at the forecast of power and do the following for example:
Pretty much that. I also have ecebee turn off etc if it’s expensive but this app seems like it can be used for this even if i don’t have solar or battery is that true?
thank you
Hi,
EMHASS works well even without a battery or solar system, as it can provide an optimized schedule based on price alone and then switch your devices according to that plan.
I also use Amber and have set up automations that trigger based on their dynamic pricing. For instance, I have rules in place for my dryer to switch on when Amber prices are low (green) and switch off when prices are high (yellow/red). It’s an efficient way to manage energy usage for a few devices.
However, if you’re looking to manage multiple devices, EMHASS is the way to go, as it can optimize the energy usage for all your devices simultaneously. This helps maximize savings and maintain a more sustainable household. I’ve found this combination of EMHASS and Amber to be incredibly useful in managing my home’s energy consumption effectively.
thanks so much. ill take a good look.
how do you turn your dryer on - i assume it doesn’t have touch panels? ours has on off and start touch panels but i can’t turn it on with the smart switch which sucks. but i can turn it off and then announce when to turn it on.
My old dryer and dishwasher, if I start the cycle then turn off the smart switch, it will resume the cycle when the power comes back on.
My new heat pump dryer uses a lot less power 600W down from 2kW and has a home assistant remote start option:
Unfortunately I suddenly got some problems with EMHASS.
I installed the latest update for Home Assistant and since then, I get the error of an empty JSON.
My json:
{"pv_power_forecast":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,14.6,65.35000000000001,133.8,302.75,544.5,832.75,1142.45,1447.05,1686.75,1875.85,2040.05,2084.55], "prod_price_forecast":[0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457,0.14457], "load_cost_forecast":[0.234036,0.230366,0.230366,0.223456,0.223456,0.210182,0.210182,0.214396,0.214396,0.202506,0.202506,0.198168,0.198168,0.199218,0.199218,0.198514,0.198514,0.199911,0.199911,0.198761,0.198761,0.197352,0.197352,0.189775,0.189775,0.179554,0.179554,0.149791,0.149791,0.121894], "prediction_horizon":30, "def_total_hours":[0.00], "alpha":0.5, "beta":0.5}
log:
2023-05-06T18:52:08.139145771Z stdout UnboundLocalError: local variable 'df_day' referenced before assignment
2023-05-06T18:52:08.139074920Z stdout self.df_final = pd.concat([self.df_final, df_day], axis=0)
2023-05-06T18:52:08.139009681Z stdout File "/usr/local/lib/python3.8/site-packages/emhass-0.4.8-py3.8.egg/emhass/retrieve_hass.py", line 147, in get_data
2023-05-06T18:52:08.138952880Z stdout rh.get_data(days_list, var_list)
2023-05-06T18:52:08.138724339Z stdout File "/usr/local/lib/python3.8/site-packages/emhass-0.4.8-py3.8.egg/emhass/forecast.py", line 585, in get_load_forecast
2023-05-06T18:52:08.138650588Z stdout P_load_forecast = fcst.get_load_forecast(method=optim_conf['load_forecast_method'], set_mix_forecast=True, df_now=df_input_data)
2023-05-06T18:52:08.138584837Z stdout File "/usr/local/lib/python3.8/site-packages/emhass-0.4.8-py3.8.egg/emhass/command_line.py", line 120, in set_input_data_dict
2023-05-06T18:52:08.138515323Z stdout input_data_dict = set_input_data_dict(config_path, str(data_path), costfun,
2023-05-06T18:52:08.138458610Z stdout File "src/emhass/web_server.py", line 170, in action_call
2023-05-06T18:52:08.138400534Z stdout return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
2023-05-06T18:52:08.138341945Z stdout File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1799, in dispatch_request
2023-05-06T18:52:08.138287669Z stdout rv = self.dispatch_request()
2023-05-06T18:52:08.138228431Z stdout File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1823, in full_dispatch_request
2023-05-06T18:52:08.138175105Z stdout rv = self.handle_user_exception(e)
2023-05-06T18:52:08.138112429Z stdout File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1825, in full_dispatch_request
2023-05-06T18:52:08.138054291Z stdout response = self.full_dispatch_request()
2023-05-06T18:52:08.137979027Z stdout File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 2528, in wsgi_app
2023-05-06T18:52:08.137922238Z stdout Traceback (most recent call last):
2023-05-06T18:52:08.137832824Z stdout 2023-05-06 20:52:08,137 - web_server - ERROR - Exception on /action/naive-mpc-optim [POST]
2023-05-06T18:52:08.137516519Z stdout 2023-05-06 20:52:08,136 - web_server - ERROR - Either the names of the passed variables are not correct or days_to_retrieve is larger than the recorded history of your sensor (check your recorder settings)
2023-05-06T18:52:08.137313341Z stdout 2023-05-06 20:52:08,136 - web_server - ERROR - The retrieved JSON is empty, check that correct day or variable names are passed
2023-05-06T18:52:08.120239184Z stdout 2023-05-06 20:52:08,119 - web_server - INFO - Retrieve hass get data method initiated...
2023-05-06T18:52:08.118733146Z stdout 2023-05-06 20:52:08,118 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-05-06T18:52:08.114915583Z stdout 2023-05-06 20:52:08,114 - web_server - INFO - Retrieving weather forecast data using method = list
2023-05-06T18:52:02.659197136Z stdout 2023-05-06 20:52:02,658 - web_server - INFO - Retrieve hass get data method initiated...
2023-05-06T18:52:02.650789122Z stdout 2023-05-06 20:52:02,650 - web_server - INFO - Setting up needed data
The json itself wasn’t changed and I also created a new long-lived token and set it in the secrets-yaml.
Any idea?
Thanks!
My use case:
I configured EMHASS so that energy cost is higher during non-peak hours (as an attempt to influence the model believe it is NOT a good timing to turn my heat resistance) but since some weeks of gathering stats, it’s still saying it’s OK to connect the resistance in non peak hours:
ps:
Question: setting a higher cost during non peak hours makes sense for my use case?
No idea about this, I haven’t seen these issues on my install. But this seems related to the long lived access token. Did you try restarting your system?
I don’t understand what are you trying to achieve, but if you want this kind of action then just setup an automation to do that.
EMHASS is an optimization, so the results are the reflect of the maximum possible profit for your system (if you choose that as the objective function).
Peak and non peak hours are related to power consumption not to PV production, so I really don’t understand how could that makes sense. But may be as I said I don’t understand what are you trying to achieve.
