Hey Robert, I thought those variables related to energy cost from the grid, rather than time windows for when a deferrable load should operate. I supply a list of half hourly prices (based on my tariff) for how much energy will cost from the grid.
yes maybe. Thatās just my assumption from way back when I first tried to set this up. Havenāt looked at it since.
number_of_deferrable_loads: 2
list_nominal_power_of_deferrable_loads:
- nominal_power_of_deferrable_loads: 1300
- nominal_power_of_deferrable_loads: 7360
list_operating_hours_of_each_deferrable_load:
- operating_hours_of_each_deferrable_load: 2
- operating_hours_of_each_deferrable_load: 1
list_peak_hours_periods_start_hours:
- peak_hours_periods_start_hours: "10:00"
- peak_hours_periods_start_hours: "10:00"
list_peak_hours_periods_end_hours:
- peak_hours_periods_end_hours: "16:00"
- peak_hours_periods_end_hours: "16:00"
list_treat_deferrable_load_as_semi_cont:
- treat_deferrable_load_as_semi_cont: true
- treat_deferrable_load_as_semi_cont: false
In theory it might completely roll over to the next day but in practice I find that it doesnāt. AEMO posts the next 24 hours pricing at 1230 AEST each day so I find I get consumption in the morning and then if the prices are really low the next day they will occasionally stop and roll over to the next day. Which for a pool filter pump isnāt that bad if it does 3 hours one day and then 6 hours the next.
The other thing I do is just schedule when the feed in price is extremely_low (negative) and the general price is less than 5Ā¢/ kWh so basically nothing. As a consequence my pool is currently up at 34Ā°C 
Yesterday the pool sucked 51 kWh and it cost me 26Ā¢.
- name: def_total_hours_pool_filter
unique_id: 326ca07d-fb97-4977-8821-78d5c5e0a7b5
state: >-
{{
(is_state('automation.p_deferable0_automation', 'on') | int(0)) *
states('sensor.pv_forecast_energy') | int(0) / 10
}}
- name: def_total_hours_pool_heatpump
unique_id: ad586a0f-d16a-4ab9-841d-96b753612709
state: "{{is_state('automation.p_deferable1_automation','on')|int
* max(0,((state_attr('sensor.amber_feed_in_forecast', 'forecasts')|selectattr('descriptor','eq','extremely_low')|list|count)/2)
)}}"
A bit off topic but how do you store the cost per device? Can you share your templating?
Itās a bt of a hack, you can use the Gas consumption section of the energy dashboard to store consumption and cost data.
1 Like
Iām experiencing the same issue. I would like to have a certain def load be starting in the next x hours, while the rest will remain the max of 24 hours forecast.
Today for example my boiler will not heat today because the price for 02.00AM tomorrow is cheaper.
Only option right now is to adjust the prediction_horizon right?
If youāre using MPC, can you implement a template that increases the hours (def_total_hours) during the period of time that you want the boiler to operate then reduce the hours afterwards?
1 Like
Sorry for the flurry of topics recently. Iāll be experimenting with approaches to increasing def_hours to influence scheduling.
A recent problem for me is the EMHASS containers are hitting 100% cpu usage and there seems to be some kind of queuing problem.
I am running the MPC optim every 10 mins and running ML fitting once a day. Recent changes include HASS OS upgrades and core upgrades. I am running
Any steps to debug?
Not an expert in dedicated EMHASS containers but I enabled logging for RESTful and shell commands and I see something more in the log. Maybe helpful, maybe not, but something to start with:
logger:
logs:
homeassistant.components.shell_command: debug
homeassistant.components.rest_command: debug
Yep, I have this setup. When I get into the high CPU state I get timeouts on the naive-mpc-optim action. This is with the timeout on the rest_command increased to 30secs.
Hi folks!
Just getting started with EMHass - loving this project so far. Iām just seeing some behaviour that Iām not sure is as a result of me doing something wrong.
My setup:
- 7.5kW rooftop solar
- 10kWh battery
- Amber electricyt with wholesale dynamic prices
- No deferrable loads at the moment (need to get a new switch for hot water system first)
I basically want to export excess electricity from my battery when feed-in tarrifs are favourable (usually around 7-8pm in the evening.
Today I noticed that in the morning my EMhass optimization was looking good. It was forecasting to export to the grid from the battery around 7pm. However as the day went by and I kept closer to this date it now no longer seems to suggest this and instead has a massive export spike in the middle of the day tomorrow when thereās negative feed-in tarrifs.
I run an automation every 10 minutes to update the latest amber prices via MPC.
Hereās a screenshot of my current optimisation:
And hereās the associated table:
| index | P_PV | P_Load | P_deferrable0 | P_grid_pos | P_grid_neg | P_grid | P_batt | SOC_opt | unit_load_cost | unit_prod_price | cost_profit | cost_fun_profit |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2023-10-19 17:00:00+11:00 | 1759.0 | 631.0 | 0.0 | 0.0 | -1176.0 | -1176.0 | 49.0 | 1.00 | 0.23 | 0.02 | 0.01 | 0.01 |
| 2023-10-19 17:30:00+11:00 | 929.0 | 875.0 | 0.0 | 0.0 | 0.0 | 0.0 | -54.0 | 1.00 | 0.22 | 0.01 | -0.00 | -0.00 |
| 2023-10-19 18:00:00+11:00 | 419.0 | 2378.0 | 0.0 | 0.0 | 0.0 | 0.0 | 1959.0 | 0.89 | 0.23 | 0.02 | -0.00 | -0.00 |
| 2023-10-19 18:30:00+11:00 | 275.0 | 2707.0 | 0.0 | 0.0 | 0.0 | 0.0 | 2432.0 | 0.76 | 0.26 | 0.04 | -0.00 | -0.00 |
| 2023-10-19 19:00:00+11:00 | 15.0 | 1175.0 | 0.0 | 0.0 | 0.0 | 0.0 | 1159.0 | 0.70 | 0.31 | 0.09 | -0.00 | -0.00 |
| 2023-10-19 19:30:00+11:00 | -1.0 | 1677.0 | 0.0 | 0.0 | 0.0 | 0.0 | 1679.0 | 0.61 | 0.40 | 0.17 | -0.00 | -0.00 |
| 2023-10-19 20:00:00+11:00 | -1.0 | 912.0 | 0.0 | 0.0 | -71.0 | -71.0 | 985.0 | 0.55 | 0.44 | 0.21 | 0.01 | 0.01 |
| 2023-10-19 20:30:00+11:00 | -1.0 | 1103.0 | 0.0 | 0.0 | 0.0 | 0.0 | 1105.0 | 0.49 | 0.44 | 0.21 | -0.00 | -0.00 |
| 2023-10-19 21:00:00+11:00 | -1.0 | 1182.0 | 0.0 | 0.0 | 0.0 | 0.0 | 1184.0 | 0.43 | 0.40 | 0.17 | -0.00 | -0.00 |
| 2023-10-19 21:30:00+11:00 | -1.0 | 2129.0 | 0.0 | 0.0 | 0.0 | 0.0 | 2131.0 | 0.31 | 0.37 | 0.14 | -0.00 | -0.00 |
| 2023-10-19 22:00:00+11:00 | -1.0 | 392.0 | 0.0 | 0.0 | 0.0 | 0.0 | 394.0 | 0.29 | 0.31 | 0.09 | -0.00 | -0.00 |
| 2023-10-19 22:30:00+11:00 | -1.0 | 678.0 | 0.0 | 0.0 | 0.0 | 0.0 | 680.0 | 0.26 | 0.29 | 0.07 | -0.00 | -0.00 |
| 2023-10-19 23:00:00+11:00 | -1.0 | 186.0 | 0.0 | 0.0 | 0.0 | 0.0 | 187.0 | 0.25 | 0.28 | 0.07 | -0.00 | -0.00 |
| 2023-10-19 23:30:00+11:00 | -1.0 | 178.0 | 0.0 | 0.0 | 0.0 | 0.0 | 180.0 | 0.24 | 0.29 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 00:00:00+11:00 | -1.0 | 210.0 | 0.0 | 0.0 | 0.0 | 0.0 | 212.0 | 0.22 | 0.29 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 00:30:00+11:00 | -1.0 | 168.0 | 0.0 | 0.0 | 0.0 | 0.0 | 170.0 | 0.22 | 0.28 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 01:00:00+11:00 | -1.0 | 185.0 | 0.0 | 0.0 | 0.0 | 0.0 | 186.0 | 0.21 | 0.28 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 01:30:00+11:00 | -1.0 | 215.0 | 0.0 | 0.0 | 0.0 | 0.0 | 217.0 | 0.19 | 0.29 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 02:00:00+11:00 | -1.0 | 213.0 | 0.0 | 0.0 | 0.0 | 0.0 | 214.0 | 0.18 | 0.29 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 02:30:00+11:00 | -1.0 | 239.0 | 0.0 | 0.0 | 0.0 | 0.0 | 241.0 | 0.17 | 0.29 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 03:00:00+11:00 | -1.0 | 218.0 | 0.0 | 0.0 | 0.0 | 0.0 | 220.0 | 0.16 | 0.28 | 0.06 | -0.00 | -0.00 |
| 2023-10-20 03:30:00+11:00 | -1.0 | 218.0 | 0.0 | 0.0 | 0.0 | 0.0 | 220.0 | 0.14 | 0.28 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 04:00:00+11:00 | -1.0 | 311.0 | 0.0 | 0.0 | 0.0 | 0.0 | 313.0 | 0.13 | 0.28 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 04:30:00+11:00 | -1.0 | 148.0 | 0.0 | 0.0 | 0.0 | 0.0 | 149.0 | 0.12 | 0.28 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 05:00:00+11:00 | -1.0 | 175.0 | 0.0 | 0.0 | 0.0 | 0.0 | 177.0 | 0.11 | 0.29 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 05:30:00+11:00 | -1.0 | 157.0 | 0.0 | 0.0 | 0.0 | 0.0 | 159.0 | 0.10 | 0.28 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 06:00:00+11:00 | -1.0 | 165.0 | 0.0 | 0.0 | 0.0 | 0.0 | 167.0 | 0.09 | 0.28 | 0.07 | -0.00 | -0.00 |
| 2023-10-20 06:30:00+11:00 | 123.0 | 162.0 | 0.0 | 0.0 | 0.0 | 0.0 | 39.0 | 0.09 | 0.31 | 0.09 | -0.00 | -0.00 |
| 2023-10-20 07:00:00+11:00 | 1162.0 | 146.0 | 0.0 | 0.0 | -1015.0 | -1015.0 | 0.0 | 0.09 | 0.32 | 0.10 | 0.05 | 0.05 |
| 2023-10-20 07:30:00+11:00 | 2294.0 | 190.0 | 0.0 | 0.0 | -2104.0 | -2104.0 | 0.0 | 0.09 | 0.28 | 0.06 | 0.06 | 0.06 |
| 2023-10-20 08:00:00+11:00 | 3274.0 | 674.0 | 0.0 | 0.0 | -2599.0 | -2599.0 | 0.0 | 0.09 | 0.26 | 0.05 | 0.06 | 0.06 |
| 2023-10-20 08:30:00+11:00 | 4117.0 | 1114.0 | 0.0 | 0.0 | -3003.0 | -3003.0 | 0.0 | 0.09 | 0.27 | 0.05 | 0.08 | 0.08 |
| 2023-10-20 09:00:00+11:00 | 4815.0 | 669.0 | 0.0 | 0.0 | -4146.0 | -4146.0 | 0.0 | 0.09 | 0.25 | 0.04 | 0.08 | 0.08 |
| 2023-10-20 09:30:00+11:00 | 5315.0 | 279.0 | 0.0 | 0.0 | -5035.0 | -5035.0 | 0.0 | 0.09 | 0.25 | 0.04 | 0.10 | 0.10 |
| 2023-10-20 10:00:00+11:00 | 5684.0 | 489.0 | 0.0 | 0.0 | -5194.0 | -5194.0 | 0.0 | 0.09 | 0.22 | 0.01 | 0.03 | 0.03 |
| 2023-10-20 10:30:00+11:00 | 5990.0 | 798.0 | 0.0 | 0.0 | -5191.0 | -5191.0 | 0.0 | 0.09 | 0.22 | 0.01 | 0.03 | 0.03 |
| 2023-10-20 11:00:00+11:00 | 5990.0 | 846.0 | 0.0 | 0.0 | -5143.0 | -5143.0 | 0.0 | 0.09 | 0.19 | -0.01 | -0.03 | -0.03 |
| 2023-10-20 11:30:00+11:00 | 5990.0 | 845.0 | 0.0 | 0.0 | -144.0 | -144.0 | -5000.0 | 0.33 | 0.16 | -0.05 | -0.00 | -0.00 |
| 2023-10-20 12:00:00+11:00 | 5990.0 | 739.0 | 0.0 | 0.0 | -9000.0 | -9000.0 | 3749.0 | 0.13 | 0.16 | -0.05 | -0.22 | -0.22 |
| 2023-10-20 12:30:00+11:00 | 5990.0 | 267.0 | 0.0 | 0.0 | -722.0 | -722.0 | -5000.0 | 0.38 | 0.16 | -0.05 | -0.02 | -0.02 |
| 2023-10-20 13:00:00+11:00 | 5990.0 | 247.0 | 0.0 | 0.0 | -742.0 | -742.0 | -5000.0 | 0.62 | 0.16 | -0.05 | -0.02 | -0.02 |
| 2023-10-20 13:30:00+11:00 | 5990.0 | 265.0 | 0.0 | 0.0 | -724.0 | -724.0 | -5000.0 | 0.87 | 0.16 | -0.05 | -0.02 | -0.02 |
| 2023-10-20 14:00:00+11:00 | 5990.0 | 267.0 | 0.0 | 0.0 | -2984.0 | -2984.0 | -2737.0 | 1.00 | 0.16 | -0.05 | -0.07 | -0.07 |
| 2023-10-20 14:30:00+11:00 | 5618.0 | 254.0 | 0.0 | 0.0 | -5363.0 | -5363.0 | 0.0 | 1.00 | 0.20 | -0.01 | -0.03 | -0.03 |
| 2023-10-20 15:00:00+11:00 | 5028.0 | 275.0 | 0.0 | 0.0 | -7273.0 | -7273.0 | 2521.0 | 0.86 | 0.22 | 0.01 | 0.04 | 0.04 |
| 2023-10-20 15:30:00+11:00 | 4330.0 | 491.0 | 0.0 | 0.0 | -8589.0 | -8589.0 | 4750.0 | 0.61 | 0.23 | 0.02 | 0.09 | 0.09 |
| 2023-10-20 16:00:00+11:00 | 3525.0 | 340.0 | 0.0 | 0.0 | -7934.0 | -7934.0 | 4750.0 | 0.35 | 0.25 | 0.04 | 0.16 | 0.16 |
| 2023-10-20 16:30:00+11:00 | 2628.0 | 265.0 | 0.0 | 0.0 | -7113.0 | -7113.0 | 4750.0 | 0.09 | 0.25 | 0.04 | 0.14 | 0.14 |
Cost totals for latest optimization results
| index | Cost Totals |
|---|---|
| cost_profit | 0.53 |
| cost_fun_profit | 0.53 |
Config:
hass_url: empty
long_lived_token: empty
costfun: profit
logging_level: INFO
optimization_time_step: 30
historic_days_to_retrieve: 2
method_ts_round: nearest
set_total_pv_sell: false
lp_solver: COIN_CMD
lp_solver_path: /usr/bin/cbc
set_nocharge_from_grid: false
set_nodischarge_to_grid: false
set_battery_dynamic: false
battery_dynamic_max: 0.9
battery_dynamic_min: -0.9
load_forecast_method: naive
sensor_power_photovoltaics: sensor.solar_panel_production_w
sensor_power_load_no_var_loads: sensor.total_consumption_w
number_of_deferrable_loads: 1
list_nominal_power_of_deferrable_loads:
- nominal_power_of_deferrable_loads: 600
list_operating_hours_of_each_deferrable_load:
- operating_hours_of_each_deferrable_load: 0
list_peak_hours_periods_start_hours:
- peak_hours_periods_start_hours: "05:54"
list_peak_hours_periods_end_hours:
- peak_hours_periods_end_hours: "09:24"
list_treat_deferrable_load_as_semi_cont:
- treat_deferrable_load_as_semi_cont: true
load_peak_hours_cost: 0.1907
load_offpeak_hours_cost: 0.1419
photovoltaic_production_sell_price: 0.065
maximum_power_from_grid: 9000
list_pv_module_model:
- pv_module_model: REC_Solar_REC380TP2SM_72_XV_BLK
list_pv_inverter_model:
- pv_inverter_model: SolarEdge_Technologies_Ltd___SE6000x__240V_
list_surface_tilt:
- surface_tilt: 18
list_surface_azimuth:
- surface_azimuth: 36
list_modules_per_string:
- modules_per_string: 10
list_strings_per_inverter:
- strings_per_inverter: 2
set_use_battery: true
battery_discharge_power_max: 5000
battery_charge_power_max: 5000
battery_discharge_efficiency: 0.95
battery_charge_efficiency: 0.95
battery_nominal_energy_capacity: 9700
battery_minimum_state_of_charge: 0.09
battery_maximum_state_of_charge: 1
battery_target_state_of_charge: 0.6
Would love to understand why that is. I donāt understand the spike in the middle of the day at negative rates, and no export at 7-8pm when thereās good feed-in tarrifs.
Cheers,
Andreas
what does your rest command look like?
This is it:
post_mpc_optim: "curl -i -H \"Content-Type: application/json\" -X POST -d '{
\"load_cost_forecast\":{{(([states('sensor.alexandria_general_price')|float(0)] + state_attr('sensor.alexandria_general_forecast', 'forecasts') |map(attribute='per_kwh')|list)[:48])}},
\"prod_price_forecast\":{{(([states('sensor.alexandria_feed_in_price')|float(0)] + state_attr('sensor.alexandria_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list)[:48])}},
\"prediction_horizon\":{{min(48,(state_attr('sensor.alexandria_feed_in_forecast', 'forecasts')|map(attribute='per_kwh')|list|length)+1)}},
\"soc_init\":{{(states('sensor.solaredgemb_battery1_state_of_charge')|float(0))/100}},
\"soc_final\":0.09,
\"def_total_hours\":[0]
}' http://localhost:5000/action/naive-mpc-optim"
Check the optimization status in the add-on logs: feasible/infeasible?
Setting the total number of operating hours for deferrable loads to zero can be sometimes problematic.
If you have an infeasible problem then set the operating hours to some vale but the nominal power to zero.
3 Likes
I have been very interested in being part of this project but unfortunately I have SMA inverters which is holding me back.
According to SMA I cannot take control of switching my inverters output levels. This sounds weird to me because if the grid connection goes down my inverters will switch off. I have argued that all I want to be able to do is exactly that at the time that I choose. Computer says no.
Any ideas?
Pat
Why do you need to switch the inverters?
Patrick, I assume you are specifically talking about controlling site export? This is normally of benefit when you are on a retail electricity plan that has wholesale market price exposure - like Amber.
My experience here has been that most inverters require āinstaller credentialsā to change this part of the configuration. If you are in Australia part of the reason for this is too much export can have local grid voltage impacts.
The inverter I know that allows you to make such changes is SolarEdge. Some googling indicates this device may be of use. It is not clear if it exposes an API you can call from HASS https://www.payperwatt.com/post/sma-zero-export-device-sma-export-limiter-2021
Did you get a solution to this yet? I have the same issueā¦
There is patch for this issue. Coming up in the following release.
Iāll try to publish a new release tonight.
3 Likes
Sladey
that is exactly my situation. Iām with Amber and since the change of seasons coming towards summer the prices are going FIT negative every day. Iāve taken the step of limiting my inverter output to the bare minimum (I have installer credentials)and that at least stops me from having a situation where I was paying to provide power into the grid.
Trouble is - if there is a spike in FIT prices during peak demand times 6pm to 8pm the only way I can get my battery to upload is to first change the inverter limit - then manually discharge the battery whilst monitoring prices. Spike dissapears and I then have to reverse.
My argument is always - on grid disconnect the inverter has built in smarts to effectively āstopā production. This isnāt achieved by some boffin monitoring all SMA inverters and then logging into each one as installer and stopping the ouptut. It has to be achievable through preset commands.
Pat