EMHASS - Energy Management for Home Assistant

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

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

[MarcoPolet]

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

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

[RudolfR]

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.

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

[Gummbahla]

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.

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

[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]
        %}

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

[MarcoPolet]

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

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

[RudolfR]

@Probydoby

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

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

[MarcoPolet]

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

[RudolfR]

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

[Sicco92]

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

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

[MarcoPolet]

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

[Whiskey48]

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 ]

[scoobs]

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.

[MarcoPolet]

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.

[scoobs]

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.

[MarcoPolet]

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.

[RudolfR]

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?

[scoobs]

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.



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

[Get!em]

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

[scoobs]

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.

[Get!em]

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 ]

[scoobs]

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 ]