Acties:
  • +5 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online

EMHASS - Energy Management for Home Assistant

Introductie
EMHASS is een tool voor het optimaliseren van je energieverbruik.
Op basis van diverse parameters en wiskundige berekeningen geeft het systeem aan wanneer apparaten (zgn Deferrables) het beste kunnen worden ingeschakeld, op basis van de energieprijs en het aanbod van de eigen PV-installatie.

Afbeeldingslocatie: https://tweakers.net/i/2Tkqhr-9Kr_lgpfEehpQ55l7vHg=/800x/filters:strip_exif()/f/image/UrV2rCzLKC8Gg01dequWgpw1.png?f=fotoalbum_large

Doel van dit topic is om te helpen bij het configureren en inspiratie op te doen van anderen die hetzelfde doel hebben. De documentatie van EMHASS bevat een hoop informatie, maar schrikt daardoor ook wel af.
Gebruik
EMHASS is een python applicatie, die ook beschikbaar is gemaakt als add-on.
Er is een webinterface met een aantal knoppen en het resultaat van de laatste berekeningen. Indien gewenst kunnen daar wat parameters worden ingegeven en kan er wat worden geëxperimenteerd met de verschillende optimalisaties, het resultaat is direct te zien in de grafieken.

Voor “productie” kan e.e.a. worden bediend via automatiseren en automatische REST calls.

Uitleg terminologie

Deferrables
Bij ‘deferrables’ kun je denken aan een warmtepompboiler of een EV kunnen zo worden uitgespreid over de dag, om optimaal gebruik te maken van de beschikbare zonne-energie, dynamische tarieven en een evt. batterij.

Van deferrables kun je aangeven of ze als ‘semi-continuous’ beschouwd moeten worden of dat de belasting nog enigszins regelbaar is.

Een deferrable zou ook een wasmachine of een droger kunnen zijn, maar hoe je deze verbruikspatronen erin krijgt is mij nog niet duidelijk.

Algoritmes

EMHASS kan op verschillende manieren een energieplan voor je maken, door het aanroepen van een REST API. Met behulp van een publish-data kan EMHASS de berekende waarden doorgeven aan Home Assistant en hier kun je op acteren door je warmtepompboiler in of uit te schakelen, of door meer of minder power naar je thuisbatterij of EV te sturen.

https://emhass.readthedoc...#the-emhass-optimizations
Perfect optim
Een model op basis van alleen de historische gegevens. Alsof vandaag exact gelijk zal zijn aan de dag ervoor.
Dayahead-optim
Een plan voor de komende 24 uur op basis van de weersvooruitzichten, energieprijzen en het verwachte verbruik.

Vaak aangevuld met de MPC hieronder. omdat de betrouwbaarheid van de forecasts mogelijk niet helemaal klopt, waardoor de voorspelling steeds verder gaat afwijken van de werkelijkheid.
Naive MPC optim
Als aanvulling op de dayahead-optimization kan met regelmaat een nieuwe MPC-optimalisatie worden uitgevoerd.

Daarin is nog een plek voor de waardes alpha en beta. Deze bepalen het gewicht van de forecasts t.o.v. de actuele waarde.

Beide zijn standaard 0.5.

alpha: Het gewicht van de forecast. "A weight for the forecast data side"

beta: Het gewicht van de hudige meting. "A weight for the current/real values side"

https://emhass.readthedoc...rrent-values-in-forecasts
Machine-learning
Een model dat op basis van veel historische data voorspellingen leert maken over de toekomst.
Cost functions
EMHASS kan met diverse doelen optimaliseren.

* Winst
* Eigen verbruik

Integratie met Home Assistant

Via REST calls van EMHASS kunnen de diverse optimalisaties worden aangeroepen.
Een speciale call ‘publish-data’ stuurt de actuele waarden van de optimalisatie naar Home Assistant.
Home Assistant kan dan het opladen van je EV starten, of de batterij laden, met een automation.
Shell Commands
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
  emhass_perfect_optim: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/perfect-optim
  emhass_dayahead_optim: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/dayahead-optim
  emhass_naive_mpc: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/naive-mpc-optim
  emhass_publish_data: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/publish-data
  emhass_ml_model_fit: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/forecast-model-fit
  emhass_ml_model_predict: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/forecast-model-predict
  emhass_ml_model_tune: >
    curl -i -H "Content-Type:application/json" -X POST -d '{{payload}}' http://localhost:5000/action/forecast-model-ptune



Omdat shell commando’s niet te herladen zijn zonder Home Assistant te herstarten heb ik de payload als variabele in het commando opgenomen. De aanroep in een automation kan dan zorgen voor de juiste invulling van de gegevens. En die zijn wel eenvoudig opnieuw te laden.
Day-ahead Automation
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
id: bbb661ac-2094-4b06-ada2-f93f91ba3a7b
alias: "EMHASS: Dayahead optimization"

trigger:
  - platform: time
    at: "05:34:56"

variables:
  soc_min: 0.05
  soc_max: 1
  soc_init: >
    {{ states("sensor.athom_smart_plug_v3_50f110_jbd_bms_state_of_charge") | float(default=0) / 100.0 }}
  pd_max: 400
  pc_max: 350
  load_cost_forecast: >
    {% set time_now = now() %}
    {% set high = 0.26644 %}
    {% set low = 0.26402 %}
    {% set minutes = time_now.minute %}
    {% set rounded_minutes = (minutes + 15) // 30 * 30 %}
    {% set rounded_time = time_now.replace(minute=0) + timedelta(minutes=rounded_minutes) %}
    {% set end_time = time_now + timedelta(hours=24) %}
    {% set data = namespace(tariffs=[]) %}
    {% for period_start in range(0, 48) %}
      {% set t = time_now + timedelta(minutes=30*period_start) %}
      {% if (23 <= t.hour or 0 <= t.hour < 7) or (t.weekday() >= 5 or t.weekday() <= 1) %}
        {% set tariff = low %}
      {% else %}
        {% set tariff = high %}
      {% endif %}
      {% set data.tariffs = data.tariffs + [tariff] %}
    {% endfor %}
    {{ data.tariffs[:48] }}

  pv_p_fc: >
    {% set today = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast') | selectattr('period_start', 'gt', utcnow()) | map(attribute='pv_estimate') | map('multiply',1000) | map('int') | list %}
    {% set tomorrow = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast') | map(attribute='pv_estimate') | map('multiply', 1000)| map('int') | list %}
    {{ today + tomorrow[:48] }}

action:
  - service: shell_command.emhass_dayahead_optim
    data:
      payload: >
        {"SOCmax": {{ soc_max }}, "SOCmin": {{ soc_min }}, "SOCtarget": {{ soc_init }}, "Pd_max": {{ pd_max }}, "Pc_max": {{ pc_max }}, "weather_forecast_cache_only": true, "pv_power_forecast": {{ pv_p_fc }}, "load_cost_forecast": {{ load_cost_forecast }} }


Naive MPC automation (WIP)

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
id: 1ecff611-d460-4713-8b1a-a60dc2ac87a2
alias: "EMHASS: MPC optimization"

trigger:
  - platform: time_pattern
    minutes: "/5"

variables:
  prediction_horizon: >
    {% set time = now() %}
    {% set time = time.replace(minute=0) %}
    {% set horizon = time.replace(day=time.day + 1, hour=5, minute=35) %}
    {% set horizon_seconds = horizon - time %}
    {% set horizon_hours = horizon_seconds.total_seconds() / 60 %}
    {% set pred_horizon = horizon_hours // 30 %}
    {% set pred_horizon = pred_horizon | int(0) %}
    {{ pred_horizon }}
  prod_price_forecast: >
    {% set data = namespace(tariffs=[]) %}
    {% set prod_price = 0.055 %}
    {% set data = namespace(tariffs=[]) %}
    {% for i in range(0, 48, 1) %}
      {% set data.tariffs = data.tariffs + [prod_price] %}
    {% endfor %}
    {{ data.tariffs[:prediction_horizon] }}
  load_cost_forecast: >
    {% set time_now = now() %}
    {% set high = 0.26644 %}
    {% set low = 0.26402 %}
    {% set minutes = time_now.minute %}
    {% set rounded_minutes = (minutes + 15) // 30 * 30 %}
    {% set rounded_time = time_now.replace(minute=0) + timedelta(minutes=rounded_minutes) %}
    {% set end_time = time_now + timedelta(hours=24) %}
    {% set data = namespace(tariffs=[]) %}
    {% for period_start in range(0, 48) %}
      {% set t = time_now + timedelta(minutes=30*period_start) %}
      {% if (23 <= t.hour or 0 <= t.hour < 7) or (t.weekday() >= 5 or t.weekday() <= 1) %}
        {% set tariff = low %}
      {% else %}
        {% set tariff = high %}
      {% endif %}
      {% set data.tariffs = data.tariffs + [tariff] %}
    {% endfor %}
    {{ data.tariffs[:48] }}
  # TODO: Use average (5min?) for 'now'-value?
  load_p_fc: >
    {% set p_load_fc = state_attr('sensor.p_load_forecast', 'forecasts') | map(attribute='p_load_forecast') | list %}
    {% set p_load_now = [states('sensor.power_load_no_var_loads') ] %}
    {{ (p_load_now + p_load_fc)[:prediction_horizon] }}

  soc_min: 0.05
  soc_max: 1
  soc_init: >
    {{ states("sensor.athom_smart_plug_v3_50f110_jbd_bms_state_of_charge") | float(default=0) / 100.0 }}

  num_def_loads: 0
  def_total_hours: 0

  pv_p_fc: >
    {% set today = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast') | selectattr('period_start', 'gt', utcnow()) | map(attribute='pv_estimate') | map('multiply',1000) | map('int') | list %}
    {% set tomorrow = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast') | map(attribute='pv_estimate') | map('multiply', 1000)| map('int') | list %}
    {{ (today + tomorrow)[:prediction_horizon] }}

action:
  - service: shell_command.emhass_naive_mpc
    data:
      payload: >
        { "prediction_horizon": {{ prediction_horizon }}, "prod_price_forecast": {{ prod_price_forecast }}, "soc_final": {{ soc_min }}, "soc_init": {{ soc_init }}, "num_def_loads": 0, "def_total_hours": {{ def_total_hours }}, "pv_power_forecast": {{ pv_p_fc }}, "load_power_forecast": {{ load_p_fc }}, "load_cost_forecast": {{ load_cost_forecast }} }

Configuratie

De configuratie van EMHASS is een yaml met diverse opties voor je energieprijzen, lijsten deferrables en evt een batterij.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
logging_level: DEBUG
data_path: default
costfun: profit
sensor_power_photovoltaics: sensor.solar_panels_total_output_power
sensor_power_load_no_var_loads: sensor.power_load_no_var_loads
set_total_pv_sell: false
set_nocharge_from_grid: false
set_nodischarge_to_grid: false
maximum_power_from_grid: 9000
maximum_power_to_grid: 9000
number_of_deferrable_loads: 2
list_nominal_power_of_deferrable_loads:
  - nominal_power_of_deferrable_loads: 0
  - nominal_power_of_deferrable_loads: 0
list_operating_hours_of_each_deferrable_load:
  - operating_hours_of_each_deferrable_load: 0
  - operating_hours_of_each_deferrable_load: 0
list_start_timesteps_of_each_deferrable_load:
  - start_timesteps_of_each_deferrable_load: 0
  - start_timesteps_of_each_deferrable_load: 0
list_end_timesteps_of_each_deferrable_load:
  - end_timesteps_of_each_deferrable_load: 0
  - end_timesteps_of_each_deferrable_load: 0
list_peak_hours_periods_start_hours:
  - peak_hours_periods_start_hours: "00:00"
list_peak_hours_periods_end_hours:
  - peak_hours_periods_end_hours: "00:00"
list_treat_deferrable_load_as_semi_cont:
  - treat_deferrable_load_as_semi_cont: true
  - treat_deferrable_load_as_semi_cont: true
list_set_deferrable_load_single_constant:
  - set_deferrable_load_single_constant: false
  - set_deferrable_load_single_constant: false
list_set_deferrable_startup_penalty:
  - set_deferrable_startup_penalty: 0
  - set_deferrable_startup_penalty: 0
load_peak_hours_cost: 0.26644
load_offpeak_hours_cost: 0.26402
photovoltaic_production_sell_price: 0.055
list_pv_module_model:
  - pv_module_model: CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M
list_pv_inverter_model:
  - pv_inverter_model: Shenzhen_Growatt_New_Energy_Co___Ltd___SPH_3600TL_BL_US__240V_
list_surface_tilt:
  - surface_tilt: 37
list_surface_azimuth:
  - surface_azimuth: 165
list_modules_per_string:
  - modules_per_string: 6
list_strings_per_inverter:
  - strings_per_inverter: 1
inverter_is_hybrid: false
compute_curtailment: false
set_use_battery: true
battery_nominal_energy_capacity: 2500
Pd_max: 400
Pc_max: 320
eta_disch: 0.95
eta_ch: 0.95
Enom: 2600
SOCmin: 0.05
SOCmax: 0.99
SOCtarget: 0.8
Interpolatie
Het kan helpen om bepaalde sensoren te interpoleren.

YAML:
1
2
3
var_interp: 
  - sensor.power_photovoltaics
  - sensor.power_load_no_var_loads


https://emhass.readthedocs.io/en/latest/config.html

PV-installatie

Er is een mogelijkheid om handmatig je een PV-installatie configureren, met type panelen en omvormer-vermogen. Helaas is de onderliggende database niet up-to-date.
Solcast
Een beter alternatief is ‘Solcast’, voor de hobbyist is een gratis API beschikbaar met 10 API calls per dag. Aangezien de informatie maar 1x per 6 uur wordt bijgewerkt is dit ruim voldoende. Solcast heeft ook ondersteuning voor meerdere dak-oriëntaties.
Solar.Forecast
Solar.Forecast is ook een gratis API, met een resolutie van 1h, max 12 requests per uur per IP en werkt met het totaal aantal Wp van de installatie.

Load

Het verbruik van het huis moet ook bekend zijn, EMHASS heeft tenminste 48h historie nodig op deze sensor.
De sensor moet de belasting van het huis zijn, zonder deferrables en volgens mij ook zonder PV of batterij.

Ik heb het verbruik van mijn P1 meter genomen en daar de opbrengst van de panelen bij opgeteld. Evt. opladen van de batterij of juist het ontladen neem ik er ook niet in mee.

YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
    - name: "Power Consumed by Home"
      state: "{{ states('sensor.power_from_grid_net_sum') | float(0) + states('sensor.solar_panels_total_output_power') | float(0) }}"
      unit_of_measurement: "W"
    - name: "Power load no var loads"
      unique_id: b699a98f-80bb-480d-bc7d-64489d271b77
      unit_of_measurement: W
      device_class: power
      state: >
        {% set powerload = states('sensor.power_consumed_by_home') | float(default=0) %}
        {% set battery_prod = states('sensor.powerstream_6588_inverter_output_watts') | int(0) %}
        {% set battery_cons = states('sensor.home_battery_power_usage_corrected') | float(default=0) %}
        {% set value = ( powerload + battery_prod - battery_cons) | round(1,default=0) %}
        {{ value }}

Batterij

Van een batterij configureer je de capaciteit, maar ook de efficientie en de maximale hoeveelheid vermogen waarmee je kunt op- en ontladen. En hoe vol/leeg de batterij mag zijn.

YAML:
1
2
3
4
5
6
7
8
9
10
set_use_battery: true
battery_nominal_energy_capacity: 2500
Pd_max: 400
Pc_max: 320
eta_disch: 0.95
eta_ch: 0.95
Enom: 2600
SOCmin: 0.05
SOCmax: 0.99
SOCtarget: 0.8

Links

EMHASS:
https://github.com/davidusb-geek/emhass

Home Assistant community:
https://community.home-as...for-home-assistant/338126

EMHASS add-on:
https://github.com/davidusb-geek/emhass-add-on

De officiële documentatie vind je hier:
https://emhass.readthedocs.io/en/latest/

Solcast:
https://toolkit.solcast.com.au/register

Solcast Integratie (HACS)
https://github.com/BJReplay/ha-solcast-solar

Document van Robert Cruikshank:
https://cruikshank-my.sha...r2aXqf_6aQB5AO1A?e=5zmaVB

[ Voor 27% gewijzigd door RudolfR op 24-10-2024 19:27 ]


Acties:
  • 0 Henk 'm!

  • Bertbj40
  • Registratie: Oktober 2024
  • Laatst online: 12-11-2024
Dank je wel voor je uitleg. Ik heb al een tijdje emhass draaien. Maar ik vind nergens de sensor.p_batt_forecast en de andere sensoren terug. Hoe en waar moet ik die instellen?

Acties:
  • 0 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
Die worden in HA aangemaakt door EMHASS door een publish_data. (Kan via webinterface)

Daar zal eerst een optimalisatieberekening voor gedaan moeten zijn.

Ervan uitgaande dat je batterij is ingesteld in de yaml, uiteraard.

Acties:
  • 0 Henk 'm!

  • Pejdref
  • Registratie: November 2012
  • Laatst online: 11:36
Mooie OP, jammer dat er vooralsnog weinig activiteit is hier. Ik heb deze integratie wel eens voorbij zien komen, maar liet me inderdaad afschrikken door:
De documentatie van EMHASS bevat een hoop informatie, maar schrikt daardoor ook wel af.
.

Zelf heb ik wel wat logica om mijn verbruik te optimaliseren, maar vooralsnog is dat vooral voor de leuk omdat ik nog een vast contract heb met boetevrij salderen.

Ook voelt de EMHASS integratie een beetje aan als een blackbox waarvan je niet weet wat die doet, terwijl voor mij een deel van de fun is om de logica van automatiseringen zelf te verzinnen/begrijpen. Maar wellicht zie ik dat verkeerd. Misschien lijkt het ook minder interessant omdat mijn aantal 'deferrables' beperkt zijn (wasmachine, vaatwasser, warmtepomp DHW) en niet regelbaar (alleen aan/uit).

Op welke manier gebruik je de integratie zelf @RudolfR ?

Acties:
  • 0 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
@Pejdref

Nog nauwelijks. Ik probeer het in te regelen om te kunnen bepalen wanneer het een beste moment is om een kleine thuisbatterij op te laden of juist te benutten.

Zou graag de vaatwasser als deferrable inregelen, nu heb ik wat logica in Home Assistant die het opladen van de batterij stopzet tijdens bepaalde verbruikspieken in het bekende was-programma.

Dat soort regels is wel leuk om te zien werken, maar kan me voorstellen dat dat snel onoverzichtelijk wordt.

Acties:
  • 0 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
Bovenstaande is geschreven voor v0.10.6 van de add-on. Inmiddels is er een 0.11.0 die e.e.a. omgooit aan de settings.

In github staat een video met een uitleg van de wijzigingen.
https://github.com/davidu...4#issuecomment-2336723252

Acties:
  • 0 Henk 'm!

  • The Source
  • Registratie: April 2000
  • Laatst online: 09:29
Ik draai het meeste op in Homey en had voor de zomer zelf wat flows gemaakt om op basis van terug levering de zwembad pomp + zwembad warmtepomp aan te zetten en zo ook de bereginings instalatie. Heel lomp:

- beregeing in thuis voor 9h bij 1kW terug levering voor uurtje totaal
- zwembad pomp (filteren) 950W na 11h voor 3h per dag
- zwembad warmte pomp (verwarmen) 1500 - 2500W na 11h als er 3kW terug geleverd wordt (2 + 950 van pomp). DIt nog niet op basis van water temp en schakelen tussen de standen.

Leuk voor in de zomer (en bovenstaande gebruik je pas als temp in nacht boven 15 graden blijft, dus dit jaar van laat juni tot eind sept. maar aan begin en eind merkte ik al dat het moeilijker was om ivm bewolking het met gratis stroom te doen (opgewekt).

Ondertussen ook een airco (in zomer met overvloed aan zon geen probleem) maar in winter verwarmen iets moeilijker. Daarnaast ook een warm waterpomp voor sww en verwarming. Die kan ik beperkt sturen, het water / de woning moet warm, maar zo goedkooop mogelijk. Een ander probleem is dat de hoogte van deze load variable is afhankelijk van de buiten temp en/of het aantal keer dat mensen douchen.

En dan heb ik nog de vaatwasser (slim), wasmachine (dom) en de droger (dom) die eventueel in te plannen zijn als de vrouw meewerkt.

Omdat ik de aircos en warmte pomp via ESPhome aanstuur ondertussen ook HA geinstalleerd naast Homey. HA heeft een iets moeilijkere leercurve, maar ondertussen het meeste van mijn energie (Homey > MQTT > HA) ook inzichtelijk.
Afbeeldingslocatie: https://tweakers.net/i/KEAM8M7J2jRxndYRyV8iV4ZSoR8=/800x/filters:strip_exif()/f/image/mtBThVClNz3P704zTPaCtr9U.png?f=fotoalbum_large

Zoals je ziet verbruikt de Ecodan warmtepomp stroom als er nog geen zon is of niet meer is. Daarnaast zal ik ook wellicht een batterij aanschaffen zodra salderen stopt. Aangezien ik (teveel) panelen heb wil ik tegen die tijd ook inzichtelijk krijgen wat mijn echte energie behoeft is en nu al starten met optimzaliseren dmv EMHASS.

Dank je voor je start post, die geeft mij al wat oplossingen voor vragen die ik had :)

Een paar vragen:
- sensor_power_photovoltaics, ik heb 2 installaties voor zonneopwek, moet ik daar een nieuwe sensor voor proberen te maken die ze optelt?
- Bij solar systems zie ik mijn 2 omvormers er niet tussen staan, hoe dit op te lossen? En moet ik dit wel invullen als ik solcast al (in homey) gebruik. Ik zie niet hoe ik dat hier toevoeg.

Acties:
  • 0 Henk 'm!

  • Pieterve
  • Registratie: Oktober 2010
  • Laatst online: 23-04 18:40
[b]The Source in "EMHASS - Energy Management for Home Assistant"

Een paar vragen:
- sensor_power_photovoltaics, ik heb 2 installaties voor zonneopwek, moet ik daar een nieuwe sensor voor proberen te maken die ze optelt?
- Bij solar systems zie ik mijn 2 omvormers er niet tussen staan, hoe dit op te lossen? En moet ik dit wel invullen als ik solcast al (in homey) gebruik. Ik zie niet hoe ik dat hier toevoeg.
- je kan een combinatiesensor maken
- je kan 2 omvormers toevoegen, of 2 strings met verschillende orientatie

Acties:
  • +1 Henk 'm!

  • Pieterve
  • Registratie: Oktober 2010
  • Laatst online: 23-04 18:40
Ik draai EMHASS al een klein jaar, als alternatief heb ik ooit predbatt geprobeerd, maar die regelde minder goed, maar is wel gebruiksvriendelijker en heeft een beter UI.
En predbatt kan zelf je omvormer aansturen.

Stiekem hoop ik dat EVCC (wat ik gebruik voor de EV) verder gaat ontwikkelen richting een EMS.

EMHASS is vrij lastig in stellen en heeft veel automatisaties en scripts nodig.

Ik gebruik het met een thuisbatterij en gezien ons verbruiksprofiel onregelmatig is, was de MLC niet betrouwbaar omdat er geen regelmaat was in het verbruik.
Nu heb ik bepaalde verbruiksprofielen aangemaakt als template sensor afhankelijk van wie er thuis is, weekend of vakantie. Deze data stuur ik door naar EMHASS (samen met soc, solcast, etc.)

Acties:
  • 0 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
@The Source

Ik kwam er ook niet uit om mijn PV via EMHASS te configureren, vandaar dat ik voor Solcast ben gegaan.
Je kunt misschien iets met vergelijkbare karakteristieken vinden en het aantal Wp ongeveer kloppend maken?

Ik heb ervoor gekozen om de solcast integratie van HA te gebruiken om meer grip te hebben op de max 10 API-calls per dag. Via automations kan ik dan de forecasts meegeven aan de curl-calls naar EMHASS.

Zoals hier, waar ik een lijst maak van vandaag en morgen tot aan de 'prediction_horizon'.
YAML:
1
2
3
4
  pv_p_fc: >
    {% set today = state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast') | selectattr('period_start', 'gt', utcnow()) | map(attribute='pv_estimate') | map('multiply',1000) | map('int') | list %}
    {% set tomorrow = state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast') | map(attribute='pv_estimate') | map('multiply', 1000)| map('int') | list %}
    {{ (today + tomorrow)[:prediction_horizon] }}

Acties:
  • 0 Henk 'm!

  • The Source
  • Registratie: April 2000
  • Laatst online: 09:29
Zo ik heb EMHASS ook aan de gang (maar daar is alles meegezegd).
Omdat ik Solcast al gebruik op Homey en die limited API calls heeft heb ik Solar Forecast gebruikt voor HA. Ik moet het nog wel een beetje tuning zodat de verwachte opbrengst overeenkomt met de gerealiseerde, maar dit doe ik met kleine stapjes.

Mijn load (p1) moet ik de variable load nog vanaf trekken en ik moet mijn deferrable loads nog better meten en hopelijk kan ik die een mooi naampje geven want van die technisch namen wordt ik niet blij :) en dan nog de automations....

Kan ik die leuke chart van de optimization in een van mijn dashboards plaatsen?

Acties:
  • +1 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
@The Source

Ja, ik heb hier een apex-chart gevonden. En daar alle deferrables uitgehaald.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
type: custom:apexcharts-card
apex_config:
  chart:
    height: auto
header:
  show: true
  title: EMHASS Daily Forecast
  show_states: true
  colorize_states: true
graph_span: 36h
span:
  start: minute
  offset: +0h
all_series_config:
  stroke_width: 1
now:
  show: true
  label: Now
yaxis:
  - min: -7
    max: 13
    decimals: 0
    apex_config:
      forceNiceScale: true
      tick_amount: 4
series:
  - entity: sensor.consumption_savings_dmo
    float_precision: 0
    color: black
    name: Savings (vs DMO)
    show:
      legend_value: false
      in_chart: false
  - entity: sensor.total_cost_fun_value
    unit: $
    invert: true
    float_precision: 0
    name: Cost
    show:
      legend_value: false
      in_chart: false
    transform: return x *-1
  - entity: sensor.consumption_forecast
    unit: kWh
    float_precision: 0
    name: House
    show:
      legend_value: false
      in_chart: false
  - entity: sensor.pv_forecast_energy
    unit: kWh
    float_precision: 0
    color: orange
    name: Solar
    show:
      legend_value: false
      in_chart: false
  - entity: sensor.p_pv_forecast
    type: line
    stroke_width: 2
    color: orange
    extend_to: false
    show:
      in_header: false
      legend_value: false
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.date), entry.p_pv_forecast/1000];
      });
  - entity: sensor.p_load_forecast
    type: line
    color: purple
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.date), entry.p_load_forecast/1000];
      });
  - entity: sensor.p_batt_forecast
    curve: stepline
    color: lightgreen
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    type: area
    data_generator: |
      return entity.attributes.battery_scheduled_power.map((entry) => {
        return [new Date(entry.date), entry.p_batt_forecast/1000];
      });
  - entity: sensor.p_grid_forecast
    curve: stepline
    color: lightgray
    type: area
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.date), entry.p_grid_forecast/1000];
      });
  - entity: sensor.p_deferrable0
    curve: stepline
    color: blue
    name: Pool Pump
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable0/1000];
      });
  - entity: sensor.p_deferrable1
    curve: stepline
    color: red
    name: Pool Heater
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable1/1000];
      });
  - entity: sensor.p_deferrable3
    curve: stepline
    name: HVAC
    color: blue
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable3/1000];
      });
  - entity: sensor.p_deferrable4
    curve: stepline
    color: red
    name: Hot Water
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable4/1000];
      });
  - entity: sensor.p_deferrable2
    curve: stepline
    color: black
    name: Car
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable2/1000];
      });
  - entity: sensor.p_deferrable5
    curve: stepline
    name: Car2
    color: grey
    extend_to: false
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable5/1000];
      });
