Is it possible to pass an defearable load generated from a different system into emhass? Would be great for emhass to know of a big load if we would like to generate it from a different system?
It doesn’t matter to EMHASS where the load comes from it can schedule it. You can then tailor your automations to switch that load even if it is external.
What did you have in mind?
If emhass does know of the load it can also plan for charging the batteries and so on. Mabey the mpc option is better for this since it can pass soc and run more often. Instead of day ahead
It might help if you were able to talk about the load characteristics.
I do something like this with my HVAC over winter.
Over summer I let EMHASS schedule my cooling for a variable number of hours that the weather forecast is over a set point. This works well because the hottest part of the day is the sunniest so I have lots of cheap solar PV generation EMHASS can direct into my HVAC.
Over winter this doesn’t work as I need my heating in the morning and evening, which is often the most expensive time, so EMHASS won’t schedule for those times. In this case I don’t let EMHASS schedule my HVAC and instead allow that consumption to appear in my power_load_no_var_loads sensor.
You can see below my Load Forecast (purple) is high from 0800-1200, that is the load of my unscheduled HVAC, you can see how EMHASS has delayed my pool heater (black) and EV charging (green) until my Load Forecast (purple) has reduced.
The Load Forecast is just yesterday’s consumption and the advantage of running high frequency MPC if that if my plans change from yesterday and I run my HVAC longer or shorter the MPC ‘now’ calculation will detect this and may start heating the pool earlier if I switch my HVAC off early or may delay the pool heating if I’m running my HVAC later (seen through power_load_no_var_loads).
The sensor.power_load_no_var_loads is in many ways the catchall for all the other loads in your household that EMHASS doesn’t know about, but needs to factor into its optimisation.
Yes. Main issue is that I cannot use emhass to calculate ev charging since it will never charge when we are home since it is not possible to set within time ranges for the defearable load. So charging will always happen when we are at work. And when I do a ev charging of 60kw of something without emhass the soc will miss completely. And there are some cheap hours it could have charged our batteries from grid to use batteries power instead of expensive grid power later that day.
Emhass work almost perfect exept for this 
I will try to setup with mpc optim every hour and see if this solves mye issue.
I have a question about the sensor_power_load_no_var_loads.
I use this template for that sensor
- name: Huidig verbruik zonder wp
unique_id: 664ab9ff-3875-4a45-b53a-685b7a8f7f96
unit_of_measurement: "W"
device_class: power
availability: >-
{{ has_value("sensor.huidig_verbruik") and
has_value("sensor.wasmachien_vermogen") and
has_value("sensor.droogkast_vermogen") and
has_value("sensor.warmtepompboiler_huidig_verbruik") and
has_value("sensor.afwasmachien_vermogen") }}
state: >
{% if (states("sensor.huidig_verbruik") | float(default=0) -
states("sensor.wasmachien_vermogen") | float(default=0) -
states("sensor.droogkast_vermogen") | float(default=0) -
states("sensor.warmtepompboiler_huidig_verbruik") | float(default=0) -
states("sensor.afwasmachien_vermogen") | float(default=0)) | round(1) > 0 %}
{{ (states("sensor.huidig_verbruik") | float(default=0) -
states("sensor.wasmachien_vermogen") | float(default=0) -
states("sensor.droogkast_vermogen") | float(default=0) -
states("sensor.warmtepompboiler_huidig_verbruik") | float(default=0) -
states("sensor.afwasmachien_vermogen") | float(default=0)) | round(1)}}
{% else %}
{{ 0 | float(default=0) }}
{% endif %}
Sometimes my heatpump for hot water sensor.warmtepompboiler_huidig_verbruik goes on because the water in the boiler is to cold (before emhass schedules it). Do I have to leave it out the sensor_power_load_no_var_loads on that moment?
The same for other deferrable loads when they are turned on without emhass?
dsy-ahead optimisation works well when things are known for the next 24 hours; pricing fixed, solar PV forecast reliable and household loads fixed.
EV charging challenges this as the car comes and goes during the day as well as charges offsite. It looks like you are trying to setup your EV as a battery in EMHASS, I have setup my EV as a deferrable load, not the battery in EMHASS.
I run high frequency MPC to assist with this added complexity.
If the car isn’t home and not plugged in then I schedule 0 hours for EV charging (def_total_hours), which allows EMHASS to allocate power to other devices for the day.
When the car has plugged in and at home I schedule (def_totak_hours) the number of hours to arrive the desired SOC (usually 90%) at my maximum charging rate of 11 kW.
By running high frequency MPC as the situation with my car changes it dynamically adjusts the EMHASS optimisation plan throughout the day.
Last week we took delivery of our 2nd EV (now a sustainable energy household!) and I have the second EV setup as another deferrable load. It is fascinating to watch EMHASS dynamically schedule and charge the to two EVs as they come and go during the day.
2 Likes
Quick question
What are the definitions of these two configurations?
They both have the same description and it’s not clear to me what they are for.
My battery has two SOC entities:
One is the SOC total and the second is the SOC usable.
When the battery is 100% charged they will both indicate 100%.
When the battery approaches 0% charge the usable (or user) entity will hit 0% when the total (or real) entity will still show about 9% which is reserved, can’t be used. At present my battery doesn’t get below about 5% usable. I think that’s because its about 5 years old.
What should I be setting these two configuartion to? Or do they have no effect with the following switch set to off:
Thanks in advance
Om not using ev battery as battery in emhass. I have a different battery connected to the solar inverter. Yes I i agree it works perfectly when there are no unknown loads.
1 Like
Hi.
This can be used to limit the power dynamic of your battery between time steps in power per unit of time.
The basic equation is this one for positive battery power values (battery discharging):
P_bat_pos[k+1] - P_bat_pos[k] <= timeStep*battery_dynamic_max*Pd_max
So let’s put some numbers.
If for time 12:00 you have a battery power of say 1000W then P_bat_pos[12:00] = 1000.
If for time 13:00 you have a battery power of say 2000W then P_bat_pos[13:00] = 2000.
So this is assuming a timeStep of 1h. And lets assume Pd_max=3000.
If battery_dynamic_max is set to say 0.25 then you will be limiting your battery dynamic power to 750W because timeStep*battery_dynamic_max*Pd_max=1*0.25*3000=750.
So that jump of 1000W between 12:00 and 13:00 won’t be allowed in the optimization results.
On the other hand if you let that default value to battery_dynamic_max=1 your dynamic limit is now 3000W and that jump of power will be allowed in the results.
The same reasoning applies to negative battery powers (battery charging)
1 Like
Hi everyone! Anyone had issues with getting data published but when you open EMHASS ui you don’t see anything published? Also automations not triggering.
I raised No data published but logs display data published · Issue #45 · davidusb-geek/emhass-add-on · GitHub for this, but checking here if I may have missed something obvious
Ok, thanks for that.
I’m inclined to use the full power of the battery so I understand I would set it to 1 and -1 to be able to draw or charge at its maximum 3.3kW?
I can actually command the battery to charge or discharge at whatever rate I choose using POST command anyway and have automations set up to do so at maximum power of 3.3kW.
So the best way to then automate charging from the grid for morning peek (which is at 07:00 when everybody is up making coffee and with the heaters on, winter here) am I right in using sensor.p_batt_forecast? When this sensor drops at 03:00 (or whenever) and it’s dark outside then its predicting that a charge is required to avoid the inevitable price rise at 07:00?
The example below is showing that there won’t be a need to charge overnight because the battery charge will last until the sun comes up. But that will probably change as the day goes on and the forecast will change with it.
So, I should have an automation that checks that its night time (or that the sun is not driving the PV) and if p_batt_forecast drops below 0, probably towards -3300, then I should command the battery to charge until p_batt_forecast goes above 0. Have I got this right?
I wouldn’t try and second guess EMHASS by checking if it is day or night via automations.
As your battery allows you to set your charging rate, I would just set that value exactly from p_batt_forecast, maybe every five minutes.
ok. I’ll have to develop a level of trust first (test it in other words). But sounds good. Thanks Mark.
Actually, it does seem to be predicting a charge of -2,594 (assuming - figure means charge)
and that’s what’s being supplied by PV
So don’t want to charge from the grid now, just let the sun do its thing.
Ok so I set up an automation that does three things
- Charges at p_batt_forecast when its a negative figure
- Puts the battery into standby when p_batt_forecast is 0
- Puts the battery into ‘Automatic - self consumption’ when above 0 (don’t quite trust it to discharge at p_batt_forecast yet)
Result:
Overynight is charged the battery to just under 50% when there’s a sunny day coming up so not sure why?
Also, the forecast seems to want to charge again in the middle of a sunny day?
I’m on the Ausgrid two way trial tariff that adds an extra 26.58 c/kWh FiT between 14:00 and 20:00 so I don’t want to be charging when this schedule wants to charge. I’ll want to be discharging somewhat but not too much as I want to get over the evening peek which will end at 20:00.
So I want the system to combine the forecast PV and battery capacity and calculate the discharge rate to streatch battery to 20:00 and feed in as much energy during this Ausgrid two way tariff peek. Perhaps I have something misconfigured?
My shell commands:
shell_command:
dayahead_optim: 'curl -i -H "Content-Type: application/json" -X POST -d ''{}'' http://localhost:5000/action/dayahead-optim'
publish_data: 'curl -i -H "Content-Type: application/json" -X POST -d ''{}'' http://localhost:5000/action/publish-data'
post_amber_forecast:
'curl -i -H ''Content-Type: application/json'' -X POST -d ''{"prod_price_forecast":{{(
state_attr(''sensor.cecil_st_feed_in_forecast'', ''forecasts'')|map(attribute=''per_kwh'')|list)
}},"load_cost_forecast":{{(
state_attr(''sensor.cecil_st_general_forecast'', ''forecasts'') |map(attribute=''per_kwh'')|list)
}},"prediction_horizon":33}'' http://localhost:5000/action/dayahead-optim'
post_emhass_forecast:
'curl -i -H ''Content-Type: application/json'' -X POST -d ''{"prod_price_forecast":{{(
state_attr(''sensor.cecil_st_feed_in_forecast'', ''forecasts'')|map(attribute=''per_kwh'')|list)
}},{{states(''sensor.solcast_24hrs_forecast'')}},"load_cost_forecast":{{(
state_attr(''sensor.cecil_st_general_forecast'', ''forecasts'') |map(attribute=''per_kwh'')|list)
}}}'' http://localhost:5000/action/dayahead-optim'
post_mpc_optim_solcast:
'curl -i -H "Content-Type: application/json" -X POST -d ''{"load_cost_forecast":{{(
([states(''sensor.cecil_st_general_price'')|float(0)] +
state_attr(''sensor.cecil_st_general_forecast'', ''forecasts'') |map(attribute=''per_kwh'')|list)[:48])
}}, "prod_price_forecast":{{(
([states(''sensor.cecil_st_feed_in_price'')|float(0)] +
state_attr(''sensor.cecil_st_feed_in_forecast'', ''forecasts'')|map(attribute=''per_kwh'')|list)[:48])
}}, "pv_power_forecast":{{states(''sensor.solcast_24hrs_forecast'')
}}, "prediction_horizon":48,"soc_init":{{(states(''sensor.sonnenbatterie_84324_state_charge_user'')|float(0))/100
}},"soc_final":1.0,"def_total_hours":[2,2,2,0]}'' http://localhost:5000/action/naive-mpc-optim'
# def_total_hours [Deferrable_0=PoolPump] [Deferrable_1=DW] [Deferrable_2=WM&D] [Deferrable_3=tesla]
Automations that call these shell commands are as follows:
- calling dayahead_optim at 05:30
- calling post_mpc_optim_solcast and then publish_data every 5 min
But I’m not calling post_amber_forecast or post_emhass_forecast at all. Don’t understand if these are required.
Can you show p_grid_forecast for the same period. It should be scheduling exports during the high pricing and shouldn’t charge to much overnight, unless these is a high price in the morning.
Can you also show the table from the web interface in port :5000 as that will show the full picture.
Mark, david,
Is there a way to set the export price target? I noticed the lowest price was 10c overnight then wanted to charge… but targeting to sell at 11c? is there a way to set the sell target price?
If you look at your load cost and prod price you are not injecting the Amber prices, thus EMHASS isn’t optimising for those price signals.
How are you calling your optimisation?