:fill(white):strip_exif()/i/2006976478.jpeg?f=thumbmini)
Nibe F1145-15 EXP | PCM42 koeling | KV300 buffervat vloerverwarming | VPA300 boilervat | UKV20 500L buffervat zwembad + ELK9(kW) elek.backup element | POOL40 | 80L E-boiler | NibeGW voor HASS MODBUS koppeling | Zon-PV: 23,49 kWP + SE25K Solaredge omvormer
/u/189401/crop5a5e7beb70a42_cropped.png?f=community)
:strip_icc():strip_exif()/u/2145230/crop679ba1e673748_cropped.jpg?f=community)
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).:
[...]
Dat leek mij dus ook en ga vanaf nu alleen maar de MPC om de x minuten draaien.
Wel een vervolgvraag:
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?
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.
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:
:no_upscale():strip_icc():strip_exif()/f/image/cCrOz3kFYnPVCypYzrqiyKJx.jpg?f=user_large)
Dus pas 's avonds een gunstige cost function. Kunnen jullie een dergelijke grafiek ook plaatsen?
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.:strip_exif()/f/image/yCE1qQNmKa7z1XEMVn3l13nR.png?f=user_large)
:
[...]
Het is te warm om die formules na te rekenen
[Afbeelding]
:no_upscale():strip_icc():strip_exif()/f/image/0tyDRKdbElP3mviFxq2wo2q2.jpg?f=user_large)
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 ]
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.
:no_upscale():strip_icc():strip_exif()/f/image/7jBHEEL3ZFAnZ28q0w92JTfD.jpg?f=user_large)
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.
:no_upscale():strip_icc():strip_exif()/f/image/slp1XFCuwiHi1xUX81QlT39X.jpg?f=user_large)
Hoe hebben jullie dit ingeregeld?
[ Voor 26% gewijzigd door diamanten op 23-06-2025 12:38 ]
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| # ----------------
# 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:
:strip_exif()/f/image/h0Wr0YqQ75NPTDyvbstmbwy7.png?f=user_large)
En met de prijzen van vandaag maakt emhass er dit van:
:strip_exif()/f/image/ayAbNoKgRhVeMVfgy3LP7DPo.png?f=user_large)
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
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:
1
| 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?
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.
:strip_exif()/f/image/bq1gi8SV7eMZ6mVz6hkiarfC.jpg?f=fotoalbum_large)
Hierbij de code en graag jullie suggesties ter verbetering:
:no_upscale():strip_icc():strip_exif()/f/image/bq1gi8SV7eMZ6mVz6hkiarfC.jpg?f=user_large)
Hierbij de code en graag jullie suggesties ter verbetering:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| - 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 ]
Grappig, we zitten grotendeels op dezelfde lijn (althans volgens Chatgtp):
:strip_exif()/f/image/K64YxyCDyrRJCXHIH2pDWMQE.png?f=user_large)
Ik heb de modus template toegevoegd en ben nu aan het proefdraaien (zowel met vaste als dynamische tarieven).
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.
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.
:strip_exif()/f/image/T83aB4abH0Q7XTYHrMaoBzV4.png?f=user_large)
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
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.
/f/image/zGtK05cdpSPtSNeWwaRbUwvS.png?f=fotoalbum_large)
:strip_exif()/f/image/zGtK05cdpSPtSNeWwaRbUwvS.png?f=user_large)
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:
Ik vind het ook veel leesbaarder
Als voorbeeld, hier zijn een paar van mijn rest_commands:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| 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
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?
:strip_exif()/f/image/yB4rCf0Gef6pbnGnt3DE5ZuV.jpg?f=fotoalbum_large)
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?
:no_upscale():strip_icc():strip_exif()/f/image/yB4rCf0Gef6pbnGnt3DE5ZuV.jpg?f=user_large)
:strip_icc():strip_exif()/u/685142/crop66d0254153c6a_cropped.jpg?f=community)
Gasloos 2019 + WP Panasonic H-serie 7kW + 300 liter boilervat + PV 12.415Wp + Home Assistant + Hyundai Ioniq 6 First Edition + Zaptec laadpaal
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:
/f/image/VL9GYLbYP4O3ci7JJYBkgmwN.png?f=fotoalbum_large)
In de bovenste grafiek is de lichtblauwe lijn bij 1000W mijn warmtepomp. Er zitten 2 spikes, eentje om 17:00 en eentje om 18:45. Die wil ik dus weg hebben.
Ik heb geprobeerd om de set_deferrable_startup_penalty op een hoog getal te zetten. Dat lijkt die te negeren. Ook set_deferrable_load_single_constant op true lijkt niks te doen.
Ik heb ook geprobeerd om nominal_power_of_deferrable_loads te verlagen (van 2500W naar 1000W). Dat lijkt nog het meeste effect te hebben, maar het gaat niet helemaal weg. Daarnaast kan mijn warmtepomp meer verbruiken dan die 1000W, en dat wordt dan niet goed meegenomen in EMHASS.
Heeft iemand dit al goed werkend? Zo ja, zou je je config en parameters willen delen?
Ter info, hier mijn config (de 4e deferrable load is de warmtepomp):
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:
:strip_exif()/f/image/VL9GYLbYP4O3ci7JJYBkgmwN.png?f=user_large)
In de bovenste grafiek is de lichtblauwe lijn bij 1000W mijn warmtepomp. Er zitten 2 spikes, eentje om 17:00 en eentje om 18:45. Die wil ik dus weg hebben.
Ik heb geprobeerd om de set_deferrable_startup_penalty op een hoog getal te zetten. Dat lijkt die te negeren. Ook set_deferrable_load_single_constant op true lijkt niks te doen.
Ik heb ook geprobeerd om nominal_power_of_deferrable_loads te verlagen (van 2500W naar 1000W). Dat lijkt nog het meeste effect te hebben, maar het gaat niet helemaal weg. Daarnaast kan mijn warmtepomp meer verbruiken dan die 1000W, en dat wordt dan niet goed meegenomen in EMHASS.
Heeft iemand dit al goed werkend? Zo ja, zou je je config en parameters willen delen?
Ter info, hier mijn config (de 4e deferrable load is de warmtepomp):
En de parameters die ik naar EMHASS stuur:
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:
:strip_exif()/f/image/jw0Ol8qyyuVck9AALd96UgXU.png?f=user_large)
Tussen 2:30 en 5:30 zou de warmtepomp aan moeten staan, wat voor vannacht inderdaad een mooi schema is. Helaas staat er weer een stom kwartiertje tussen waarop de warmtepomp uit zou moeten staan, van 3:30-3:45. Dat is het duurste kwartier in de reeks, maar het verschil met het een-na-duurste kwartier is 0,001 euro. Een startup penalty zou daar gewoon 1 run van maken, maar die optie lijkt genegeerd te worden.
Die links had ik al gevonden, maar er lijkt nog weinig met de thermal_battery optie gespeeld te worden. Ik zal eens op het HA forum posten. Thanks!
emhass_dayahead_optim: "curl -i -H \"Content-Type:application/json\" -X POST -d '{}' http://192.168.1.200:5000/action/dayahead-optim" Het zat inderdaad in de 'localhost' .. en ja je kan een breuk zoeken.
