EMHASS: An Energy Management for Home Assistant

Ive copied everything you have to be honest haha. And thank you massively in advance.

I found the automation was disabled and only me pushing the internal button changed it after smashing it.

Now its displaying a little better but very odd data

alias: EMHASS MPC optimization
description: ""
trigger:
  - platform: time_pattern
    minutes: /1
condition: []
action:
  - service: rest_command.naive_mpc_optim
    data: {}
  - service: shell_command.publish_data
    data: {}
mode: single

Thats my dashboard coming together from your help and robert in the sonnens forum.

I Have checked over my solar sensor and i cant find why the EmHass is predicting such high measurments

image

The last image shows 17k of generation.

I cant find were that value is coming from

You should copy your rest command into developer tools templates to see what the values expand to.

SolCast has recently changed its values so you should change your multiply statement from 2000 to 1000.

What a pain in the bum, Yep 100%, im waiting for it all to update correct but yes. The 1000 multiplyer worked a charm.

No its time to play with other settings.

Is there a way to make cards bigger to fill more of the screen? or just zoom the chrome browser is only way?

Could you put this apex card Yaml file up here please. :slight_smile:

type: custom:apexcharts-card
experimental:
  color_threshold: true
graph_span: 16h
span:
  start: minute
now:
  show: true
  label: now
  color: red
yaxis:
  - id: first
    min: -0.1
    max: 0.9
    decimals: 1
    apex_config:
      forceNiceScale: true
  - id: second
    opposite: true
    min: -4000
    max: 7000
    decimals: 1
    apex_config:
      forceNiceScale: true
header:
  show: true
  title: Energy flow
  show_states: true
  colorize_states: true
series:
  - entity: sensor.cecil_st_general_forecast
    yaxis_id: first
    float_precision: 2
    show:
      in_header: after_now
    stroke_width: 4
    name: price kWh
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.start_time), entry.per_kwh];
      });
  - entity: sensor.cecil_st_feed_in_forecast
    yaxis_id: first
    float_precision: 2
    show:
      in_header: after_now
    stroke_width: 4
    name: FiT kWh
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.start_time), entry.per_kwh];
      });
  - entity: sensor.p_batt_forecast
    yaxis_id: second
    curve: stepline
    type: area
    show:
      in_header: before_now
    stroke_width: 2
    color: rgb(0,255,0)
    name: Batt Forecast
    data_generator: |
      return entity.attributes.battery_scheduled_power.map((entry) => {
        return [new Date(entry.date), entry.p_batt_forecast];
      });
  - entity: sensor.p_deferrable0
    yaxis_id: second
    curve: stepline
    stroke_width: 2
    name: Pool
    show:
      in_header: before_now
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable0];
      });
  - entity: sensor.p_deferrable1
    yaxis_id: second
    curve: stepline
    stroke_width: 2
    name: Car
    color: black
    show:
      in_header: before_now
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable1];
      });
  - entity: sensor.p_pv_forecast
    yaxis_id: second
    curve: stepline
    show:
      in_header: before_now
    stroke_width: 2
    name: PV Forecast
    color: rgb(255,255,0)
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.date), entry.p_pv_forecast];
      });
  - entity: sensor.p_load_forecast
    yaxis_id: second
    curve: stepline
    show:
      in_header: before_now
    stroke_width: 2
    name: Load Forecast
    color: rgb(255,0,0)
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.date), entry.p_load_forecast];
      });
  - entity: sensor.p_grid_forecast
    yaxis_id: second
    curve: stepline
    color: rgb(0,255,255)
    type: area
    show:
      in_header: before_now
    stroke_width: 2
    name: Grid Forecast
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.date), entry.p_grid_forecast];
      });

Thank you,

Yet again

Is there a way that i can devide the battery output sensor? Im terrible with creating sensors,

The system value it puts out is correct but it assumes that i can charge at 11600w, this is over 3 units. So i need to provide the correct flow vlaue back to my inverter.

I have used the node redflow that robert created and this works wonders.
I have 1 x 5kw inverter with 20kwh
2 x sonnens with 10kwh in each.

Sonnens only can do 3.3kw max each charge and discharge.

Even if i get the flow value devided i may get a better result

You would have to do something like this:

sensors:

# Split .p_batt_forecast  

  - platform: template
    sensors:
      p_batt_forecast_a:
        unique_id: p_batt_forecast_a
        unit_of_measurement: W
        value_template: >-
          {{ states('sensor.p_batt_forecast')|float(0) / 4 }}

  - platform: template
    sensors:
      p_batt_forecast_b:
        unique_id: p_batt_forecast_b
        unit_of_measurement: W
        value_template: >-
          {{ states('sensor.p_batt_forecast')|float(0) / 4 }}

  - platform: template
    sensors:
      p_batt_forecast_c:
        unique_id: p_batt_forecast_c
        unit_of_measurement: W
        value_template: >-
          {{ states('sensor.p_batt_forecast')|float(0) / 4 }}

  - platform: template
    sensors:
      p_batt_forecast_d:
        unique_id: p_batt_forecast_d
        unit_of_measurement: W
        value_template: >-
          {{ states('sensor.p_batt_forecast')|float(0) / 4 }}

or if not in equal 4 parts, whatever ratio is required.

Calculate it on paper first and then transpose the calculation into jinja. Experiment with the jinja code in the developer tools. Then use sensor.p_batt_forecast_a b c d for each battery.

You might have to get more elaborate and change the rate of charge if the batteries are at different levels and you want to charge one battery more than the others, so they all reach 100% at the same time.

1 Like

Home Assistant 2023.9 also supports template creation from the user interface, which makes this easier:

Hello!
Any idea why setting set_nodischarge_to_grid to true makes the optimization process “infeasible”?

hass_url: empty
long_lived_token: empty
costfun: self-consumption
logging_level: DEBUG
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: true
set_battery_dynamic: false
battery_dynamic_max: 0.9
battery_dynamic_min: -0.9
load_forecast_method: naive
sensor_power_photovoltaics: sensor.production_pv_w
sensor_power_load_no_var_loads: sensor.consumption_w
number_of_deferrable_loads: 1
list_nominal_power_of_deferrable_loads:
  - nominal_power_of_deferrable_loads: 0
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: "07:00"
list_peak_hours_periods_end_hours:
  - peak_hours_periods_end_hours: "23:00"
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: 6000
list_pv_module_model:
  - pv_module_model: SunPower_SPR_E20_327
  - pv_module_model: SunPower_SPR_P19_395_COM
list_pv_inverter_model:
  - pv_inverter_model: SMA_America__SB3000TL_US_22__240V_
  - pv_inverter_model: SMA_America__STP50_US_40__480V_
list_surface_tilt:
  - surface_tilt: 17
  - surface_tilt: 17
list_surface_azimuth:
  - surface_azimuth: 225
  - surface_azimuth: 225
list_modules_per_string:
  - modules_per_string: 9
  - modules_per_string: 14
list_strings_per_inverter:
  - strings_per_inverter: 1
  - strings_per_inverter: 1
set_use_battery: true
battery_discharge_power_max: 7100
battery_charge_power_max: 7100
battery_discharge_efficiency: 0.95
battery_charge_efficiency: 0.95
battery_nominal_energy_capacity: 27000
battery_minimum_state_of_charge: 0.3
battery_maximum_state_of_charge: 0.9
battery_target_state_of_charge: 0.6

Oh i didnt know that, im updating now. Ill try find it.

I do have to ask if anyone else started experiance entities not updating once emhasss running?

My power meter info from sonnen stop displaying info and requires me to do a hard reset on entire home assist to reboot them.

Im not sure if when im updating info to try get values correct or just random as its about 3 tims a day.

Hi Mark,

Ive found tou have solaredge metering, how did you manage to get this consumption monitoring working to go into emhass?

I used a mix of sensors from the solaredge integration to calculate the household load:

    modbus_consumption:
      friendly_name: "Consumption"
      device_class: power
      unit_of_measurement: W
      value_template: "{{ (states('sensor.solaredge_i1_ac_power')|int(0) 
                        + states('sensor.solaredge_i2_ac_power')|int(0) 
                        - states('sensor.apf_battery_entity')|int(0)
                        - states('sensor.solaredge_m1_ac_power')|int(0))}}"

The calculated consumption is the sum of the power from two SolarEdge inverter sensors minus the power from a battery entity and the grid export SolarEdge sensor.

The battery Entity, is that power discharging?

Negative battery is charging 9am-12pm.
Positive battery is exporting to grid after 6pm.

Sorry i ment the value

    modbus_consumption:
      friendly_name: "Consumption"
      device_class: power
      unit_of_measurement: W
      value_template: "{{ (states('sensor.solaredge_i1_ac_power')|int(0) 
                        + states('sensor.solaredge_i2_ac_power')|int(0) 
                        - states('sensor.apf_battery_entity')|int(0) ******this one******
                        - states('sensor.solaredge_m1_ac_power')|int(0))}}"

Quick question about the “household power consumption sensor in Watts”. At the solar panels are working the value is always negative. So shouldn’t be the inverter output also being extracted from the household power consumption?

And will this not also the case for when EMHASS would like to discharge the battery?

Another question about the “The desired battery state of charge at the end of each optimization cycle”. If I turn this off (so 0) the Cost total is higher than leaving the option default at 0,6.

In my current configuration it’s 12.18 euro (with value 0) and 9.27 euro with value 0.6.

Why is this option good to use?