EMHASS: An Energy Management for Home Assistant

Share your Projects! Custom Integrations
1253

Agree with 110hs here. It depends on what your purpose is with the optimization.
If your goal is to reach a specific target SOC at a specific time, you should reduce your horizon for every recalculation so you keep the target time.

In my scenario, I don’t really care what SOC I have at midnight, or at any other time. I only care about optimizing charging, discharging, buying and selling, in order to maximize profit. I may change to a higher min SOC later in order to keep some backup power in the battery in case of a blackout, but I haven’t installed the backup solution yet. So for now, I just optimize for profit, and knowing what happens in hour 23 of a 24 hour horizon may change the battery strategy.

1 Like
1254

I echo that. Just to share with everybody (maybe this inspires somebody or somebody will inspire me) what I’m planning to do: I’m mostly interested in self-consumption so I hope (“Winter is coming” in EU :wink: ) EMHASS will let me know the maximum I have to charge the battery at night (low prices) in order to be able to cover my household consumption of the next day, in combination with the expected solar production (wich in this season is not enough to cover everything). I’m using MPC only (for its flexibility in setting the initial SOC) with a still reducing horizon, as I may want to have a backup of 20% (I hope I can get at the least possible price) to be sure to partially cover the consumption of the following night (basically I do not plan to discharge my battery but only charge it as needed).

2 Likes
1255

Thanks for the explanation everyone!

2 Likes
1257

Unfortunately the Tesla API only reports power for vehicles as whole numbers.

I find I get better accuracy by computing on the fly:

    ev_power:
      friendly_name: "EV Power"
      value_template: "{{ (states('sensor.ev_phases')|int(0)
                          *state_attr('sensor.duka_charger_power','charger_volts')|int(0)
                          *state_attr('sensor.duka_charger_power','charger_amps_actual')|int(0))}}"
      unit_of_measurement: W
      device_class: power
1258

Yes I’ve done the same.

1259

FYI: I’ve submitted a feature request to HA to implement in the Forecast.solar integration the possibility to have access to the forecast datapoints, which has the great benefit to rely on your lat&long for more accurate predictions.
To those using this integration… feel free to vote it :slight_smile:
https://community.home-assistant.io/t/forecast-solar-integration-make-the-pv-power-and-energy-forecast-production-datapoints-accessible/621680

1260

Hi all,
I try to get this to work and like to add my water heating as a deferrable load. As its not a on/off switch I need to set a temperature to start heating the water. That can be easily done by an automation. I set operating_hours_of_each_deferrable_load time of 2 hours. But EMHASS schedules this load sometimes in two different timeframes (each 1h, eg. one in the night and one at day). I have a solar system without battery and flexible grid prices. I’m passing the grid prices and the solar forecasts for 24h (1h timeframe) to the dayahead-optim. As the heating may contains a large amount of watts i set the nominal_power_of_deferrable_loads to 11000 (the maximum watts). Most of the time it needs way less.

Is it possible to force EMHASS to schedule the time frame in a row?

1261

Oh then thats totally different and extreamly variable on the answer

1262

Has anyone managed to use the cost fun prediction for the current 24 hour only?

Im looking at mine and its $20, it seriously couldnt be so it must be calculating tomorrow in this variable.

Anyone made a temple or calc to stop at current day midnight only?

1263

Have a look at the web UI and it will show you exactly what is included in the calculation.

There is no current way to only calculate a partial cost function.

A potential change to EMHASS could provide the cost function for each period as an attribute.

1264

Have you taken a look at the set_def_constant parameter. It is a list containing true/false for each deferrable load. From the docs “Define if we should set each deferrable load as a constant fixed value variable with just one startup for each optimization task”. I am using this to control how often my pool pump is turned on an off. I must admit I don’t quite understand the behaviour I am seeing.

@davidusb what does “for each optimization task” mean if for example I am running the MPC optimizer every 5 mins?

1265

Hi, my solar often gets curtailed due to limits on the amount I an export to the grid (5kW). This means that EMHASS sees a lower actual value for PV production than it should (I am adding the latest actual/now value from PV production as the first element of my PV production forecast).

Is the solution here to adjust alpha and beta to reduce the weighting of the “current/now” value in the PV forecast?

1266

That would be a good way to manage it which I hadn’t thought of. Will give it a go.

I’m currently using the solcast now solar forecast to keep my pv higher than the curtailed limit.

But dynamic alpha/ beta might be a better way to do this.

1267

Im lost as to what you mean look at the web UI, its all numbers, that obviously relate to something, i dont know how i would limit that calc.

1268

The web UI shows you how the total cost function is calculated, it is the sum of the column cost_profit.

1000005747
1000005747864×1920 100 KB

1269

What about also not adding the current value as first element of the forecast array?

1270

Hello guys, does any one of you had succuss running the day ahead strategy in parallel with the machine learning one? I mean multiple instances of EMHASS via automatizations using curl command.

1271

This is not how you should use it.
ML (machine learning) is intended as a way to create an internal model for EMHASS to better predict future consumption.
So you are expected to run it once in a while (weekly maybe).
Once you are satisfied with the ML model you can just run your optimization(s) having EMHASS using mlforacster instead of naive as load forecast method

1272

Thanks for your swift answer, I meant using the machine learning algorithm for other purposes. For instance I want to run a machine learning algorithm to predict a room’s temperature without losing my daily day-ahead automatization.

1 Like
1273

Yes this is totally possible.
You just need to have one running instance of EMHASS.
However you can save as many machine learning models as you want. Just provide a custom name for each model to differentiate them.

For example to fit two different ML model using the forecast-model-fit endpoint then call that endpoint twice with different payloads like this:

The first payload for the first model:

runtimeparams = {
    "days_to_retrieve": 30,
    "model_type": "my_first_fancy_ML_model",
    "var_model": "sensor.home_power_consumption",
    "sklearn_model": "KNeighborsRegressor",
    "num_lags": 48,
    "split_date_delta": '48h',
    "perform_backtest": False
}

The second payload for the second ML model:

runtimeparams = {
    "days_to_retrieve": 30,
    "model_type": "my_second_fancy_ML_model",
    "var_model": "sensor.room_temperature",
    "sklearn_model": "KNeighborsRegressor",
    "num_lags": 48,
    "split_date_delta": '48h',
    "perform_backtest": False
}

Follow the same approach to use the predict and tune endpoints.

4 Likes