EMHASS - Energy Management for Home Assistant

[diamanten]

RudolfR schreef op vrijdag 4 juli 2025 @ 10:23:
@diamanten

Ziet er leuk uit met die symbolen, maar ik zou liever een simpele tekst-state maken en de vormgeving aan de UI overlaten.

ik vind "net_" verwarrend in het engels, omdat het lijkt op 'netto', daarom kies ik voor 'grid'

YAML:

        {% elif soc <= min_soc and batt > 0 %}
          "🛑 Ontladen geblokkeerd: SoC te laag."

        {% elif soc >= max_soc and batt < 0 %}
          "🛑 Laden gestopt: batterij is vol."

Deze begrijp ik niet goed, emhass zal toch geen batt > 0 berekenen in periods waar de soc lager is dan min_soc?
En idem voor het laden?

Ook berekent EMHASS p_grid waar je uit af kunt leiden of er sprake is van terugleveren/afnemen.
Jouw template lijkt een soort mix tussen de prognose van EMHASS en de actuele werkelijkheid.
Volgens mij kun je dat beter los blijven zien.

Ook zie ik twee verschillende 'Geen batterijactie" met twee verschillende iconen, waarvan de tweede een weegschaal is, die ik zou verwachten bij de 'balans/net zero' modus.

Dank voor je feedback! Ik ga eea verder aanpassen.
Nb. ik controleer op min soc en max soc omdat ik mijn accu in deze testfase ook nog op een andere manier aanstuur.

[Xoliul]

Ik ben al even bezig met manueel EMS-achtige automatisaties te doen via vanilla HA (gewone automations).
Dingen zoals toestellen aan en uitschakelen op basis van verbruik, EV laten load balancen en solar excess verbruiken, etc..
Het lukt wel maar voelt wat onoverzichtelijk, 'tis erg moeilijk om schalende prioriteiten te doen, alles zit verdeeld over template sensors en automations, veel heen en weer springen, moeilijk overzicht..

Ik denk dat EMHASS wel de oplossing is, maar:
Ik draai op Synology in Docker, dus moet al weer een extra docker container opstarten. Ben sowieso geen fan van het idee dat EMHASS apart draait van HA, waarom is dit zo, heeft het echt voordelen, vinden jullie dat goed werkbaar? Het lijkt nogal een gedoe op het eerste zicht...

Ook heb ik dan nog eens bijzonder moeilijk toegang tot mijn maandelijkse stroomprijzen via API, moet al web-scraping gaan doen, en het lijkt alsof de prijzen pas de op het einde van de maand bekend zijn (neemt maandelijks gemiddeld EPEXDAM..) Maakt dit uit ?

Heb ook geen thuisbatterij, als dat uitmaakt.

[RudolfR]

@Xoliul

Batterij is geen vereiste. Planbare loads dan des te meer, EV, boiler.

Hoe bedoel je "apart", als add-on? Of bij jou op aparte computers? Waarom voelt dat verkeerd?

Een EMS lijkt me een wezenlijk andere functie dan een domoticasysteem. Kan prima gescheiden via een API?

[Xoliul]

RudolfR schreef op vrijdag 1 augustus 2025 @ 13:34:
@Xoliul

Batterij is geen vereiste. Planbare loads dan des te meer, EV, boiler.

Hoe bedoel je "apart", als add-on? Of bij jou op aparte computers? Waarom voelt dat verkeerd?

Een EMS lijkt me een wezenlijk andere functie dan een domoticasysteem. Kan prima gescheiden via een API?

Apart als in aparte container om te updaten, in te stellen, dan ook nog ens zorgen dat het goed communiceert en synchroniseert (gaat naar mijn ervaring toch altijd wat mis). Vaak gebeurt er dan een update en werkt het plots niet meer samen. Ik heb zo al m'n Z-wave spul weg gedaan omdat ik het zo beu was dat zwave2mqtt stopte met werken bij zowat iedere update van Home Assistant die ik deed, werd er knettergek van.
Als het allemaal in Home Assistant zit, dan werkt het gewoon meteen bij een update.

[Torch1969]

Xoliul schreef op zaterdag 2 augustus 2025 @ 10:15:
[...]


Apart als in aparte container om te updaten, in te stellen, dan ook nog ens zorgen dat het goed communiceert en synchroniseert (gaat naar mijn ervaring toch altijd wat mis). Vaak gebeurt er dan een update en werkt het plots niet meer samen. Ik heb zo al m'n Z-wave spul weg gedaan omdat ik het zo beu was dat zwave2mqtt stopte met werken bij zowat iedere update van Home Assistant die ik deed, werd er knettergek van.
Als het allemaal in Home Assistant zit, dan werkt het gewoon meteen bij een update.

Tja, dan is de keuze voor het draaien van home assistant in docker (op Synology) voor jou misschien niet de juiste? Dan mis je de “add-on” functionaliteit (wat in feite ook docker containers zijn, maar dan meer onder stuur van home assistant zelf) en het gemak daarvan.

[RudolfR]

Inmiddels een andere aanpak gekozen met EMHASS.

Voorheen probeerde om heel vaak de MPC te draaien om de actuele waarden van PV/P1 te gebruiken. Maar dat is tijdrovend en je loopt altijd achter de feiten aan.

Draai ik de MPC nu iedere 15 minuten en ik regel op basis van de P1 meter en de 'strategie' uit EMHASS, die ik bepaal mbv de berekende waardes, voor grid import en batterij.

Daardoor kan emhass zero_import/geen batterij berekend hebben, maar kan ik bij load toch de batterij bijschakelen.
Bijv. Als ik de was opzet op een zonnige dag. Gaat best goed.

[diamanten]

RudolfR schreef op dinsdag 5 augustus 2025 @ 20:03:
Inmiddels een andere aanpak gekozen met EMHASS.

Voorheen probeerde om heel vaak de MPC te draaien om de actuele waarden van PV/P1 te gebruiken. Maar dat is tijdrovend en je loopt altijd achter de feiten aan.

Draai ik de MPC nu iedere 15 minuten en ik regel op basis van de P1 meter en de 'strategie' uit EMHASS, die ik bepaal mbv de berekende waardes, voor grid import en batterij.

Daardoor kan emhass zero_import/geen batterij berekend hebben, maar kan ik bij load toch de batterij bijschakelen.
Bijv. Als ik de was opzet op een zonnige dag. Gaat best goed.

Interessant, ik ben ook nog zoekende naar de meest efficiente aanpak. Ik draai nu de MPC elke 3 minuten.
Betekent jouw aanpak: EMHASS voor de strategie en je P1-meter voor de operationele uitvoering? Kan je nog wat meer voorbeelden geven van een 'override'? Bijv. ga je ook opladen ondanks dat EMHASS dit niet adviseert? En zo ja, op basis van welke criteria?

[RudolfR]

@diamanten

Ja, dat is het inderdaad.

Ik heb net als jij een template sensor:

YAML:

- sensor:
    - name: "EMHASS battery mode"
      unique_id: 2022603f-cb5a-4693-a70d-f0eef4b6883e
      icon: mdi:battery-heart-outline
      state: >
        {# Waarden ophalen #}
        {% set p_pv = states('sensor.p_pv')| float(0) %}
        {% set p_batt = states('sensor.p_batt_forecast') | float(0) %}
        {% set p_load = states('sensor.p_load_forecast') | float(0) %}
        {% set p_grid = states('sensor.p_grid_forecast') | float(0) %}
        {% set soc = states('sensor.athom_smart_plug_v3_50f110_jbd_bms_state_of_charge') | float(0) %}
        {# Bepaal modus #}
        {% set mode = 'idle' %}
        {% if p_batt < 0 %}
          {% set mode = 'charge' %}
        {% else %}
          {% if soc < 3 %}
            {% set mode = 'blocked' %}
          {% elif p_grid < 20 %}
            {% set mode = 'net_zero' %}
          {% else %}
            {% set mode = 'discharge' %}
          {% endif %}
        {% endif %}
        {{ mode }}

In m'n automation heb ik een aantal variabelen, op basis van de modus.

YAML:

  p_batt_forecast: >
    {{ states('sensor.p_batt_forecast') | float(0) }}
  p_batt_limit: >
    {{ iif(states('sensor.emhass_battery_mode') == 'discharge', p_batt_forecast, 650) }}
  p_batt_limit2: >
    {{ iif(states('sensor.emhass_battery_mode') == 'blocked', 0, p_batt_limit) }}

Zodat ik bij 'net_zero' gewoon naar nul-op-de-meter kan sturen op basis van de P1-meter.
Zonder daarbij de waarde van EMHASS te gebruiken dus.

Opladen ook, daar gaat het overschot ook de batterij in, tenzij de SoC hoog is of EMHASS ook laden voorstelt.

YAML:

  p_surplus: >
    {% set available_for_charging = -p_to_charger - p_to_grid + p_from_grid + p_from_battery %}
    {{ iif(available_for_charging > 0, 0, available_for_charging) }}
  p_batt: >
    {% set p_batt_fc = states('sensor.p_batt_forecast') | float(0) %}
    {% set battery_mode = states('sensor.emhass_battery_mode') %}
    {% set soc = states('sensor.athom_smart_plug_v3_50f110_jbd_bms_state_of_charge') | float(0) %}
    {% if battery_mode == 'charge' or soc > 95 %}
      {{ [p_surplus, p_batt_fc] | max }}
    {% endif %}

Dat zal vast minder goed passen bij een dynamisch tarief, maar dat heb ik niet, dus ik wil alleen laden met PV.

[diamanten]

RudolfR schreef op woensdag 6 augustus 2025 @ 10:41:
@diamanten

Ja, dat is het inderdaad.

Ik heb net als jij een template sensor:

YAML:

- sensor:
    - name: "EMHASS battery mode"
      unique_id: 2022603f-cb5a-4693-a70d-f0eef4b6883e
      icon: mdi:battery-heart-outline
      state: >
        {# Waarden ophalen #}
        {% set p_pv = states('sensor.p_pv')| float(0) %}
        {% set p_batt = states('sensor.p_batt_forecast') | float(0) %}
        {% set p_load = states('sensor.p_load_forecast') | float(0) %}
        {% set p_grid = states('sensor.p_grid_forecast') | float(0) %}
        {% set soc = states('sensor.athom_smart_plug_v3_50f110_jbd_bms_state_of_charge') | float(0) %}
        {# Bepaal modus #}
        {% set mode = 'idle' %}
        {% if p_batt < 0 %}
          {% set mode = 'charge' %}
        {% else %}
          {% if soc < 3 %}
            {% set mode = 'blocked' %}
          {% elif p_grid < 20 %}
            {% set mode = 'net_zero' %}
          {% else %}
            {% set mode = 'discharge' %}
          {% endif %}
        {% endif %}
        {{ mode }}

In m'n automation heb ik een aantal variabelen, op basis van de modus.

YAML:

  p_batt_forecast: >
    {{ states('sensor.p_batt_forecast') | float(0) }}
  p_batt_limit: >
    {{ iif(states('sensor.emhass_battery_mode') == 'discharge', p_batt_forecast, 650) }}
  p_batt_limit2: >
    {{ iif(states('sensor.emhass_battery_mode') == 'blocked', 0, p_batt_limit) }}

Zodat ik bij 'net_zero' gewoon naar nul-op-de-meter kan sturen op basis van de P1-meter.
Zonder daarbij de waarde van EMHASS te gebruiken dus.

Opladen ook, daar gaat het overschot ook de batterij in, tenzij de SoC hoog is of EMHASS ook laden voorstelt.

YAML:

  p_surplus: >
    {% set available_for_charging = -p_to_charger - p_to_grid + p_from_grid + p_from_battery %}
    {{ iif(available_for_charging > 0, 0, available_for_charging) }}
  p_batt: >
    {% set p_batt_fc = states('sensor.p_batt_forecast') | float(0) %}
    {% set battery_mode = states('sensor.emhass_battery_mode') %}
    {% set soc = states('sensor.athom_smart_plug_v3_50f110_jbd_bms_state_of_charge') | float(0) %}
    {% if battery_mode == 'charge' or soc > 95 %}
      {{ [p_surplus, p_batt_fc] | max }}
    {% endif %}

Dat zal vast minder goed passen bij een dynamisch tarief, maar dat heb ik niet, dus ik wil alleen laden met PV.

Grappig, we zitten grotendeels op dezelfde lijn (althans volgens Chatgtp):
Ik heb de modus template toegevoegd en ben nu aan het proefdraaien (zowel met vaste als dynamische tarieven).

[dennisdew16]

Is er iemand de mij een beetje op weg kan helpen?
Volgens mij heb ik alle parameters ingevuld die nodig zijn voor de berekening maar er klopt geen hout van de waarde die ik eruit krijg. PV opwek wordt al helemaal niet gezien, terwijl ik wel alle solcast waarden heb ingevuld. Ik weet dat de leercurve stijl is maar omdat ik ook maar 10 API calls per dag mag doen is het testen tot nu toe zonder positief resultaat gebleven. Ook met de info uit diverse fora raak ik niet wijzer.

Zie onderstaand mijn huidige configuratie. Daarnaast in HA config nog de solcast parameters ingevuld.

code:

{
  "adjusted_pv_regression_model": "LassoRegression",
  "adjusted_pv_solar_elevation_threshold": 10,
  "battery_charge_efficiency": 0.92,
  "battery_charge_power_max": 1200,
  "battery_discharge_efficiency": 0.92,
  "battery_discharge_power_max": 1200,
  "battery_dynamic_max": 0.9,
  "battery_dynamic_min": -0.9,
  "battery_maximum_state_of_charge": 0.99,
  "battery_minimum_state_of_charge": 0.1,
  "battery_nominal_energy_capacity": 5760,
  "battery_target_state_of_charge": 0.4,
  "compute_curtailment": false,
  "continual_publish": false,
  "costfun": "profit",
  "delta_forecast_daily": 1,
  "end_timesteps_of_each_deferrable_load": [
    0,
    0
  ],
  "historic_days_to_retrieve": 7,
  "inverter_is_hybrid": false,
  "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"
      }
    ]
  },
  "load_peak_hours_cost": 0.1907,
  "logging_level": "INFO",
  "lp_solver": "default",
  "lp_solver_path": "empty",
  "lp_solver_timeout": 45,
  "maximum_power_from_grid": 9000,
  "maximum_power_to_grid": 5500,
  "method_ts_round": "nearest",
  "minimum_power_of_deferrable_loads": [
    200,
    200
  ],
  "modules_per_string": [
    16
  ],
  "nominal_power_of_deferrable_loads": [
    2000,
    750
  ],
  "num_threads": 0,
  "number_of_deferrable_loads": 2,
  "open_meteo_cache_max_age": 30,
  "operating_hours_of_each_deferrable_load": [
    4,
    1
  ],
  "optimization_time_step": 30,
  "photovoltaic_production_sell_price": 0.1419,
  "production_price_forecast_method": "constant",
  "pv_inverter_model": [
    "Fronius_International_GmbH__Fronius_Primo_5_0_1_208_240__240V_"
  ],
  "pv_module_model": [
    "CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M"
  ],
  "sensor_linear_interp": [
    "sensor.actueel_verbruik_w"
  ],
  "sensor_power_load_no_var_loads": "sensor.actueel_verbruik_w",
  "sensor_power_photovoltaics": "sensor.total_pv_generation",
  "sensor_power_photovoltaics_forecast": "sensor.thuis",
  "sensor_replace_zero": [
    "sensor.pv_power",
    "sensor.thuis"
  ],
  "set_battery_dynamic": false,
  "set_deferrable_load_single_constant": [
    false,
    false
  ],
  "set_deferrable_startup_penalty": [
    0,
    0
  ],
  "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": false,
  "set_zero_min": true,
  "start_timesteps_of_each_deferrable_load": [
    0,
    0
  ],
  "strings_per_inverter": [
    1
  ],
  "surface_azimuth": [
    205
  ],
  "surface_tilt": [
    30
  ],
  "treat_deferrable_load_as_semi_cont": [
    true,
    true
  ],
  "weather_forecast_method": "solcast",
  "weight_battery_charge": 0,
  "weight_battery_discharge": 0
}

[MarcoPolet]

Misschien een paar tips:
- onderaan de webpagina van EMHASS zie je het optimization result. Als dat anders is dan Optimal klopt er niets van. Weet niet wat er bij jou als uitkomst kwam (ik vermoed unfeasible oid), maar dan betekent dat meestal dat je onjuiste of tegenstrijdige parameters hebt doorgegeven.
- voor wat betreft solcast: ik gebruik daarvoor de HACS integratie (BJReplay / ha-solcast-solar), die werkt wel prettig, want dan kun je zelf aangeven hoe vaak hij de API mag gebruiken, dat verdeelt hij dan over de dag en tussenin geeft hij de vorige waarden terug, dan heb je dus geen last van de 10 calls max.
- waar ik erg veel baat bij gehad heb ik in HA de Developer Tools | Template pagina, daar kun je veel van de parameters die je runtime doorgeeft aan EMHASS evalueren of ze juist zijn
- de logs van EMHASS geven ook aardig wat info, hoewel ook wel eens een hele brei, waar moeilijk doorheen te lezen is. Vooral op zoek gaan naar de eerte fout die optrad
- je zou het leven nog iets gemakkelijker kunnen maken door bv. eerst zonder batterij en bv, naar 1 deferrable load te werken dan maak je het probleem mogelijk wat kleiner / gemakkelijker te doorgronden
- en verder: hou vol, als het eenmaal draait dan is 't erg mooi en stabiel

[dennisdew16]

MarcoPolet schreef op zaterdag 16 augustus 2025 @ 15:28:
Misschien een paar tips:
- onderaan de webpagina van EMHASS zie je het optimization result. Als dat anders is dan Optimal klopt er niets van. Weet niet wat er bij jou als uitkomst kwam (ik vermoed unfeasible oid), maar dan betekent dat meestal dat je onjuiste of tegenstrijdige parameters hebt doorgegeven.
- voor wat betreft solcast: ik gebruik daarvoor de HACS integratie (BJReplay / ha-solcast-solar), die werkt wel prettig, want dan kun je zelf aangeven hoe vaak hij de API mag gebruiken, dat verdeelt hij dan over de dag en tussenin geeft hij de vorige waarden terug, dan heb je dus geen last van de 10 calls max.
- waar ik erg veel baat bij gehad heb ik in HA de Developer Tools | Template pagina, daar kun je veel van de parameters die je runtime doorgeeft aan EMHASS evalueren of ze juist zijn
- de logs van EMHASS geven ook aardig wat info, hoewel ook wel eens een hele brei, waar moeilijk doorheen te lezen is. Vooral op zoek gaan naar de eerte fout die optrad
- je zou het leven nog iets gemakkelijker kunnen maken door bv. eerst zonder batterij en bv, naar 1 deferrable load te werken dan maak je het probleem mogelijk wat kleiner / gemakkelijker te doorgronden
- en verder: hou vol, als het eenmaal draait dan is 't erg mooi en stabiel

Bedankt voor de tips, ga ik in ieder geval naar kijken:
- Resultaat is Optimal dus dat gaat dan goed denk ik?
- Solcast gebruik ik ook op die manier. Dat werkt wel goed alleen nog problemen om het werkend te krijgen in EMHASS
- Ik snap niet precies wat je bedoelt met de runtime parameters maar ben wel bekend met de dev tools. Daar valt mogelijk dus nog wat te winnen
- Logs gaven voornamelijk solcast aan, al lijkt dit nu goed te gaan. Nu een probleem met var_no_loads sensor. Misschien moet ik even wachten totdat deze twee dagen aan historische data heeft. Mocht het dan nog niet lukken kom ik er uiteraard op terug.
- Beginnen met de basis had misschien wel handig geweest inderdaad. Mocht het niet lukken ga ik dit overwegen, want ik ga door tot het werkt

[RudolfR]

Zonder twee dagen historie in je var_no_loads kom je niet ver, nee.
Even geduld dus.

[dennisdew16]

Ik heb nu de PV schakelaar uit staan en dan wordt de data in ieder geval wel geladen. Echter ondanks dat ik "weather forecast method" op solcast heb staan wordt er geen data geladen. Ik begreep dat je zonne data ook uit solcast kan halen maar mogelijk doe ik dan iets verkeerd. Zie onderstaand voor huidige situatie, waarbij P_PV dus niks doet.

[MarcoPolet]

Hoe roep je EMHASS aan? Gebruik je day-ahead (eenmalig per dag) en dan bv. elke 10 minuten MPC?
Als je solcast vanuit EMHASS zelf wilt gebruiken dan moet je ook het solcast rooftop-id en de api-key meesturen. Als je nog steeds de HACS solcast integratie gebruikt, dan zou je eigenlijk csv moeten opgeven (althans, dat doe ik), en dan geef je in de aanroep van bv. de day-ahead call de pv-forecast mee:
zoiets:
"pv_power_forecast\": {{state_attr('sensor.solcast_48hrs_forecast_15minutes_interval_current_quarter', 'solar_power') }}

deze zal bij jou niet direct werken, omdat ik zelf vanuit de 30 minuten solcast een list gemaakt heb voor 15 minuten interval (als voorbereiding op de kwartier-prijzen vanaf oktober ergens).

[dennisdew16]

Wat een termen allemaal haha. Ik klik nu gewoon een keer per dag op day ahead. Daarnaast moet je dus frequent de MPC aanroepen? En ik heb de API en rooftop-id al ingevuld maar dat werkt helaas niet. Ik zou wel jou methode eens kunnen proberen om het werkend te krijgen.

[MarcoPolet]

Komt vast goed uiteindelijk :-) Eerst alleen daily is prima om de boel op te starten en te snappen, maar door die mpc call elke 10 minuten werkt hij e.e.a. steeds bij, o.a. ook de deferrable loads, maar ook een eventueel hierziene zonneverwachting. Je moet ook nog de publish regelmatig doen, bv. na elke mpc, deze zorgt er dan weer voor dat de resultaten terugkomen. Maar wees gerust, als je de daily eenmaal hebt draaien, zijn die anderen nagenoeg gelijk (de mpc) of een stuk gemakkelijker (de publish).

Dat klikken is wel handig om e.e.a. te proberen, maar rechstreeks vanuit HA is gemakkelijker voor de latere termijn. Kan op meerdere manieren, ik definieer een curl commando in configuration.yaml (als een shell_command). Deze worden dan via automations aangeroepen.

Wat eerder al werd genoemd, het is een flinke leercurve

[RudolfR]

@dennisdew16
Dit idee:

code:

curl -i -H "Content-Type:application/json" -X POST -d '{"solcast_rooftop_id":"<your_system_id>","solcast_api_key":"<your_secret_api_key>"}' http://localhost:5000/action/dayahead-optim

Zie ook de documentatie:
https://emhass.readthedoc...st/forecasts.html#solcast

[Sicco92]

Tipje: gebruik rest_command in plaats van shell_command, vooral als je nog van alles aan het inrichten bent. Als je een shell_command wijzigt, dan moet je eerst Home Assistant herstarten voordat het commando daadwerkelijk gewijzigd wordt. Bij een rest_command kan je via de Developer Tools de RESTful Command reloaden, dan heb je gelijk al een nieuwe/gewijzigde service zonder te herstarten. https://www.home-assistant.io/integrations/rest_command/

Als voorbeeld, hier zijn een paar van mijn rest_commands:

YAML:

rest_command:
  emhass_dayahead_optim:
    url: http://localhost:5000/action/dayahead-optim
    method: post
    timeout: 300
    content_type: 'application/json'
    payload: >
      {
        "load_cost_forecast": {{ state_attr('sensor.current_price_for_electricity_usage', 'upcoming_24_hours_emhass_1h') }},
        "prod_price_forecast": {{ state_attr('sensor.current_price_for_electricity_return', 'upcoming_24_hours_emhass_1h') }},
        "def_total_hours": {{ states('sensor.deferrable_loads') }}
      }
  emhass_npc_optim_with_pv_15m:
    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) %}
      {
        "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.6
      }

