EMHASS - Energy Management for Home Assistant

maandag 18 augustus 2025 16:58

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

Acties:

maandag 18 augustus 2025 17:52

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

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

Acties:

donderdag 21 augustus 2025 16:24

Topicstarter

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

Acties:

donderdag 21 augustus 2025 19:08

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

Afbeeldingslocatie: https://tweakers.net/i/pJgXmxijiXnIo4N-mFMGBC2Laac=/800x/filters:strip_exif()/f/image/zGtK05cdpSPtSNeWwaRbUwvS.png?f=fotoalbum_large

Acties:

donderdag 21 augustus 2025 20:02

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

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

Acties:

donderdag 21 augustus 2025 20:17

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

Acties:

donderdag 21 augustus 2025 20:18

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

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

Wat eerder al werd genoemd, het is een flinke leercurve

Acties:

donderdag 21 augustus 2025 20:32

Topicstarter

@dennisdew16
Dit idee:

code:

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

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

Acties:

donderdag 21 augustus 2025 20:37

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

Als voorbeeld, hier zijn een paar van mijn rest_commands:

YAML:

rest_command:
  emhass_dayahead_optim:
    url: http://localhost:5000/action/dayahead-optim
    method: post
    timeout: 300
    content_type: 'application/json'
    payload: >
      {
        "load_cost_forecast": {{ state_attr('sensor.current_price_for_electricity_usage', 'upcoming_24_hours_emhass_1h') }},
        "prod_price_forecast": {{ state_attr('sensor.current_price_for_electricity_return', 'upcoming_24_hours_emhass_1h') }},
        "def_total_hours": {{ states('sensor.deferrable_loads') }}
      }
  emhass_npc_optim_with_pv_15m:
    url: http://localhost:5000/action/naive-mpc-optim
    method: post
    timeout: 300
    payload: >
      {% set horizon = min(144, state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h_15min') | length | int) %}
      {
        "load_cost_forecast": {{ state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h_15min') | tojson }},
        "prod_price_forecast": {{ state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h_15min_return') | tojson }},
        {% if state_attr('sensor.solcast_forecast_data', 'forecasts') != [] %}"pv_power_forecast": {{ state_attr('sensor.solcast_24hrs_forecast_15m', 'forecasts')[:horizon] | tojson }},{% endif %}
        "prediction_horizon": {{ horizon | tojson }},
        "soc_init": {{ (states('sensor.hyper_2000_electric_level') | float(0) / 100) | round(2) | tojson }},
        "soc_final": 0.6
      }

Ik vind het ook veel leesbaarder

Acties:

vrijdag 22 augustus 2025 09:58

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

Acties:

vrijdag 22 augustus 2025 10:49

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

Afbeeldingslocatie: https://tweakers.net/i/qs-ojtzY0AGujGvrvyMGmxmuuso=/800x/filters:strip_icc():strip_exif()/f/image/yB4rCf0Gef6pbnGnt3DE5ZuV.jpg?f=fotoalbum_large

Acties:

vrijdag 22 augustus 2025 11:16

Topicstarter

@diamanten

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

Acties:

zondag 24 augustus 2025 00:46

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

Acties:

zondag 24 augustus 2025 09:39

RudolfR schreef op donderdag 21 augustus 2025 @ 20:18:
@dennisdew16
Dit idee:
code:
1
curl -i -H "Content-Type:application/json" -X POST -d '{"solcast_rooftop_id":"<your_system_id>","solcast_api_key":"<your_secret_api_key>"}' http://localhost:5000/action/dayahead-optim
Zie ook de documentatie:
https://emhass.readthedoc...st/forecasts.html#solcast

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

Acties:

maandag 25 augustus 2025 12:59

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

Acties:

maandag 25 augustus 2025 13:58

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

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

code:

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

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

Acties:

maandag 25 augustus 2025 14:50

Topicstarter

@dennisdew16

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

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

code:

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

Acties:

maandag 25 augustus 2025 15:48

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

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

Acties:

maandag 25 augustus 2025 17:07

Topicstarter

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

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

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

Hier is alleen een pv_power_forecast voldoende voor een goed resultaat:

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

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

Acties:

maandag 25 augustus 2025 17:35

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

Acties:

maandag 1 september 2025 14:24

Topicstarter

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.

Acties:

vrijdag 5 september 2025 17:17

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:
1
2
3
4
5
6
7
8
9
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 ]

Acties:

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.

zaterdag 6 september 2025 11:21

Acties:

zaterdag 6 september 2025 13:45

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.

Acties:

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.

zaterdag 6 september 2025 20:17

Acties:

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.

woensdag 10 september 2025 22:27

Acties:

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 ]

donderdag 11 september 2025 16:58

Acties:

vrijdag 12 september 2025 09:57

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.

Acties:

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/

woensdag 24 september 2025 10:20

Acties:

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?

woensdag 24 september 2025 10:38

Acties:

woensdag 24 september 2025 13:28

Topicstarter

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

Acties:

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

woensdag 24 september 2025 14:09

Acties:

ruub26

Zou je je config kunnen delen?

woensdag 24 september 2025 14:49

Acties:

zondag 28 december 2025 17:40

Topicstarter

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

Acties:

zondag 28 december 2025 18:05

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

Acties:

zondag 28 december 2025 19:01

Topicstarter

@ZatarraNL

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

Acties:

zondag 28 december 2025 19:10

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

Acties:

zondag 28 december 2025 19:30

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 ]

Acties:

vrijdag 2 januari 2026 20:00

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

Acties:

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

Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal

vrijdag 2 januari 2026 21:25

Acties:

dinsdag 13 januari 2026 19:41

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.

Acties:

dinsdag 13 januari 2026 19:58

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 ]

Acties:

dinsdag 13 januari 2026 20:03

Topicstarter

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

Acties:

vrijdag 23 januari 2026 21:23

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

Acties:

zaterdag 24 januari 2026 11:11

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

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

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

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

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

Acties:

zondag 25 januari 2026 20:28

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

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

Dit is bijvoorbeeld het schema voor vanochtend:

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

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

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

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

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

JSON:

{
  "adjusted_pv_model_max_age": 24,
  "adjusted_pv_regression_model": "LassoRegression",
  "adjusted_pv_solar_elevation_threshold": 10,
  "battery_charge_efficiency": 0.9,
  "battery_charge_power_max": 1201,
  "battery_discharge_efficiency": 0.89,
  "battery_discharge_power_max": 899,
  "battery_dynamic_max": 0.9,
  "battery_dynamic_min": -0.9,
  "battery_maximum_state_of_charge": 1,
  "battery_minimum_state_of_charge": 0.2,
  "battery_nominal_energy_capacity": 3840,
  "battery_stress_cost": 0,
  "battery_stress_segments": 10,
  "battery_target_state_of_charge": 0.5,
  "compute_curtailment": true,
  "continual_publish": false,
  "costfun": "profit",
  "delta_forecast_daily": 2,
  "end_timesteps_of_each_deferrable_load": [
    0,
    0,
    0,
    0
  ],
  "historic_days_to_retrieve": 2,
  "influxdb_database": "homeassistant",
  "influxdb_host": "localhost",
  "influxdb_measurement": "W",
  "influxdb_port": 8086,
  "influxdb_retention_policy": "autogen",
  "influxdb_use_ssl": false,
  "influxdb_verify_ssl": false,
  "inverter_ac_input_max": 1200,
  "inverter_ac_output_max": 800,
  "inverter_efficiency_ac_dc": 1,
  "inverter_efficiency_dc_ac": 1,
  "inverter_is_hybrid": false,
  "inverter_stress_cost": 0,
  "inverter_stress_segments": 10,
  "load_cost_forecast_method": "hp_hc_periods",
  "load_forecast_method": "naive",
  "load_negative": false,
  "load_offpeak_hours_cost": 0.1419,
  "load_peak_hour_periods": {
    "period_hp_1": [
      {
        "start": "02:54"
      },
      {
        "end": "15:24"
      }
    ],
    "period_hp_2": [
      {
        "start": "17:24"
      },
      {
        "end": "20:24"
      }
    ]
  },
  "load_peak_hours_cost": 0.1907,
  "logging_level": "DEBUG",
  "lp_solver_timeout": 45,
  "maximum_power_from_grid": 17000,
  "maximum_power_to_grid": 17000,
  "method_ts_round": "nearest",
  "minimum_power_of_deferrable_loads": [
    0,
    0,
    0,
    0,
    0
  ],
  "model_type": "load_forecast",
  "modules_per_string": [
    8
  ],
  "nominal_power_of_deferrable_loads": [
    11000,
    7200,
    2500,
    1000
  ],
  "num_lags": 48,
  "num_threads": 0,
  "number_of_deferrable_loads": 4,
  "open_meteo_cache_max_age": 30,
  "operating_hours_of_each_deferrable_load": [
    0,
    0,
    0,
    0
  ],
  "optimization_time_step": 15,
  "perform_backtest": false,
  "photovoltaic_production_sell_price": 0.1419,
  "production_price_forecast_method": "constant",
  "pv_inverter_model": [
    "GoodWe_Technologies_Co___Ltd___GW5000A_MS__240V_"
  ],
  "pv_module_model": [
    "JA_Solar_JAM72S01_375_PR"
  ],
  "sensor_linear_interp": [
    "sensor.power_load_no_var_loads_filter"
  ],
  "sensor_power_load_no_var_loads": "sensor.power_load_no_var_loads_filter",
  "sensor_power_photovoltaics": "sensor.pv_power",
  "sensor_power_photovoltaics_forecast": "sensor.p_pv_forecast",
  "sensor_replace_zero": [
    "sensor.pv_power"
  ],
  "set_battery_dynamic": false,
  "set_deferrable_load_single_constant": [
    false,
    false,
    true,
    false
  ],
  "set_deferrable_startup_penalty": [
    0,
    0,
    1,
    4
  ],
  "set_nocharge_from_grid": false,
  "set_nodischarge_to_grid": false,
  "set_total_pv_sell": false,
  "set_use_adjusted_pv": false,
  "set_use_battery": true,
  "set_use_pv": true,
  "set_zero_min": true,
  "sklearn_model": "KNeighborsRegressor",
  "split_date_delta": "48h",
  "ssl_no_verify": false,
  "start_timesteps_of_each_deferrable_load": [
    0,
    0,
    0,
    0
  ],
  "strings_per_inverter": [
    2
  ],
  "surface_azimuth": [
    169
  ],
  "surface_tilt": [
    40
  ],
  "treat_deferrable_load_as_semi_cont": [
    false,
    false,
    false,
    false
  ],
  "use_influxdb": false,
  "use_websocket": true,
  "var_model": "sensor.power_load_no_var_loads",
  "weather_forecast_method": "open-meteo",
  "weight_battery_charge": 0,
  "weight_battery_discharge": 0.05
}

En de parameters die ik naar EMHASS stuur:

YAML:

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

Acties:

zondag 25 januari 2026 20:41

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

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

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

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

Beide worden regelmatig door de ontwikkelaars bezocht en vragen beantwoord.

Acties:

zaterdag 21 februari 2026 14:18

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

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

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

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

Beide worden regelmatig door de ontwikkelaars bezocht en vragen beantwoord.

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

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

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

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

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

Acties:

VentingBow5

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

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

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

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

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

zaterdag 21 februari 2026 15:00

Acties:

zaterdag 21 februari 2026 20:51

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

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

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

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

Acties:

VentingBow5

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

zaterdag 28 maart 2026 07:57

Acties:

dinsdag 31 maart 2026 16:05

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

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

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

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

Acties:

Los Tigros

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

code:

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

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

donderdag 16 april 2026 13:22

Acties:

donderdag 16 april 2026 20:59

Topicstarter

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

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

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

Tips?

Acties:

donderdag 7 mei 2026 09:29

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

Tips?

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

Acties:

donderdag 14 mei 2026 12:39

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

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

Zien jullie nog iets wat beter kan worden ingesteld?

Ter info, hier nog de YAML voor de automatisering:

YAML:

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

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

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

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

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

mode: restart

Acties:

donderdag 14 mei 2026 21:02

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

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

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

In automation.yaml

- alias: EMHASS day-ahead optimization

trigger:

platform: time

at: '13:00:00'

action:

- service: shell_command.dayahead_optim

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

Heb de rechten goed staan.

Maar werkt niet. Iemand een idee?

Acties:

donderdag 14 mei 2026 21:40

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

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

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

In automation.yaml

- alias: EMHASS day-ahead optimization

trigger:

platform: time

at: '13:00:00'

action:

- service: shell_command.dayahead_optim

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

Heb de rechten goed staan.

Maar werkt niet. Iemand een idee?

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

Acties:

donderdag 14 mei 2026 21:59

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

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

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

Acties:

vrijdag 15 mei 2026 14:42

Topicstarter

Ik heb dat zo:

YAML:

1
2
3

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

YAML:

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

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

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

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

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

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

Acties:

donderdag 21 mei 2026 16:25

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

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

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

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

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

Acties:

donderdag 21 mei 2026 17:06

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

Qua instellingen niets veranderd

code:

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

Acties:

donderdag 21 mei 2026 17:43

Topicstarter

@vincent_1971

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

Acties:

donderdag 21 mei 2026 18:01

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

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

Acties:

donderdag 21 mei 2026 19:51

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

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

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

Acties:

donderdag 21 mei 2026 21:52

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

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

In het bugreport wordt ook een eenvoudige fix aangegeven:

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

"heat_topology": {

"sources": []

}

(niet geprobeerd, zit nog op .2)

Acties:

vrijdag 22 mei 2026 20:03

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

In het bugreport wordt ook een eenvoudige fix aangegeven:

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

"heat_topology": {

"sources": []

}

(niet geprobeerd, zit nog op .2)

Geprobeerd..werkt niet

Acties:

Topicstarter

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

zondag 24 mei 2026 09:33

Acties:

JaRuBe

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

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

zondag 24 mei 2026 11:43

Acties:

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

zondag 24 mei 2026 12:24

Acties:

maandag 25 mei 2026 22:05

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

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

Acties:

zaterdag 13 juni 2026 11:51

Topicstarter

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

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

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

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

Acties:

savale

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

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

zaterdag 13 juni 2026 17:09

Acties:

zaterdag 20 juni 2026 11:04

Topicstarter

Dat kan zeker.

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

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

Acties:

zaterdag 20 juni 2026 16:50

Topicstarter

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

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

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

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

Acties:

ward0

Hallo,

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

Waarom? Het laden van de EV...

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

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

maandag 22 juni 2026 09:34

Acties:

maandag 22 juni 2026 09:43

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

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

Acties:

maandag 22 juni 2026 11:17

Topicstarter

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

Volledige payload:

code:

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

Acties:

maandag 22 juni 2026 11:30

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

Acties:

maandag 22 juni 2026 12:58

Topicstarter

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

Acties:

maandag 22 juni 2026 16:59

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

Acties:

maandag 22 juni 2026 18:19

Topicstarter

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

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

Blijft koffiedik kijken zonder alle gegevens.

Acties:

maandag 22 juni 2026 18:57

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

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

Acties:

maandag 22 juni 2026 19:51

Topicstarter

Oké, dus emhass doet het goed?

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

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

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

Acties:

woensdag 24 juni 2026 12:47

Emhass doet het naar mijn idee goed.

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

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

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

Grafiek is inderdaad een custom:apexcharts-card

Acties:

donderdag 25 juni 2026 09:52

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

Acties:

donderdag 25 juni 2026 20:47

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

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

Acties:

zaterdag 11 juli 2026 02:59

Topicstarter

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

YAML:

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

  #  ssl: false
  #  verify_ssl: false

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

      # Electricity prices
      #- sensor.actual_energy_price_per_kwh

      # Optional (recommended for EMHASS)
      - sensor.battery_state_of_charge

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

Acties:

hbvdh

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

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

YAML:

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

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

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

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

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

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

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

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

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

zaterdag 11 juli 2026 09:34

Acties:

zaterdag 11 juli 2026 14:48

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

Acties:

hbvdh

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

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

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

zaterdag 11 juli 2026 17:25

Acties:

zaterdag 11 juli 2026 18:59

Topicstarter

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

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

Acties:

savale

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

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

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

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

dinsdag 14 juli 2026 14:21

Acties: