EMHASS - Energy Management for Home Assistant

[scoobs]

Hoeveel levert zo'n ML-model je eigenlijk op? Mijn verbruik is niet zo heel spannend, en ik heb met backtesten op het afgelopen jaar gemerkt dat een per-kwartier 7dma en perfect prediction (oftewel, het daadwerkelijke verbruik in de predictor doorvoeren) me zo'n 10 euro per jaar scheelde op het EMS.

[RudolfR]

Durf ik niet te zeggen. Ik heb er in het verleden alleen wat mee geëxperimenteerd, maar kreeg weinig betrouwbare R-waardes.
Mogelijk omdat m'n grootverbruikers (vaatwasser, wasmachine, droger, keuken) niet gemeten worden.

Niet mijn intentie geweest om het te blijven gebruiken, maar misschien iets over het hoofd gezien.

[Ollie]

Hoi allemaal. Ik ben sinds een weekje ook aan het experimenteren met EMHASS om alvast het e.e.a. voor te bereiden op het einde van de saldering in januari. Ik heb aardig wat zonnepanelen en sinds een paar maanden een Growatt APX accu van 20kWh. Uiteindelijk wil ik kijken om o.a. mijn EV op het slimste moment op te laden maar heb besloten maar te beginnen met het slim gebruikmaken van mijn accu. Het was in het begin wat overweldigend maar ik heb volgens mij inmiddels een configuratie die aardig lijkt te werken en redelijk doet wat in mijn ogen logisch en rendabel is. Ik draai iedere 15 minuten een MPC optimalisatie met profit als keuze.

Nu valt me zojuist echter op dat EMHASS nu besluit mijn accu met 5kW te ontladen aan het net (tegen een prod prijs van 19,8ct), voor ongeveer 15-30 minuten. Daardoor is de accu eerder leeg en tegen de tijd dat deze leeg is zal er dus uit het net ingekocht moeten worden. Volgens EMHASS zal dit dan gebeuren tegen een tarief van ongeveer 33ct. Ik begrijp niet helemaal waarom EMHASS deze keuze maakt en niet besluit de accu in dit geval uitsluitend in te zetten om het huisverbruik op te vangen en de 33ct kosten te voorkomen.

Ik snap dat het lastig is hier zo een conclusie aan te hangen (zeker zonder dat jullie mijn complete configuratie weten) maar ben benieuwd of anderen ook wel eens soortgelijk gedrag gezien hebben en hoe jullie hiermee omgaan.

Bedankt!

[Thomg]

Ollie schreef op maandag 12 oktober 2026 @ 23:30:
Hoi allemaal. Ik ben sinds een weekje ook aan het experimenteren met EMHASS om alvast het e.e.a. voor te bereiden op het einde van de saldering in januari. Ik heb aardig wat zonnepanelen en sinds een paar maanden een Growatt APX accu van 20kWh. Uiteindelijk wil ik kijken om o.a. mijn EV op het slimste moment op te laden maar heb besloten maar te beginnen met het slim gebruikmaken van mijn accu. Het was in het begin wat overweldigend maar ik heb volgens mij inmiddels een configuratie die aardig lijkt te werken en redelijk doet wat in mijn ogen logisch en rendabel is. Ik draai iedere 15 minuten een MPC optimalisatie met profit als keuze.

Nu valt me zojuist echter op dat EMHASS nu besluit mijn accu met 5kW te ontladen aan het net (tegen een prod prijs van 19,8ct), voor ongeveer 15-30 minuten. Daardoor is de accu eerder leeg en tegen de tijd dat deze leeg is zal er dus uit het net ingekocht moeten worden. Volgens EMHASS zal dit dan gebeuren tegen een tarief van ongeveer 33ct. Ik begrijp niet helemaal waarom EMHASS deze keuze maakt en niet besluit de accu in dit geval uitsluitend in te zetten om het huisverbruik op te vangen en de 33ct kosten te voorkomen.

Ik snap dat het lastig is hier zo een conclusie aan te hangen (zeker zonder dat jullie mijn complete configuratie weten) maar ben benieuwd of anderen ook wel eens soortgelijk gedrag gezien hebben en hoe jullie hiermee omgaan.

Bedankt!

Heb dit gedrag eigenlijk niet gezien sinds het goed werkt sinds een paar weken geleden na wat iteratieslagen. Mijn eerste vermoeden is dat je EMHASS de energieprijzen niet correct voert, maar dat is echt heel erg koffiedik kijken als je je config/output niet deelt zoals je zelf ook zegt

Overigens:
"Nu valt me zojuist echter op dat EMHASS nu besluit mijn accu met 5kW te ontladen aan het net (tegen een prod prijs van 19,8ct), voor ongeveer 15-30 minuten. Daardoor is de accu eerder leeg en tegen de tijd dat deze leeg is zal er dus uit het net ingekocht moeten worden. Volgens EMHASS zal dit dan gebeuren tegen een tarief van ongeveer 33ct. Ik begrijp niet helemaal waarom EMHASS deze keuze maakt en niet besluit de accu in dit geval uitsluitend in te zetten om het huisverbruik op te vangen en de 33ct kosten te voorkomen."
Is niet helemaal correct. Als je de PROFIT function gebruikt zal EMHASS focussen op maximaal buy low en sell high. Thuisverbruik opvangen is compleet out of scope en wil je ook helemaal niet zolang je nog kan salderen.

[Ollie]

Thomg schreef op dinsdag 13 oktober 2026 @ 10:43:
[...]

Heb dit gedrag eigenlijk niet gezien sinds het goed werkt sinds een paar weken geleden na wat iteratieslagen. Mijn eerste vermoeden is dat je EMHASS de energieprijzen niet correct voert, maar dat is echt heel erg koffiedik kijken als je je config/output niet deelt zoals je zelf ook zegt

Overigens:
"Nu valt me zojuist echter op dat EMHASS nu besluit mijn accu met 5kW te ontladen aan het net (tegen een prod prijs van 19,8ct), voor ongeveer 15-30 minuten. Daardoor is de accu eerder leeg en tegen de tijd dat deze leeg is zal er dus uit het net ingekocht moeten worden. Volgens EMHASS zal dit dan gebeuren tegen een tarief van ongeveer 33ct. Ik begrijp niet helemaal waarom EMHASS deze keuze maakt en niet besluit de accu in dit geval uitsluitend in te zetten om het huisverbruik op te vangen en de 33ct kosten te voorkomen."
Is niet helemaal correct. Als je de PROFIT function gebruikt zal EMHASS focussen op maximaal buy low en sell high. Thuisverbruik opvangen is compleet out of scope en wil je ook helemaal niet zolang je nog kan salderen.

Dank voor je reactie. Hierbij mijn volledige configuratie, hopelijk geeft dat wat meer info.

code:

{
  "adjusted_pv_model_max_age": 24,
  "adjusted_pv_regression_model": "LassoRegression",
  "adjusted_pv_solar_elevation_threshold": 30,
  "battery_charge_efficiency": 0.85,
  "battery_charge_power_derating": [],
  "battery_charge_power_max": 5000,
  "battery_discharge_efficiency": 0.85,
  "battery_discharge_power_max": 5000,
  "battery_dynamic_max": 0.9,
  "battery_dynamic_min": -0.9,
  "battery_identification_model_max_age": 24,
  "battery_identification_trust_tier": "observe",
  "battery_maximum_state_of_charge": 0.9,
  "battery_minimum_state_of_charge": 0.1,
  "battery_nominal_energy_capacity": 20000,
  "battery_soc_deficit_cost": 0.01,
  "battery_soc_deficit_threshold": 0.15,
  "battery_soc_final_reward_factor": 0,
  "battery_soc_surplus_cost": 0.01,
  "battery_soc_surplus_threshold": 0.9,
  "battery_stress_cost": 0,
  "battery_stress_segments": 10,
  "battery_target_state_of_charge": 0.6,
  "capacity_charge_interval_timesteps": 1,
  "capacity_cost_per_kw": 0,
  "compute_curtailment": false,
  "continual_publish": true,
  "cost_forecast_per_deferrable_load": [],
  "costfun": "profit",
  "def_minimum_off_time": [],
  "def_minimum_on_time": [],
  "deferrable_load_groups": [],
  "deferrable_load_max_cost": [],
  "delta_forecast_daily": 1,
  "end_timesteps_of_each_deferrable_load": [],
  "historic_days_to_retrieve": 2,
  "influxdb_database": "homeassistant",
  "influxdb_host": "localhost",
  "influxdb_measurement": "W",
  "influxdb_port": 8086,
  "influxdb_retention_policy": "autogen",
  "influxdb_use_ssl": false,
  "influxdb_verify_ssl": false,
  "inverter_ac_input_max": 5000,
  "inverter_ac_output_max": 5000,
  "inverter_efficiency_ac_dc": 1,
  "inverter_efficiency_dc_ac": 1,
  "inverter_is_hybrid": false,
  "inverter_power_curve_ac_dc": [],
  "inverter_power_curve_dc_ac": [],
  "inverter_stress_cost": 0,
  "inverter_stress_segments": 10,
  "is_electric_load": [],
  "load_cost_forecast_method": "hp_hc_periods",
  "load_forecast_method": "naive",
  "load_negative": false,
  "load_offpeak_hours_cost": 0.1419,
  "load_peak_hour_periods": {
    "period_hp_1": [
      {
        "start": "02:54"
      },
      {
        "end": "15:24"
      }
    ],
    "period_hp_2": [
      {
        "start": "17:24"
      },
      {
        "end": "20:24"
      }
    ]
  },
  "load_peak_hours_cost": 0.1907,
  "logging_level": "INFO",
  "lp_solver_mip_rel_gap": 0.02,
  "lp_solver_timeout": 90,
  "maximum_power_from_grid": 17000,
  "maximum_power_to_grid": 17000,
  "method_ts_round": "first",
  "minimum_power_of_deferrable_loads": [],
  "mlforecaster_weather_features": [],
  "model_type": "load_forecast",
  "modules_per_string": [
    13,
    3,
    12
  ],
  "nominal_power_of_deferrable_loads": [],
  "num_lags": 48,
  "num_threads": 0,
  "number_of_batteries": 1,
  "number_of_deferrable_loads": 0,
  "open_meteo_cache_max_age": 30,
  "operating_hours_of_each_deferrable_load": [],
  "optimization_time_step": 15,
  "perform_backtest": false,
  "photovoltaic_production_sell_price": 0.1419,
  "production_price_forecast_method": "constant",
  "publish_deferrable_load_states": true,
  "publish_horizon_attributes": true,
  "pv_inverter_model": [
    "3600",
    "1000",
    "5000"
  ],
  "pv_module_model": [
    "250",
    "295",
    "445"
  ],
  "sensor_battery_state_of_charge": [
    "sensor.growatt_inverter_roof_house_front_battery_soc"
  ],
  "sensor_linear_interp": [
    "sensor.growatt_total_pv_active_power",
    "sensor.power_load_no_var_loads",
    "sensor.growatt_inverter_roof_house_front_total_battery_charge_power",
    "sensor.growatt_inverter_roof_house_front_battery_soc"
  ],
  "sensor_power_battery": [
    "sensor.growatt_inverter_roof_house_front_total_battery_charge_power"
  ],
  "sensor_power_load_no_var_loads": "sensor.power_load_no_var_loads",
  "sensor_power_photovoltaics": "sensor.growatt_total_pv_active_power",
  "sensor_power_photovoltaics_forecast": "sensor.p_pv_forecast",
  "sensor_replace_zero": [
    "sensor.power_photovoltaics",
    "sensor.p_pv_forecast"
  ],
  "set_battery_dynamic": false,
  "set_battery_first_priority": true,
  "set_deferrable_load_single_constant": [],
  "set_deferrable_max_startups": [],
  "set_deferrable_startup_penalty": [],
  "set_nocharge_from_grid": false,
  "set_nodischarge_to_grid": false,
  "set_total_pv_sell": false,
  "set_use_adjusted_pv": true,
  "set_use_battery": true,
  "set_use_battery_identification": true,
  "set_use_pv": true,
  "set_zero_min": true,
  "sklearn_model": "KNeighborsRegressor",
  "split_date_delta": "48h",
  "ssl_no_verify": false,
  "start_timesteps_of_each_deferrable_load": [],
  "strings_per_inverter": [
    1,
    1,
    1
  ],
  "surface_azimuth": [
    131,
    221,
    221
  ],
  "surface_tilt": [
    20,
    20,
    30
  ],
  "tariff_schedule_time_zone": "",
  "treat_deferrable_load_as_semi_cont": [],
  "use_influxdb": false,
  "use_victoriametrics": false,
  "use_websocket": true,
  "var_model": "sensor.power_load_no_var_loads",
  "victoriametrics_database": "",
  "victoriametrics_host": "localhost",
  "victoriametrics_metric_regex": ".+_value",
  "victoriametrics_port": 8428,
  "victoriametrics_use_ssl": false,
  "victoriametrics_verify_ssl": false,
  "weather_forecast_method": "open-meteo",
  "weather_forecast_pv_quantile_bias": 0,
  "weight_battery_charge": [
    0.022
  ],
  "weight_battery_discharge": [
    0.022
  ]
}

Ik begrijp dat het opvangen van thuisverbruik momenteel niet nuttig is, dat is mijn doel ook niet. De reden dat ik nu met EMHASS bezig ben is om een systeem op te tuigen die ik dadelijk vanaf januari kan gebruiken, wanneer het salderen verdwijnt. Als ik daarvoor andere settings/configuraties moet gebruiken dan hoor ik het graag!

Mijn huidige configuratie resulteert vandaag nu hierin (na het draaien van de MPC):



Zover ik kan zien lijken de prijzen in EMHASS wel te kloppen. Ik heb voor nu even Zonneplan aangehouden als referentie.

[ Voor 56% gewijzigd door Ollie op 13-10-2026 11:08 ]

[Thomg]

Ollie schreef op dinsdag 13 oktober 2026 @ 11:02:
[...]

Dank voor je reactie. Hierbij mijn volledige configuratie, hopelijk geeft dat wat meer info.

Ik begrijp dat het opvangen van thuisverbruik momenteel niet nuttig is, dat is mijn doel ook niet. De reden dat ik nu met EMHASS bezig ben is om een systeem op te tuigen die ik dadelijk vanaf januari kan gebruiken, wanneer het salderen verdwijnt. Als ik daarvoor andere settings/configuraties moet gebruiken dan hoor ik het graag!

Mijn huidige configuratie resulteert vandaag nu hierin (na het draaien van de MPC):

[Afbeelding]

Zover ik kan zien lijken de prijzen in EMHASS wel te kloppen. Ik heb voor nu even Zonneplan aangehouden als referentie.

Ah, je moet je batterij gewenste eindpercentage op je laagste percentage instellen, bijv. 10%. Nu focussed EMHASS op je batterij volkrijgen voor de nacht. Dat verklaart waarom je batterij max oplaad. Overigens zou ik hier niet al te veel naar kijken, als de prijzen voor morgen bekend zijn draait EMHASS weer bij.
Je EMHASS is trouwens wel vrij streng ingesteld, nu laad het niet op in de middag rond 26 cent om te ontladen in de avond rond 37 cent. Was dat je intentie? Zo ziet het er bij mij uit.

De issue dat de batterij opgeladen word voor de nacht en niet oplaad in de middag hebben hier niets met elkaar te maken.

Edit: Je weight charge en discharge zijn te hoog voor EMHASS om dat prijsverschil waard te maken, dus besluit het effectief niets te doen voor vandaag. 85% oplaad, 85% discharge, 2.2 cent oplaad EN 2.2 cent charge is vrij heftig en zorgt ervoor dat EMHASS het pas bij extreme prijsverschillen (>20 cent) het waard gaat vinden om te op- en ontladen.

Nog een edit: Je prijzen kloppen ook niet. Prijzen zijn altijd bekend tot 12 uur 's nachts, vandaag of morgen. Niet wat je nu hebt (12 uur 's middags?)

[ Voor 13% gewijzigd door Thomg op 13-10-2026 11:18 ]

[Ollie]

Dankje! Ik ga er nog eens goed naar kijken.

Die soc_final op de laagst mogelijke SOC zetten, is dat handig?
Die heb ik nu inderdaad vast op 0.6 staan, maar heb ik nog niet veel mee geexperimenteerd.

Ik heb idd wat moeite om de accu goed ingesteld te krijgen. Het punt is dat de accu, wanneer deze gebruikt wordt (langzaam laden, snel laden, langzaam ontladen, snel ontladen, maakt niets uit), ergens tussen de 150-250W eigenverbruik heeft. Ik heb nog niet echt een goede manier gevonden om dit in EMHASS mee te nemen. Ter compensatie heb ik de charge en discharge efficientie maar op 85% gezet en de charge en discharge cost heb ik gebaseerd op de levensduur en investering van de accu.

Heb je daar nog suggesties voor?

EDIT: Wat betreft de prijzen, klopt. Ik doe nu een MPC optim voor 96 punten (24 uur met 15 minuten interval). Ik twijfel nog wat hier handig voor is. Misschien laten lopen tot het moment waarop de prijzen beschikbaar zijn (dus tot 23:59 vandaag en vanaf 13:15 tot 23:59 morgen)?

[ Voor 16% gewijzigd door Ollie op 13-10-2026 11:21 ]

[Thomg]