Ik vind het ook veel leesbaarder

[MarcoPolet]

Ha goeie tip, dat wist ik ook niet, heb hierom inderdaad zeker 100 keer herstart....

[diamanten]

Nu de ML mogelijkheden van Emhass aan het testen.
Ipv de pv-forecast van open-meteo of solcast te gebruiken heb ik de sensor met mijn zonnepanelen vermogen in het model geladen en predict gedaan. De correlatie is aardig goed en ik draai er nu de MPC mee.
Hebben jullie ook ervaring hiermee?

[RudolfR]

@diamanten

Ik denk dat je dataset te beperkt is voor goede resultaten; zeker nu het weer verandert.
Met PV kreeg ik ook wel zoiets, maar met de load niet, ook niet over 30 dagen.

[Sicco92]

Die power load sensor was bij mij ook nog wel een dingetje met EMHASS. Ik heb er soms kleine piekjes in zitten van bijvoorbeeld de compressor van de koelkast of de keukenboiler. EMHASS extrapoleert die piekjes dan naar het hele kwartier, waardoor ik vaak een erg onrustige voorspelling kreeg. Nu maakt die load-voorspelling voor mij nog weinig uit, maar vanaf 2027 wordt die belangrijker omdat er dan vaker op NOM gedraaid moet gaan worden.

Dit heb ik opgelost door in Home Assistant een filter-sensor aan te maken die een moving_average heeft van 5 minuten. Die sensor gebruik ik nu in EMHASS, en dat geeft een veel rustiger én accurater beeld van mijn base-load.

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

[dennisdew16]

RudolfR schreef op donderdag 21 augustus 2025 @ 20:18:
@dennisdew16
Dit idee:

code:

curl -i -H "Content-Type:application/json" -X POST -d '{"solcast_rooftop_id":"<your_system_id>","solcast_api_key":"<your_secret_api_key>"}' http://localhost:5000/action/dayahead-optim

Zie ook de documentatie:
https://emhass.readthedoc...st/forecasts.html#solcast

Ik heb dit geprobeerd maar dan krijg ik hetzelfde resultaat als dat ik gewoon de API key en rooftop ID invul in de configuratie. Nog steeds 0 PV_load....

[MarcoPolet]

Komt er in het EMHASS log nog iets interessants voorbij? Dat is vaak de eerste plek om dit soort dingen te onderzoeken. In de EMHASS config dan de logging level nog even op DEBUG zetten.

[dennisdew16]

MarcoPolet schreef op zondag 24 augustus 2025 @ 09:39:
Komt er in het EMHASS log nog iets interessants voorbij? Dat is vaak de eerste plek om dit soort dingen te onderzoeken. In de EMHASS config dan de logging level nog even op DEBUG zetten.

Goeie tip, heb het nu op debug gezet. Echter niks geks.
En misschien gebruik ik het verkeerd, maar als ik al zoiets simpels als onderstaand uitvoer:

code:

curl -i -H "Content-Type:application/json" -X POST -d '{"solcast_rooftop_id":"xxx","solcast_api_key":"xxx"}' http://192.168.1.xxx:5000/action/dayahead-optim

Krijg ik geen foutmeldingen maar ook geen PV opwek te zien. En met de documentatie kom ik er ook niet echt uit. Ik heb echt het idee dat ik dingen over het hoofd zie of het dus niet goed gebruik maar ik kom er tot op heden weer niet uit...

[RudolfR]

@dennisdew16

Dat komt waarschijnlijk omdat je de andere parameters voor de dayahead er nu niet bij hebt?
Ik doe dat zo, maar ik geef pv_power_forecast zelf mee, jij zou dit vervangen door de settings voor solcast.

Via de web-ui kun je dit er in plakken (type 'Box') bij Input Runtime Parameters voordat je de dayahead uitvoert (via de knop in de UI)

code:

      {"entity_save": true, "publish_prefix": "",
      "battery_maximum_state_of_charge": 1, "battery_minimum_state_of_charge":
      0.02, "battery_target_state_of_charge": 0.24,
      "battery_discharge_power_max": 600, "battery_charge_power_max": 800.0,
      "weather_forecast_cache": false, "pv_power_forecast": [0, 0, 0, 0, 0, 14,
      265, 553, 815, 1061, 1265, 1486, 1632, 1801, 1933, 2014, 2059, 2080, 2076,
      2058, 2006, 1925, 1807, 1666, 1493, 1296, 1093, 878, 631, 490, 406, 277,
      117, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], "load_cost_forecast":
      [0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.25112,
      0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112] }

[dennisdew16]

@RudolfR Als ik de LIST gebruik en ik doe bijvoorbeeld jou PV data invullen dan krijg ik inderdaad wel de PV_Load te zien. Mijn gedachte was echter dat emhass dit zelf zou ophalen...
Maar goed, is de oplossing dan iets van een template sensor maken die elke dag die waarde ophaalt, of hoe doe jij het in de specifieke geval om de pv data te laden?

Dan nog een vraag over de input parameters: welke data moet hier perse in staan? Of zijn dit allemaal optionele parameters om de voorspelling nauwkeuriger te maken?

[RudolfR]

@dennisdew16
EMHASS kan dat ook doen, maar dan moet je in de gegevens van solcast meenemen als runtime parameters. (en pv_power_forecast weglaten)

Ik heb de solcast integratie in Home Assistant en die haalt de waardes op. Daarvan maak ik een array voor EMHASS, om mee te geven aan de day-ahead en MPC.


Met alleen solcast krijg ik een infeasible resultaat, maar dat kan ook de combinatie zijn van mijn standaard-instellingen. Ga dat niet te vaak doen, want dat kost me vast api-hits.

Hier is alleen een pv_power_forecast voldoende voor een goed resultaat:

{"pv_power_forecast":[0,0,0,0,0,14,265,553,815,1061,1265,1486,1632,1801,1933,2014,2059,2080,2076,2058,2006,1925,1807,1666,1493,1296,1093,878,631,490,406,277,117,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}, aangenomen dat die dan van solcast komt zou alleen de api-info voor solcast voldoende moeten zijn. Misschien zit je al aan je limiet en komt er geen data terug om mee te rekenen?

[ Voor 31% gewijzigd door RudolfR op 25-08-2025 16:00 ]

[dennisdew16]

@RudolfR Ik heb inmiddels een template sensor die mij ook die waarde geeft. Hoe integreer ik dit nu in de configuratie zodat ie deze data uitleest? Gaat bij mij om sensor.pv_power_forecast.

edit: heb nu onderstaand en dat lijkt enigzins te werken.

code:

rest_command:
  emhass_dayahead_optim:
    url: http://localhost:5000/action/dayahead-optim
    method: post
    timeout: 300
    content_type: 'application/json'
    payload: >
      {
        "pv_power_forecast": {{ states('sensor.pv_power_forecast') }}
      }

Maar betekend dit dus eigenlijk dat alles via rest commands moet lopen? Want dan snap ik waarom ie bij mij niks deed als ik alleen de standaard configuratie gebruik.

[ Voor 57% gewijzigd door dennisdew16 op 25-08-2025 17:15 ]

[RudolfR]

Alles verloopt via rest calls inderdaad.
Ook als je straks een berekening hebt zul je met regelmaat een publish moeten aanroepen zodat HA de laatste waardes doorkrijgt (passend bij de huidige periode)

Tegenwoordig kun je alles wel meegeven als runtime parameter; eerder was dat niet zo en moest een deel worden ingesteld in de config van de addon.

Je kunt het nog steeds mixen. Settings die je niet meegeeft komen dan uit je standaard config. In de rest-call kunt je er er dan voor kiezen om een andere waarde mee te geven en de config te overrulen.

[diamanten]

Sicco92 schreef op vrijdag 22 augustus 2025 @ 11:16:
Die power load sensor was bij mij ook nog wel een dingetje met EMHASS. Ik heb er soms kleine piekjes in zitten van bijvoorbeeld de compressor van de koelkast of de keukenboiler. EMHASS extrapoleert die piekjes dan naar het hele kwartier, waardoor ik vaak een erg onrustige voorspelling kreeg. Nu maakt die load-voorspelling voor mij nog weinig uit, maar vanaf 2027 wordt die belangrijker omdat er dan vaker op NOM gedraaid moet gaan worden.

Dit heb ik opgelost door in Home Assistant een filter-sensor aan te maken die een moving_average heeft van 5 minuten. Die sensor gebruik ik nu in EMHASS, en dat geeft een veel rustiger én accurater beeld van mijn base-load.

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

Ik zat dit ook eens te bekijken:

Sensor power loads with no variable loads:
The name of the household power consumption sensor in Watts from Home Assistant. The deferrable loads that we will want to include in the optimization problem should be subtracted from this sensor in HASS.

Vraag: een dergelijke sensor kan toch eigenlijk nooit '0' zijn vanwege het altijd aanwezige sluipverbruik?

Nu is mijn sensor_power_load_no_var_loads namelijk vaak iets boven de '0' W is (ook met gebruik van bovenstaand filter), waarschijnlijk omdat mijn zonnepanelen (Enphase) slechts om de 60 seconden een update geven en dus niet in sync zijn met mijn P1-meter (om de 10 seconden).
Ik heb 's nachts een sluipverbruik van rond de 300W, dus eigenlijk is dat ook de minimale waarde van sensor_power_load_no_var_loads of zie ik dat verkeerd?

[ Voor 11% gewijzigd door diamanten op 01-09-2025 18:25 ]

[cnoobie]

Dag allemaal, wow wat een kennis en ervaring zit hier. Mijn vraag is misschien een beetje offtopic. Kennen (of zijn) jullie mensen/bedrijven die dit soort toepassingen (home assistant als home energy management system met zonnepanelen, warmtepomp, laadpaal en toekomstige thuisbatterij) voor anderen in kunnen richten? Tegen betaling natuurlijk? Deze leercurve is mij te steil, maar ik wil niet afhankelijk worden van techbedrijven die over 5 jaar misschien niet meer bestaan of hun app ineens uitschakelen.

[diamanten]

cnoobie schreef op vrijdag 5 september 2025 @ 17:17:
Dag allemaal, wow wat een kennis en ervaring zit hier. Mijn vraag is misschien een beetje offtopic. Kennen (of zijn) jullie mensen/bedrijven die dit soort toepassingen (home assistant als home energy management system met zonnepanelen, warmtepomp, laadpaal en toekomstige thuisbatterij) voor anderen in kunnen richten? Tegen betaling natuurlijk? Deze leercurve is mij te steil, maar ik wil niet afhankelijk worden van techbedrijven die over 5 jaar misschien niet meer bestaan of hun app ineens uitschakelen.

Helpen kan altijd, ik zou eerst zelf beginnen met home assistant. Eerst je zonnepanelen toevoegen, P1-meter koppelen, smart sockets installeren, etc. Zo ben ik vorig jaar ook gestart.
Anders ben je ook weer afhankelijk van een derde die iets heeft ingericht, wat niet helemaal helder is.

[Torch1969]

cnoobie schreef op vrijdag 5 september 2025 @ 17:17:
Dag allemaal, wow wat een kennis en ervaring zit hier. Mijn vraag is misschien een beetje offtopic. Kennen (of zijn) jullie mensen/bedrijven die dit soort toepassingen (home assistant als home energy management system met zonnepanelen, warmtepomp, laadpaal en toekomstige thuisbatterij) voor anderen in kunnen richten? Tegen betaling natuurlijk? Deze leercurve is mij te steil, maar ik wil niet afhankelijk worden van techbedrijven die over 5 jaar misschien niet meer bestaan of hun app ineens uitschakelen.

Ik ben het met @diamanten eens. Gewoon beginnen. Een EMS gebaseerd op zoiets als home assistant blijft je aandacht vragen. Dat is juist ook de kracht (steeds verder verbeteren) en hobby (je blijft betrokken bij je energie verbruik en hoe dat te optimaliseren). Het is geen kwestie van één keer installeren en instellen en jarenlang blijven draaien. Als je rustig de tijd neemt kun je de leercurve uitrekken en minder stijl maken. Als je dat toch niet aandurft, dan moet je je afvragen of deze route wel iets voor jou is. Alternatief kan iets als home wizard zijn. Een stuk toegankelijker en ook gericht op inzicht in verbruik en sturen op verbruik.

[cnoobie]

Dank @diamanten en @Torch1969, eerlijk antwoord en ik snap jullie punt heel goed. Toch zou ik wensen dat er een tussenweg was…wel open source en onafhankelijk, maar zonder dat je er zelf een hele expert in moet worden. Beetje zoals Proton betrouwbare diensten levert, en niet met je data aan de haal gaat. Net als voor Proton zou iemand als ik bereid zijn daar voor te betalen. En HA lijkt me een perfect platform met community voor handige ondernemers om zulke diensten op te baseren. Anyway…zal dit topic niet blijven vervuilen met deze discussie, nogmaals dank.

[Xoliul]

Ik zat wat verder te kijken of ik EMHASS eens kan testen, maar blijkbaar is EMHASS op Synology Docker redelijk out of date, iemand een oplossing voor?

[ Voor 35% gewijzigd door Xoliul op 10-09-2025 22:31 ]

[Sicco92]

Xoliul schreef op woensdag 10 september 2025 @ 22:27:
Ik zat wat verder te kijken of ik EMHASS eens kan testen, maar blijkbaar is EMHASS op Synology Docker redelijk out of date, iemand een oplossing voor?

Kan je niet gewoon een container opspinnen op basis van een image? Als je ghcr.io/davidusb-geek/emhass:0.13.4 gebruikt, dan heb je de laatste versie.

[Teun_2]

cnoobie schreef op vrijdag 5 september 2025 @ 17:17:
Dag allemaal, wow wat een kennis en ervaring zit hier. Mijn vraag is misschien een beetje offtopic. Kennen (of zijn) jullie mensen/bedrijven die dit soort toepassingen (home assistant als home energy management system met zonnepanelen, warmtepomp, laadpaal en toekomstige thuisbatterij) voor anderen in kunnen richten? Tegen betaling natuurlijk? Deze leercurve is mij te steil, maar ik wil niet afhankelijk worden van techbedrijven die over 5 jaar misschien niet meer bestaan of hun app ineens uitschakelen.

Een oud collega van me heeft er zijn (deel)beroep van gemaakt: https://smartenergycontrol.be/over-ons/

[zaphod_b]

Hallo allemaal. Nieuw met EMHASS, en ik vind het behoorlijk ingewikkeld om het goed ingesteld te krijgen... Ik worstel nog met de PV voorspelling. Ik gebruik Solcast en ChatGPT adviseerde het volgende in m'n HA config:

code:

      - name: "Solcast PV Forecast Power Series"
        unique_id: solcast_pv_forecast_power_series
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set forecast = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow','detailedForecast') %}
          {% if forecast %}
            {# Show the first interval’s W value in state #}
            {% set first = forecast[0].pv_estimate | float(0) %}
            {{ ((first / 0.5) * 1000) | round(0) }}
          {% else %}
            0
          {% endif %}
        attributes:
          forecast: >
            {% set forecast = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow','detailedForecast') %}
            {% if forecast %}
              {% set data = [] %}
              {% for step in forecast %}
                {% set w = ((step.pv_estimate | float(0)) / 0.5 * 1000) | round(0) %}
                {% set rec = {"datetime": step.period_start, "value": w} %}
                {% set data = data + [rec] %}
              {% endfor %}
              {{ data }}
            {% else %}
              []
            {% endif %}

In m'n EMHASS config ziet het er nu zo uit:

code:

  "pv_power_forecast": {
    "method": "ha",
  "entity_id": "sensor.solcast_pv_forecast_power_series"
  },

Maar... ik zie in de grafiekjes na een daily optimize niks over een solar voorspelling... In de EMHASS logs:

code:

[2025-09-24 10:20:16 +0200] [25] [INFO]  >> Performing dayahead optimization...
[2025-09-24 10:20:16 +0200] [25] [INFO] Performing day-ahead forecast optimization
[2025-09-24 10:20:16 +0200] [25] [INFO] Perform optimization for the day-ahead
[2025-09-24 10:20:16 +0200] [25] [WARNING] Solver default unknown, using default
[2025-09-24 10:20:16 +0200] [25] [INFO] Status: Optimal
[2025-09-24 10:20:16 +0200] [25] [INFO] Total value of the Cost function = -1.70
[2025-09-24 10:20:16 +0200] [25] [INFO] Optimization status: Optimal
[2025-09-24 10:20:17 +0200] [25] [INFO]  >> Sending rendered template table data

Iemand die dit werkend heeft en de correcte config heeft?

[RudolfR]

@zaphod_b

Ik loop een beetje achter met EMHASS, maar ik ben niet bekend met een pv_power_forecast method: "ha" en een entity_id die kan worden uitgelezen.
Ik ben gewend dat je die forecast moet meegeven als parameter in de rest-call.

[zaphod_b]

RudolfR schreef op woensdag 24 september 2025 @ 10:38:
@zaphod_b

Ik loop een beetje achter met EMHASS, maar ik ben niet bekend met een pv_power_forecast method: "ha" en een entity_id die kan worden uitgelezen.
Ik ben gewend dat je die forecast moet meegeven als parameter in de rest-call.

Ik gebruik geen rest-call of automations, tot nu toe. Heb EMHASS als add-on draaien en druk vie de GUI op optimize. Config in /share/config.json

[ruub26]

Zou je je config kunnen delen?

[RudolfR]

@zaphod_b

Dit kun je zo in de 'Box' plakken voor een day-ahead, maar zoals gezegd, pv_power_forecast is een array, geen entity van HA.

JSON:

      {"entity_save": true, "publish_prefix": "",
      "battery_maximum_state_of_charge": 1, "battery_minimum_state_of_charge":
      0.02, "battery_target_state_of_charge": 0.13,
      "battery_discharge_power_max": 600, "battery_charge_power_max": 800.0,
      "weather_forecast_cache": false, "pv_power_forecast": [0, 0, 0, 0, 0, 0,
      0, 133, 672, 949, 1240, 1430, 1616, 1780, 1836, 1873, 1853, 1823, 1748,
      1648, 1598, 1577, 1485, 1330, 1145, 929, 717, 480, 315, 160, 39, 0, 0, 0,
      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], "load_cost_forecast": [0.25112,
      0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.25112, 0.25112,
      0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112] }

[ZatarraNL]

Ik overweeg me te gaan verdiepen in emhass. Wie gebruikt dit nog? Of zijn er nog alternatieven?

[RudolfR]

@ZatarraNL

Ik. Weinig activiteit op dit moment, maar werkt goed.

[MarcoPolet]

ZatarraNL schreef op zondag 28 december 2025 @ 17:40:
Ik overweeg me te gaan verdiepen in emhass. Wie gebruikt dit nog? Of zijn er nog alternatieven?

Ik gebruik het ook, werkt erg goed, maar wel een flink steile leercurve, hoewel er inmiddels ook behoorlijk goede documentatie is. En een vrij actief forum. En hier bij tweakers krijg je ook vast hulp :-)

[ZatarraNL]

Dank voor alle reacties. Ik was even benieuwd of het misschien toch was doodgebloed. Ik heb nu allerlei automations die zelf statisch bepalen of er energie verbruikt moet worden, of niet. Dus ik denk dat ik dit wel ga proberen. Mooi dat de ervaringen is dat het goed werkt.

Nog beginnertips?

[ Voor 3% gewijzigd door ZatarraNL op 28-12-2025 19:11 ]

[vincent_1971]

Gewoon installeren. En kijken bij de instellingen wat het betekend..ook handig om de automatisering 1 keer per dag uit te laten voeren.

[hemertje]

ZatarraNL schreef op zondag 28 december 2025 @ 17:40:
Ik overweeg me te gaan verdiepen in emhass. Wie gebruikt dit nog? Of zijn er nog alternatieven?

een alternatief: Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[ZatarraNL]

hemertje schreef op vrijdag 2 januari 2026 @ 20:00:
[...]


een alternatief: Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

Dank voor de tip. Ga ik eens goed bekijken.

[ZatarraNL]

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?

[ Voor 12% gewijzigd door ZatarraNL op 13-01-2026 19:45 ]

[RudolfR]

@ZatarraNL

Je moet zelf een array aanbieden met de prijzen van de aankomende timeperiods, meestal uren.
In de load_cost_forecast staat een lijstje met prijzen per uur, vanaf 3 PM, dus eerst wat dure uren, dan de nacht, en dan weer de ochtend/middag.

YAML:

  domain: shell_command
  service: emhass_dayahead_optim
  service_data:
    payload: >-
      {"entity_save": true, "publish_prefix": "dh_",
      "battery_maximum_state_of_charge": 1, "battery_minimum_state_of_charge":
      0.02, "battery_target_state_of_charge": 0.0,
      "battery_discharge_power_max": 600, "battery_charge_power_max": 800.0,
      "weather_forecast_cache": false, "pv_power_forecast": [73, 51, 26, 2, 0,
      0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
      0, 0, 0, 0, 0, 0, 17, 47, 85, 144, 213, 247, 245, 219, 196, 173, 143,
      109], "load_cost_forecast": [0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.25112, 0.25112, 0.25112, 0.25112,
      0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112, 0.25112,
      0.25112, 0.25112, 0.25112, 0.25112, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322, 0.26322,
      0.26322, 0.26322, 0.26322] }

[ Voor 3% gewijzigd door RudolfR op 13-01-2026 19:59 ]

[diamanten]

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?

Deze automation gebaseerd op Nordpool prijs voor een dynamische NL-leverancier zoals Frank/Tibber (incl.BTW en energiebelasting) gebruik ik voor het draaien van een MPC elke tien minuten (nog wel in een testopstelling). Met name het stuk voor de load_cost_forecast is relevant:

code:

alias: >-
  EMHASS: MPC optimalisatie op basis van Nord Pool dynamische tarieven (15-min
  direct)
description: >
  Voert elke 10 minuten een MPC-optimalisatie uit (15-min prijzen worden direct
  gebruikt). Gebruikt PV- en load-voorspellingen met 15-min resolutie. Zowel
  afname als teruglevering gebruiken dezelfde prijsreeks (pas aan als je andere
  tarieven hebt).
triggers:
  - trigger: time_pattern
    minutes: /10
actions:
  - action: shell_command.emhass_naive_mpc
    data:
      payload: |
        {
          "prediction_horizon": {{ prediction_horizon }},
          "prod_price_forecast": {{ prod_price_forecast }},
          "soc_init": {{ soc_init }},
          "num_def_loads": {{ num_def_loads }},
          "def_total_hours": {{ def_total_hours }},
          "pv_power_forecast": {{ pv_p_fc }},
          "load_power_forecast": {{ load_p_fc }},
          "load_cost_forecast": {{ load_cost_forecast }},
          "min_soc": {{ states('input_number.min_soc') | float }},
          "max_soc": {{ states('input_number.max_soc') | float }},
          "target_soc": {{ states('input_number.target_soc') | float }},
          "max_charging_power": {{ states('input_number.max_charge_power') | float }},
          "max_discharging_power": {{ states('input_number.max_discharge_power') | float }},
          "set_battery_dynamic": {{ 1 if is_state('input_boolean.dynamic_battery_profile', 'on') else 0 }}
        }
  - delay:
      seconds: 5
  - action: script.emhass_rolling_forecast_en_publish
    data: {}
mode: single
variables:
  prediction_horizon: |
    {% set horizon_hours = 12 %} {{ (horizon_hours * 60 // 15) | int }}
  soc_max: 0.95
  soc_init: >
    {% set soc_val = (states('input_number.dummy_soc') | float(90)) / 100 %} {{
    soc_max if soc_val > soc_max else soc_val }}
  load_cost_forecast: >
    {% set steps = prediction_horizon %} {% set raw_today =
    state_attr('sensor.nordpool_kwh_nl_eur_6_095_021', 'raw_today') or [] %} {%
    set raw_tomorrow = state_attr('sensor.nordpool_kwh_nl_eur_6_095_021',
    'raw_tomorrow') or [] %} {% set all_slots = (raw_today + raw_tomorrow) %} {%
    set now_ts = now() %} {% set start_idx = 0 %} {% for i in
    range(all_slots|length) %}
      {% set slot = all_slots[i] %}
      {% if as_datetime(slot.start) >= now_ts %}
        {% set start_idx = i %}
        {% break %}
      {% endif %}
    {% endfor %} {% set tail = all_slots[start_idx:] %} {% set values = tail |
    map(attribute='value') | list %} {% if values | length < steps %}
      {% set values = values + ([values[-1] if values|length>0 else 0.0] * (steps - values|length)) %}
    {% else %}
      {% set values = values[:steps] %}
    {% endif %} {{ values | tojson }}
  prod_price_forecast: "{{ load_cost_forecast }}"
  load_p_fc: >
    {% set steps = prediction_horizon %} {% set p_load_fc =
    (state_attr('sensor.p_load_forecast', 'forecasts') or [])
        | map(attribute='p_load_forecast')
        | map('float', default=0.0)
        | list %}
    {% set p_load_now = [states('sensor.power_load_no_var_loads') | float(0)] %}
    {% set combined = (p_load_now + p_load_fc)[:steps] %} {% if combined |
    length < steps %}
      {% set combined = combined + ([0.0] * (steps - combined | length)) %}
    {% endif %} {{ combined | tojson }}
  pv_p_fc: >
    {% set steps = prediction_horizon %} {% set today =
    (state_attr('sensor.energy_production_today_2', 'watts') or {})
        | dictsort
        | selectattr('0', '>=', now().replace(second=0, microsecond=0).isoformat())
        | map(attribute='1')
        | map('float', default=0.0)
        | list %}
    {% set tomorrow = (state_attr('sensor.energy_production_tomorrow_2',
    'watts') or {})
        | dictsort
        | map(attribute='1')
        | map('float', default=0.0)
        | list %}
    {% set all_future = today + tomorrow %} {% set sampled = all_future[:steps]
    %} {% if sampled | length < steps %}
      {% set sampled = sampled + ([0.0] * (steps - sampled | length)) %}
    {% endif %} {{ sampled | tojson }}
  num_def_loads: 1
  def_total_hours:
    - 2

[MarcoPolet]

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.

[Sicco92]

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:

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  }}
      }

[MarcoPolet]

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.

[Sicco92]

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:

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!

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

[MarcoPolet]

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

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

[MarcoPolet]

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 ]

[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?

[RudolfR]

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?

[MarcoPolet]

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

[Gummbahla]

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:

1. Standaard (PV overschot laden): gebruikt auto modus omvormer, dus 0 op de meter.
2. Lage inkoopprijs (Geforceerd laden van het net): bovenop PV opbrengst bijladen, charge_battery modus op omvormer
3. Hoog verbruik / hoge verkoopprijs (Geforceerd ontladen): Batterij ontladen met door EMHASS opgegeven vermogen, discharge_battery op omvormer
4. 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

[vincent_1971]

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?

[MarcoPolet]

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.

[vincent_1971]

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?

[RudolfR]

Ik heb dat zo:

YAML:

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 ]

[vincent_1971]

RudolfR schreef op donderdag 14 mei 2026 @ 21:59:
Ik heb dat zo:

YAML:

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?

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.

[vincent_1971]

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'

[RudolfR]

@vincent_1971

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

[Gummbahla]

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

[vincent_1971]

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

[MarcoPolet]

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)

[vincent_1971]

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

[RudolfR]

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

[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?

[vincent_1971]

JaRuBe schreef op zondag 24 mei 2026 @ 09:33:
[...]

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

Bij mij wel. De laatste versie werkt goed hier. De vorige versie gaf ineens fouten.

[vincent_1971]

Bestaat er een mogelijkheid om een deferrable op 1 vast tijdstip uit te voeren ?

Zit te denk om bv een vaatwasser om 13:00 uit te voeren en een wpb met een veranderlijke tijdstippen. Net als een wasmachine

[ Voor 99% gewijzigd door vincent_1971 op 24-05-2026 11:09 ]

[MarcoPolet]

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.

[vincent_1971]

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

[RudolfR]

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 ]

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

[RudolfR]

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.

[RudolfR]

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)

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

[JoOv]

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?

[RudolfR]

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}

[JoOv]

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?

[RudolfR]

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?

[JoOv]

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.

[RudolfR]

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

[JoOv]

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??

[RudolfR]

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?

[JoOv]

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

[Gummbahla]

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.

[JoOv]

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?

[RudolfR]

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.