EMHASS - Energy Management for Home Assistant

zaterdag 24 januari 2026 11:11

ZatarraNL schreef op dinsdag 13 januari 2026 @ 19:41:
Ik ben druk bezig met EMHASS. Veel dingen zijn al gelukt. Het lukt me alleen niet om variabele prijzen in het model te krijgen. Hij houdt alleen vaste bedragen aan, eventueel met dal- en piektijden. Ik gebruik hiervoor deze sensoren met state-attributes:

1 sensor.entso_e_dynamische_prijzen_average_electricity_price: voor teruglevering
2 sensor.template_entso_e_dynamische_prijzen_average_electricity_price_inkoop: voor consumed

1 is zonder BTW en energiebelasting etc. (voor na 31-12-2026)

Hoe doen jullie dit? Wat moet ik in de json invullen?

Beetje late reactie maar heb je in de configuratie bij Tariff ook de Load cost method op csv gezet? Daar staat hij bij mij op, en ik stuur dan ook een list mee zoals anderen aangeven.

Acties:

zondag 25 januari 2026 20:28

Ik ben bezig om mijn warmtebehoefte in EMHASS te krijgen, zodat EMHASS slim mijn warmtepomp aan kan sturen. Ik volg hiervoor de instructies op https://emhass.readthedocs.io/en/latest/thermal_battery.html, en ik heb volgens mij parameters gevonden/berekend die mijn huis aardig representeren.

Ik loop er tegenaan dat ik de aansturing van de warmtepomp vanuit EMHASS op sommige momenten volstrekt onlogisch vind. Een warmtepomp doet het liefst lange runs ipv meerdere kortere runs, en dat krijg ik met geen mogelijkheid in EMHASS. Gisteravond kreeg ik een schema waarbij de warmtepomp in 3 uur tijd maar liefst 6 keer een kwartiertje aan zou moeten gaan. Vanochtend gaat het wat beter, maar EMHASS gooit er nog steeds random kwartiertjes tussen waarop de warmtepomp aan zou moeten springen.

Dit is bijvoorbeeld het schema voor vanochtend:

Afbeeldingslocatie: https://tweakers.net/i/xweuIPzOnrLuohqM1tLRQIpv-3s=/800x/filters:strip_exif()/f/image/VL9GYLbYP4O3ci7JJYBkgmwN.png?f=fotoalbum_large

In de bovenste grafiek is de lichtblauwe lijn bij 1000W mijn warmtepomp. Er zitten 2 spikes, eentje om 17:00 en eentje om 18:45. Die wil ik dus weg hebben.

Ik heb geprobeerd om de set_deferrable_startup_penalty op een hoog getal te zetten. Dat lijkt die te negeren. Ook set_deferrable_load_single_constant op true lijkt niks te doen.
Ik heb ook geprobeerd om nominal_power_of_deferrable_loads te verlagen (van 2500W naar 1000W). Dat lijkt nog het meeste effect te hebben, maar het gaat niet helemaal weg. Daarnaast kan mijn warmtepomp meer verbruiken dan die 1000W, en dat wordt dan niet goed meegenomen in EMHASS.

Heeft iemand dit al goed werkend? Zo ja, zou je je config en parameters willen delen?

Ter info, hier mijn config (de 4e deferrable load is de warmtepomp):

JSON:

{
  "adjusted_pv_model_max_age": 24,
  "adjusted_pv_regression_model": "LassoRegression",
  "adjusted_pv_solar_elevation_threshold": 10,
  "battery_charge_efficiency": 0.9,
  "battery_charge_power_max": 1201,
  "battery_discharge_efficiency": 0.89,
  "battery_discharge_power_max": 899,
  "battery_dynamic_max": 0.9,
  "battery_dynamic_min": -0.9,
  "battery_maximum_state_of_charge": 1,
  "battery_minimum_state_of_charge": 0.2,
  "battery_nominal_energy_capacity": 3840,
  "battery_stress_cost": 0,
  "battery_stress_segments": 10,
  "battery_target_state_of_charge": 0.5,
  "compute_curtailment": true,
  "continual_publish": false,
  "costfun": "profit",
  "delta_forecast_daily": 2,
  "end_timesteps_of_each_deferrable_load": [
    0,
    0,
    0,
    0
  ],
  "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": 1200,
  "inverter_ac_output_max": 800,
  "inverter_efficiency_ac_dc": 1,
  "inverter_efficiency_dc_ac": 1,
  "inverter_is_hybrid": false,
  "inverter_stress_cost": 0,
  "inverter_stress_segments": 10,
  "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": "DEBUG",
  "lp_solver_timeout": 45,
  "maximum_power_from_grid": 17000,
  "maximum_power_to_grid": 17000,
  "method_ts_round": "nearest",
  "minimum_power_of_deferrable_loads": [
    0,
    0,
    0,
    0,
    0
  ],
  "model_type": "load_forecast",
  "modules_per_string": [
    8
  ],
  "nominal_power_of_deferrable_loads": [
    11000,
    7200,
    2500,
    1000
  ],
  "num_lags": 48,
  "num_threads": 0,
  "number_of_deferrable_loads": 4,
  "open_meteo_cache_max_age": 30,
  "operating_hours_of_each_deferrable_load": [
    0,
    0,
    0,
    0
  ],
  "optimization_time_step": 15,
  "perform_backtest": false,
  "photovoltaic_production_sell_price": 0.1419,
  "production_price_forecast_method": "constant",
  "pv_inverter_model": [
    "GoodWe_Technologies_Co___Ltd___GW5000A_MS__240V_"
  ],
  "pv_module_model": [
    "JA_Solar_JAM72S01_375_PR"
  ],
  "sensor_linear_interp": [
    "sensor.power_load_no_var_loads_filter"
  ],
  "sensor_power_load_no_var_loads": "sensor.power_load_no_var_loads_filter",
  "sensor_power_photovoltaics": "sensor.pv_power",
  "sensor_power_photovoltaics_forecast": "sensor.p_pv_forecast",
  "sensor_replace_zero": [
    "sensor.pv_power"
  ],
  "set_battery_dynamic": false,
  "set_deferrable_load_single_constant": [
    false,
    false,
    true,
    false
  ],
  "set_deferrable_startup_penalty": [
    0,
    0,
    1,
    4
  ],
  "set_nocharge_from_grid": false,
  "set_nodischarge_to_grid": false,
  "set_total_pv_sell": false,
  "set_use_adjusted_pv": false,
  "set_use_battery": 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": [
    0,
    0,
    0,
    0
  ],
  "strings_per_inverter": [
    2
  ],
  "surface_azimuth": [
    169
  ],
  "surface_tilt": [
    40
  ],
  "treat_deferrable_load_as_semi_cont": [
    false,
    false,
    false,
    false
  ],
  "use_influxdb": false,
  "use_websocket": true,
  "var_model": "sensor.power_load_no_var_loads",
  "weather_forecast_method": "open-meteo",
  "weight_battery_charge": 0,
  "weight_battery_discharge": 0.05
}

En de parameters die ik naar EMHASS stuur:

YAML:

rest_command:
  emhass_npc_optim_with_pv_15m_with_def_heat_pump:
    url: http://localhost:5000/action/naive-mpc-optim
    method: post
    timeout: 300
    payload: >
      {% set horizon = min(144, state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h_15min') | length | int) %}
      {% set charging_on_or_planned = is_state('switch.ev_smart_charging_ev_connected', 'on') and (is_state('sensor.ev_smart_charging_charging', 'on') or is_state_attr('sensor.ev_smart_charging_charging', 'charging_is_planned', true)) %}
      {% set charging_load = (state_attr('sensor.ev_smart_charging_charging', 'charging_number_of_hours') | float(0) / 0.25) | int if charging_on_or_planned else 0 %}
      {% set charging_on_or_planned_2 = is_state('switch.ev_smart_charging_ev_connected_2', 'on') and (is_state('sensor.ev_smart_charging_charging_2', 'on') or is_state_attr('sensor.ev_smart_charging_charging_2', 'charging_is_planned', true)) %}
      {% set charging_load_2 = (state_attr('sensor.ev_smart_charging_charging_2', 'charging_number_of_hours') | float(0) / 0.25) | int if charging_on_or_planned_2 else 0 %}
      {% set dhw_load = 
        6 if is_state('binary_sensor.mitsubishi_next_dhw_run_is_legionella_run', 'on') else
        2 if states('sensor.mitsubishi_tank_water_temperature') | float(0) - states('input_number.dhw_temperature_setpoint') | float(0) < -2 else
        0 %}
      {% set heat_pump_load = 
        8 if is_state('sensor.mitsubishi_operating_mode', 'Heating') or is_state('sensor.mitsubishi_operating_mode', 'Cooling') else
        0 %}
      {% set heat_pump_flow_temp = states('number.mitsubishi_h_c_thermostat_target_temperature') | float(25) %}
      {
        "load_cost_forecast": {{ state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h_15min') | tojson }},
        "prod_price_forecast": {{ state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h_15min_return') | tojson }},
        {% if state_attr('sensor.solcast_forecast_data', 'forecasts') != [] %}"pv_power_forecast": {{ state_attr('sensor.solcast_24hrs_forecast_15m', 'forecasts')[:horizon] | tojson }},{% endif %}
        "prediction_horizon": {{ horizon | tojson }},
        "soc_init": {{ (states('sensor.hyper_2000_electric_level') | float(0) / 100) | round(2) | tojson }},
        "soc_final": {{ 0.4 if is_state('sensor.season', ['autumn', 'winter']) else 0.6 }},
        "operating_timesteps_of_each_deferrable_load": {{ [
          charging_load, 
          charging_load_2, 
          dhw_load, 
          heat_pump_load
        ] | tojson }},
        "def_load_config": [
          {},
          {},
          {},
          {
            "thermal_battery": {
              "supply_temperature": {{ heat_pump_flow_temp | tojson }},
              "volume": 22.0,
              "start_temperature": 21.5,
              "min_temperatures": {{ [21.0] * horizon }},
              "max_temperatures": {{ [26.0] * horizon }},
              "carnot_efficiency": 0.44,
              "u_value": 0.33,
              "envelope_area": 258.8,
              "ventilation_rate": 0.5,
              "heated_volume": 380.7,
              "window_area": 22.8,
              "shgc": 0.5,
              "internal_gains_factor": 0
            }
          }
        ],
        "outdoor_temperature_forecast": {{ [-4.0] * horizon  }}
      }

Acties:

zondag 25 januari 2026 20:41

Sicco92 schreef op zaterdag 24 januari 2026 @ 11:11:
Ik ben bezig om mijn warmtebehoefte in EMHASS te krijgen, zodat EMHASS slim mijn warmtepomp aan kan sturen. Ik volg hiervoor de instructies op https://emhass.readthedocs.io/en/latest/thermal_battery.html, en ik heb volgens mij parameters gevonden/berekend die mijn huis aardig representeren.

Was het eind-resultaat wel Optimal? Als EMHASS Infeasible als eindresultaat heeft wordt e.e.a. meestal troep.

Verder ook veel kennis op de Engelse forums:
https://community.home-as...ement-for-home-assistant/

Speciek over het thermal model:
https://github.com/davidusb-geek/emhass/discussions/340

Beide worden regelmatig door de ontwikkelaars bezocht en vragen beantwoord.

Acties:

zaterdag 21 februari 2026 14:18

MarcoPolet schreef op zondag 25 januari 2026 @ 20:28:
[...]

Was het eind-resultaat wel Optimal? Als EMHASS Infeasible als eindresultaat heeft wordt e.e.a. meestal troep.

Verder ook veel kennis op de Engelse forums:
https://community.home-as...ement-for-home-assistant/

Speciek over het thermal model:
https://github.com/davidusb-geek/emhass/discussions/340

Beide worden regelmatig door de ontwikkelaars bezocht en vragen beantwoord.

Ja, dat was wel Optimal bij die pogingen inderdaad. Daar ligt het dus niet aan.

Mijn gok is dat de startup_penalty simpelweg genegeerd wordt bij het gebruik van het thermal_model. Zojuist heb ik het nog eens getest, en ik krijg nu dit:

Afbeeldingslocatie: https://tweakers.net/i/RPJAIluIPJpv9D4ii1XtJOHvP30=/800x/filters:strip_exif()/f/image/jw0Ol8qyyuVck9AALd96UgXU.png?f=fotoalbum_large

Tussen 2:30 en 5:30 zou de warmtepomp aan moeten staan, wat voor vannacht inderdaad een mooi schema is. Helaas staat er weer een stom kwartiertje tussen waarop de warmtepomp uit zou moeten staan, van 3:30-3:45. Dat is het duurste kwartier in de reeks, maar het verschil met het een-na-duurste kwartier is 0,001 euro. Een startup penalty zou daar gewoon 1 run van maken, maar die optie lijkt genegeerd te worden.

Die links had ik al gevonden, maar er lijkt nog weinig met de thermal_battery optie gespeeld te worden. Ik zal eens op het HA forum posten. Thanks!

Acties:

VentingBow5

Ik heb sinds een paar dagen EMHASS draaien, het was inderdaad een steile leer curve maar ik ben happy met het resultaat. Ik draai DayAhead om 00:00 en MPC om de 15 min, behalve om 00:00 en allebei met een 24h forecast. Ik gebruik lists voor alle input data (load_power, pv_power, prod_price, load_cost). Voor load power een sql query waar bij mpc de eerste waarde vervangen wordt door actuele waarde, pv_power vanuit mijn HA Solcast setup en ook hier wordt bij mpc de eerste waarde vervangen door actuele waarde, en de prijzen vanuit Nordpool. Om b.v. 00:00 zijn de prijzen voor na 13:00 nog niet bekend, de laatste bekende waarde wordt dan als fixed waarde meegenomen voor de rest van de lijst, zodra ze beschikbaar zijn worden ze vervangen door de correcte.

Ik heb zelf zonnepanelen en 3 Sessy batterijen, nog geen deferrable loads (EV dit jaar). EMHASS ziet de 3 batterijen als 1 batterij en ik heb dus nog een template sensor gecreeerd waar ik de strategie opladen/ontladen bepaal. Zodat per batterij min/max soc en max laden/ontladen niet overschreden wordt. Ook heb ik een prioriteit voor de batterijen (welke eerst, tweede en als laatste) ingebouwd zodat de batterij die het minst geladen/ontladen (charged_energy) heeft altijd als eerste wordt gebruikt, bij een vermogen >1200W springt de tweede bij (vermogen gelijk verdeeld) en bij >1800W wordt het vermogen verdeeld over alle drie. Mocht tijdens het laden of ontladen een batterij zijn min/max soc overschrijden wordt het setpoint op 0W gezet en het vermogen gelijk verdeeld over de overgebleven batterijen maar nooit hoger dan de opgegeven max laad/ontlaad limieten.

Automatisering is redelijk eenvoudig aangezien ik geen deferrables heb en kijkt naar zowel p_batt als p_grid_forecast voor aansturing, als zowel p_batt en p_grid_forecast een waarde hebben dan gebruik ik p_batt als setpoint voor mijn batterijen, als p_batt een waarde heeft maar p_grid_forecast is 0 dan draai ik nul op de meter.

Het enige waar ik nog mee struggle is de alpha en beta voor MPC. Ik geef ze mee in de mpc call maar weet niet zo goed welke waarde ik ze mee moet geven. Nu alpha=0.25 en beta=0.75.

Nu wil ik de setup een tijdje monitoren en kijken of alles werkt zoals ik in mijn hoofd had . Volgende stap wordt de forecast module, eerst load power en dan pv power forecast.

zaterdag 21 februari 2026 15:00

Acties:

zaterdag 21 februari 2026 20:51

VentingBow5 schreef op zaterdag 21 februari 2026 @ 14:18:
en de prijzen vanuit Nordpool. Om b.v. 00:00 zijn de prijzen voor na 13:00 nog niet bekend, de laatste bekende waarde wordt dan als fixed waarde meegenomen voor de rest van de lijst, zodra ze beschikbaar zijn worden ze vervangen door de correcte.

Het enige waar ik nog mee struggle is de alpha en beta voor MPC. Ik geef ze mee in de mpc call maar weet niet zo goed welke waarde ik ze mee moet geven. Nu alpha=0.25 en beta=0.75.

Nu wil ik de setup een tijdje monitoren en kijken of alles werkt zoals ik in mijn hoofd had . Volgende stap wordt de forecast module, eerst load power en dan pv power forecast.

Goed bezig!! Paar overdenkingen:
Alpha/beta: gebruik tot nu toe niet, defaults zijn 0,5/0,5 en dat lijkt bij mij in elk geval behoorlijk goed te zijn
Qua prijzen; ik draai zelf de day-ahead met als trigger de 'tomorrow_valid' naar true van de nordpool integratie. Dan zit je er vlot bij. Verder vul ik altijd tot 48 uur vooruit aan vanuit de EpexPredictor integratie:
https://github.com/b3nn0/EpexPredictor/tree/main
Die geeft in basis ook de NL nordpool/epex prijzen terug, maar extrapoleert die op basis van weers/wind voorspelling, dagen in de week, etc. Kun je lokaal in een Docker draaien

Acties:

VentingBow5

Dank, ik ga me eens verdiepen in de EpexPredictor. Ik zal de alpha en beta weer op de default 0.5 zetten totdat ik een reden heb om ze te veranderen.

zaterdag 28 maart 2026 07:57

Acties:

dinsdag 31 maart 2026 16:05

Iemand al een work-around gevonden voor het timezone probleem (hierdoor werkt de publish niet):
ValueError: Mixed timezones detected. Pass utc=True in to_datetime or tz='UTC' in DatetimeIndex to convert to a common timezone.

Lost zich morgen (komende nacht 3:00) waarschijnlijk vanzelf wel op, maar zou wel prettig zijn als e.e.a. gewoon doorwerkt. Er is al wel een Issue van gemeld bij EMHASS github, maar daar geen oplossingen voor zover ik zie.

Heb mijn Docker TZ al even van Europe/Amsterdam naar UTC gezet, maar dat helpt niet. Mocht je dat ook willen doen, lijkt alleen te werken in combinatie met schakelen tussen 2 versie-nummers (bv. 0.16.2 -> 0.17.1, en dan eventueel weer terug).

[ Voor 25% gewijzigd door MarcoPolet op 28-03-2026 07:58 ]

Acties:

Los Tigros

Ik gebruik EMHASS met Sigenergy en werkt top. Ik zit echter even met de sensoren voor de stroomprijs van Zonneplan. Ik gerbruik nu o.a

code:

solar:
      current_power: sensor.sigen_plant_pv_power
      forecasts:
        - sensor.solcast_pv_forecast_forecast_today
        - sensor.solcast_pv_forecast_forecast_tomorrow
        - sensor.solcast_pv_forecast_forecast_day_3
    amber:
      general: sensor.zonneplan_current_electricity_tariff
      feed_in: sensor.zonneplan_current_electricity_tariff

Maar zoals je ziet nu dus zelfde prijs voor inkoop en verkoop omdat de zonneplan integratie ze niet beiden geeft. Iemand die hier een goede oplossing voor heeft?

donderdag 16 april 2026 13:22

Acties:

donderdag 16 april 2026 20:59

Topicstarter

Hoe zorgen jullie ervoor dat de batterij zo goed als leeg is aan het begin van een zonnige dag?

Ik draai ieder kwartier een MPC en de dayahead dagelijks om 3.30 uur. Aangezien de MPC minstens 5 periodes nodig heeft, stopt deze automatisch om 1.00 uur. Die periode is het energieverbruik toch aardig stabiel (en laag).
Echter is de tijd daarna soms te kort om de batterij te gebruiken, zeker als de zon vroeg schijnt.

Stelregel bij de DA is dat soc_begin = soc_final, en ik heb geprobeerd om soc_final aan te passen aan de hoeveelheid zon (meer zon verwacht => lagere soc om 3.30), maar dat is ook gekunsteld?

Tips?

Acties:

donderdag 7 mei 2026 09:29

RudolfR schreef op donderdag 16 april 2026 @ 13:22:
Hoe zorgen jullie ervoor dat de batterij zo goed als leeg is aan het begin van een zonnige dag?

Tips?

Ik optimaliseer op kosten, maar als ik jouw verhaal lees, dan wil jij maximale zelf consumptie, misschien dat je die setting nog niet gekozen hebt in de configuratie? Profit --> self consumption

Acties:

donderdag 14 mei 2026 12:39

Ik heb een tijdje EMHASS laten draaien als simulatie, en sinds deze week ook voor het echt in combinatie met een 15kWh Dyness Tower Pro & Goodwe GW15K-ET20 omvormer. Ik draai elke 15 minuten een MPC update van EMHASS op basis van dynamische energieprijzen en werkelijke PV / verbruiksdata. Hoewel EMHASS goed z'n best doet, is het natuurlijk lastig rekening te houden met fluctuerende waarden en werkelijke opbrengst. Daarom heb ik mijn batterijaansturing nu op 4 scenario's laten sturen:

Standaard (PV overschot laden): gebruikt auto modus omvormer, dus 0 op de meter.
Lage inkoopprijs (Geforceerd laden van het net): bovenop PV opbrengst bijladen, charge_battery modus op omvormer
Hoog verbruik / hoge verkoopprijs (Geforceerd ontladen): Batterij ontladen met door EMHASS opgegeven vermogen, discharge_battery op omvormer
Battery lock (Batterij op 0, evt PV overschot op net 'dumpen', of netto import zonder batterij bij te schakelen): Discharge modus, maar max battery discharge gelijk aan huidige SOC.

Zien jullie nog iets wat beter kan worden ingesteld?

Ter info, hier nog de YAML voor de automatisering:

YAML:

alias: EMHASS Slimme Batterijsturing
description: "EMHASS Slimme Batterijsturing"
triggers:
  - entity_id: sensor.p_batt_forecast
    trigger: state
actions:
  - variables:
      p_batt_raw: "{{ states('sensor.p_batt_forecast') | float(0) }}"
      p_grid: "{{ states('sensor.p_grid_forecast') | float(0) }}"
      p_batt: "{{ [ [p_batt_raw, 10000] | min, -10000 ] | max }}"
      charge_pct: "{{ ((p_batt | abs / 15000) * 100) | round(0) }}"
      current_soc: "{{ states('sensor.goodwe_battery_state_of_charge') | float(0) }}"

  - choose:
      # SCENARIO 1: PV overschot laden (p_batt < -100 & p_grid <= 0)
      - conditions:
          - condition: template
            value_template: "{{ p_batt < -100 and p_grid <= 0 }}"
        sequence:
          - action: select.select_option
            target:
              entity_id: select.goodwe_ems_mode
            data:
              option: auto
          - action: switch.turn_off
            target:
              entity_id: switch.goodwe_fast_charging_switch

      # SCENARIO 2: Geforceerd laden van net (p_batt < -100 & p_grid > 0)
      - conditions:
          - condition: template
            value_template: "{{ p_batt < -100 and p_grid > 0 }}"
        sequence:
          - action: select.select_option
            target:
              entity_id: select.goodwe_ems_mode
            data:
              option: charge_battery
          - action: number.set_value
            target:
              entity_id: number.goodwe_fast_charging_power
            data:
              value: "{{ charge_pct }}"
          - action: switch.turn_on
            target:
              entity_id: switch.goodwe_fast_charging_switch

      # SCENARIO 3: Ontladen (p_batt > 100)
      # Dekt zowel huisverbruik als export
      - conditions:
          - condition: template
            value_template: "{{ p_batt > 100 }}"
        sequence:
          - action: switch.turn_off
            target:
              entity_id: switch.goodwe_fast_charging_switch
          - action: select.select_option
            target:
              entity_id: select.goodwe_ems_mode
            data:
              option: discharge_battery
          - action: number.set_value
            target:
              entity_id: number.goodwe_ems_power_limit
            data:
              value: "{{ p_batt | abs | round(0) }}"
          - action: number.set_value
            target:
              entity_id: number.goodwe_depth_of_discharge_on_grid
            data:
              value: 90

      # SCENARIO 4: Battery-lock (p_batt rond 0)
      # Dwingt PV naar het net als p_grid < 0, of staat gewoon standby.
      - conditions:
          - condition: template
            value_template: "{{ p_batt | abs <= 100 }}"
        sequence:
          - action: switch.turn_off
            target:
              entity_id: switch.goodwe_fast_charging_switch
          - action: select.select_option
            target:
              entity_id: select.goodwe_ems_mode
            data:
              option: discharge_battery
          - action: number.set_value
            target:
              entity_id: number.goodwe_depth_of_discharge_on_grid
            data:
              value: "{{ (100 - current_soc) | round(0) }}"

mode: restart

Acties:

donderdag 14 mei 2026 21:02

Ben pasgeleden begonnen met EMHass.Draai op een raspberry pi 5.0 Home Assistant OS

Wil nu graag Day-Ahead Optimazion enzovoort automatisch uitvoeren. Iemand een idee hoe je zoiets in 'leken taal' kan uitleggen?

In configuration.yaml automation: include automations.yaml Uitroepteken weggehaald

In automation.yaml

- alias: EMHASS day-ahead optimization

trigger:

platform: time

at: '13:00:00'

action:

- service: shell_command.dayahead_optim

In dayahead_optim.sh curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' [url="http://localhost:5000/action/dayahead-optim"]http://localhost:5000/action/dayahead-optim[/url]

Heb de rechten goed staan.

Maar werkt niet. Iemand een idee?

Acties:

donderdag 14 mei 2026 21:40

vincent_1971 schreef op donderdag 14 mei 2026 @ 12:39:
Ben pasgeleden begonnen met EMHass.Draai op een raspberry pi 5.0 Home Assistant OS

Wil nu graag Day-Ahead Optimazion enzovoort automatisch uitvoeren. Iemand een idee hoe je zoiets in 'leken taal' kan uitleggen?

In configuration.yaml automation: include automations.yaml Uitroepteken weggehaald

In automation.yaml

- alias: EMHASS day-ahead optimization

trigger:

platform: time

at: '13:00:00'

action:

- service: shell_command.dayahead_optim

In dayahead_optim.sh curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' [url="http://localhost:5000/action/dayahead-optim"]http://localhost:5000/action/dayahead-optim[/url]

Heb de rechten goed staan.

Maar werkt niet. Iemand een idee?

In Settings, Automations, kun je de automations min of meer grafisch bekijken en zie je ook Traces van wat er is gebeurd, dat zou je wellicht info geven wat er mis gaat. Misschien is he took handiger om meteen het curl commando aan te roepen vanuit de automation, en niet via het .sh script.

Acties:

donderdag 14 mei 2026 21:59

MarcoPolet schreef op donderdag 14 mei 2026 @ 21:02:
[...]

In Settings, Automations, kun je de automations min of meer grafisch bekijken en zie je ook Traces van wat er is gebeurd, dat zou je wellicht info geven wat er mis gaat. Misschien is he took handiger om meteen het curl commando aan te roepen vanuit de automation, en niet via het .sh script.

Bedankt. Weet je hoe je het curl script vanuit automations kan aanroepen? Welk commando?

Acties:

vrijdag 15 mei 2026 14:42

Topicstarter

Ik heb dat zo:

YAML:

1
2
3

shell_command:
  emhass_dayahead_optim: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/dayahead-optim

YAML:

  - service: shell_command.emhass_dayahead_optim
    data:
      payload: >
        {"entity_save": true, "publish_prefix": "dh_", "battery_maximum_state_of_charge": {{ soc_max }}, "battery_minimum_state_of_charge": {{ soc_min }}, "battery_target_state_of_charge": {{ soc_init }}, "battery_discharge_power_max": {{ pd_max }}, "battery_charge_power_max": {{ pc_max }}, "weather_forecast_cache": false, "pv_power_forecast": {{ pv_p_fc }}, "load_cost_forecast": {{ load_cost_forecast }} }

Een aantal shell_command's met de diverse endpoints, allemaal met een payload-parameter.
Die payload geef ik dus altijd mee in de aanroep van de automations.

Het shell_command is dus direct de aanroep van curl, niet nog apart een los script dat vanaf het filesystem geladen zou moeten worden.

"localhost" is een slecht voorbeeld, dat werkt sinds kort niet meer goed:
https://github.com/davidusb-geek/emhass/issues/833

alternatief is 127.0.0.1 of de slug van je app, of homeassistant?

[ Voor 18% gewijzigd door RudolfR op 14-05-2026 22:42 ]

Acties:

donderdag 21 mei 2026 16:25

RudolfR schreef op donderdag 14 mei 2026 @ 21:59:
Ik heb dat zo:
YAML:
1
2
3
shell_command:
  emhass_dayahead_optim: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/dayahead-optim
YAML:
1
2
3
4
  - service: shell_command.emhass_dayahead_optim
    data:
      payload: >
        {"entity_save": true, "publish_prefix": "dh_", "battery_maximum_state_of_charge": {{ soc_max }}, "battery_minimum_state_of_charge": {{ soc_min }}, "battery_target_state_of_charge": {{ soc_init }}, "battery_discharge_power_max": {{ pd_max }}, "battery_charge_power_max": {{ pc_max }}, "weather_forecast_cache": false, "pv_power_forecast": {{ pv_p_fc }}, "load_cost_forecast": {{ load_cost_forecast }} }
Een aantal shell_command's met de diverse endpoints, allemaal met een payload-parameter.
Die payload geef ik dus altijd mee in de aanroep van de automations.

Het shell_command is dus direct de aanroep van curl, niet nog apart een los script dat vanaf het filesystem geladen zou moeten worden.

"localhost" is een slecht voorbeeld, dat werkt sinds kort niet meer goed:
https://github.com/davidusb-geek/emhass/issues/833

alternatief is 127.0.0.1 of de slug van je app, of homeassistant?

emhass_dayahead_optim: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://192.168.1.200:5000/action/dayahead-optim" Het zat inderdaad in de 'localhost' .. en ja je kan een breuk zoeken. $_/-\o_$

Acties:

donderdag 21 mei 2026 17:06

Krijg nu plotseling de volgende foutmelding als day-ahead-optimization doe. Iemand een idee?

Qua instellingen niets veranderd

code:

File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1464, in handle_request
    return await self.full_dispatch_request(request_context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1502, in full_dispatch_request
    result = await self.handle_user_exception(error)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1059, in handle_user_exception
    raise error
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1500, in full_dispatch_request
    result = await self.dispatch_request(request_context)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1597, in dispatch_request
    return await self.ensure_async(handler)(**request_.view_args)  # type: ignore[return-value]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/emhass/web_server.py", line 693, in action_call
    input_data_dict = await set_input_data_dict(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/emhass/command_line.py", line 1079, in set_input_data_dict
    ) = await utils.treat_runtimeparams(
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/emhass/utils.py", line 1890, in treat_runtimeparams
    compiled = compile_heat_topology(heat_topology)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/emhass/utils.py", line 509, in compile_heat_topology
    sources = topology.get("sources", []) or []
              ^^^^^^^^^^^^
AttributeError: 'str' object has no attribute 'get'

Acties:

donderdag 21 mei 2026 17:43

Topicstarter

@vincent_1971

Niet automatisch de laatste versie van EMHASS app geïnstalleerd, daar zijn sinds gisteren 2 nieuwe versies van?

Acties:

donderdag 21 mei 2026 18:01

vincent_1971 schreef op donderdag 21 mei 2026 @ 16:25:
Krijg nu plotseling de volgende foutmelding als day-ahead-optimization doe. Iemand een idee?

Je bent niet de enige: https://github.com/davidusb-geek/emhass/issues/876

Acties:

donderdag 21 mei 2026 19:51

Gummbahla schreef op donderdag 21 mei 2026 @ 17:43:
[...]

Je bent niet de enige: https://github.com/davidusb-geek/emhass/issues/876

Zo ver was ik nog niet..bedankt. Dacht al even had wat verkeerd gedaan. Wacht het wel af..

Acties:

donderdag 21 mei 2026 21:52

vincent_1971 schreef op donderdag 21 mei 2026 @ 18:01:
[...]

Zo ver was ik nog niet..bedankt. Dacht al even had wat verkeerd gedaan. Wacht het wel af..

In het bugreport wordt ook een eenvoudige fix aangegeven:

In de configuratie "heat_topology": "null" vervangen door:

"heat_topology": {

"sources": []

}

(niet geprobeerd, zit nog op .2)

Acties:

vrijdag 22 mei 2026 20:03

MarcoPolet schreef op donderdag 21 mei 2026 @ 19:51:
[...]

In het bugreport wordt ook een eenvoudige fix aangegeven:

In de configuratie "heat_topology": "null" vervangen door:

"heat_topology": {

"sources": []

}

(niet geprobeerd, zit nog op .2)

Geprobeerd..werkt niet

Acties:

Topicstarter

Dan de laatste versie maar proberen, volgens mij is het daarin opgelost.

zondag 24 mei 2026 09:33

Acties:

JaRuBe

RudolfR schreef op vrijdag 22 mei 2026 @ 20:03:
Dan de laatste versie maar proberen, volgens mij is het daarin opgelost.

kan iemand bevestigen dat het is opgelost met die laatste release?

zondag 24 mei 2026 11:43

Acties:

Zou je de vaatwasser dan niet gewoon los van EMHASS kunnen starten? Het energieverbruik komt uiteindelijk dan wel in de verbruiksschattingen terecht. Als je het echt wilt dan zou je nog kunnen werken met het window steeds opschuiven bij elke MPC call, dus bv. eerst 15 slots vooruit, een uur later 14 slots vooruit, etc.

zondag 24 mei 2026 12:24

Acties:

maandag 25 mei 2026 22:05

MarcoPolet schreef op zondag 24 mei 2026 @ 11:43:
Zou je de vaatwasser dan niet gewoon los van EMHASS kunnen starten? Het energieverbruik komt uiteindelijk dan wel in de verbruiksschattingen terecht. Als je het echt wilt dan zou je nog kunnen werken met het window steeds opschuiven bij elke MPC call, dus bv. eerst 15 slots vooruit, een uur later 14 slots vooruit, etc.

Nog niet aan gedacht. Bedankt ga er erns mee asn de slag

Acties:

zaterdag 13 juni 2026 11:51

Topicstarter

Ik ben 0.17.2 weer aan het terugzetten vanuit de backup. Met 0.17.5 werd de batterij maar matig ontladen.

Er zaten wel wat settings in die me interessant leken, zoals 'battery_soc_deficit_cost', daarmee zou het mogelijk moeten zijn om tijdelijke een lagere SoC toe te staan, maar met een penalty voor de duur.
Niet echt kunnen testen, want ik kon er geen documentatie van vinden. Later nog een poging wagen, nu te warm en zonde om de batterij niet te benutten.

edit:
Was mogelijk user error, soc_init was omhoog gekropen door een avondje weg en bijbehorend verbruik.

[ Voor 11% gewijzigd door RudolfR op 26-05-2026 10:24 ]

Acties:

savale

Hier 20+ zonnenpanelen, (uitschakelbaar) 20kwh thuisbatterijen, een EV en binnenkort een dynamisch contract en wellicht dit jaar ook een warmtepomp. Ik heb nu NOM / EV laadstrategie aardig zelf draaiend gekregen, maar ben benieuwd of emhass me kan gaan helpen met de dynamische energieprijzen:
ofewel: zorgen dat de batterij / ev niet de ochtend wordt volgeladen als de energieprijs in de middag negatief is en dat soort zaken.

Ik denk dat ik eerst emhass eens ga installeren / configureren en voorzien van de data en dan kom ik er hopelijk achter wat je er echt mee kunt.

zaterdag 13 juni 2026 17:09

Acties:

zaterdag 20 juni 2026 11:04

Topicstarter

Dat kan zeker.

Laden van een EV is een deferrable die je kunt inplannen.

In de nieuwste versie zit ook logica in het algoritme om curtailment van PV te verschuiven naar later op de dag en een configureerbare penalty voor een te lang lege of volle batterij.

Acties:

zaterdag 20 juni 2026 16:50

Topicstarter

Inmiddels met succes over op de rolling-horizon MPC, dwz een horizon van 24 uur met 48 periodes van 30 minuten en een target voor de batterij van 0.

Voorheen had ik een geforceerde eindtijd van 3.30 uur en regelde ook de MPC naar die horizon met een soc-target van 30%, met als gevolg dat er daarna niet genoeg tijd meer was om de batterij nog leeg te maken.

Daar is nu geen sprake meer van. Vanochtend is de batterij een klein uurtje leeg geweest en over een half uur is-ie weer vol. Mooi op tijd om even bij te springen als de vaatwasser straks aangaat.

(Op een lege batterij zit nu een kleine penalty, op een volle batterij (nog) niet)

Acties:

ward0

Hallo,

Ik gebruik predbat momenteel, maar overweeg toch meer en meer de overstap naar EMHASS.

Waarom? Het laden van de EV...

Nu heb ik HA zelfs iets geknutseld, maar het blijft knutselen.

Ik zou die 150eur bij EVCC kunnen betalen, maar dat is nu net het doel niet van opensource.

maandag 22 juni 2026 09:34

Acties:

maandag 22 juni 2026 09:43

Afbeeldingslocatie: https://tweakers.net/i/UME-AecJRJuotuJyldbxrT5UzIE=/800x/filters:gifsicle():strip_exif()/f/image/0dOvgfCncKdb54zbbXqzwuPf.gif?f=fotoalbum_large

Hallo,
ik heb Emhass ingericht met een virtuele batterij, om hiermee te kunnen berekenen of een thuisbatterij voor ons interessant is. De Emhass voorspelling maak ik inzichtelijk met bovenstaande grafiek en kan daarmee zien wat Emhass van plan is.. Door een voortschrijdend horizon in Emhass lukt het me (nog) niet om de besparing met een batterij te berekenen.
Heeft iemand hier een oplossing voor?

Acties:

maandag 22 juni 2026 11:17

Topicstarter

Moeilijk te zeggen zonder de gegevens van je batterij en de aanroep van je MPC.
Mogelijk staan de kosten van gebruik batterij te hoog?
Ik gebruik:
"weight_battery_charge": 0.03, "weight_battery_discharge": 0.01

Volledige payload:

code:

      {"weight_battery_charge": 0.03, "weight_battery_discharge": 0.01,
      "entity_save": true, "publish_prefix": "mpc_", "prediction_horizon": 48,
      "alpha": 0.15, "beta": 0.85, "battery_maximum_state_of_charge": 1,
      "battery_minimum_state_of_charge": 0.02, "battery_target_state_of_charge":
      0, "battery_discharge_power_max": 600, "battery_charge_power_max": 800.0,
      "prod_price_forecast": [0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055,
      0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055,
      0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055,
      0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055,
      0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055, 0.055,
      0.055], "soc_init": 0.4, "number_of_deferrable_loads": 2,
      "operating_hours_of_each_deferrable_load": [0, 0], "load_cost_forecast":
      [0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621,
      0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621,
      0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621,
      0.25, 0.25, 0.25, 0.25, 0.25, 0.25, 0.25, 0.25, 0.25, 0.25, 0.25, 0.25,
      0.25, 0.25, 0.25, 0.25, 0.2621, 0.2621, 0.2621, 0.2621, 0.2621],
      "pv_power_forecast": [1257, 1897, 2031, 2147, 2246, 2332, 2377, 2395,
      2370, 2318, 2215, 2107, 1972, 1804, 1610, 1395, 1165, 946, 718, 637, 560,
      459, 359, 196, 25, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 22, 94,
      280, 517, 754, 994, 1219, 1419], "weather_forecast_cache_only": true}

Acties:

maandag 22 juni 2026 11:30

Hoe heb jij de kosten weight_battery_charge": 0.03, "weight_battery_discharge": 0.01 berekend?
Waarom is er verschil in kosten voor het laden en ontladen?

Acties:

maandag 22 juni 2026 12:58

Topicstarter

Is een inschatting van de afschrijving per cycle, omgerekend naar €/kWh, willekeurig verdeeld over charge/discharge.
Volgens mij iets als:
Kostprijs batterij / (verwacht aantal cycles * kWh per cycle)
kWh per cycle is afhankelijk van de capaciteit en de depth of discharge, iets van 90% van de max. capaciteit waarschijnlijk?

Acties:

maandag 22 juni 2026 16:59

Thuis batterij nominaal 16,384 kW ; 0,5C DOD 80%
8000 cycli gegarandeerd;
investering € 8000 (wel incl noodstroom)
Dit is € 1,00 per cyclus van 12,5 kWh
Geeft dus een bruto kostprijs van € 0,08 per kWh
Laden 95% / ontladen 95% efficiency: geeft dan een netto kostprijs van € 0,0886 per kWh welke door de batterij gaat.
Met deze waarden rekent Emhass in mijn business_case .
Maar nu wil ik de besparing op mijn energiekosten uitrekenen door het gebruik van een (nu virtuele) batterij.

Acties:

maandag 22 juni 2026 18:19

Topicstarter

@JoOv
Ik zie wel wat opladen/ontladen van de batterij, tot ongeveer 15% SoC, maar dat is tegen elf uur al helemaal op, dat lijkt grotendeels terug het net op te gaan?

Was die capaciteit misschien bedoeld om de nacht door te komen? Kan me wel voorstellen dat 2kWh nu genoeg is voor een nachtje op batterij. De MPC zal met een rollende horizon niet meer opladen dan ook weer verbruikt (tenminste, als je battery_target_state_of_charge=0 hebt, net als ik).
Hij gaat dus niet opladen "omdat het kan".

Blijft koffiedik kijken zonder alle gegevens.

Acties:

maandag 22 juni 2026 18:57

Afbeeldingslocatie: https://tweakers.net/i/Rjy-HtUHky9B8rC9hf0V9dJ6A7Y=/800x/filters:gifsicle():strip_exif()/f/image/xPETa6jCWqWQA4S6eOo1yWzs.gif?f=fotoalbum_large

Schijnbaar heeft Emhass berekend dat het meer (€ ) opbrengt om de stroom vanavond duur te verkopen, dan dit te bewaren voor huisverbruik. Vervolgens zie je dat morgenvroeg de opgewekte stroom wordt teruggeleverd. (Gele en groene lijn lopen parallel) Rond de middag begint de batterij te laden (zwarte lijn = accuvermogen negatief en groene lijn gaat naar 0), met een piek rond 15:00 uur. En 15:00 uur is precies het tijdstip van de goedkoopste stroom. Dus 's morgens terugleveren tegen een iets hogere prijs en voorkomen dat er teruggeleverd wordt ,als de prijzen het laagst zijn!
De SOC staat op de linker Y-as en gaat van 1,6 kW tot max 14,1 kW
Op de linker Y-as staat het vermogen in Watt
Welke gegevens ontbreken er??

Acties:

maandag 22 juni 2026 19:51

Topicstarter

Oké, dus emhass doet het goed?

Staat mogelijk op costfun 'profit', met cost of self-consumption krijg je vast wat anders.

Gegevens als de energieprijs maken natuurlijk uit voor de uitkomst van de optimalisatie. Met alleen het resultaat is het lastig te bepalen of dat klopt.

Wel een mooie grafiek, is dat ook gewoon apex-charts?

Acties:

woensdag 24 juni 2026 12:47

Emhass doet het naar mijn idee goed.

Mode = Profit
Mijn gedachte hierachter is als self consumption meer oplevert, zou dat ook uit de profit mode moeten komen

In dit model wordt met dynamische energieprijzen gewerkt, daarom krijg je 's morgens een grafiek tot 24:00 uur van die dag, na 16:00 uur (als de epex prijzen voor de volgende dag bekend zijn, rekent Emhass door tot morgennacht 24:00 uur. En inderdaad de energieprijs of de spread ervan bepaalt voor Emhass de rekensom. De dynamische energieprijs (per kwartier) is eigenlijk de enige bekende waarde voor Emhass, al de andere zijn voorspellingen.

Omdat de voorspellingen in Emhass per 5 minuten kunnen veranderen (elke 5 minuten MPC optimalisatie) en omdat er geen "dagafsluiting" is, wordt het nu lastig om de "batterij_winst" uit Emhass te berekenen.
En juist daarvoor zoek ik nu een oplossing.

Grafiek is inderdaad een custom:apexcharts-card

Acties:

donderdag 25 juni 2026 09:52

Ik heb in HA een aparte helper gemaakt die per run de kosten/opbrengsten bijhoudt. Hij berekend het totale cumulatief verbruik/opbrengst vermenigvuldigd met het dan geldende inkoop-/verkooptarief. Bij elke MPC call schrijft hij de laatste waarde weg naar een dagteller. Daarmee heb je per dag de totale opbrengsten of kosten inzichtelijk.

Acties:

donderdag 25 juni 2026 20:47

Gummbahla schreef op woensdag 24 juni 2026 @ 12:47:
Ik heb in HA een aparte helper gemaakt die per run de kosten/opbrengsten bijhoudt. Hij berekend het totale cumulatief verbruik/opbrengst vermenigvuldigd met het dan geldende inkoop-/verkooptarief. Bij elke MPC call schrijft hij de laatste waarde weg naar een dagteller. Daarmee heb je per dag de totale opbrengsten of kosten inzichtelijk.

Hoe ziet die helper eruit? Haal je de waarden uit Emhass?
Zou je de yaml van deze helper willen delen?

Acties:

zaterdag 11 juli 2026 02:59

Topicstarter

Ik heb al een tijdje de data in InfluxDB staan, nu met deze settings:

YAML:

influxdb:
  #  host: 192.168.1.245
  #  port: 8086
  #  database: homeassistant
  #  username: !secret influxdb_username
  #  password: !secret influxdb_password
  max_retries: 3
  default_measurement: state

  #  ssl: false
  #  verify_ssl: false

  include:
    entities:
      # PV production sensors
      # Load / consumption sensors
      - sensor.solar_panels_total_output_power
      - sensor.power_load_no_var_loads
      # For adjusted solar panel forecast
      - sensor.p_pv_forecast

      # Electricity prices
      #- sensor.actual_energy_price_per_kwh

      # Optional (recommended for EMHASS)
      - sensor.battery_state_of_charge

sensor.p_pv_forecast heb ik recent toegevoegd, want anders kun je geen gebruik maken van optie 'set_use_adjusted_pv'. Wel logisch, jammer dat-ie crasht en dat ie niet automatisch terugvalt op de history van Home Assistant. Daar staat ook een dag of 30 in.
Hopelijk over een tijdje terug naar Influx voor een beter eigen model.

Acties:

hbvdh

Net deze post gevonden, ben drie dagen bezig EMHASS Add-on op HA goed te laten werken. de meeste zaken heb ik via de AI van google gemaaakt maar al mijn zaken zijn nu geregeld via de configuration.yaml, daar zitten de rest commando's in die alles regelen. Wat ik in de opening post lees is dat het allemaal ook via helpers, sensor en automation kan.

Ik heb 2900wp ZP, 15k Batterij, en het doel is self-consumption met slim laden op goedkope tijden. Het werkt nu wel maar ik vind de rest commando's heel erg on stabiel.

YAML:

Hier is de configuration.yaml:
rest_command:
  emhass_dayahead_optim:
    url: "http://127.0.0.1:5000/action/dayahead-optim"
    method: POST
    content_type: "application/json"
    timeout: 240
    payload: "{{ payload }}"

  emhass_naive_mpc_optim:
    url: "http://127.0.0.1:5000/action/naive-mpc-optim"
    method: POST
    content_type: "application/json"
    payload: >-
      {% set prices = state_attr('sensor.actuele_stroomprijs_all_in_2', 'forecast') %}
      {% if prices is not none and prices | length > 0 %}
        {% set price_list = prices | map(attribute='value') | list %}
      {% else %}
        {% set price_list = [0.25] * 96 %}
      {% endif %}
      
      {# Echte live meting omrekenen van kW naar Watts door te vermenigvuldigen met 1000 #}
      {% set p_load_raw = states('sensor.pylontech_force_h3x_load_power') | float(none) %}
      {% set p_load = (p_load_raw * 1000) if p_load_raw is not none else 500 %}

      {# Als de sensor al in Watts meet en de uitkomst extreem hoog wordt, beschermen we de grens #}
      {% if p_load > 50000 %}
        {% set p_load = p_load_raw | float(500) %}
      {% endif %}

      {% set soc_raw = states('sensor.pylontech_force_h3x_battery_soc') | float(none) %}
      {% set battery_soc = (soc_raw / 100) if soc_raw is not none and soc_raw > 0 else 0.5 %}
      
      {% set zero_val = 0 %}
      {% set zero_list = [zero_val] * 96 %}
      
      {# We gebruiken je echte live wattage (bijv. 650W) als de basis-voorspelling #}
      {% set base_load_val = p_load if p_load > 100 else 600 %}
      {% set dynamic_load_list = [base_load_val] * 96 %}

      {# Haal de uurlijkse Solcast data op #}
      {% set today_solcast = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedHourly') %}
      {% set tomorrow_solcast = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedHourly') %}
      
      {% if today_solcast is not none and tomorrow_solcast is not none %}
        {% set today_list = today_solcast | map(attribute='pv_estimate') | map('multiply', 1000) | list %}
        {% set tomorrow_list = tomorrow_solcast | map(attribute='pv_estimate') | list %}
        {% set hourly_combined = today_list + tomorrow_list %}
        
        {% set ns = namespace(filled=[]) %}
        {% for item in hourly_combined %}
          {% set ns.filled = ns.filled + [item, item, item, item] %}
        {% endfor %}
        {% set combined_solar = ns.filled[:96] %}
      {% else %}
        {% set combined_solar = zero_list %}
      {% endif %}

      {% if is_state('input_boolean.emhass_fetch_solcast_live', 'on') %}
        {% set use_cache = false %}
      {% else %}
        {% set use_cache = true %}
      {% endif %}

      {% if is_state('sun.sun', 'below_horizon') %}
        {% set final_soc_target = battery_soc %}
      {% else %}
        {% set final_soc_target = 0.1 %}
      {% endif %}

      {{ {
        "prod_price_forecast": price_list,
        "load_cost_forecast": price_list,
        "load_power_forecast": dynamic_load_list,
        "pv_power_forecast": combined_solar,
        "pv_location_irradiance_forecast": zero_list,
        "pv_location_temperature_forecast": zero_list,
        "pv_location_wind_speed_forecast": zero_list,
        "prediction_horizon": price_list | length,
        "num_def_loads": 0,
        "soc_init": battery_soc | round(2),
        "soc_final": final_soc_target | round(2),
        "soc_min": 0.1,
        "soc_max": 1.0,
        "p_load_now": p_load | round(1),
        "weather_forecast_cache_only": use_cache
      } | to_json }}
      
  emhass_publish_data:
    url: "http://127.0.0.1:5000/action/publish-data"
    method: POST
    payload: "{}"

  emhass_long_model_fit:
    url: "http://127.0.0.1:5000/action/longmodel-fit"
    method: POST
    content_type: "application/json"
    payload: '{"days_to_retrieve": 30}'

zaterdag 11 juli 2026 09:34

Acties:

zaterdag 11 juli 2026 14:48

Wat bedoel je precies met instabiel? Werkt het maar af en toe? Of is het laden/ontladen heel instabiel?

Acties:

hbvdh

wat ik zag vanacht rond 00:30 dat alles er goed uitzag de voorspellingen klopte enigsinds met de werkelijkheid. dus mooi.
vanmiddag rond 12:00 zou hij volgens de voorpelling moeten gaan laden van net, maar de batterij deed niets, was voor 20% vol. Wat bleek, dat de grafieken allenmaal opgschovenwaren naar nu, dus de tijden versprongen en hij von dat hij om 20:00 uur moest gaan laden.
Dus alle voorspellinge waren in tijd verschoven. Dat is nu weer hersteld en hij gooit nu de al geweest tijden weg en vult de aankomende 24 uur aan met de laatse bekende waarde (in hetgeval van nordpool prijzen).

Wat ik met stabilitiet bedoel, is dat 1 klein foutje in deze code al gelijk er voorzorgt dat het in zijn geheel niet meer werkt.

Ik zou graag voor elk onderdeel een apparte helper of sensor hebben die het allemaal regeld en klaarmaakt voor EMHASS zodat een klijn foutje makkelijker op te sporen is en de acties gecontrolleerd kunnen worden (door mij, heb niet veel coding ervaring).

zaterdag 11 juli 2026 17:25

Acties:

zaterdag 11 juli 2026 18:59

Topicstarter

Voor wat experimenteren gebruik je het best de Web UI van emhass waar je in het invoerveld (als box) gewoon een json payload zet.

Ja, die lange json payload is wel een uitdaging, een foutje is zo gemaakt.

Acties:

savale

Hier ook emhass aan weten te slingeren met solcast + dynamische tarieven. Accu / zonnepanelen info lijkt ook goed door te komen. Ik gebruik het in een python venv omgeving.

De voorspellingen die eruit komen zijn wel fraai, moet nu gaan uitdenken hoe en wat ik met deferables ga doen. Ik vind het wat onhandig dat je vaste uren moet opgeven per deferable. Dat wisselt een beetje per dag...

Kan ook gewoon de voorspellingen gaan inzetten in mijn eigen automations. Nog niet helemaal duidelijk wat nou handig is.

[ Voor 13% gewijzigd door savale op 11-07-2026 19:02 ]

dinsdag 14 juli 2026 14:21

Acties:

woensdag 15 juli 2026 16:50

Je hoeft geen vaste uren voor deferables op te geven, alleen hoe lang de deferable nodig heeft / beschikbaar is voor energieconsumptie.
Ik scan in mijn HA elke deferable (wasmachine, droger, etc.) op hun status. Als de status 'gereed voor uitvoering' is, geef ik 'm mee aan de eerstvolgende REST call, totdat de uitvoering klaar is. Ik zorg ook nog dat, afhankelijk van het ingestelde programma, de geschatte verbruikswaarde en duur van uitvoering wordt aangepast. Dus bijv. een 60-graden eco was met 2kW verbruik over 3 uur, of een 30-graden snelle was met 0,7kW over 1 uur.

Acties:

overhyped

ward0 schreef op zaterdag 20 juni 2026 @ 16:50:

Ik zou die 150eur bij EVCC kunnen betalen, maar dat is nu net het doel niet van opensource.

Beetje off-topic, maar Dat is nu precies wel het doel van open source. Je kan het proberen, je kan het snappen, aanpassen, verbeteren, en uiteindelijk betaal je de ontwikkelaars voor hun tijd en effort op de manier die zij aangeven.

vrijdag 17 juli 2026 07:57

Acties:

FSchaafsma

hbvdh schreef op zaterdag 11 juli 2026 @ 14:48:
wat ik zag vanacht rond 00:30 dat alles er goed uitzag de voorspellingen klopte enigsinds met de werkelijkheid. dus mooi.
vanmiddag rond 12:00 zou hij volgens de voorpelling moeten gaan laden van net, maar de batterij deed niets, was voor 20% vol. Wat bleek, dat de grafieken allenmaal opgschovenwaren naar nu, dus de tijden versprongen en hij von dat hij om 20:00 uur moest gaan laden.
Dus alle voorspellinge waren in tijd verschoven. Dat is nu weer hersteld en hij gooit nu de al geweest tijden weg en vult de aankomende 24 uur aan met de laatse bekende waarde (in hetgeval van nordpool prijzen).

Het is inderdaad nogal wat programmeren om de juiste waarden aan emhass door te geven. De controle kan je in dit geval denk ik het beste doen door in de emhass web pagina naar de tabel aan het einde te kijken, welke waarden als input gebruikt zijn voor de berekening, zoals die voor p_pv bijvoorbeeld.

In dit geval is denk ik een probleem dat je de solcast today en tomorrow voorspelling doorgeeft, terwijl emhass de komende 24 uur verwacht. Op deze manier verwacht emhass dus constant dat ie het beste over zo'n 12 uur kan gaan laden. Je moet uit de solcast voorspelling die waarden van de komende 24 uur halen en die doorgeven.

Ik gebruik iets als:

code:

        {% set pv_all = pv_today + pv_tomorrow %} 
        {% set now_ts = as_timestamp(now()) %}
        {% set ns = namespace(pv=[]) %}

        {% for item in pv_all %}
          {% set start_ts = as_timestamp(item.period_start) %}

          {% if start_ts >= now_ts - 1800 %}
            {# 30-minute kWh -> two 15-minute kWh values #}
            {% set v = item.pv_estimate | float(0) * 2000 %}
            {% set ns.pv = ns.pv + [v / 2, v / 2] %}
          {% endif %}
        {% endfor %}

        {% set pv_last = ns.pv[-1] if ns.pv|count > 0 else 0 %}

        {% set pv_forecast =
           (ns.pv + ([pv_last] * 96))[:96]
        %}

vrijdag 17 juli 2026 20:19

Acties:

hbvdh

Dat is inmiddels verholpen en werkt goed.

Ik ben nu via een andere weg aan het proberen de voorspeller MLForcaster beter aan het werk te krijgen. Lukt aardig maar moet gedult hebben.

Ik ben ook bezig te kijken of met extra sensoren ik een extern model over meerdere sensoren een voorspelling kan laten doen en dat dan bij elkaar voeren als voorspelling voor "morgen".

zondag 26 juli 2026 19:15

Acties:

woensdag 12 augustus 2026 09:44

Is er toevallig al iemand die met de HomeAssistant Tibber Grid Rewards integratie en zijn laadpaal integratie het aankomende verbruik van zijn laadpaal probeert te benaderen? Ik heb nu het laden overgelaten aan Tibber in combinatie met Grid Rewards, maar daarmee verliest EMHASS de controle hierover, en zullen de schattingen en acties niet meer helemaal optimaal zijn. Mijn idee is om met de integraties te voorspellen wanneer (en met hoeveel Watt) het laden zal plaatsvinden, en dit dat met de deferable loads & timeslots in EMHASS mee te nemen, onder zeg maar strikte voorwaarden, zodat de uitkomst van EMHASS nagenoeg overeenkomt met de verwachtingen (en werkelijkheid) van Tibber/Grid Rewards... Maar das denk ik nog een aardig klusje, dus als iemand dit al gedaan heeft dan graag delen :-)

Acties:

Probydoby

In deze thread lees ik dat mensen periodiek MPC runs doen. Ik ben nu voor het eerst aan het testen met EMHASS met slechts 1 deferrable (keukenboiler) en wat mij opvalt is dat de MPC de boiler naar de volgende dag plaatst.

De minimale runtime is 1 uur, maar als hij telkens met een nieuwe horizon van 24 uur kan plannen dan heeft hij natuurlijk de mogelijkheid om het oneindig op te schuiven en zo nooit de boiler aan te zetten.

Wat mij dan logisch lijkt is om de MPC een telkens kleinere planningshorizon te geven, beginnend bij 24 uur, en steeds aflopend tot de volgende dag waar hij weer begint met 24 uur vooruit te kijken. Is dit logisch?

De reden dat ik voor MPC kies is omdat ik wil dat hij inspeelt als de solar forecast anders is dan verwacht (of ons verbruik is anders).

woensdag 12 augustus 2026 12:23

Acties:

woensdag 12 augustus 2026 13:14

Topicstarter

@Probydoby

Ja, dat is zeker logisch. Volgens mij moet de horizon wel altijd minstens 5 periodes lang zijn.

Acties:

Probydoby

@RudolfR Alleen moet ik dan ook niet meegeven (en dus bijhouden m.b.v. een helper) dat de boiler al x periode heeft gedraaid die dag, en dat van de operational hours van die deferrable aftrekken voor de volgende MPC optimalisatie run? Anders denkt ie bij elke run, dat hij weer opnieuw 1 uur moet aanstaan, terwijl die die dag misschien al heeft gedraaid.

woensdag 12 augustus 2026 20:29

Acties:

zaterdag 15 augustus 2026 21:47

Probydoby schreef op woensdag 12 augustus 2026 @ 13:14:
@RudolfR Alleen moet ik dan ook niet meegeven (en dus bijhouden m.b.v. een helper) dat de boiler al x periode heeft gedraaid die dag, en dat van de operational hours van die deferrable aftrekken voor de volgende MPC optimalisatie run? Anders denkt ie bij elke run, dat hij weer opnieuw 1 uur moet aanstaan, terwijl die die dag misschien al heeft gedraaid.

Dat moet inderdaad, ik doe dat ook met mijn zwembadpomp, je kunt in de helpers eenvoudig een statistics helper toevoegen, die bv. kijkt naar de state 'On'. Dan telt hij dat mooi op voor elke dag. Ik heb dan ook een paar dit soort sensoren om te bepalen tot hoe hoe laat hij mag wachten, dit geef je mee met de MPC call:

- sensor:
  - unit_of_measurement: h
    device_class: DURATION
    default_entity_id: sensor.hours_until_next_11pm
    name: Hours Until Next 11 pm
    state: "{% if now().hour >= 23 %}  
               {{ (24 - now().hour + 22) + (0 if now().minute > 30 else 1) }}
            {% else %}
               {{ (23 - now().hour) + (0 if now().minute > 30 else 1) }}
            {% endif %}"

Acties:

zaterdag 15 augustus 2026 23:59

Topicstarter

Het is me opgevallen dat de batterij 's ochtends niet (bijna) helemaal ontladen is.
De load voor de MPC klopt niet met de werkelijkheid; die is te hoog, daar wordt capaciteit voor gereserveerd en dat wordt dus niet benut.

Waardes in de bron-sensor 'sensor.power_load_no_var_loads' zijn wel correct, en het staat ook goed in infludb.

In de day-ahead staat het wel goed; ik geef geen p_load_fc mee in de MPC-call.
Iemand een suggestie?

YAML:

{% set dh = state_attr('sensor.dh_p_load_forecast', 'forecasts') | default([], true) %}
{% set mpc = state_attr('sensor.p_load_forecast', 'forecasts') | default([], true) %}
Timestamp                 | Day-Ahead (W) | MPC (W)  | Diff (W)
---------------------------------------------------------------
{%- for item in dh %}
  {%- set ts = item.date %}
  {%- set hour = (ts | as_datetime).hour %}
  {%- if hour >= 0 and hour < 6 %}
    {%- set mpc_match = mpc | selectattr('date', 'eq', ts) | list %}
    {%- set dh_val = item.dh_p_load_forecast | float(0) | round(0) %}
    {%- if mpc_match | length > 0 %}
      {%- set mpc_val = mpc_match[0].p_load_forecast | float(0) | round(0) %}
{{ ts }} | {{ "%-13s" | format(dh_val) }} | {{ "%-8s" | format(mpc_val) }} | {{ dh_val - mpc_val }}
    {%- else %}
{{ ts }} | {{ "%-13s" | format(dh_val) }} | N/A      | N/A
    {%- endif %}
  {%- endif %}
{%- endfor %}

code:

Timestamp                 | Day-Ahead (W) | MPC (W)  | Diff (W)
---------------------------------------------------------------
2026-08-15T03:30:00+02:00 | 187           | N/A      | N/A
2026-08-15T04:00:00+02:00 | 204           | N/A      | N/A
2026-08-15T04:30:00+02:00 | 163           | N/A      | N/A
2026-08-15T05:00:00+02:00 | 222           | N/A      | N/A
2026-08-15T05:30:00+02:00 | 154           | N/A      | N/A
2026-08-16T00:00:00+02:00 | 215           | 2571     | -2356
2026-08-16T00:30:00+02:00 | 216           | 1027     | -811
2026-08-16T01:00:00+02:00 | 211           | 1183     | -972
2026-08-16T01:30:00+02:00 | 169           | 1135     | -966
2026-08-16T02:00:00+02:00 | 189           | 1283     | -1094
2026-08-16T02:30:00+02:00 | 168           | 1233     | -1065
2026-08-16T03:00:00+02:00 | 204           | 1143     | -939

Acties:

zondag 16 augustus 2026 14:37

@RudolfR Ik merkte zelf dat EMHASS zich bij mijn MPC calls veel te veel aantrok van piekverbruik. Dus een piekje in het stroomverbruik doordat de koelkast aansprong, zorgde al voor een heel hoog verbruik voor het hele kwartier. Hierdoor werd het voorspelde verbruik te hoog, en sowieso was de voorspelling erg onrustig.
Ook zit er een mismatch tussen het interval van de P1-meter (die per seconde meet) en mijn stroommeters (die soms per 30/60 seconden meten). Hierdoor viel het verbruik soms te hoog uit, omdat de stroommeters van een apparaat achter liep en het dus niet uit de sensor werd gefilterd.

Ik heb dit zelf opgelost door een filter (in Home Assistant) in te bouwen voor de sensor die een doorlopend gemiddelde van de sensor geeft. Hierdoor worden de kortdurende piekjes eruit gefilterd en de interval-mismatches eruit gemiddeld, en wordt de voorspelling in EMHASS veel rustiger.
Deze filter geeft me het doorlopende gemiddelde van de afgelopen 5 minuten. Voor mij meer dan genoeg voor een voorspelling en werkt prima met mijn EMHASS setup.

YAML:

sensor:
  - platform: filter
    name: "Power load no var loads filter"
    unique_id: d2261339-79ee-4d0f-a225-bb7c3357da87
    entity_id: sensor.power_load_no_var_loads
    filters:
      - filter: time_simple_moving_average
        window_size: "00:05"
        precision: 0

[ Voor 17% gewijzigd door Sicco92 op 16-08-2026 00:02 ]

Acties:

Cookiemonsterrr

savale schreef op zaterdag 11 juli 2026 @ 18:59:
Hier ook emhass aan weten te slingeren met solcast + dynamische tarieven. Accu / zonnepanelen info lijkt ook goed door te komen. Ik gebruik het in een python venv omgeving.

De voorspellingen die eruit komen zijn wel fraai, moet nu gaan uitdenken hoe en wat ik met deferables ga doen. Ik vind het wat onhandig dat je vaste uren moet opgeven per deferable. Dat wisselt een beetje per dag...

Kan ook gewoon de voorspellingen gaan inzetten in mijn eigen automations. Nog niet helemaal duidelijk wat nou handig is.

Met deferable kan je vaste vermogen en tijd instellen in de configuratie, maar hoeft hij niet elke dag te gebruiken, bij mij word de boiler 1x in de 3/4 dagen van 41 naar 48 graden opgestookt. bij mij heb ik sww zo ingesteld dat hij met elke 15 min mpc data inschiet voor de deferable, dus als mijn boiler onder de 41 graden is schiet hij er 3100watt in voor 2 uur, is de boiler boven de 42 graden word die niet mee berekent en is die niet zichtbaar in de grafiek. Dit werkt top omdat hij elke 15 min prijzen inschiet en herberekent en dus de deferable alleen stuurd bij vraag en de goedkoopste tijden, nu dus 13:00/15:00.

zondag 16 augustus 2026 20:39

Acties:

maandag 17 augustus 2026 16:34

RudolfR schreef op zaterdag 15 augustus 2026 @ 21:47:
Het is me opgevallen dat de batterij 's ochtends niet (bijna) helemaal ontladen is.
De load voor de MPC klopt niet met de werkelijkheid; die is te hoog, daar wordt capaciteit voor gereserveerd en dat wordt dus niet benut.

Waardes in de bron-sensor 'sensor.power_load_no_var_loads' zijn wel correct, en het staat ook goed in infludb.

In de day-ahead staat het wel goed; ik geef geen p_load_fc mee in de MPC-call.
Iemand een suggestie?

YAML:

{% set dh = state_attr('sensor.dh_p_load_forecast', 'forecasts') | default([], true) %}
{% set mpc = state_attr('sensor.p_load_forecast', 'forecasts') | default([], true) %}
Timestamp                 | Day-Ahead (W) | MPC (W)  | Diff (W)
---------------------------------------------------------------
{%- for item in dh %}
  {%- set ts = item.date %}
  {%- set hour = (ts | as_datetime).hour %}
  {%- if hour >= 0 and hour < 6 %}
    {%- set mpc_match = mpc | selectattr('date', 'eq', ts) | list %}
    {%- set dh_val = item.dh_p_load_forecast | float(0) | round(0) %}
    {%- if mpc_match | length > 0 %}
      {%- set mpc_val = mpc_match[0].p_load_forecast | float(0) | round(0) %}
{{ ts }} | {{ "%-13s" | format(dh_val) }} | {{ "%-8s" | format(mpc_val) }} | {{ dh_val - mpc_val }}
    {%- else %}
{{ ts }} | {{ "%-13s" | format(dh_val) }} | N/A      | N/A
    {%- endif %}
  {%- endif %}
{%- endfor %}

code:

Timestamp                 | Day-Ahead (W) | MPC (W)  | Diff (W)
---------------------------------------------------------------
2026-08-15T03:30:00+02:00 | 187           | N/A      | N/A
2026-08-15T04:00:00+02:00 | 204           | N/A      | N/A
2026-08-15T04:30:00+02:00 | 163           | N/A      | N/A
2026-08-15T05:00:00+02:00 | 222           | N/A      | N/A
2026-08-15T05:30:00+02:00 | 154           | N/A      | N/A
2026-08-16T00:00:00+02:00 | 215           | 2571     | -2356
2026-08-16T00:30:00+02:00 | 216           | 1027     | -811
2026-08-16T01:00:00+02:00 | 211           | 1183     | -972
2026-08-16T01:30:00+02:00 | 169           | 1135     | -966
2026-08-16T02:00:00+02:00 | 189           | 1283     | -1094
2026-08-16T02:30:00+02:00 | 168           | 1233     | -1065
2026-08-16T03:00:00+02:00 | 204           | 1143     | -939

Weet je heel zeker dat je dezelfde waarden meegeeft met de day-ahead EMHASS call en de MPC EMHASS call? Zijn beide uitkomsten nog wel gelijk als je direct na de dayahead de MPC laat lopen? Bovenstaand zijn wel erg grote verschillen! Welke prediction methode gebruik je (naive, typical, mlforecaster etc)?

Acties:

Whiskey48

Afbeeldingslocatie: https://tweakers.net/i/3_2_8-nP0MDUrToxoDq1Rd19L-M=/x800/filters:strip_icc():strip_exif()/f/image/x8nncwFMIoJhQYi2uaGIlABO.jpg?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/MCjkl9FcilGlzypA_X97FpXJh3E=/800x/filters:strip_icc():strip_exif()/f/image/7DkDT3Uv3v7b9pFd4NtrVU4R.jpg?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/Re9SWjFCgfNll3TCBqaI1A-4CHk=/800x/filters:strip_icc():strip_exif()/f/image/Agyy8EtnFwAYQnmsMV1vYIgk.jpg?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/TxfCYGpd4qUPF37Wy4_DtUNoPlw=/800x/filters:strip_icc():strip_exif()/f/image/BwKOoLzVVfa4MxjvQLsmTqkn.jpg?f=fotoalbum_large

Hoi allemaal!
Ik heb 6x een Zendure Solar Flow 800 plus (eigenlijk 8x). En heb ook een Anker Solix E5000 met 10kWh gekocht die op 7 grote zonnepanelen aan worden aangesloten. (totaal dus 22kWh met 9,5kW laadvermogen).

Nu gaf Anker bij de introductie aan dat hun CT klem geschikt was om het gedrag van een accu van derden te monitoren, dat deze niet elkaar in de weg zitten. Dit hebben ze echter teruggetrokken en heb ik 2 systemen die niet goed samenwerken.

Nu kwam ik op het advies om in HA de batterijen aan te gaan sturen. Ik ga een N100 mini PC hiervoor inrichten om aan te sturen. Ik heb nu een Homey Pro waar er een Slimladen app is, maar die ondersteund deze combinatie (nog) niet.

... even een dubbele check ... maar zou dat kunnen met EMHASS in HA??
Is er iemand die me hiermee op weg zou kunnen helpen of dit niet/wel mogelijk zou zijn?

*edit: ik heb Omnibattery gevonden ... dit zou het moeten kunnen wat lijkt!!

[ Voor 5% gewijzigd door Whiskey48 op 17-08-2026 16:44 ]

zondag 30 augustus 2026 23:43

Acties:

maandag 31 augustus 2026 20:14

Ook ik meld me alvast eens hier. Ik had van de week eens met claude eerst zelf wat analyses uitgevoerd van de diverse energiemarkten (onbalans vs day ahead) en met een snelle backtest bleek dat zelfs een simpel diy ems het stukken beter leek te doen dan wat mijn leverancier voor elkaar krijgt op de onbalansmarkt.

(Voor diegene die het systeem niet kennen: leverancier BalansEnergie levert een 48kwh accu met een 12kw hybride omvormer. Goede hardware voor de prijs, maar het hele contract wat erbij zit is gewoon bagger.) Daarnaast is er in mijn geval nog 20kwp en een aux omvormer op het dak. Hey verbruik pre-installatie was iets van 5MWh/y. Nu zal dat iets meer zijn.

Ipv het wiel zelf uit te vinden (en dus mijn eigen ML ideëen uit te gaan testen) zag ik dat emhass tal van mogelijkheden heeft op dit vlak, zowel aan de load als prediction kant. Zelfs dingen als pv deratings op basis van schaduw, stof, of eventuele curtailment events van pv zichtbaar zouden moeten worden. Ik ben nu al razend enthousiast. Het is een goed moment om eens influxdb of victoriametrics op te tuigen om zo snel mogelijk hoge kwaliteits data op te gaan slaan - hoewel de default lts van HA vast een goede start zijn.

Ohja, de setup wordt ingericht om te handelen op day ahead, evt met zaken als stress factor op 2, omdat een snelle test al liet zien dat dat 30% minder kwh rondpompte, terwijl het slechts 1% minder opbrengst had.

Ik heb even snel wat gelezen, maar het topic is verbazingwekkend rustig voor wat deze software lijkt te kunnen. Tussen de populariteit van home assistant enerzijds en de energiemarkt anderzijds had ik verwacht dat dit topic wel wat sneller zou lopen. Ik ben iig wel benieuwd.

Acties:

maandag 31 augustus 2026 21:16

scoobs schreef op zondag 30 augustus 2026 @ 23:43:
Ook ik meld me alvast eens hier. Ik had van de week eens met claude eerst zelf wat analyses uitgevoerd van de diverse energiemarkten (onbalans vs day ahead) en met een snelle backtest bleek dat zelfs een simpel diy ems het stukken beter leek te doen dan wat mijn leverancier voor elkaar krijgt op de onbalansmarkt.

(Voor diegene die het systeem niet kennen: leverancier BalansEnergie levert een 48kwh accu met een 12kw hybride omvormer. Goede hardware voor de prijs, maar het hele contract wat erbij zit is gewoon bagger.) Daarnaast is er in mijn geval nog 20kwp en een aux omvormer op het dak. Hey verbruik pre-installatie was iets van 5MWh/y. Nu zal dat iets meer zijn.

Ipv het wiel zelf uit te vinden (en dus mijn eigen ML ideëen uit te gaan testen) zag ik dat emhass tal van mogelijkheden heeft op dit vlak, zowel aan de load als prediction kant. Zelfs dingen als pv deratings op basis van schaduw, stof, of eventuele curtailment events van pv zichtbaar zouden moeten worden. Ik ben nu al razend enthousiast. Het is een goed moment om eens influxdb of victoriametrics op te tuigen om zo snel mogelijk hoge kwaliteits data op te gaan slaan - hoewel de default lts van HA vast een goede start zijn.

Ohja, de setup wordt ingericht om te handelen op day ahead, evt met zaken als stress factor op 2, omdat een snelle test al liet zien dat dat 30% minder kwh rondpompte, terwijl het slechts 1% minder opbrengst had.

Ik heb even snel wat gelezen, maar het topic is verbazingwekkend rustig voor wat deze software lijkt te kunnen. Tussen de populariteit van home assistant enerzijds en de energiemarkt anderzijds had ik verwacht dat dit topic wel wat sneller zou lopen. Ik ben iig wel benieuwd.

Leuke post! Inderdaad is het hier vrij rustig :-). Mijn vermoeden is dat de learning curve toch wel vrij steil is om EMHASS te kunnen gebruiken. Je moet sowieso al over een flinke HomeAssistant kennis beschikken, en daarna het EMHASS systeem ook nog doorgronden. Is de laatste tijd wel flink vooruit gegaan door verbeterde documentatie, en de hulp van AI en dergelijke, maar blijft soms nog best lastig doorgronden waarom er iets niet goed werkt. Succes met het opzetten, inderdaad beginnen met alvast goede data in Influx zetten zal later helpen goede voorspellingen te doen.

Acties:

maandag 31 augustus 2026 21:31

Het enige waar ik nog naar moet kijken is hoe jullie dat hebben gedaan met influxdb. Gebruiken jullie hier VictoriaMetrics tegenwoordig? Ik las dat de QL niet compactibel is met de influxdb 1.x vormgeving die emhass vraagt. En idealiter houd ik alles ha gerelateerd binnen ha. Geen externe containers die apart onderhouden moeten worden.

Acties:

maandag 31 augustus 2026 21:43

Ik heb een apart linux-servertje met een docker die influxdb 1.12.2 draait. Op zich weinig onderhoud aan, het draait stabiel. Op deze server draait o.a. ook MQTT, Frigate.

Acties:

woensdag 2 september 2026 14:25

Topicstarter

Mijn influx draait ook in een aparte LXC op dezelfde proxmox host.

De influxdb app voor HA wordt niet meer gesupport.
https://github.com/hassio-addons/addon-influxdb

Mogelijk is er al ergens een fork?

Acties:

woensdag 2 september 2026 15:00

De keuze is uiteindelijk geworden om ML in EMHASS vooralsnog te laten voor wat het is. Mijn plannen voor een recorder zijn breder dan alleen EMHASS, dus ik besefte dat VictoriaMetrics de betere oplossing voor mij is. Voornamelijk omdat ik niet iets wil gaan uitrollen wat effectief al EOL is, en daarnaast schijnt VM wat beter om te gaan met resources. Ik kijk tzt wel even hoe we het gaan aanvangen. Eerst maar eens de datacollection aanzetten. Allicht zet ik er specifiek voor EMHASS wel iets van een connector tussen prop voor de queries, als er zoiets bestaat.

Dat gezegd hebbende, een eerste opzetje in mijn HA draait. Vooralsnog in shadowmode, omdat ik verplicht een EMS moet afnemen van de batterijleverancier. Dat handelt op onbalans en aFRR, maar een aantal zaken op de energiemarkt hebben ervoor gezorgd dat day-ahead gewoon beter presteert dan de andere twee.

Vooralsnog doet het EMS alsof salderen niet meer bestaat, maar ik denk dat ik die designkeuze terugzet: het is een heel kleine change die op 1 jan zo gemaakt is. En het is een stuk eerlijker om zo te vergelijken wat beide doen

Onderstaande is een allereerste opzet die mijn claude code heeft gepushed naar de dev-page van mijn HA als dashboard. Er valt nog een hoop te tunen, maar ik vind het bijster interessant.

Afbeeldingslocatie: https://tweakers.net/i/Y_mCcEqMHvavGH5N9CpNX3sAbvQ=/800x/filters:strip_exif()/f/image/hKxQ4gAUdbfZJLFgCBKpEXl9.png?f=fotoalbum_large

Wat ik denk ik wel ga doen is kijken welke automations voor thermal batteries in EMHASS kunnen, of dat ik dat alsnog bewust houd op mijn "eigen geschreven" MPC met constraints. Die zijn redelijk complex en ik verwacht niet dat EMHASS daarmee overweg kan (Bijvoorbeeld voor verwarmen overschakelen van electrisch naar pelletkachel, wanneer grid offline is voor langere tijd/SoC laag is.)

Acties:

Get!em

Oh die ja!

scoobs schreef op woensdag 2 september 2026 @ 14:25:
De keuze is uiteindelijk geworden om ML in EMHASS vooralsnog te laten voor wat het is. Mijn plannen voor een recorder zijn breder dan alleen EMHASS, dus ik besefte dat VictoriaMetrics de betere oplossing voor mij is. Voornamelijk omdat ik niet iets wil gaan uitrollen wat effectief al EOL is, en daarnaast schijnt VM wat beter om te gaan met resources. Ik kijk tzt wel even hoe we het gaan aanvangen. Eerst maar eens de datacollection aanzetten. Allicht zet ik er specifiek voor EMHASS wel iets van een connector tussen prop voor de queries, als er zoiets bestaat.

Dat gezegd hebbende, een eerste opzetje in mijn HA draait. Vooralsnog in shadowmode, omdat ik verplicht een EMS moet afnemen van de batterijleverancier. Dat handelt op onbalans en aFRR, maar een aantal zaken op de energiemarkt hebben ervoor gezorgd dat day-ahead gewoon beter presteert dan de andere twee.

Vooralsnog doet het EMS alsof salderen niet meer bestaat, maar ik denk dat ik die designkeuze terugzet: het is een heel kleine change die op 1 jan zo gemaakt is. En het is een stuk eerlijker om zo te vergelijken wat beide doen

Onderstaande is een allereerste opzet die mijn claude code heeft gepushed naar de dev-page van mijn HA als dashboard. Er valt nog een hoop te tunen, maar ik vind het bijster interessant.

[Afbeelding]

Wat ik denk ik wel ga doen is kijken welke automations voor thermal batteries in EMHASS kunnen, of dat ik dat alsnog bewust houd op mijn "eigen geschreven" MPC met constraints. Die zijn redelijk complex en ik verwacht niet dat EMHASS daarmee overweg kan (Bijvoorbeeld voor verwarmen overschakelen van electrisch naar pelletkachel, wanneer grid offline is voor langere tijd/SoC laag is.)

VictoriaMetrics voor EMHASS wordt hier besproken InfluxDB data storage no longer usable via the documented add-on — official HA Community Add-on has been archived · Issue #1100 · davidusb-geek/emhass

woensdag 2 september 2026 15:04

Acties:

woensdag 2 september 2026 15:10

Nondeju, kom ik jou ook tegen in dit topic.

Maar bedankt voor de tip. Het ziet ernaar uit dat het allemaal wel geregeld is tegen de tijd dat ik genoeg data heb om de MLforecasters in te gaan zetten.

Acties:

Get!em

Oh die ja!

scoobs schreef op woensdag 2 september 2026 @ 15:04:
Nondeju, kom ik jou ook tegen in dit topic.

Maar bedankt voor de tip. Het ziet ernaar uit dat het allemaal wel geregeld is tegen de tijd dat ik genoeg data heb om de MLforecasters in te gaan zetten.

Ik heb al een hele tijd VictoriaMetrix als losse LXC aan Homeassistant gekoppeld. Ben wel ooit gemigreerd van InFluxDB naar VM, dat was een hel. Koppelen van HomeAssistant aan VictoriaMetrix was trouwens snel te doen omdat het gewoon zelfde protocol is als InfluxDB voor writes.

Let goed op, de default retentie van VictoriaMetrix staat te kort en al je oudere data wordt automagisch weggegooid. Bij Influx is dat precies andersom (oneindig) en ook nog eens onzuinig (zonder optimalisatie), waardoor je disk heel snel vollloopt.

[ Voor 9% gewijzigd door Get!em op 02-09-2026 15:11 ]

woensdag 2 september 2026 15:54

Acties:

maandag 14 september 2026 01:06

Yes, dat had ik al op 100y gezet. Over een paar dagen meet ik de dbsize van VM maar eens meten. Na een paar uur is dat nog niet accuraat. Maar het lijkt op ongeveer 1-2GB/y neer te komen, met een samplerate van 15 sec, en wat metadata over de samples erbij.

Probleem van VM en EMHASS is dat de reads anders zijn helaas.

[ Voor 30% gewijzigd door scoobs op 02-09-2026 15:54 ]

Acties:

maandag 5 oktober 2026 21:20

En toen was VM toegevoegd aan versie 18.3. Perfecte timing

Acties:

maandag 5 oktober 2026 22:22

Topicstarter

Afgelopen weekend de discrepantie tussen de dayahead en de MPC eindelijk kunnen oplossen.

Ik had al een tijdje een _filter-sensor met een 5min moving average, en daarop inmiddels voldoende historie verzameld, maar dat helaas nauwelijks effect.

Veranderen van de modus van naive naar typical gaf problemen, door een missende .pkl?
Uiteindelijk is het gelukt door een nieuw ML-model te trainen, nu matchen de waardes weer voor de nacht.

Acties:

maandag 5 oktober 2026 23:03

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.

Acties:

maandag 12 oktober 2026 23:30

Topicstarter

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.

Acties:

dinsdag 13 oktober 2026 10:43

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!

Acties:

dinsdag 13 oktober 2026 11:02

Aww yiss

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.

Acties:

dinsdag 13 oktober 2026 11:07

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):

Afbeeldingslocatie: https://tweakers.net/i/FY3AT49Ki3aa3K6RODfzZtesHFI=/800x/filters:strip_exif()/f/image/RdSiF2UHIf5maCpLeU2CDLKf.png?f=fotoalbum_large

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 ]

Acties:

dinsdag 13 oktober 2026 11:20

Aww yiss

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.

Afbeeldingslocatie: https://tweakers.net/i/tcmowo187BZMA-hOLqdvoAh-pgw=/800x/filters:strip_exif()/f/image/HNKoYmt1cuh9zVLmOpAmpanH.png?f=fotoalbum_large

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 ]

Acties:

dinsdag 13 oktober 2026 11:34

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 ]

Acties:

dinsdag 13 oktober 2026 11:37

Aww yiss

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.

Acties:

dinsdag 13 oktober 2026 13:52

@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.

Acties:

dinsdag 13 oktober 2026 15:03

Aww yiss

@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.

Afbeeldingslocatie: https://tweakers.net/i/wKgkjDZS1wO3s5o8DE2td5FykCg=/800x/filters:strip_exif()/f/image/EhrRiKrsR9sZgDiV9RHvzMAd.png?f=fotoalbum_large

Acties:

dinsdag 13 oktober 2026 15:25

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?

Afbeeldingslocatie: https://tweakers.net/i/XpB_4DwCiIbmElrXyEuCw5U0cHs=/800x/filters:strip_exif()/f/image/eWmiM7uNSAMPHmaWMADDP1bd.png?f=fotoalbum_large

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

Acties:

dinsdag 13 oktober 2026 15:30

Aww yiss

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.

Acties:

dinsdag 13 oktober 2026 15:42

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.

Acties:

dinsdag 13 oktober 2026 15:57

Aww yiss

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.

Acties:

vrijdag 16 oktober 2026 20:43

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!

Acties:

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.

vrijdag 16 oktober 2026 21:22

Acties:

vrijdag 16 oktober 2026 22:10

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 :-)

Acties:

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.

maandag 19 oktober 2026 21:11

Acties:

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

UNOX: The worst operating system

maandag 19 oktober 2026 21:29

Acties:

maandag 19 oktober 2026 22:05

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.

Acties: