EMHASS: An Energy Management for Home Assistant

I added

"curl -i -H \"Content-Type:application/json\" -X POST -d '{\"set_def_constant\":[true, true], \"load_cost_forecast\":[{{(
          ([states('sensor.energy_buy_price')|float(0)] +
          state_attr('sensor.energy_buy_price', 'forecasts') |map(attribute='per_kwh')|list)[:24])
          }}]}' http://localhost:5000/action/dayahead-optim"

to the config and wanted to adapt the sensor.energy_buy_price to

- platform: template
  sensors:
    energy_buy_price:
      friendly_name: "Energy buy price"
      unit_of_measurement: "€"
      value_template: >-
        {% set weekdays = [0, 1, 2, 3, 4] %}
        {% set entry1_to_7 = [0.1777] * 7 %}
        {% set entry8_to_23 = [0.2162] * 16 %}
        {% set entry24 = [0.1777] * 1 %}

        {% if now().weekday() in weekdays %}
          {% if now().hour < 8 %}
            {{ entry1_to_7 }}
          {% elif now().hour > 22 %}
            {{ entry24 }}
          {% else %}
            {{ entry1_to_7 + entry8_to_23 }}
          {% endif %}
        {% else %}
          {{ [0.1777] * 24 }}
        {% endif %}

But that doesn’t work. What am I doing wrong? In the development section this seems to work but the sensor doesn’t return a list if I implement it.

I am at an equal point… still trying to figure this out! :slight_smile:

You are trying to create a sensor that is meant to hold a single value as state but actually you are trying to make it contain a list, which is not intended for. And in any case there is a strict limit on the amount of characters a sensor state can contain, which will soon make this approach fail.
In the previous examples people were mapping the information contained in the attributes, from a sensor that actually contained it.
You can’t copy-paste the same code and just change the name of the sensor as it will not work.
What you could do is to create a sensor that contains the current cost and in the attributes the forecast if this is the approach you want to take.

I whish I’ld understand what you mean by this.

What you could do is to create a sensor that contains the current cost and in the attributes the forecast if this is the approach you want to take.

I had this sensor but I don’t know how to get the data into a list for emhass.

- platform: template
  sensors:
    energy_buy_price:
      friendly_name: "Energy buy price"
      unit_of_measurement: "€"
      value_template: >
          {% if states('sensor.electricity_meter_active_tariff')|string == 'low' %}
              0.1777
          {% else %}
              0.2162
          {% endif %}

Dear all,

I am testing EMHASS as an add-on to HA and I am seeing some weird behaviour of my battery. It looks like it’s charging although I am having almost no production from my PV here in dark Europe :frowning: these days. If there is some production this is instantly consumed by the current home loads I have active.

Below are extracts from my config file showing the battery parameters and some graphs of the result of todays dah ahead optimisation.

“hass_url”: “empty”,

“long_lived_token”: “empty”,

“costfun”: “cost”,

“logging_level”: “DEBUG”,

“optimization_time_step”: 60,

“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”: true,

“set_nodischarge_to_grid”: true,

“set_battery_dynamic”: false,

“battery_dynamic_max”: 0.9,

“battery_dynamic_min”: -0.9,

“weight_battery_discharge”: 1.0,

“weight_battery_charge”: 1.0,

“load_forecast_method”: “naive”,

….

“set_use_battery”: true,

“battery_discharge_power_max”: 3840,

“battery_charge_power_max”: 3840,

“battery_discharge_efficiency”: 0.95,

“battery_charge_efficiency”: 0.95,

“battery_nominal_energy_capacity”: 10515,

“battery_minimum_state_of_charge”: 0.05,

“battery_maximum_state_of_charge”: 1.0,

“battery_target_state_of_charge”: 0.05

ts P_PV P_Load P_deferrable0 P_deferrable1 P_grid_pos P_grid_neg P_grid P_batt SOC_opt unit_load_cost unit_prod_price cost_profit cost_fun_cost optim_status
2024-01-06 00:00:00+01:00 0 1656.0 0.0 0.0 1656.0 0.0 1656.0 0.0 0.05 0.21 0.09 -0.34 -0.34 Optimal
2024-01-06 01:00:00+01:00 0 1765.0 0.0 0.0 1765.0 0.0 1765.0 0.0 0.05 0.20 0.08 -0.36 -0.36 Optimal
2024-01-06 02:00:00+01:00 0 1716.0 0.0 0.0 1716.0 0.0 1716.0 0.0 0.05 0.20 0.08 -0.34 -0.34 Optimal
2024-01-06 03:00:00+01:00 0 1737.0 0.0 0.0 1737.0 0.0 1737.0 0.0 0.05 0.20 0.08 -0.34 -0.34 Optimal
2024-01-06 04:00:00+01:00 0 1666.0 2300.0 700.0 4666.0 0.0 4666.0 0.0 0.05 0.19 0.07 -0.90 -0.90 Optimal
2024-01-06 05:00:00+01:00 0 1705.0 2300.0 700.0 4705.0 0.0 4705.0 0.0 0.05 0.19 0.07 -0.91 -0.91 Optimal
2024-01-06 06:00:00+01:00 0 1701.0 2300.0 0.0 4001.0 0.0 4001.0 0.0 0.05 0.19 0.07 -0.78 -0.78 Optimal
2024-01-06 07:00:00+01:00 0 2122.0 0.0 0.0 2122.0 0.0 2122.0 0.0 0.05 0.19 0.08 -0.41 -0.41 Optimal
2024-01-06 08:00:00+01:00 0 2072.0 0.0 0.0 2072.0 0.0 2072.0 0.0 0.05 0.20 0.08 -0.42 -0.42 Optimal
2024-01-06 09:00:00+01:00 140 1914.0 0.0 0.0 1914.0 0.0 1914.0 -140.0 0.06 0.21 0.09 -0.40 -0.40 Optimal
2024-01-06 10:00:00+01:00 502 1905.0 0.0 0.0 1905.0 0.0 1905.0 -502.0 0.11 0.21 0.09 -0.41 -0.41 Optimal
2024-01-06 11:00:00+01:00 990 2004.0 0.0 0.0 2004.0 0.0 2004.0 -990.0 0.20 0.22 0.10 -0.44 -0.44 Optimal
2024-01-06 12:00:00+01:00 1203 2184.0 0.0 0.0 2184.0 0.0 2184.0 -1203.0 0.31 0.22 0.10 -0.48 -0.48 Optimal
2024-01-06 13:00:00+01:00 1203 1946.0 0.0 0.0 1946.0 0.0 1946.0 -1203.0 0.41 0.22 0.10 -0.43 -0.43 Optimal
2024-01-06 14:00:00+01:00 941 1911.0 0.0 0.0 1911.0 0.0 1911.0 -941.0 0.50 0.21 0.09 -0.41 -0.41 Optimal
2024-01-06 15:00:00+01:00 456 1876.0 0.0 0.0 1876.0 0.0 1876.0 -456.0 0.54 0.21 0.09 -0.40 -0.40 Optimal
2024-01-06 16:00:00+01:00 93 1841.0 0.0 0.0 1841.0 0.0 1841.0 -93.0 0.55 0.21 0.09 -0.39 -0.39 Optimal
2024-01-06 17:00:00+01:00 0 1817.0 0.0 0.0 1817.0 0.0 1817.0 0.0 0.55 0.21 0.09 -0.38 -0.38 Optimal
2024-01-06 18:00:00+01:00 0 1850.0 0.0 0.0 0.0 0.0 0.0 1850.0 0.36 0.23 0.10 -0.00 -0.00 Optimal
2024-01-06 19:00:00+01:00 0 2018.0 0.0 0.0 0.0 0.0 0.0 2018.0 0.16 0.22 0.10 -0.00 -0.00 Optimal
2024-01-06 20:00:00+01:00 0 2657.0 0.0 0.0 1538.0 0.0 1538.0 1119.0 0.05 0.22 0.10 -0.34 -0.34 Optimal
2024-01-06 21:00:00+01:00 0 2192.0 0.0 0.0 2192.0 0.0 2192.0 0.0 0.05 0.21 0.09 -0.47 -0.47 Optimal
2024-01-06 22:00:00+01:00 0 2023.0 0.0 0.0 2023.0 0.0 2023.0 0.0 0.05 0.21 0.09 -0.42 -0.42 Optimal
2024-01-06 23:00:00+01:00 0 2029.0 0.0 0.0 2029.0 0.0 2029.0 0.0 0.05 0.21 0.09 -0.42 -0.42 Optimal


So bottom line I don’t understand why my battery charges to 50%, which explains the discharge around 18h.

Thanks
Yves

You forecast a decent amount of pv generation. Your system assumes to store this for usage later in the day deu to price differential. Tweak your efficiency (eg to 90% instead of 95%) this way the algorithm will not optimize at a mere 2 c difference.

Alternatively you can play with the weight, bot are now at 1, would put discharge to 0 and charge to for example 0.05 or 0.1, assuming a cost of 5c or 10c to charge the battery.

That should result in the PV being used directly to load instead of storing it.

3 Likes

@davidusb
Additional function for consideration somewhere in battery settings “Maximize battery life” switch.
This can include activation of following constrains:

  • Limit battery MAX discharge to 10%
  • Limit battery max charge to 90%
  • Include compulsory 10 min pause between charge/discharge mode switches. This allows battery chemistry to stabilise (applicable for Li chemistry) between current reversal.
  • Charge current reduction to 50% after battery reaches 80% (this one not as critical)

I don’t want my battery to export to the grid for less than around $0.15/ kWh.

I had to change two things to make this happen.

I was setting soc_finsl to 0 to map a full discharge cycle, but this was forcing EMHASS see at all prices.

I have now set soc_final to min(20, currentSOC).

I was setting both the discharge and charge penalty weighting to 0.15, but it was still cycling the battery.

I have now set the discharge weighting to 0.15 and the charging weighting to 0 and it seems to be the behavior I’m after.


2 Likes

Some of this can be programmed through automations right? For instance, if charge/ discharge is initiated you can include a wait in the automation prior to action. Node red has similar functionality.

What would be nice is if we can expand the number of parameters we can feed through a shell command or rest command. Eg max charge/discharge in watts, charge from grid, profit /cost/ self consumption. That way you can achieve everything you mention through automations and with mpc see the results right away.

I have one question: Would it be possible to use EMHass as a trigger to swtich my battery loading strategy?
To the background: I have a tibber energy tariff which is on an hourly basis. Normally, when sun is shining good. The energy prices are low. In these times I would like to set my solar bat strategy to Battery Load first, so that I can use that energy when prices are high.
What I would need from EMHass would be a switch or a trigger to use in my node red automation (or in HA).

Can I do that with this integration?

When p_batt_forecast output is negative the battery is supposed to charge. This can happen via PV or grid (positive).
You can combine them to create a template sensor or so.

To use EMHASS in this fashion, which is a supported configuration, you need to setup a battery automation.

Here is what I use for my powerwall.

Great thanks a lot. Once I have the battery charging strategy setup implemented, I will try this out. Great stuff!!

This is how I’ve set it up usinf node-red: ‘My Documentation

2 Likes

I like to try out emhass add on, but i can use help
i haven’t find out how to save the config to get started

“Failed to save add-on configuration, not a valid value”

Reset to default more times, doesn’t help
After reset is “save” grey and after adding data it’s blue
In YAML i think i didn’t miss any of the 61 lines to change, but i can’t find out which line give the error

What do i miss?

HA is running on a proxmox VM
Core2024.1.3 / Supervisor2023.12.0 / Operating System11.4 / Frontend20240104.0

Did you try already with an ESP32 to RS485 for control

If miss one you can add if know the address

I have two Deye SUN-12K -SG04LP3-EU not as parallel running with esp32 in off-grid mode with grid support (Mosttime i am off-grid, as grid connection cost 60W more )
If you use ESP32> RS485 then you have still the RS232 available for another (back) control, I have only the dongle in use for a short moment, when i update the firmware manually from PC.

There is a bug in the default config.

Just update the time for peak hours period.

1 Like

Top, that solved it

Can I now look around for off-grid with grid connection only if I want to swap. (It costs 60W to stay grid-connected for my setup)
I have no peak hours but dynamic hourly prices spot market (entso-e) with net-metering for taxes.

1 Like

EMHASS experts… please take a look!

Could someone please explain a bit the use of weight_battery_discharge and --charge? Are they defined in cents?
When I use weight_battery_charge at 12.0, I assume something like the cost of energy per kwh is increased by 12 cent?