view_layout:
  position: main


apex charts is beschikbaar via HACS.
https://github.com/RomRider/apexcharts-card


Voor mij weinig voortgang vandaag. Heel de dag infeasible resultaten ivm een lege accu en ook geen zon om dat op te lossen....

Acties:
  • 0 Henk 'm!

  • llevering
  • Registratie: September 2000
  • Laatst online: 11:40
@RudolfR bedankt voor het starten van dit topic. Ik ben ook met Emhass begonnen i.v.m. een a.s. switch naar een dynamisch contract. Nog geen batterij, dat staat op het wensenlijstje voor de toekomst.

Het heeft een steile leercurve en veel geduld nodig. Ik heb heel veel aan je voorbeelden gehad. Wat ook nog een uitdaging was, is dat je niet altijd de dynamische prijzen op elk moment van de dag 24u vooruit weet. Opgelost met de prediction_horizon en het switchen naar het MPC model. Uiteindelijk zag ik dat de oplossing ook min of meer in jouw MPC voorbeeld stond, maar ik dacht laat ik makkelijk beginnen met dayahead-optim, alleen dat ondersteunt geen dynamische tijdspanne zover ik kan zien.

Weinig concreets nu van mij kant, maar ik vind het leuk dat dit topic er is en het onderwerp niet ondersneeuwt in andere topics. Dus daarom wilde ik me toch even melden. Ben jij nog verder gekomen met de implementatie?

Ik ga trouwens 2 warmtepompboilers dynamisch aansturen en misschien de warmtepomp (laatste weet ik nog niet zeker, want ik heb een eigen optimalisatie die behoorlijk goed werkt).

Acties:
  • 0 Henk 'm!

  • RikBast
  • Registratie: November 2024
  • Laatst online: 30-01 18:42
@RudolfR leuk dat hier een topic over EMHASS is gestart, ben er sinds april dit jaar mee begonnen en ik leer iedere keer weer bij. Ik heb een batterij inclusief dynamisch contract en dat gaat wel lekker. Het is alleen dat je veel automations nodig heb en ik had 0,0 ervaring met home assistant. Nu gaat het wel enigszins.
Alleen heb ik day ahead en daarna MPC nog niet helemaal door, in eerste instantie gebruikte ik alleen MPC, maar op het HA forum wordt toch de combinatie aangeraden. Wellicht dit hier wat duidelijker wordt op het forum :-)

Acties:
  • +1 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
@llevering

Volgens mij is de truc om eenmalig de dayahead te draaien als je de nieuwe prijzen hebt voor de komende dag en dat aan te vullen met de MPC, met een horizon op het moment dat je de volgende dayahead gaat uitvoeren.
Zeker ook omdat je bij de MPC de actuele waardes van je verbruik en opwek kan meegeven, als eerste index van de array.

