Multiple deferrable_loads

[gieljnssns]

I wan't to use multiple deferrable_loas, like dishwasher, washing machine, dryer, hot water, boost of my thermostat Some of my deferrable_loads aren't needed every day. Is there a way to tell to emhass if that deferrable_load is needed? Maybe an input_boolean to controle every deferrable_load?

[purcell-lab]

You can pass the run hours for each optimisation run, that will achieve this desired effect.

I have been playing around with different variables to modify the run hours dynamically.

You can see some switches and external temperature as well as costs that sometimes will drive the total_hours to zero.

"def_total_hours [EV 11 kW]": {{ state_attr('sensor.duka_charging_rate_sensor','time_left')|int(2)}}
"def_total_hours [EV@home 11 kW]": {{(is_state('binary_sensor.duka_charger', 'on') | abs) * ((100-states('sensor.duka_battery')|int(0))/11)|int(0)}}
"def_total_hours [Pool Filter 1.4 kW]": 4
"def_total_hours [HVAC humidity 4 kW]": {{max(0,(state_attr('climate.family','current_humidity')|int(0) - 60)/10)|int(0)}}
"def_total_hours [HVAC temp 4 kW]": {{max(0,(state_attr('climate.bedroom','current_temperature')|float(0) -
                                        state_attr('climate.daikin_ap46401','temperature')|float)|int(0))}}
"def_total_hours [HVAC No People 4 kW]": {{states('zone.home')}}
"def_total_hours [Pool Heater 5 kW]": {{states('input_number.pool_temperature_set_point')|int - 
                                   states('input_number.pool_temperature')|int}}
"def_total_hours_ev": "{{(is_state('binary_sensor.duka_charger', 'on') | abs) * 
                          min(((100-states('sensor.duka_battery')|int(0))/11)|int(0), ((state_attr('sensor.amber_general_forecast', 'forecasts')|
                          selectattr('descriptor','eq','extremely_low')|list|count)/4))|int(0)}}"              
"def_total_hours_hvac": "{{(state_attr('weather.location_hourly','forecast')[:24]|selectattr('temperature','gt',24)|
                            map(attribute='temperature')|list|count)}}"

"def_total_hours [EV 11 kW]": 2
"def_total_hours [EV@home 11 kW]": 2
"def_total_hours [Pool Filter 1.4 kW]": 4
"def_total_hours [HVAC humidity 4 kW]": 0
"def_total_hours [HVAC temp 4 kW]": 0
"def_total_hours [HVAC No People 4 kW]": 1
"def_total_hours [Pool Heater 5 kW]": 4
"def_total_hours_ev": "2"              
"def_total_hours_hvac": "3"

I then call this using the following shell command:

\"def_total_hours\":[{{states('sensor.def_total_hours_pool_filter')
          }},{{states('sensor.def_total_hours_pool_heatpump')
          }},{{states('sensor.def_total_hours_ev')
          }},{{states('sensor.def_total_hours_hvac')
          }},{{states('sensor.def_total_hours_hws')
          }}]}' http://localhost:5000/action/naive-mpc-optim"

\"def_total_hours\":[6,6,2,3,6]}' http://localhost:5000/action/naive-mpc-optim"

[davidusb-geek]

Hi, we will take Mark's reply as the solution to this. Indeed this use case was the goal when providing the possibility to pass some of the configuration parameters at runtime, in order to update them on the go.

You can pass these parameters also with the dayahead-optim end point.

You can also pass all these parameters at runtime:

• num_def_loads for the number of deferrable loads to consider.

• P_deferrable_nom for the nominal power for each deferrable load in Watts.

• def_total_hours for the total number of hours that each deferrable load should operate.

• treat_def_as_semi_cont to define if we should treat each deferrable load as a semi-continuous variable.

• set_def_constant to define if we should set each deferrable load as a constant fixed value variable with just one startup for each optimization task.

• solcast_api_key for the SolCast API key if you want to use this service for PV power production forecast.

• solcast_rooftop_id for the ID of your rooftop for the SolCast service implementation.

[gieljnssns]

@purcell-lab can you show me your automatisations in HA that fire your naive-mpc-optim and dayahead-optim How often do they fire? Is it possible to show all your EMHASS configs? Also your EMHASS configuration file? In the naive-mpc-optim you need to pass battery data?

When applying this controller, the following runtimeparams should be defined: prediction_horizon for the MPC prediction horizon. Fix this at at least 5 times the optimization time step. soc_init for the initial value of the battery SOC for the current iteration of the MPC. soc_final for the final value of the battery SOC for the current iteration of the MPC. def_total_hours for the list of deferrable loads functioning hours. These values can decrease as the day advances to take into account receding horizon daily energy objectives for each deferrable load.

I do not have batteries.

[davidusb-geek]

If you don't have a battery, no need to provide the SOC parameters at runtime. From the documentation :

:param soc_init: The initial battery SOC for the optimization. This parameter is optional, if not given soc_init = soc_final = soc_target from the configuration file. :param soc_final: The final battery SOC for the optimization. This parameter is optional, if not given soc_init = soc_final = soc_target from the configuration file.