Ollie schreef op dinsdag 13 oktober 2026 @ 11:20:
Dankje! Ik ga er nog eens goed naar kijken.

Die soc_final op de laagst mogelijke SOC zetten, is dat handig?
Die heb ik nu inderdaad vast op 0.6 staan, maar heb ik nog niet veel mee geexperimenteerd.

Ik heb idd wat moeite om de accu goed ingesteld te krijgen. Het punt is dat de accu, wanneer deze gebruikt wordt (langzaam laden, snel laden, langzaam ontladen, snel ontladen, maakt niets uit), ergens tussen de 150-250W eigenverbruik heeft. Ik heb nog niet echt een goede manier gevonden om dit in EMHASS mee te nemen. Ter compensatie heb ik de charge en discharge efficientie maar op 85% gezet en de charge en discharge cost heb ik gebaseerd op de levensduur en investering van de accu.

Heb je daar nog suggesties voor?

EDIT: Wat betreft de prijzen, klopt. Ik doe nu een MPC optim voor 96 punten (24 uur met 15 minuten interval). Ik twijfel nog wat hier handig voor is. Misschien laten lopen tot het moment waarop de prijzen beschikbaar zijn (dus tot 23:59 vandaag en vanaf 13:15 tot 23:59 morgen)?

> Die soc_final op de laagst mogelijke SOC zetten, is dat handig?
Nou, nee, het is eigenlijk een soort van balans. 60% is OK, maar dan krijg je dus wel dat het lijkt alsof het oplaad voor 12 uur 's nachts waar dat eigenlijk nooit gewenst is. Prijzen zijn vrij consistent het goedkoopst rond 3 uur en rond de middag. Maar het maakt niet heel veel uit zolang je maar EMHASS tijdig de nieuwe prijzen voert. Met 10% krijg je iig nooit dat EMHASS "dan toch maar" de batterij gaat opladen als er iets niet goed gaat.

> Ik heb idd wat moeite om de accu goed ingesteld te krijgen. Het punt is dat de accu, wanneer deze gebruikt wordt (langzaam laden, snel laden, langzaam ontladen, snel ontladen, maakt niets uit), ergens tussen de 150-250W eigenverbruik heeft.
Oef, dat is vrij absurd. Volgend jaar wil je wss liever naar NOM en om dan constant zoveel extra te verbruiken trekt eigenlijk je usecase onderuit. Je kan dat dan beter in je charge en discharge efficiency verwerken, want dan is EMHASS toch bezig.

> Ter compensatie heb ik de charge en discharge efficientie maar op 85% gezet en de charge en discharge cost heb ik gebaseerd op de levensduur en investering van de accu.
Eerlijk, als dit praktisch is, zeker gezien je eigenverbruik die je net noemt, klopt dit wel.

> Heb je daar nog suggesties voor?
Heel kort door de bocht een andere batterij. Met zulke verliezen en sluipverbruik gaat het vrij waardeloos zijn buiten zonnige periodes m.u.v. de willekeurige uitschieter.

>EDIT: Wat betreft de prijzen, klopt. Ik doe nu een MPC optim voor 96 punten (24 uur met 15 minuten interval). Ik twijfel nog wat hier handig voor is. Misschien laten lopen tot het moment waarop de prijzen beschikbaar zijn (dus tot 23:59 vandaag en vanaf 13:15 tot 23:59 morgen)?
Ik heb zelf zoiets geschreven met AI

code:

  emhass_naive_mpc:
    url: "http://ha.test:5000/action/naive-mpc-optim"
    method: post
    content_type: "application/json"
    payload: >
      {%- set now_ts = as_timestamp(now()) %}
      {%- set step_ts = (now_ts // 900) * 900 %}

      {%- set raw_prices = state_attr('sensor.frank_energie_electricity_prices_current_electricity_price_all_in','prices') | default([], true) %}
      {%- set raw_prices_tomorrow = state_attr('sensor.frank_energie_electricity_prices_average_electricity_price_tomorrow_all_in','tomorrow_prices') | default([], true) %}
      {%- set all_raw = raw_prices + raw_prices_tomorrow %}

      {%- set fallback_duration = 900 if (all_raw | length) > 50 else 3600 %}

      {%- set price_list = namespace(list=[]) %}
      {%- set seen_price_slots = namespace(list=[]) %}
      {%- for p in all_raw %}
        {%- set p_from_ts = as_timestamp(p.from) %}
        {%- if p_from_ts not in seen_price_slots.list %}
          {%- set seen_price_slots.list = seen_price_slots.list + [p_from_ts] %}
          {%- set p_till_ts = as_timestamp(p.till) if (p.till is defined and p.till) else (p_from_ts + fallback_duration) %}
          
          {%- if p_till_ts > step_ts %}
            {%- set start_ts = [p_from_ts, step_ts] | max %}
            {%- set slots = ((p_till_ts - start_ts) // 900) | int %}
            {%- set price_val = p.price | float(0) %}
            {%- for _ in range(slots) %}
              {%- set price_list.list = price_list.list + [price_val] %}
            {%- endfor %}
          {%- endif %}
        {%- endif %}
      {%- endfor %}

      {%- set raw_pv = state_attr('sensor.solcast_pv_forecast_forecast_today','detailedForecast') | default([], true) %}
      {%- set raw_pv_tomorrow = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow','detailedForecast') | default([], true) %}
      {%- set pv_list_raw = namespace(list=[]) %}
      {%- set seen_pv_slots = namespace(list=[]) %}
      {%- for item in (raw_pv + raw_pv_tomorrow) %}
        {%- set start_ts = as_timestamp(item.period_start) %}
        {%- if start_ts not in seen_pv_slots.list %}
          {%- set seen_pv_slots.list = seen_pv_slots.list + [start_ts] %}
          {%- set pv_w = ((item.pv_estimate | default(0)) * 1000) | int(0) %}
          {%- if start_ts >= step_ts %}
            {%- set pv_list_raw.list = pv_list_raw.list + [pv_w, pv_w] %}
          {%- elif (start_ts + 1800) > step_ts %}
            {%- set pv_list_raw.list = pv_list_raw.list + [pv_w] %}
          {%- endif %}
        {%- endif %}
      {%- endfor %}

      {%- set horizon = price_list.list | length %}
      {%- set pv_len = pv_list_raw.list | length %}
      {%- if pv_len < horizon %}
        {%- set final_pv = pv_list_raw.list + [0] * (horizon - pv_len) %}
      {%- else %}
        {%- set final_pv = (pv_list_raw.list)[:horizon] %}
      {%- endif %}

      {%- set soc = (states('sensor.battery_000100707960_battery_state_of_charge') | float(0)) / 100 %}
      {%- set soc_final_target = 0.1 %}

      {
        "pv_power_forecast": {{ final_pv | tojson }},
        "load_cost_forecast": {{ price_list.list | tojson }},
        "prod_price_forecast": {{ price_list.list | tojson }},
        "prediction_horizon": {{ horizon }},
        "soc_init": {{ soc }},
        "soc_final": {{ soc_final_target }}
      }
  emhass_publish_data:
    url: "http://ha.test:5000/action/publish-data"
    method: post
    content_type: "application/json"
    payload: "{}"

Deze hoort in je configuration.yaml en roep je ieder kwartier aan met een automation.

code:

alias: 'EMHASS: Run Naive MPC Optimization'
description: >-
  Triggers EMHASS naive MPC optimization every 15 minutes and on Home Assistant
  startup
triggers:
  - minutes: /15
    trigger: time_pattern
actions:
  - data: {}
    action: rest_command.emhass_naive_mpc
  - action: rest_command.emhass_publish_data
    data: {}

Laatste kan je gebruiken as is, eerste zou ik eerst zelf aan een AI voeren om te tweaken voor jouw usecase. Als je bijv. geen solcast gebruikt kan je dat eruit halen.

[Sicco92]

@Ollie Je hebt set_battery_first_priority op true staan. Volgens de documentatie zal EMHASS eerst de accu leegtrekken voordat die stroom van het grid zal halen. Gezien je posts, wil je dat niet. Probeer het eens met die setting uit.

[Thomg]

@Ollie Morgen zit er zo'n 30 cent verschil tussen piek en dal in de ochtend en 25 in de late middag, als het correct geconfigureerd is verwacht ik dat het iig bij jou probeert op te laden rond 12 vannacht en dumpt rond 8.

[Ollie]

Bedankt voor de tips!

Ik heb set_battery_first_priority teruggezet op false en het ziet er nu inderdaad een stuk beter uit en zie geen export vanuit de accu naar het net wanneer ik dat niet verwacht. Dank @Sicco92!

@Thomg , ik zie dat hij morgenochtend om 09:00 wel een kwartiertje gaat "dumpen", maar zie hem niet de accu extra opladen vannacht. Misschien dat dat te maken heeft met de charge en discharge cost die ik ingesteld heb waardoor het nog steeds niet rendabel is?

[ Voor 10% gewijzigd door Ollie op 13-10-2026 15:17 . Reden: Horizon loopt nu tot morgen 23:59 ]

[Thomg]

Ollie schreef op dinsdag 13 oktober 2026 @ 15:03:
Bedankt voor de tips!

Ik heb set_battery_first_priority teruggezet op false en het ziet er nu inderdaad een stuk beter uit en zie geen export vanuit de accu naar het net wanneer ik dat niet verwacht. Dank @Sicco92!

@Thomg , ik zie dat hij morgenochtend om 09:00 wel een kwartiertje gaat "dumpen", maar zie hem niet de accu extra opladen vannacht. Misschien dat dat te maken heeft met de charge en discharge cost die ik ingesteld heb waardoor het nog steeds niet rendabel is?

[Afbeelding]

Ik zie de P_Batt nog steeds P_Load volgen wat aardig impliceert dat jouw EMHASS nog geconfigureerd is om vooral eigen verbruik op te vangen.

[Ollie]

Is het niet zo dat hij gewoon kijkt wat het meeste geld oplevert (functie PROFIT)? Als dat betekent dat hij op de meeste momenten het huis het beste vanuit de accu kan voorzien, dan zal hij dat doen toch?

Ik zie in jouw EMHASS plan dat de kWh prijs voor productie gelijk is aan die van consumptie. Dat is nu natuurlijk het geval, maar vanaf januari niet meer en krijg je een heel stuk minder voor die teruggeleverde energie (als het goed is zou die productie prijs in mijn EMHASS plan moeten kloppen met de situatie vanaf januari). Dan moet het verschil ook wel erg groot worden denk ik om het te verantwoorden om het net te gebruiken terwijl er energie in de accu zit.

[Thomg]

Ollie schreef op dinsdag 13 oktober 2026 @ 15:30:
Is het niet zo dat hij gewoon kijkt wat het meeste geld oplevert (functie PROFIT)? Als dat betekent dat hij op de meeste momenten het huis het beste vanuit de accu kan voorzien, dan zal hij dat doen toch?

Ik zie in jouw EMHASS plan dat de kWh prijs voor productie gelijk is aan die van consumptie. Dat is nu natuurlijk het geval, maar vanaf januari niet meer en krijg je een heel stuk minder voor die teruggeleverde energie (als het goed is zou die productie prijs in mijn EMHASS plan moeten kloppen met de situatie vanaf januari). Dan moet het verschil ook wel erg groot worden denk ik om het te verantwoorden om het net te gebruiken terwijl er energie in de accu zit.

Dat is ook wat ik precies wil nu natuurlijk, vanaf januari is het 90% zelfverbruik en zal EMHASS vooral overtollige energie slim ontladen en goedkope benodigde energie opladen. Ik zie dat bij jou de prod_price en load_cost elkaar niet volgen, dat wil je nu nog wel. Maximaal inzetten op buy cheap sell high, tenzij je meer teruglevert dan verbruikt natuurlijk (kuch zonnepanelen).
Of stuurt het nu niks aan en wil je enkel nu "observeren" en de aansturing pas aanzetten volgend jaar?

Maar onderaan de streep is het dus heel erg logisch dat het bij jou vooral je verbruik probeert te compenseren, omdat je het een veel lager bedrag voed voor terugleveropbrengst dan oplaadkosten gaat het disproportioneel zwaar verbruik compenseren prioritiseren.

[Ollie]

Thomg schreef op dinsdag 13 oktober 2026 @ 15:42:
[...]

Dat is ook wat ik precies wil nu natuurlijk, vanaf januari is het 90% zelfverbruik en zal EMHASS vooral overtollige energie slim ontladen en goedkope benodigde energie opladen. Ik zie dat bij jou de prod_price en load_cost elkaar niet volgen, dat wil je nu nog wel. Maximaal inzetten op buy cheap sell high, tenzij je meer teruglevert dan verbruikt natuurlijk (kuch zonnepanelen).
Of stuurt het nu niks aan en wil je enkel nu "observeren" en de aansturing pas aanzetten volgend jaar?

Maar onderaan de streep is het dus heel erg logisch dat het bij jou vooral je verbruik probeert te compenseren, omdat je het een veel lager bedrag voed voor terugleveropbrengst dan oplaadkosten gaat het disproportioneel zwaar verbruik compenseren prioritiseren.

Exact, volgens mij zijn we het eens .

Ik ben inderdaad met name nu aan het experimenteren als voorbereiding op januari, niet als doel om het nu actief te laten draaien. Het stuurt nu welliswaar tijdelijk wel mijn accusysteem aan, maar dat is meer als test dan als doel om iets aan te verdienen (ik heb zelfs nog een modelcontract, dus dat tariefgestuurd regelen heeft bij mij nu echt geen zin ).

Ik ben in ieder geval weer een stapje verder!

[denneappel]

Ik heb zowel een AC aangesloten PV set (Enphase) als 3x een Zendure 800 pro met ieder ~2.5Wp DC PV.
Nu kan ik de batterijen acher een proxy zetten en dus als 1 batterij aansturen en dat is prima.

Maar kan ik in emhass ook meerdere PV sets definieren?
De DC PV gaat altijd de batterij in. De AC PV kan dat beperkt tot het AC laad vermogen van de batterijen.

[MarcoPolet]

denneappel schreef op vrijdag 16 oktober 2026 @ 20:43:
Ik heb zowel een AC aangesloten PV set (Enphase) als 3x een Zendure 800 pro met ieder ~2.5Wp DC PV.
Nu kan ik de batterijen acher een proxy zetten en dus als 1 batterij aansturen en dat is prima.

Maar kan ik in emhass ook meerdere PV sets definieren?
De DC PV gaat altijd de batterij in. De AC PV kan dat beperkt tot het AC laad vermogen van de batterijen.

Ik denk dat je dat het best met solcast en de solcast hacs integratie kunt doen. Volgens mij kun je in solcast (per gratis account) sowieso 2 omvormers/strings definieren, en ik vermoed met wat kunst-en-vliegwerk wel een 2e account kunt aanmaken, die dan in hacs-solcast integratie kunt samenvoegen tot 1 voorspelling. Niet zelf getest of nageplozen, dus geen garanties :-)

[denneappel]

MarcoPolet schreef op vrijdag 16 oktober 2026 @ 21:22:
[...]

Ik denk dat je dat het best met solcast en de solcast hacs integratie kunt doen. Volgens mij kun je in solcast (per gratis account) sowieso 2 omvormers/strings definieren, en ik vermoed met wat kunst-en-vliegwerk wel een 2e account kunt aanmaken, die dan in hacs-solcast integratie kunt samenvoegen tot 1 voorspelling. Niet zelf getest of nageplozen, dus geen garanties :-)

Er 1 voorspelling van maken is prima te doen. Het probleem zit hem (denk ik) in het feit dat het DC deel sowieso in de batterij terecht komt en het veel grotere AC deel maar beperkt in de batterij kan.

De AC omvormer van de batterijen is 3kW en de AC PV set 25kWp.

[Korvaag]

Leuk dit topic. Ik ben ook met EMHASS bezig maar er zitten nog aardig wat haken en ogen aan MPC zeg. Ik heb zelf 0 deferrable loads dus alles zet ik zelf aan. Dat heeft tot gevolg dat de MPC call een wasmachine direct als 2000W verbruik de naive-mpc-optim ingooit en dat een enorme impact heeft op het hele plan. Ik heb nu een stuk code dat de prediction_horizon zo 'manipuleert' dat ie dat niet gaat zien als (voorbeeld) aankomende 6 uur een verbruik van 2000W.

Nou ben ik er nog maar net mee bezig hoor, maar het viel me vandaag op dat het om 14:15 gemaakte plan (dayahead-optim) door MPC zover overhoop werd gegooid dat mijn accu's nooit aan laden toekwamen omdat EMHASS dat elkens ging ehh.. ja ik noem het maar even 'uitstellen'. Iets wat niet logisch was imho omdat het goedkoopste moment van de dag toch echt het goedkoopste moment van de dag blijft en daar zowel een wasmachine mag aan staan als het laden van de accu.

* Korvaag is er nog niet helemaal in thuis

[scoobs]

Voor verbruik is er een tussenoplossing tussen naive en de ml modellen: 7d moving avg, per kwartier. Zit niet standaard in emhass dus zul je zelf moeten bouwen. Op die manier heeft een naive load minder impact op de rest van de dag.

[MarcoPolet]

Alternatief zou kunnen zijn: meet met een (wifi) verbruiksmeter het vermogen van je wasmachine (dus die 2000W) en haal dat af van je power_var_no_loads. In dat geval zal hij de wasmachine (en evt. andere) niet meenemen in de voorspellingen.