Zo draait het nu bij mij:
- Rond middernacht de Dayahead, dan wordt de horizon verschoven voor de MPC
- Iedere 5 minuten de MPC met de horizon op middernacht
- Die MPC aangevuld met actuele waardes van verbruik/opwek. Met "alpha": 0.25, "beta": 0.75
- De dayahead gebruikt prefix 'dh_', en de mpc 'mpc_'

Waar ik nu tegenaan loop:
- Forecasts van solcast zijn te optimistisch, ook met dat sombere weer.
- 'Profit' lijkt daardoor weinig te doen (met een vast contract?), 'self-consumption' zal ook kleine beetjes PV in de batterij willen stoppen, evt aangevuld met energie van het net.
- EMHASS lijkt naar een target SOC toe te regelen, ook bij een overvloed aan zon die nog in de batterij opgeslagen zou kunnen worden, maar dit lijkt niet te gebeuren

@RikBast
HA Community forum is ook een leerzame plek, maar hoop hier wat van andere Tweakers te leren die ook met het grillige Nederlandse weer te maken hebben.

Acties:
  • 0 Henk 'm!

  • RikBast
  • Registratie: November 2024
  • Laatst online: 30-01 18:42
Ik heb begrepen dat je de SOC waarden van de day ahead gebruikt voor de MPC calculaties gedurende de dag vordert. Dat wil ik eens testen.

Bij forecast.solar kun je dit gebruiken: https://doc.forecast.solar/actual (heb je wel abo nodig), zo gebruik ik nu, omdat voorspellingen inderdaad niet altijd goed zijn.

met v0.11.2 krijg ik hem niet op 'profit' meer gezet, weet niet waarom. Staat nu op "selconsumption' , werkte voorheen wel, je zag dat bij 'hoge' prijzen de batterij ging ontladen naar het net.

Acties:
  • 0 Henk 'm!

  • llevering
  • Registratie: September 2000
  • Laatst online: 11:40
RudolfR schreef op maandag 25 november 2024 @ 19:41:
Volgens mij is de truc om eenmalig de dayahead te draaien als je de nieuwe prijzen hebt voor de komende dag en dat aan te vullen met de MPC, met een horizon op het moment dat je de volgende dayahead gaat uitvoeren.
Ondanks de uitgebreidde documentatie was het mij nog niet duidelijk dat die samengaan, goede tip.

Helaas heb ik het probleem dat de add-on steeds crasht, regelmatig bij het berekenen van dayahead/mpc, maar sowieso bij het publiceren van data. Ik vrees dat mijn Odroid N2 misschien niet genoeg geheugen heeft. Op wat voor configuraties draaien jullie?

Acties:
  • +1 Henk 'm!

  • RikBast
  • Registratie: November 2024
  • Laatst online: 30-01 18:42
Day-Ahead is bij mij te onbetrouwbaar vanwege de PV voorspelling op het moment dat de DA heeft gedraaid. De array met SOC waarden redt ie daarna nooit met MPC, vanwege de veranderende PV omstandigheden gedurende de dag, dus ja het grillige weer. Ben dus weer terug bij alleen MPC met een SOC_init die de huidige SOC waarde heeft en een vast SOC_final van 0.9

Ik draai de HA met add-on op een mac-mini M1 met UTM-VM

Acties:
  • 0 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
@llevering

Ik had ook onverklaarbare crashes van de add-on. Inmiddels meer geheugen toegekend aan de HA OS VM en sindsdien geen problemen meer gezien. Ben van 4GB naar 6GB gegaan. (Proxmox NUC i5/16GB)

Mooi op tijd voor de winterzon.

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

min_soc staat nu nog op 40%. Ik wil graag af en toe de 100% halen voor het balanceren van de cellen.
Nadeel van die zonnige winterdagen is de bijbehorende lage temperaturen, dan schakelen er ook Airco's bij en dat is voor de regeling wel een uitdaging.
De vaatwasser is ook "smart" dus met een automatisering in HA onderbreek ik het opladen van de ACCU even. (eergisteren)
De MPC deed dat gisteren ook voor de domme wasmachine, zelfs even wat automatische peak-shaving. _/-\o_

Acties:
  • 0 Henk 'm!

  • MarcoPolet
  • Registratie: Januari 2017
  • Laatst online: 30-04 14:57
RikBast schreef op dinsdag 26 november 2024 @ 17:23:
Day-Ahead is bij mij te onbetrouwbaar vanwege de PV voorspelling op het moment dat de DA heeft gedraaid. De array met SOC waarden redt ie daarna nooit met MPC, vanwege de veranderende PV omstandigheden gedurende de dag, dus ja het grillige weer. Ben dus weer terug bij alleen MPC met een SOC_init die de huidige SOC waarde heeft en een vast SOC_final van 0.9

Ik draai de HA met add-on op een mac-mini M1 met UTM-VM
Beetje late reactie, maar ik had dit topic nog niet gezien. Ik gebruik al denk ik een jaar EMHASS en ben er erg blij mee, stuur ern mijn EV, zwembadpomp en zwembadverwarming mee aan. Ik gebruik solcast voor de PV voorspelling.
Specifiek voor jou vraag; update je bij die MPC ook je solcast weer opnieuw? Die update iets van 6 keer per dag en zal dan dus wat beter worden dan het moment van de nieuwe day-ahead. Overigens zie ik ook regelmatig dat mensen als eerste waarde de huidige PV opbrengst meegeven aan de MPC call, en daarna de voorspellingen van solcast.

Acties:
  • 0 Henk 'm!

  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 11:19
Hier een geïnteresseerde ENHASS lezer.

Ik meen van de week ergens gelezen te hebben dat er ook een NL vertaling beschikbaar is, nu zie ik deze nergens terug.

Kijk ik fout of is er toch geen NL vertaling beschikbaar?

IS er ergens een NL stappenplan beschikbaar?
De gebruikte ENG termen zeggen me vaak helaas niets...

Alvast bedankt voor jullie reactie(s).

(y)

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


Acties:
  • 0 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
@hemertje

Mij is niets bekend van een NL versie.

  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 11:19
oke, dank voor je reactie

ik zal binnenkort wel met men vragen hier terug komen verwacht ik :P

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


  • Reaper.JA2
  • Registratie: Oktober 2009
  • Laatst online: 30-04 09:13
MarcoPolet schreef op zaterdag 25 januari 2025 @ 20:42:
[...]

Beetje late reactie, maar ik had dit topic nog niet gezien. Ik gebruik al denk ik een jaar EMHASS en ben er erg blij mee, stuur ern mijn EV, zwembadpomp en zwembadverwarming mee aan.
Heb je een indicatie wat het je opgebracht heeft; hoeveel verhoging van verbruik eigen opwek?

Wil ook graag mn warmtepomp aansturen op maximaal veel PV-opwek.

"Improvement. It is the goal of life search" - Carl "Reaper" Shepards


Acties:
  • +2 Henk 'm!

  • MarcoPolet
  • Registratie: Januari 2017
  • Laatst online: 30-04 14:57
Reaper.JA2 schreef op donderdag 20 februari 2025 @ 08:59:
[...]

Heb je een indicatie wat het je opgebracht heeft; hoeveel verhoging van verbruik eigen opwek?

Wil ook graag mn warmtepomp aansturen op maximaal veel PV-opwek.
Eigen verbruik was/is niet mijn hoogste doel, hij stuurt op kosten. En aangezien ik uiteindelijk meer verbruik dan opwek, kan ik alles salderen. De inkoop en verkoop prijs die ik EMHASS invoer zijn dus gelijk. Hij kijkt dus vooral naar de momenten dat de stroom goedkoop is, niet perse wanneer er opbrengst is. Natuurlijk ligt dat wel vaak min of meer gelijk, maar zeker niet altijd, met name richting eind van de middag.
Als de saldering er af is dan zal ik de dan geldende prijzen moeten toepassen natuurlijk. Ook moet ik binnenkort denk ik iets anders gaan sturen; ik heb een thuisaccu met een omvormer waar ook panelen op kunnen. Nu gaan de panelen nog met hun eigen omvormer, maar die gaan straks naar de accu-omvormer. Dan kan ik dus met gelijkstroom laden, wat efficienter is. Ik moet nog uitvogelen hoe ik die optimalisatie het best in EMHASS kwijt kan.
(Edit: fyi, er is trouwens wel een instelling in EMHASS die self-consumption als uitgangspunt neemt)

[ Voor 4% gewijzigd door MarcoPolet op 20-02-2025 16:44 ]


Acties:
  • 0 Henk 'm!

  • MarcoPolet
  • Registratie: Januari 2017
  • Laatst online: 30-04 14:57
Ter info, vandaag bericht van Tibber:
Vanaf juni 2025 stappen Europese energiebeurzen, waaronder EPEX Spot voor Nederland, over op kwartierprijzen in plaats van uurprijzen. Een stap vooruit voor de energiemarkt – en natuurlijk gaat Tibber mee!
Momenteel gebruik ik EMHASS op uur-basis, wordt nog een werkje om dit naar kwartier te trekken, maar an sich wel mooi om weer wat nauwkeuriger te sturen.

Acties:
  • 0 Henk 'm!

  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 11:19
Het verloop zal in de praktijk met minder grote stappen zijn per kwartier dan per uur

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


Acties:
  • 0 Henk 'm!

  • Thorsd
  • Registratie: Oktober 2022
  • Laatst online: 09:55
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.

Acties:
  • 0 Henk 'm!

  • Sicco92
  • Registratie: September 2010
  • Laatst online: 11:36
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
{% 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 ]


Acties:
  • 0 Henk 'm!

  • Brokencore
  • Registratie: Juli 2002
  • Laatst online: 10:05
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).

Acties:
  • +1 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
@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.

Acties:
  • +1 Henk 'm!

  • Thorsd
  • Registratie: Oktober 2022
  • Laatst online: 09:55
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.

Acties:
  • 0 Henk 'm!

  • Sicco92
  • Registratie: September 2010
  • Laatst online: 11:36
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 :D

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.

Acties:
  • +1 Henk 'm!

  • Reaper.JA2
  • Registratie: Oktober 2009
  • Laatst online: 30-04 09:13
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 :P

"Improvement. It is the goal of life search" - Carl "Reaper" Shepards


Acties:
  • +1 Henk 'm!

  • Beekforel
  • Registratie: November 2001
  • Laatst online: 11:50

Beekforel

Is eigenlijk geen vis

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

Acties:
  • +2 Henk 'm!

  • desalnietemin
  • Registratie: December 2018
  • Laatst online: 30-04 22:04
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 ]

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


Acties:
  • 0 Henk 'm!

  • Thorsd
  • Registratie: Oktober 2022
  • Laatst online: 09:55
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,
toon volledige bericht
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.

Acties:
  • +1 Henk 'm!

  • desalnietemin
  • Registratie: December 2018
  • Laatst online: 30-04 22:04
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

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


Acties:
  • +1 Henk 'm!

  • Thorsd
  • Registratie: Oktober 2022
  • Laatst online: 09:55
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.

Acties:
  • +1 Henk 'm!

  • RudolfR
  • Registratie: Maart 2011
  • Nu online
Er is nu ook een topic voor 'Day Ahead Optimizer':
Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

Acties:
  • +1 Henk 'm!

  • desalnietemin
  • Registratie: December 2018
  • Laatst online: 30-04 22:04
@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

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

Pagina: 1