EMHASS - Energy Management for Home Assistant

[Thorsd]

Is er iemand die al een EMHASS implementatie heeft (of ermee bezig is) voor de aansturing van een full electric warmtepomp icm dynamische tarieven? Er lijkt een mooi deferrable load thermal model in te zitten.

Aansturing kan hier generiek dmv de SG (smart grid) interface (uit/normaal/capacity1/capacity2), of evt door heishamon (Panasonic J).

Optimaliseren voor PV is voor mij minder belangrijk. In november t/m februari gebruikt de WP 80% van het WP-jaartotaal, en eigen PV consumptie is dan al >90%. Daarnaast zit in de dynamische tarieven impliciet al een grote component van wanneer PV beschikbaar is.

[Sicco92]

Thorsd schreef op maandag 10 maart 2025 @ 12:01:
Is er iemand die al een EMHASS implementatie heeft (of ermee bezig is) voor de aansturing van een full electric warmtepomp icm dynamische tarieven? Er lijkt een mooi deferrable load thermal model in te zitten.

Aansturing kan hier generiek dmv de SG (smart grid) interface (uit/normaal/capacity1/capacity2), of evt door heishamon (Panasonic J).

Optimaliseren voor PV is voor mij minder belangrijk. In november t/m februari gebruikt de WP 80% van het WP-jaartotaal, en eigen PV consumptie is dan al >90%. Daarnaast zit in de dynamische tarieven impliciet al een grote component van wanneer PV beschikbaar is.

Ik ben ermee bezig, maar heb het nog niet werkend gekregen. Ik vind de documentatie rondom deze functie nog niet geweldig, dus ik kom er nog niet echt verder mee helaas. Bij mijn pogingen krijg ik steeds een TypeError: unsupported operand type(s) for -: 'int' and 'NoneType' en ik heb helaas nog niet kunnen vinden wat ik fout doe.

Ik vind de waarden die ik moet gebruiken voor heating_rate en cooling_constant ook nog niet heel duidelijk. Ik had gehoopt dat ik daar achter zou kunnen komen door trial and error, maar het gaat bij mij vooral fout bij de errors

Dit is mijn payload voor de naive-npc-optim endpoint trouwens, mocht je daar wat aan hebben (of de fout spotten):

Django/Jinja:

{% set horizon = min(72, state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h') | length | int) %}
{% set ns = namespace(temps=[]) %}
{% for i in range(horizon) %}
  {% set ns.temps = ns.temps + [20.7] %}
{% endfor %}
{
  "load_cost_forecast": {{ state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h') | tojson }},
  "prod_price_forecast": {{ state_attr('sensor.entsoe_prices_forecast_30', 'prices_36h') | tojson }},
  {% if state_attr('sensor.solcast_forecast_data', 'forecasts') != [] %}"pv_power_forecast": {{ state_attr('sensor.solcast_24hrs_forecast', 'forecasts')[:horizon] | tojson }},{% endif %}
  "prediction_horizon": {{ horizon | tojson }},
  "soc_init": {{ (state_attr('sensor.battery_sim_zendure_hyper_2000_5_76_kwh', 'percentage') | float(0) / 100) | round(2) | tojson }},
  "soc_final": 0.6,
  "def_load_config": [
    {"thermal_config": {
      "heating_rate": 0.6,
      "cooling_constant": 0.4,
      "overshoot_temperature": 23,
      "start_temperature": 22,
      "desired_temperatures": {{ ns.temps | tojson }}
      }
    }
  ]
}

[ Voor 31% gewijzigd door Sicco92 op 10-03-2025 17:11 ]

[Brokencore]

Ben wat aan het zoeken om de energie afname optimaal af te stemmen op de EPEX prijzen. Kan ik met deze tool ook de verwachte energiebelasting van een gebouw simuleren? Dus de warmteverlies berekening in combinatie met de weersvoorspelling en eventueel gekoppeld aan een agenda met het gebruik van de ruimte? Gaat om een grotere ruimte met 100+ mensen welke ook een thermisch opwarming met zich mee brengen.

Mijn doel is om per dag het benodigde verwarmingsvermogen te berekenen en dit zo gunstig mogelijk in te kopen (grondwarmtepomp welke zijn buffer opwarmt).

[RudolfR]

@Brokencore

In de basis is dat het thermal model;
https://emhass.readthedocs.io/en/latest/thermal_model.html

Maar de parameter voor de warmte van 100 man ontbreekt. Wel de energieprijs, buitentemperatuur en gewenste binnentemperatuur.

[Thorsd]

Sicco92 schreef op maandag 10 maart 2025 @ 17:05:
[...]

Ik ben ermee bezig, maar heb het nog niet werkend gekregen. Ik vind de documentatie rondom deze functie nog niet geweldig, dus ik kom er nog niet echt verder mee helaas. Bij mijn pogingen krijg ik steeds een TypeError: unsupported operand type(s) for -: 'int' and 'NoneType' en ik heb helaas nog niet kunnen vinden wat ik fout doe.

Dankjewel, ik ben er zelf nog niet mee begonnen, en ga het tzt proberen. Maar wat betreft de fout: er wordt ergens geprobeerd een "NoneType" van een getal af te trekken. Ik zie geen "-" in je code, dus je zal ergens een variabele van NoneType doorgegeven aan een plek waar wel een getal-variabele verwacht wordt.

Ik vind de waarden die ik moet gebruiken voor heating_rate en cooling_constant ook nog niet heel duidelijk. Ik had gehoopt dat ik daar achter zou kunnen komen door trial and error, maar het gaat bij mij vooral fout bij de errors

Ik heb even in de documentatie en code gekeken, en de heating_rate is een variabele die aangeeft hoe snel de warmtebron de ruimte op kan warmen - zonder dat er thermische verliezen zijn - op nominaal vermogen. Ik was even in de war over de delta_t in de formule maar dat is de tijdsinterval (dus 1 uur) en niet het temperatuurverschil. De constante is dus inderdaad in graad per uur.

De cooling_rate geeft aan hoeveel de ruimte afkoelt doordat het buiten kouder is. De eenheid is graad per uur per graad verschil met de buitentemperatuur. Dus als de variabele 0.1 is, en het binnen 20 is en buiten 0, dan koelt de ruimte zonder verwarming 2 graden per uur af.

[Sicco92]

Thorsd schreef op maandag 10 maart 2025 @ 17:59:
[...]


Dankjewel, ik ben er zelf nog niet mee begonnen, en ga het tzt proberen. Maar wat betreft de fout: er wordt ergens geprobeerd een "NoneType" van een getal af te trekken. Ik zie geen "-" in je code, dus je zal ergens een variabele van NoneType doorgegeven aan een plek waar wel een getal-variabele verwacht wordt.
[

Klopt, en ik ben wat dichter bij de fout. De payload in het voorbeeld in de documentatie heeft ook nog een outdoor_temperature_forecast key. Ik dacht dat die optioneel was, want EMHASS kan zelf ook weersvoorspellingen ophalen.
Blijkbaar is die in (mijn geval) niet optioneel, want als ik outdoor_temperature_forecast wel meegeef met een lijst even lang als mijn horizon, dan krijg ik geen foutmelding meer. Een stapje verder dus

Volgende horde is dat ik een Infeasible berekening krijg met de huidige config, maar ik gok dat dat ligt aan de random getallen die ik heb ingevuld.

[Reaper.JA2]

Wil hier een iets andere benadering kiezen, wat wellicht interessant kan zijn voor de mensen hier.

Opstelling: lucht-water warmtepomp, PV en EV.

Ik wil graag dat Home Assistant achteruit kijkt en bepaalt hoeveel warmer de woonkamer is dan is ingesteld, dat zie ik als het effect van de zon. Dat wil ik over de 'solar forecast' leggen, om zo vooruit te kunnen kijken en te bepalen of de warmtepomp aan moet of dat de zon het huis voldoende verwarmt. En dat de warmtepomp pas aan gaat bij een ondergrens van ~18,5 bv.

Wat denken jullie van deze aanpak?

Hoe dit in YAML te vatten is een tweede

[Beekforel]

Reaper.JA2 schreef op donderdag 20 maart 2025 @ 09:25:
Wil hier een iets andere benadering kiezen, wat wellicht interessant kan zijn voor de mensen hier.

Opstelling: lucht-water warmtepomp, PV en EV.

Ik wil graag dat Home Assistant achteruit kijkt en bepaalt hoeveel warmer de woonkamer is dan is ingesteld, dat zie ik als het effect van de zon. Dat wil ik over de 'solar forecast' leggen, om zo vooruit te kunnen kijken en te bepalen of de warmtepomp aan moet of dat de zon het huis voldoende verwarmt. En dat de warmtepomp pas aan gaat bij een ondergrens van ~18,5 bv.

Wat denken jullie van deze aanpak?

Hoe dit in YAML te vatten is een tweede

Ik probeer zo'n soort benadering handmatig nu het stookseizoen bijna klaar is. Maar dan wel met de aanpassing dat als ik verwacht dat het na de nacht op de ondergrens komt, ik overdag bij stook. Dat betekent soms 's avonds in de korte broek op de bank maar dan wel warmte gebufferd op PV stroom en met de efficiëntie COP.

Dit gaat best ok, maar handmatig is flut natuurlijk. Ik heb gister EMHASS geïnstalleerd maar moet nu eerst even wachten tot de load sensor genoeg data heeft.

[desalnietemin]

Interessant topic. Dank voor het starten @RudolfR .

Ik was op zoek naar in eerste instantie een simpele automation blueprint die ik kon gaan gebruiken om o.b.v., de goedkoopste ENTSO-E prijzen enkele apparaten te gaan sturen. Toen kwam ik bij deze uit: https://www.creatingsmart...nt-0-2-0/#google_vignette.

Verder kwam ik deze ook nog tegen: https://flexmeasures.io (met deze HAS integratie: https://github.com/FlexMeasures/flexmeasures-ha-integration). Wat volgens mij de kern is waar het om draait, het maken van geoptimaliseerde schema's. Iemand ervaring met flexmeasures toevallig? Die lijkt me iets eenvoudiger dan EMHASS maar wellicht ben ik hier appels met peren aan het vergelijken.

Zelf heb ook de nodige zon-PV, idealiter wil ik de apparaten waar ik mijn verbruik van kan uitstellen (water-water warmtepomp met buffervaten, thuislaadpunt, wasmachine, droger, vaatwasser en hotfill boiler) (deferables) maximaal laten verbruiken als ik zelf opwek en mocht er nog aanvullend nodig zijn dan wanneer de prijs het laagste is (obs dynamische tarieven). Toen kwam ik op deze post uit. Zou dat theoretische mogelijk moeten zijn met EMHASS?

Groet en dank,

[ Voor 17% gewijzigd door desalnietemin op 29-03-2025 21:10 ]

[Thorsd]

desalnietemin schreef op zaterdag 29 maart 2025 @ 20:57:
Interessant topic. Dank voor het starten @RudolfR .

Ik was op zoek naar in eerste instantie een simpele automation blueprint die ik kon gaan gebruiken om o.b.v., de goedkoopste ENTSO-E prijzen enkele apparaten te gaan sturen. Toen kwam ik bij deze uit: https://www.creatingsmart...nt-0-2-0/#google_vignette.

Verder kwam ik deze ook nog tegen: https://flexmeasures.io (met deze HAS integratie: https://github.com/FlexMeasures/flexmeasures-ha-integration). Wat volgens mij de kern is waar het om draait, het maken van geoptimaliseerde schema's. Iemand ervaring met flexmeasures toevallig? Die lijkt me iets eenvoudiger dan EMHASS maar wellicht ben ik hier appels met peren aan het vergelijken.

Zelf heb ook de nodige zon-PV, idealiter wil ik de apparaten waar ik mijn verbruik van kan uitstellen (water-water warmtepomp met buffervaten, thuislaadpunt, wasmachine, droger, vaatwasser en hotfill boiler) (deferables) maximaal laten verbruiken als ik zelf opwek en mocht er nog aanvullend nodig zijn dan wanneer de prijs het laagste is (obs dynamische tarieven). Toen kwam ik op deze post uit. Zou dat theoretische mogelijk moeten zijn met EMHASS?

Groet en dank,

Ik denk dat dat wel kan, de vraag is denk ik meer hoeveel moeite het kost om zo'n systeem op te tuigen. Zowel EMHASS als Flexmeasures vind ik nog niet heel simpel voor thuisgebruik. Ik heb wat met EMHASS gespeeld, maar na een paar uurtjes was het wel duidelijk dat er nog wat meer tijd nodig is.

De AIO energy management Home assistent component lijkt me makkelijker te gebruiken. Ik zit nu aan iets redelijk simpels en deterministisch te denken om een WP aan te sturen. Bijvoorbeeld: De smart grid ingangen van de WP (uit, normaal, capacity1 (bv 120%), en capacity2 (bv 150%)), aansturen met HASS. Bij de hoogste prijs op de dag uit, bij de laagste prijs capacity 1, anders normaal (en evt bij veel PV beschikbaar capacity 2). De AIO energy management component kan hier wel iets bij betekenen.

[desalnietemin]

Thorsd schreef op zondag 30 maart 2025 @ 12:37:
[...]


Ik denk dat dat wel kan, de vraag is denk ik meer hoeveel moeite het kost om zo'n systeem op te tuigen. Zowel EMHASS als Flexmeasures vind ik nog niet heel simpel voor thuisgebruik. Ik heb wat met EMHASS gespeeld, maar na een paar uurtjes was het wel duidelijk dat er nog wat meer tijd nodig is.

De AIO energy management Home assistent component lijkt me makkelijker te gebruiken. Ik zit nu aan iets redelijk simpels en deterministisch te denken om een WP aan te sturen. Bijvoorbeeld: De smart grid ingangen van de WP (uit, normaal, capacity1 (bv 120%), en capacity2 (bv 150%)), aansturen met HASS. Bij de hoogste prijs op de dag uit, bij de laagste prijs capacity 1, anders normaal (en evt bij veel PV beschikbaar capacity 2). De AIO energy management component kan hier wel iets bij betekenen.

Hi @Thorsd , ik ben benieuwd, dat lijkt wel een goed plan inderdaad. Ik ben benieuwd hoe jij je eigen opwek goed hierin meeneemt.

Ik heb besloten om aan de slag te gaan met die flexmeasures aangezien er redelijk actief Development op is en toch nog wat eenvoudiger te doorgronden is dan EMHASS maar wel meer biedt dan die AIO energy management assistent component (omdat die laatste enkel prijs gebaseerd is en niet kijkt naar mijn eigen opgewekte zon-PV). Ik zal mijn ervaringen delen.

Groet

[Thorsd]

desalnietemin schreef op zondag 30 maart 2025 @ 13:20:
[...]


Hi @Thorsd , ik ben benieuwd, dat lijkt wel een goed plan inderdaad. Ik ben benieuwd hoe jij je eigen opwek goed hierin meeneemt.

Ik heb besloten om aan de slag te gaan met die flexmeasures aangezien er redelijk actief Development op is en toch nog wat eenvoudiger te doorgronden is dan EMHASS maar wel meer biedt dan die AIO energy management assistent component (omdat die laatste enkel prijs gebaseerd is en niet kijkt naar mijn eigen opgewekte zon-PV). Ik zal mijn ervaringen delen.

Groet

Ja, laat het even weten waar je uitkomt. Misschien met een link naar een flexmeasures topic . Ik ga voorlopig verder met de AIO integratie, PV staat op de AIO roadmap. Voorlopig is de PV opwek redelijk omgekeerd evenredig aan de dynamische prijzen, dus dat wil ik als benadering gebruiken.

Aansturing van de WP met de SG (smartgrid interface) door een Shelly Pro2 door HASS. Als HASS of de Shelly offline gaat gaan de uitgangen naar default door een script dat op de Shelly draait.

[RudolfR]

Er is nu ook een topic voor 'Day Ahead Optimizer':
Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[desalnietemin]

@RudolfR , dank voor het delen, die kende ik nog niet.

Inmiddels heb ik de AIO energy management Home assistent component draaien en schakelt mijn hotfill boiler o.b.v. de 5 goedkoopste dagprijzen. Maar verder is het heel beperkt aangezien de integratie enkel naar de ENTSO-E prijzen kijkt. Die Day Ahead Optimizer zit er uitgebreider uit maar toch weer een stuk gebruiksvriendelijker dan EMHASS of Flexmeasures. Ik ga ermee aan de slag en zal mijn bevindingen in het DAO topic posten.

Groet

[Bliksem B]

Weet iemand hoe EMHAS zich verhoudt tot jmcollin78/solar_optimizer: The Solar Optimizer integration for Home Assistant starts and stops your equipments depending on the Solar net production en PV / Solar Excess Optimizer: Auto-control appliances (wallbox, dish washer, heatpump, ...) based on excess solar power - Blueprints Exchange - Home Assistant Community?

[scruysberghs]

EMHASS kan ook kijken naar dynamische prijzen en doet ook machine learning predicties van je basis (niet stuurbaar) verbruik. Hiermee maakt die een 24uur (of langer als je meer data hebt) optimale planning voor al stuurbare vebruikers en moet je vervolgens zelf in home assuistant de automatins voorzien om aan de hand daarvan je toestellen aan te gaan sturen.

Solar optimiser kijkt enkel naar (verwachte) zonopbrengst en gaat aan de hand daarvan je toestellen aansturen.

[RudolfR]

@Bliksem B

Ik zie geen aansturing van een batterij, geloof ik.

[diamanten]

Met dank aan jullie heb ik het inmiddels draaien! 😀
Ik maak gebruik van open-meteo (forecast met interval van 15 minuten) en moest ondermeer de voorbeeld scripts aanpassen.
Documentatie zoveel mogelijk doorgenomen, maar heb toch een paar vragen:
1. Waarom dagelijks een dao draaien als een mpc meer actuele info oplevert? Of is een dao nodig om een mpc te voeden met specifieke input?
2. Ik heb 32 enphase micro omvormers, moet ik deze 32x invoeren of kan dat makkelijker? Ik gebruik nu de default instellingen voor de panelen.
3. Ik heb 2 thuisaccu’s: kan ik beide afzonderlijk invoeren of moet ik er 1 grote accu van maken?

[RudolfR]

1. Weet ik niet goed, doe ik ook. Volgens mij kan het ook met alleen de MPC.
2. Ik heb mijn panelen in solcast gezet en ik stuur de verwachtingen daarvan naar EMHASS
3. VZIW is er een geen mogelijkheid om meerdere batterijen te configureren.

[MarcoPolet]

diamanten schreef op zaterdag 14 juni 2025 @ 15:06:
Met dank aan jullie heb ik het inmiddels draaien! 😀
Ik maak gebruik van open-meteo (forecast met interval van 15 minuten) en moest ondermeer de voorbeeld scripts aanpassen.
Documentatie zoveel mogelijk doorgenomen, maar heb toch een paar vragen:
1. Waarom dagelijks een dao draaien als een mpc meer actuele info oplevert? Of is een dao nodig om een mpc te voeden met specifieke input?
2. Ik heb 32 enphase micro omvormers, moet ik deze 32x invoeren of kan dat makkelijker? Ik gebruik nu de default instellingen voor de panelen.
3. Ik heb 2 thuisaccu’s: kan ik beide afzonderlijk invoeren of moet ik er 1 grote accu van maken?

1. Ook ik weet dit niet precies, maar doe het ook, direct nadat de day-ahead nordpool prijzen bekend zijn gemaakt (zeg rond 13:30 's middags).
2. : als je in het configuratie scherm helemaal bovenaan, aan de rechterkant op de <> klikt, dan kun je de config ook bewerken in een soort text-editor. Dan kun je gemakkelijker bepaalde configs kopieren.
3. volgens mij idd ook niet. Je zou dit https://community.home-as...gement-for-home-assistant topic eens door kunnen spitten of daar de vraag stellen, is behoorlijk actief door o.a. de ontwikkelaars van EMHASS. Er is evt. ook nog een Discord channel.

[Sicco92]

Ik doe elk kwartier een nieuwe MPC en daarna gelijk een publish, zodat ik altijd met de meest actuele gegevens een voorspelling maak. Dat vond ik zelf het makkelijkste. Ik doe niet nog eens extra een DAO, dus dat is helemaal niet nodig. Heel eerlijk zou ik het verschil tussen een MPC en een DAO niet eens kunnen noemen, behalve dat een MPC volgens mij meer inputs slikt.

[diamanten]

Sicco92 schreef op zondag 15 juni 2025 @ 19:48:
Ik doe elk kwartier een nieuwe MPC en daarna gelijk een publish, zodat ik altijd met de meest actuele gegevens een voorspelling maak. Dat vond ik zelf het makkelijkste. Ik doe niet nog eens extra een DAO, dus dat is helemaal niet nodig. Heel eerlijk zou ik het verschil tussen een MPC en een DAO niet eens kunnen noemen, behalve dat een MPC volgens mij meer inputs slikt.

Dat leek mij dus ook en ga vanaf nu alleen maar de MPC om de x minuten draaien.

Wel een vervolgvraag: draai je die MPC de gehele dag door om het kwartier?
Ik zie nl diverse automations die deze optimalisatie alleen tussen XX.YY en ZZ.AA draaien. Het lijkt mij dat het zinvol is om de MPC gedurende de hele dag regelmatig te draaien. Zo heb je immers een zo actuele waarde van bijv. p_batt_forecast om je accu aan te sturen, of zie ik dat verkeerd?

[RudolfR]

@diamanten

Je kunt met regelmaat de MPC opnieuw uitvoeren, maar je kunt ook alleen een publish doen van de meest recente berekening.
Dat laatste moet volgens mij zelfs als de horizon van de MPC minder dan 5 periodes weg is.

Ik draai de MPC iedere minuut, voor de laatste actuele waardes van PV en p1, maar volgens mij is dat sub-optimaal, soms krijg ik daardoor onnodig veel aan/uit-schakelingen. (30 seconden opladen aan, bijv)

Ik heb geen EV of planbare deferrables, dus ik wil dat EMHASS snel reageert op veranderingen in verbruik en dat werkt niet echt goed.

[Sicco92]

diamanten schreef op maandag 16 juni 2025 @ 15:58:
[...]

Dat leek mij dus ook en ga vanaf nu alleen maar de MPC om de x minuten draaien.

Wel een vervolgvraag: draai je die MPC de gehele dag door om het kwartier?
Ik zie nl diverse automations die deze optimalisatie alleen tussen XX.YY en ZZ.AA draaien. Het lijkt mij dat het zinvol is om de MPC gedurende de hele dag regelmatig te draaien. Zo heb je immers een zo actuele waarde van bijv. p_batt_forecast om je accu aan te sturen, of zie ik dat verkeerd?

Ja, de hele dag door inderdaad. In de nacht krijg ik ook nieuwe voorspellingen binnen van Solcast, dus dan kan die daar gelijk mee rekenen. Voor nu nog niet heel erg relevant, maar voor na 1 januari 2027 kan dat wel verschillen geven voor de gehele voorspelling (bijv. 's nachts nog stroom dumpen als de accu te vol zit en er plotseling toch een zonnige dag voorspeld wordt).
Daarnaast voor een kwartier gekozen zodat ik makkelijk over kan naar kwartierprijzen, als die ooit aangeboden worden.

Op mijn NUC duurt de MPC-berekening ongeveer 1 minuut trouwens, dus ik trap ze altijd 50 seconden voor het kwartier af zodat de nieuwe waarden gepublished worden net als het nieuwe kwartier start.

[diamanten]

RudolfR schreef op maandag 16 juni 2025 @ 16:32:
@diamanten

Je kunt met regelmaat de MPC opnieuw uitvoeren, maar je kunt ook alleen een publish doen van de meest recente berekening.
Dat laatste moet volgens mij zelfs als de horizon van de MPC minder dan 5 periodes weg is.

Ik draai de MPC iedere minuut, voor de laatste actuele waardes van PV en p1, maar volgens mij is dat sub-optimaal, soms krijg ik daardoor onnodig veel aan/uit-schakelingen. (30 seconden opladen aan, bijv)

Ik heb geen EV of planbare deferrables, dus ik wil dat EMHASS snel reageert op veranderingen in verbruik en dat werkt niet echt goed.

ok, ik draai de mpc nu elke 10 minuten. Ik probeer de cost function te doorgronden, dat is toch een indicatie van de optimalisatie: negatief is goed? Mijn grafiek van sensor.total_cost_fun_value zit er zo uit:

Dus pas 's avonds een gunstige cost function. Kunnen jullie een dergelijke grafiek ook plaatsen?

[MarcoPolet]

Negatief = negatief, dan kost het geld, positief levert geld op

[diamanten]

MarcoPolet schreef op zaterdag 21 juni 2025 @ 08:13:
Negatief = negatief, dan kost het geld, positief levert geld op

Ok, dank.
Ik heb ook nog verder gezocht in het HA Emhass forum:
cost_profit = Σ (P_grid_pos * unit_load_cost) - Σ (P_grid_neg * unit_prod_price)

Waarbij:
P_grid_pos = verbruik uit het net
P_grid_neg = teruglevering aan het net

Als de opbrengsten (P_grid_neg * unit_prod_price) groter zijn dan de kosten (P_grid_pos * unit_load_cost), dan wordt cost_profit negatief.

Nb. het maakt mij niet uit wie gelijk heeft, alleen wil ik het snappen...

[ Voor 53% gewijzigd door diamanten op 21-06-2025 14:11 ]

[MarcoPolet]

diamanten schreef op zaterdag 21 juni 2025 @ 13:56:
[...]

Ok, dank.
Ik heb ook nog verder gezocht in het HA Emhass forum:
cost_profit = Σ (P_grid_pos * unit_load_cost) - Σ (P_grid_neg * unit_prod_price)

Waarbij:
P_grid_pos = verbruik uit het net
P_grid_neg = teruglevering aan het net

Als de opbrengsten (P_grid_neg * unit_prod_price) groter zijn dan de kosten (P_grid_pos * unit_load_cost), dan wordt cost_profit negatief.

Nb. het maakt mij niet uit wie gelijk heeft, alleen wil ik het snappen...

Het is te warm om die formules na te rekenen maar als ik de tabel in de EMHASS website bekijk, dan zie je daar duidelijk (bij mij in elk geval) dat als je te weinig productie hebt, de cost_fun_profit negatief is, en later op de dag, als er meer productie dan gebruik is, de cost_fun_profit positief wordt.

[diamanten]

MarcoPolet schreef op zaterdag 21 juni 2025 @ 15:49:
[...]

Het is te warm om die formules na te rekenen maar als ik de tabel in de EMHASS website bekijk, dan zie je daar duidelijk (bij mij in elk geval) dat als je te weinig productie hebt, de cost_fun_profit negatief is, en later op de dag, als er meer productie dan gebruik is, de cost_fun_profit positief wordt.

[Afbeelding]

Ok, ik zie inderdaad hetzelfde in mijn grafiek, alleen geen grote negatieve waarden (behalve -0.00 als mijn batterij bijspringt). Dat zou dus optimaal zijn voor mijn situatie?

[ Voor 3% gewijzigd door diamanten op 22-06-2025 13:18 ]

[MarcoPolet]

Welk doel heb je ingesteld in de configuratie? Bovenin bij de cost function. Ik heb die op profit staan, maar kan bv. ook op self-consumption. Als je dat laatste doet dan denk ik wel dat de sturing van EMHASS te langzaam is, je zou dat dan misschien moeten combineren met je accu zelf, dat die in de gaten houdt (met bv. CT klemmen) wat je gebruik/productie is, en zich daar op aanpast.

[diamanten]

MarcoPolet schreef op zondag 22 juni 2025 @ 14:01:
Welk doel heb je ingesteld in de configuratie? Bovenin bij de cost function. Ik heb die op profit staan, maar kan bv. ook op self-consumption. Als je dat laatste doet dan denk ik wel dat de sturing van EMHASS te langzaam is, je zou dat dan misschien moeten combineren met je accu zelf, dat die in de gaten houdt (met bv. CT klemmen) wat je gebruik/productie is, en zich daar op aanpast.

Doel is bij mij self-consumption. Dit werkt idd (nog) niet ideaal. Het verloop is vrij grillig en naar mijn idee wordt er (ook wel eens) geladen als er te weinig zon is of net andersom. De grafiek toont de sensor.p_batt_forecast waarden van afgelopen uren.

De MPC draait elke 5 minuten. Mijn accu kan ik wel via HA aansturen (koppeling met P1-meter die om de 10 seconden een update stuurt). Het exact volgen van sensor.p_batt_forecast waarde heb ik nu via scripts geregeld, maar ik denk dat het beter (en ook makkelijker) is als de accu NoM gaat werken bij een waarde van sensor.p_batt_forecast ongelijk 0. Dus eigenlijk een binaire mode: doe niets bij sensor.p_batt_forecast= 0 of als sensor.p_batt_forecast ongeljk 0: ga NoM laden/ontladen.
In onderstaande screenshot de belangrijkste parameters voor de batterij die bij elke MPC worden meegestuurd.

Hoe hebben jullie dit ingeregeld?

[ Voor 26% gewijzigd door diamanten op 23-06-2025 12:38 ]

[scruysberghs]

RudolfR schreef op zaterdag 14 juni 2025 @ 19:48:
1. Weet ik niet goed, doe ik ook. Volgens mij kan het ook met alleen de MPC.
2. Ik heb mijn panelen in solcast gezet en ik stuur de verwachtingen daarvan naar EMHASS
3. VZIW is er een geen mogelijkheid om meerdere batterijen te configureren.

optie voor meerdere batterijen is er momenteel niet. Ik heb ze hier nu opgeteld (capaciteit en vermogens) en splits wat emhass berekend voor de batterij dan weer uit om beide batterijen apart aan te sturen met wat logica (prioriteit tussen stekkerbatterij en eentje met hybride omvormer, zorgen dat beide batterij wat gelijkmatig gebruikt worden maar dat er rekening gehouden wordt met mindere efficiëntie bij lage vermogens enz) .

2 aparte batterijen in emhass zou idd wel beter zijn.
https://github.com/davidusb-geek/emhass/discussions/544

[scruysberghs]

diamanten schreef op maandag 23 juni 2025 @ 12:26:
[...]

Doel is bij mij self-consumption. Dit werkt idd (nog) niet ideaal. Het verloop is vrij grillig en naar mijn idee wordt er (ook wel eens) geladen als er te weinig zon is of net andersom. De grafiek toont de sensor.p_batt_forecast waarden van afgelopen uren.
[Afbeelding]
De MPC draait elke 5 minuten. Mijn accu kan ik wel via HA aansturen (koppeling met P1-meter die om de 10 seconden een update stuurt). Het exact volgen van sensor.p_batt_forecast waarde heb ik nu via scripts geregeld, maar ik denk dat het beter (en ook makkelijker) is als de accu NoM gaat werken bij een waarde van sensor.p_batt_forecast ongelijk 0. Dus eigenlijk een binaire mode: doe niets bij sensor.p_batt_forecast= 0 of als sensor.p_batt_forecast ongeljk 0: ga NoM laden/ontladen.
In onderstaande screenshot de belangrijkste parameters voor de batterij die bij elke MPC worden meegestuurd.
[Afbeelding]
Hoe hebben jullie dit ingeregeld?

ik bereken met een template een batterij control mode, deze is ofwel forcible charge, forcible discharge, do nothing of follow grid (NoM). Voor die laatste mode gebruik ik dan een aparte automatisatie om die NoM sturing te doen.
Verder run ik hier de mpc optimiser elke 2 minuten.

[diamanten]

scruysberghs schreef op zaterdag 28 juni 2025 @ 12:04:
[...]

ik bereken met een template een batterij control mode, deze is ofwel forcible charge, forcible discharge, do nothing of follow grid (NoM). Voor die laatste mode gebruik ik dan een aparte automatisatie om die NoM sturing te doen.
Verder run ik hier de mpc optimiser elke 2 minuten.

Interessant, zou je die template voor de batterij control kunnen plaatsen? Ik ben benieuwd wanneer jij kiest voor forcible charge/discharge etc.

[scruysberghs]

diamanten schreef op zaterdag 28 juni 2025 @ 16:34:
[...]

Interessant, zou je die template voor de batterij control kunnen plaatsen? Ik ben benieuwd wanneer jij kiest voor forcible charge/discharge etc.

Momenteel gebruik ik onderstaande template, aan de lijst met ongebruikte waarden bovenaan kan je zien dat ik er al wat mee gespeeld heb om het helemaal te krijgen zoals ik wil. Oorspronkelijk probeerde ik de echte waarden van de sensoren er mee in te brengen maar nu mpc elke 2 minuten loopt volg ik toch vooral wat emhass berekend. Enkel voor NoM sturing gebrik ik dan sensorwaarden van de p1 meter of de NoM functie van de batterij als die bestaat (=als batterij een eigen grid meter heeft)

code:

# ----------------
# TEMPLATE SENSORS
# ----------------
template:
  - sensor:
      - name: "EMHASS batcontrol mode"
        unique_id: emhass_batcontrol_mode
        icon: mdi:battery-heart-outline
        state: >
          {# Waarden ophalen #}
          {% set p_hybrid = states('sensor.mpc_p_hybrid_inverter')| float(0) %}
          {% set p_batt = states('sensor.mpc_p_batt_forecast') | float(0) %}
          {% set p_load = states('sensor.mpc_p_load_forecast') | float(0) %}
          {% set p_grid = states('sensor.mpc_p_grid_forecast') | float(0) %}
          {% set p_curtail = states('sensor.mpc_p_pv_curtailment') | float(0) %}
          {% set export = states('sensor.sec_pac_power_to_grid') | float(0) %}
          {% set deferrables = states('sensor.mpc_p_deferrable0') | float(0)
            + states('sensor.mpc_p_deferrable1') | float(0)
            + states('sensor.mpc_p_deferrable2') | float(0)
            + states('sensor.mpc_p_deferrable3') | float(0) %}
          {% set surplus = states('sensor.sec_surplus_power') | float(0) %}
          {% set max_captar = states('input_number.sec_pac_doel_limiet_capaciteitspiek') | float(0) %}
          {% set captar15 = states('sensor.sec_pac_extrapoleer_captar_kwartier') | float(0) %}
          {# Bepaal modus #}
          {% set mode = 'Do Nothing' %}
          {# 1. Curtailment actief: batterij niet gebruiken zodat PV niet afgeschakeld moet worden #}
          {% if p_curtail > 20 %}
            {% set mode = 'Do Nothing' %}
          {# 2. Netverbruik voorspeld als 0 → batterij mag gedrag afstemmen op netbalans #}
          {% elif p_grid == 0 %}
            {% set mode = 'Follow Grid' %}
          {# 3. Netverbruik overschrijdt capaciteitstarieflimiet → piek afvlakken #}
          {% elif p_grid > max_captar %}
            {% set mode = 'Peak Shaving' %}
          {# 4. EMHASS voorspelt laden → afdwingen #}
          {% elif p_batt < -10 %}
            {% set mode = 'Forcible Charge' %}
          {# 5. EMHASS voorspelt ontladen → afdwingen #}
          {% elif p_batt > 10 %}
            {% set mode = 'Forcible Discharge' %}
          {# 6. Standaardactie #}
          {% else %}
            {% set mode = 'Do Nothing' %}
          {% endif %}

          {{ mode }}

Dqt geeft dqn zoiets:


En met de prijzen van vandaag maakt emhass er dit van:


Heb hier nu wel calculate_curtailment uitstaan in emhass omdat ik nog groene stroom certificaten krijg op deze installatie van 45c€/kWh. Anders zou de planning er wat anders uitzien

[diamanten]

scruysberghs schreef op zondag 29 juni 2025 @ 10:35:
[...]


Momenteel gebruik ik onderstaande template, aan de lijst met ongebruikte waarden bovenaan kan je zien dat ik er al wat mee gespeeld heb om het helemaal te krijgen zoals ik wil. Oorspronkelijk probeerde ik de echte waarden van de sensoren er mee in te brengen maar nu mpc elke 2 minuten loopt volg ik toch vooral wat emhass berekend. Enkel voor NoM sturing gebrik ik dan sensorwaarden van de p1 meter of de NoM functie van de batterij als die bestaat (=als batterij een eigen grid meter heeft)

code:

# ----------------
# TEMPLATE SENSORS
# ----------------
template:
  - sensor:
      - name: "EMHASS batcontrol mode"
        unique_id: emhass_batcontrol_mode
        icon: mdi:battery-heart-outline
        state: >
          {# Waarden ophalen #}
          {% set p_hybrid = states('sensor.mpc_p_hybrid_inverter')| float(0) %}
          {% set p_batt = states('sensor.mpc_p_batt_forecast') | float(0) %}
          {% set p_load = states('sensor.mpc_p_load_forecast') | float(0) %}
          {% set p_grid = states('sensor.mpc_p_grid_forecast') | float(0) %}
          {% set p_curtail = states('sensor.mpc_p_pv_curtailment') | float(0) %}
          {% set export = states('sensor.sec_pac_power_to_grid') | float(0) %}
          {% set deferrables = states('sensor.mpc_p_deferrable0') | float(0)
            + states('sensor.mpc_p_deferrable1') | float(0)
            + states('sensor.mpc_p_deferrable2') | float(0)
            + states('sensor.mpc_p_deferrable3') | float(0) %}
          {% set surplus = states('sensor.sec_surplus_power') | float(0) %}
          {% set max_captar = states('input_number.sec_pac_doel_limiet_capaciteitspiek') | float(0) %}
          {% set captar15 = states('sensor.sec_pac_extrapoleer_captar_kwartier') | float(0) %}
          {# Bepaal modus #}
          {% set mode = 'Do Nothing' %}
          {# 1. Curtailment actief: batterij niet gebruiken zodat PV niet afgeschakeld moet worden #}
          {% if p_curtail > 20 %}
            {% set mode = 'Do Nothing' %}
          {# 2. Netverbruik voorspeld als 0 → batterij mag gedrag afstemmen op netbalans #}
          {% elif p_grid == 0 %}
            {% set mode = 'Follow Grid' %}
          {# 3. Netverbruik overschrijdt capaciteitstarieflimiet → piek afvlakken #}
          {% elif p_grid > max_captar %}
            {% set mode = 'Peak Shaving' %}
          {# 4. EMHASS voorspelt laden → afdwingen #}
          {% elif p_batt < -10 %}
            {% set mode = 'Forcible Charge' %}
          {# 5. EMHASS voorspelt ontladen → afdwingen #}
          {% elif p_batt > 10 %}
            {% set mode = 'Forcible Discharge' %}
          {# 6. Standaardactie #}
          {% else %}
            {% set mode = 'Do Nothing' %}
          {% endif %}

          {{ mode }}

Dqt geeft dqn zoiets:
[Afbeelding]

En met de prijzen van vandaag maakt emhass er dit van:
[Afbeelding]

Heb hier nu wel calculate_curtailment uitstaan in emhass omdat ik nog groene stroom certificaten krijg op deze installatie van 45c€/kWh. Anders zou de planning er wat anders uitzien

OK, dank voor je info.
Jij stuurt dus niet alleen met p_batt, maar ook met p_grid en p_curtailment.
Wat doen jouw scripts 'Peak Shaving' en 'Follow Grid' precies qua aansturing van je batterij?
Ik stuur momenteel alleen met p_batt, maar ben nog aan het zoeken naar de optimale config.

[scruysberghs]

diamanten schreef op maandag 30 juni 2025 @ 08:26:
[...]

OK, dank voor je info.
Jij stuurt dus niet alleen met p_batt, maar ook met p_grid en p_curtailment.
Wat doen jouw scripts 'Peak Shaving' en 'Follow Grid' precies qua aansturing van je batterij?
Ik stuur momenteel alleen met p_batt, maar ben nog aan het zoeken naar de optimale config.

Follow grid zet een automatisering aan die NoM sturing doet. Is wat afhankelijk van omvormer of batterij. Ofwel een loop elke paar seconden die (ont)laadvermogen zet ofwel aanezetten van en NoM functie van omvormer of batterij zelf als die zijn eigen grid/energie meter heeft.

Peak Shaving doet een extrapolatie van het het verbruik naar het einde van het lopende kwartier. Als dat dreigt over een ingestelde limiet te gaan gaat die de batterij inschakelen. Deze overruled ook steeds alle andere sturingen

[diamanten]

scruysberghs schreef op maandag 30 juni 2025 @ 13:09:
[...]


Follow grid zet een automatisering aan die NoM sturing doet. Is wat afhankelijk van omvormer of batterij. Ofwel een loop elke paar seconden die (ont)laadvermogen zet ofwel aanezetten van en NoM functie van omvormer of batterij zelf als die zijn eigen grid/energie meter heeft.

Peak Shaving doet een extrapolatie van het het verbruik naar het einde van het lopende kwartier. Als dat dreigt over een ingestelde limiet te gaan gaat die de batterij inschakelen. Deze overruled ook steeds alle andere sturingen

Wederom dank. Ik probeer eea verder te doorgronden, vandaar mijn vervolgvragen ( )
Hoe werk je met 'curtailment'?
De EMHASS-manual is niet bijster uitgebreid hierover:

code:

compute_curtailment: Set to True to compute a special PV curtailment variable (Default False).

Vraag: welke waarden kan deze variabele krijgen? Bij mij is deze nog nul (gisteren geactiveerd dus op True gezet).
Jij activeert een script als de waarde meer dan 20 is. Waarop is dat gebaseerd?
Ik heb zelf een Enphase PV. Ik kan de centrale unit (Envoy) aan of uitzetten met een HA-switch. Zou ik deze switch 'off' kunnen zetten als curtailment > 0 is?

[RudolfR]

@diamanten

Volgens mij is het evengoed een Wattage voor de hoeveelheid power die over is.
EMHASS heeft daar niks bruikbaars voor kunnen bedenken, geen gebruiker/batterij, dus tenzij je je omvormer knijpt gaat dat het net op.
Omvormer uitzetten is misschien zonde.

[diamanten]

RudolfR schreef op maandag 30 juni 2025 @ 18:37:
@diamanten

Volgens mij is het evengoed een Wattage voor de hoeveelheid power die over is.
EMHASS heeft daar niks bruikbaars voor kunnen bedenken, geen gebruiker/batterij, dus tenzij je je omvormer knijpt gaat dat het net op.
Omvormer uitzetten is misschien zonde.

Ja, afknijpen is beter. Helaas kan dat niet met mijn Enphase PV (Envoy standard non-metered).

[ Voor 3% gewijzigd door diamanten op 30-06-2025 19:27 ]

[diamanten]

Misschien voor jullie ook interessant en uiteraard voor verbetering vatbaar: grafieken zijn mooi, maar ik heb mbv chatgtp een sensor gemaakt met korte uitleg van de actuele emhass batterij actie.


Hierbij de code en graag jullie suggesties ter verbetering:

code:

- sensor:
    - name: "EMHASS Uitleg Batterijactie Simpel"
      unique_id: emhass_batt_action_reason_simpel
      state: >
        {% set batt = states('sensor.p_batt_forecast') | float(0) %}
        {% set soc = states('input_number.dummy_soc') | float(0) %}
        {% set min_soc = states('input_number.min_soc') | float(0) %}
        {% set max_soc = states('input_number.max_soc') | float(100) %}
        {% set net_power = states('sensor.gecombineerde_vermogenssensor') | float(0) %}

        {% if batt == 0 %}
          "⏳ Geen batterijactie gepland."

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

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

        {% elif batt > 0 %}
          {% if net_power < -50 %}
            "🔋 Ontladen: injectie naar net."
          {% elif net_power >= -50 and net_power <= 50 %}
            "🔋 Ontladen: in balans met verbruik."
          {% else %}
            "🔋 Ontladen: batterij dekt netverbruik."
          {% endif %}

        {% elif batt < 0 %}
          {% if net_power < -50 %}
            "⚡ Laden: eigen overschot benut."
          {% elif net_power >= -50 and net_power <= 50 %}
            "⚡ Laden: in balans met verbruik."
          {% else %}
            "⚡ Laden: via netstroom."
          {% endif %}

        {% else %}
          "⚖️ Geen batterijactie."
        {% endif %}

[ Voor 3% gewijzigd door diamanten op 02-07-2025 16:43 ]

[RudolfR]

@diamanten

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

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

YAML:

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

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

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

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

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

[diamanten]

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

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

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

YAML:

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

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

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

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

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

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

[Xoliul]

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

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

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

Heb ook geen thuisbatterij, als dat uitmaakt.

[RudolfR]

@Xoliul

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

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

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

[Xoliul]

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

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

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

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

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

[Torch1969]

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


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

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

[RudolfR]

Inmiddels een andere aanpak gekozen met EMHASS.

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

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

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

[diamanten]

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

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

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

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

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

[RudolfR]

@diamanten

Ja, dat is het inderdaad.

Ik heb net als jij een template sensor:

YAML:

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

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

YAML:

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

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

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

YAML:

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

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

[diamanten]

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

Ja, dat is het inderdaad.

Ik heb net als jij een template sensor:

YAML:

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

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

YAML:

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

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

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

YAML:

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

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

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

[dennisdew16]

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

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

code:

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

[MarcoPolet]

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

[dennisdew16]

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

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

[RudolfR]

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

[dennisdew16]

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

[MarcoPolet]

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

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

[dennisdew16]

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

[MarcoPolet]

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

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

Wat eerder al werd genoemd, het is een flinke leercurve

[RudolfR]

@dennisdew16
Dit idee:

code:

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

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

[Sicco92]

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

Als voorbeeld, hier zijn een paar van mijn rest_commands:

YAML:

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

Ik vind het ook veel leesbaarder

[MarcoPolet]

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

[diamanten]

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

[RudolfR]

@diamanten

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

[Sicco92]

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

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

YAML:

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

[dennisdew16]

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

code:

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

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

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

[MarcoPolet]

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

[dennisdew16]

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

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

code:

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

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

[RudolfR]

@dennisdew16

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

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

code:

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

[dennisdew16]

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

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

[RudolfR]

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

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


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

Hier is alleen een pv_power_forecast voldoende voor een goed resultaat:

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

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

[dennisdew16]

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

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

code:

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

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

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

[RudolfR]

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

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

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

[diamanten]

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

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

YAML:

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

Ik zat dit ook eens te bekijken:

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

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

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

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

[cnoobie]

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

[diamanten]

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

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

[Torch1969]

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

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

[cnoobie]

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

[Xoliul]

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

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

[Sicco92]

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

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

[Teun_2]

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

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

[zaphod_b]

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

code:

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

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

code:

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

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

code:

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

Iemand die dit werkend heeft en de correcte config heeft?

[RudolfR]

@zaphod_b

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

[zaphod_b]

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

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

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

[ruub26]

Zou je je config kunnen delen?

[RudolfR]

@zaphod_b

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

JSON:

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

[ZatarraNL]

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

[RudolfR]

@ZatarraNL

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

[MarcoPolet]

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

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

[ZatarraNL]

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

Nog beginnertips?

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

[vincent_1971]

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

[hemertje]

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

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

[ZatarraNL]

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


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

Dank voor de tip. Ga ik eens goed bekijken.

[ZatarraNL]

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

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

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

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

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

[RudolfR]

@ZatarraNL

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

YAML:

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

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

[diamanten]

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

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

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

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

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

code:

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

[MarcoPolet]

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

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

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

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

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

[Sicco92]

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

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

Dit is bijvoorbeeld het schema voor vanochtend:

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

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

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

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

JSON:

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

En de parameters die ik naar EMHASS stuur:

YAML:

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

[MarcoPolet]

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

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

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

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

Beide worden regelmatig door de ontwikkelaars bezocht en vragen beantwoord.

[Sicco92]

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

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

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

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

Beide worden regelmatig door de ontwikkelaars bezocht en vragen beantwoord.

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

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

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

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