Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Torch1969]

KC27 schreef op maandag 14 april 2025 @ 12:28:
[...]


Versie 2025.4.1 is nu gepubliceerd!

@KC27 Is dat helemaal goed gegaan? Op GitHub staat als latest release nog 2025.4.0. Dat zie ik ook in het scherm (linksonder staan). Ik heb vanmiddag mijn docker-image opnieuw opgebouwd, maar krijg nu ook foutmeldingen (bij reports en savings “internal server error” en als ik dan in de log van dao kijk zie ik:

[2025-04-14 18:25:09,613] ERROR in app: Exception on / [POST]
Traceback (most recent call last):
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/sqlalchemy/engine/cursor.py", line 1137, in fetchall
rows = dbapi_cursor.fetchall()
^^^^^^^^^^^^^^^^^^^^^^^
sqlite3.DatabaseError: database disk image is malformed
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
response = self.full_dispatch_request()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 882, in full_dispatch_request
rv = self.handle_user_exception(e)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
rv = self.dispatch_request()
^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/webserver/app/routes.py", line 261, in menu
return reports("savings")
^^^^^^^^^^^^^^^^^^
File "/root/dao/webserver/app/routes.py", line 582, in reports
report_df = calc_function(active_period, _tot=tot,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/prog/da_report.py", line 2172, in calc_saving_consumption
df = self.get_columns(calc_dict, active_period, _tot)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/prog/da_report.py", line 1813, in get_columns
ha_data = self.get_sensor_data(sensor, vanaf_ha, tot, key,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/prog/da_report.py", line 990, in get_sensor_data
df_raw = pd.read_sql(query, connection)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/io/sql.py", line 734, in read_sql
return pandas_sql.read_query(
^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/io/sql.py", line 1853, in read_query
data = result.fetchall()
^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/sqlalchemy/engine/result.py", line 1315, in fetchall
return self._allrows()
^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/sqlalchemy/engine/result.py", line 548, in _allrows
rows = self._fetchall_impl()
^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/sqlalchemy/engine/cursor.py", line 2135, in _fetchall_impl
return self.cursor_strategy.fetchall(self, self.cursor)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/sqlalchemy/engine/cursor.py", line 1141, in fetchall
self.handle_exception(result, dbapi_cursor, e)
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/sqlalchemy/engine/cursor.py", line 1082, in handle_exception
result.connection._handle_dbapi_exception(
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/sqlalchemy/engine/base.py", line 2352, in _handle_dbapi_exception
raise sqlalchemy_exception.with_traceback(exc_info[2]) from e
File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/sqlalchemy/engine/cursor.py", line 1137, in fetchall
rows = dbapi_cursor.fetchall()
^^^^^^^^^^^^^^^^^^^^^^^
sqlalchemy.exc.DatabaseError: (sqlite3.DatabaseError) database disk image is malformed
(Background on this error at: https://sqlalche.me/e/20/4xp6)

Ik weet nu even niet of mijn docker image of container nog niet goed is, mijn configuratie nog niet goed is, of er iets mis zit in. 2025.4.1….

Edit: wacht maar even, docker build was waarschijnlijk niet goed gegaan. Nu opnieuw gedaan en versienummer klopt nu in het scherm. Ik hou het even in de gaten…..
Edit 2: De foutmelding is er nog steeds. Als ik bij Report bij vandaag op Balans druk.
Wat me ook opvalt is dat als er een heel uur voorbij is, er bij reports geen nieuwe regel in de tabel onderaan verschijnt en bij Savings staat die regel er wel, maar met allemaal 0 getallen.
Edit 3: Als ik de container herstart, dan is alle data er t/m vorige uur en geen foutmelding. Totdat het weer een nieuw uur is.

[ Voor 4% gewijzigd door Torch1969 op 14-04-2025 21:21 ]

[Torch1969]

bvw schreef op maandag 14 april 2025 @ 18:16:
[...]

Trouwens, om chique te zijn, mag de "privileged" er niet uit? Volgens mij draait ie prima zonder.

Ok, dank voor de tip, zal de volgende container start eens zonder proberen.

[Faceless]

thys schreef op maandag 14 april 2025 @ 13:39:
[...]


Hoe haal je de verwachte SOC van DAO naar HA?

Daar is een API call voor in de documentatie. Hieronder iets aangepast voor de nieuwe output van DAO van de nieuwste versie:

code:

rest:
  - resource: http://192.168.1.168:5000/api/report/soc/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: SOC Projection
        unique_id: soc_projection
        unit_of_measurement: '%'
        value_template: "{{ value_json.data[0].value }}"
        json_attributes:
          - data

Daarna kun je er een tabelletje van maken in een paar kolommen (en alleen als er iets wijzigt) in een HTML Jinja2 Template card:

code:

type: custom:html-template-card
title: SOC verwacht
ignore_line_breaks: true
content: |
  <table>
    <tr>
      {% set ns = namespace(last_value=None, count=0) %}
      {% set now = now().strftime('%Y-%m-%d %H:%M') %}
      {% for item in state_attr('sensor.soc_projection', 'data') %}
        {% if item.time[:16] >= now and ns.last_value != item.value %}
          {% if ns.count % 4 == 0 and ns.count != 0 %}
            </tr><tr>
          {% endif %}
          <td style="padding: 0 46px 8px 0;">{{ item.time[-5:] }}<br>{{ item.value | round(0) }}%</td>
          {% set ns.last_value = item.value %}
          {% set ns.count = ns.count + 1 %}
        {% endif %}
      {% endfor %}
    </tr>
  </table>

[Undertilted]

KC27 schreef op maandag 14 april 2025 @ 11:54:
[...]

Ah, nou begrijp ik je: je hebt het over een Belgische situatie en daar wordt - in tegenstelling tot Nederland - geen BTW teruggegeven bij teruglevering.
Op dit moment voorziet DAO daar nog niet in.
Ik zal in een volgende versie (helaas niet 2025.4.1, die is al te ver) hier een optie over opnemen en implementeren.

Ik dacht misschien het nu toch al te proberen en de verkoop-kosten/opbrengsten op 0 te zetten.

Wat zou er dan gebeuren met het algoritme?

[KC27]

Torch1969 schreef op maandag 14 april 2025 @ 18:37:
[...]

@KC27 Is dat helemaal goed gegaan? Op GitHub staat als latest release nog 2025.4.0. Dat zie ik ook in het scherm (linksonder staan). Ik heb vanmiddag mijn docker-image opnieuw opgebouwd, maar krijg nu ook foutmeldingen (bij reports en savings “internal server error” en als ik dan in de log van dao kijk zie ik:

[...]


Ik weet nu even niet of mijn docker image of container nog niet goed is, mijn configuratie nog niet goed is, of er iets mis zit in. 2025.4.1….

Edit: wacht maar even, docker build was waarschijnlijk niet goed gegaan. Nu opnieuw gedaan en versienummer klopt nu in het scherm. Ik hou het even in de gaten…..
Edit 2: De foutmelding is er nog steeds. Als ik bij Report bij vandaag op Balans druk.
Wat me ook opvalt is dat als er een heel uur voorbij is, er bij reports geen nieuwe regel in de tabel onderaan verschijnt en bij Savings staat die regel er wel, maar met allemaal 0 getallen.
Edit 3: Als ik de container herstart, dan is alle data er t/m vorige uur en geen foutmelding. Totdat het weer een nieuw uur is.

Volgens mij is alles goed gegaan, ik was alleen vergeten de release te vernieuwen. Maar het ophalen van een nieuwe versie gebeurt niet met de release-data. Versienummer onderin klopt wel.
Die nieuwe release staat er nu!

Jouw foutmelding sqlite3.DatabaseError: database disk image is malformed zegt dat je HA-database is is beschadigd.
Dat kan eigenlijk niet door DAO komen, want DAO leest alleen maar uit de HA database. Dit is dan ook de eerste keer dat ik hiervan hoor/lees.

Je zou eerst het volgende kunnen proberen:

• stop DAO
• stop Home Assistant
• start Home Assistant
• check de system logging van Home Assistant
• start DAO

Als de fout blijft terugkomen dan zal de db moeten worden hersteld met deze commando's/akties:

• stop HA en DAO
• kopieer home-assistant_v2.db uit de config-directory (waar ook configuration.yaml staat) naar een machine waar je sqlite3 op kunt installeren
• run het volgende commando "sqlite3 home-assistant_v2.db ".recover" | sqlite3 ha_new.db". Dat kan (afhankelijk van de grootte) een paar minuten duren.
• kopieer ha_new naar de config-directory en hernoem deze naar home-assistant_v2.db (eerst de oude weghalen)
• start HA en DAO

[ Voor 3% gewijzigd door KC27 op 14-04-2025 22:53 ]

[KC27]

Torch1969 schreef op maandag 14 april 2025 @ 14:36:
[...]


Dat is uiteraard prima. 👍🏻
@KC27 heb net nog een edit gedaan, neem je die mee? (Tijd stond niet goed (2 uur te vroeg) in de container, daardoor klopte e.e.a. niet in reports, logging etc.)
@bvw heb jij dit probleem niet met jou docker run instructie?

Ik ben er nog niet aan toegekomen, dus je edit komt automatisch mee.
Zodra ik het klaar heb zal ik jullie vragen alles nog eens kritisch te bekijken.

[KC27]

Undertilted schreef op maandag 14 april 2025 @ 13:47:
[...]


Super!

maar het gaat verder dan dat.

Het is [spotprijs * X + Y]
btw etc, maakt minder uit. Het is een kwestie van X en Y te berekenen.

in X en Y kan je al dan niet BTW steken, maar er moet een parameter zijn voor X en 1 voor Y.

Sorry, nu kan ik je even niet meer volgen.
Wat bedoel je met X en Y?

In Nederland geldt (ik heb het over de volume kosten, niet over de vast kosten per dag en/of per maand):
Inkoop

• inkoop_kosten = inkoop_prijs x inkoop_volume
• inkoop_prijs = (dyn_tarief + energiebelasting + opslag) x (1 + btw)

Teruglevering

• teruglever_vergoeding= teruglever_prijs x teruglever_volume
• zolang je kunt salderen en tot 1-1-2027: teruglever_prijs = (dyn_tarief + energiebelasting + opslag) x (1 + btw)
• als je niet meer kunt salderen: teruglever_prijs = (dyn_tarief + opslag) x (1 + btw)

Hoe zit dat nu in België?

[Undertilted]

Inkoop

inkoop_kosten = inkoop_prijs x inkoop_volume
inkoop_prijs = (spotprijs_van_entso-e * Multiplier *(1+btw) _ + opslag *(1+btw) + toeslagen_zonder_btw + toeslagen_met_btw x (1 + btw)

Teruglevering

teruglever_vergoeding= teruglever_prijs x teruglever_volume

als je niet meer kunt salderen: teruglever_prijs = (spotprijs_van_entso-e*teruglever_multiplier + opslag)


Zoals je ziet kan je beter de kosten terugrekenen naar X*spotprijs_van_entso-e* + opslag_totaal ipv allerlei velden te voorzien voor de verschillende toeslagen en kosten.

Check https://files.boltenergie...r/online_res_el_nl_11.pdf voor een voorbeeld. Onze elektriciteitsrekening is een halve belastingsbrief.

[KC27]

Undertilted schreef op maandag 14 april 2025 @ 23:18:
Inkoop

inkoop_kosten = inkoop_prijs x inkoop_volume
inkoop_prijs = (spotprijs_van_entso-e * Multiplier *(1+btw) _ + opslag *(1+btw) + toeslagen_zonder_btw + toeslagen_met_btw x (1 + btw)

Teruglevering

teruglever_vergoeding= teruglever_prijs x teruglever_volume

als je niet meer kunt salderen: teruglever_prijs = (spotprijs_van_entso-e*teruglever_multiplier + opslag)


Zoals je ziet kan je beter de kosten terugrekenen naar X*spotprijs_van_entso-e* + opslag_totaal ipv allerlei velden te voorzien voor de verschillende toeslagen en kosten.

Check https://files.boltenergie...r/online_res_el_nl_11.pdf voor een voorbeeld. Onze elektriciteitsrekening is een halve belastingsbrief.

Dat ziet er inderdaad heel ingewikkeld uit.
Zijn alle genoemde tarieven in de bijlage al incl. BTW?

Voor mij wordt zoiets gelijk een stuk duidelijker met een voorbeeld.
Heb je misschien voor mij (mag per pm) een kopie van een maandafrekening?
En kun je een berekening geven van de kosten / opbrengsten in een uur met hoofdzakelijk inkoop en een uur met veel teruglevering?

[KC27]

stoner1978 schreef op maandag 14 april 2025 @ 15:23:
goedemiddag,

Kleine update van het "huiswerk" van @KC27
Dit werd voor mij als plantenkweker wel behoorlijk next level maar ben druk aan het stoeien geweest samen met chatGPT en we zijn tot de volgende automatisering gekomen:

code:

alias: dao vaillant starttijd berekenen met tijdvenster
triggers:
  - minutes: 59
    seconds: 0
    trigger: time_pattern
conditions:
  - condition: numeric_state
    entity_id: sensor.plug_warmtepomp_power
    below: 5
actions:
  - variables:
      huidige_temp: "{{ states('sensor.valliant_switch_temp_water') | float(0) }}"
      verschil: "{{ huidige_temp - 42 }}"
      uren_tot_ondergrens: "{{ verschil / 0.4 }}"
      gewenste_eindtijd: "{{ today_at('16:00:00') }}"
      berekende_starttijd_dt: "{{ (today_at('16:00:00') - timedelta(hours=4)) }}"
      starttijd_tijd: "{{ (today_at('16:00:00') - timedelta(hours=4)).strftime('%H:%M:%S') }}"
      eindtijd_tijd: "{{ today_at('16:00:00').strftime('%H:%M:%S') }}"
  - choose:
      - conditions:
          - condition: template
            value_template: >
              {% set start = (today_at('06:00:00')) %} {% set eind =
              (today_at('12:00:00')) %} {% set berekend = (today_at('16:00:00')
              - timedelta(hours=4)) %} {{ start <= berekend <= eind }}
        sequence:
          - target:
              entity_id: input_datetime.dao_vaillant_begin_tijd
            data:
              time: "{{ starttijd_tijd }}"
            action: input_datetime.set_datetime
          - target:
              entity_id: input_datetime.dao_vaillant_eind_tijd
            data:
              time: "{{ eindtijd_tijd }}"
            action: input_datetime.set_datetime
    default:
      - target:
          entity_id: input_datetime.dao_vaillant_begin_tijd
        data:
          time: "00:00:00"
        action: input_datetime.set_datetime
      - target:
          entity_id: input_datetime.dao_vaillant_eind_tijd
        data:
          time: "00:00:00"
        action: input_datetime.set_datetime

Er komt een tijd naar de helpers voor DAO, ga dit eens volgen om te zien of het zo werkt. Ik ben bang dat het nog niet helemaal klopt. zit nog met de verschillen in "normaal" of "Legionella" die worden nu niet meegenomen / er wordt niet naar het programma gekeken. Ook zit er een afwijking in, oftewel DAO wil eerder starten dan het opgegeven start window. is geen probleem, hij zit nog in de tijd dat hij mag draaien.
als iemand nog tips of vragen heeft hoor ik het graag!
Misschien ook eerst een paar dagen volgen, heb nu zo vaak op berekenen gedrukt dat ik niet weet of hij het nog goed doet....

[Afbeelding]

[...]

Ik probeer je automation te begrijpen, maar volgens mij zet hij altijd de window_begintijd op 12 uur en window_eindtijd op 16 uur. Ik vrees dat dit zo niet gaat werken.
Ik ben wel druk de komende dagen (o.a. met dit topic), maar ik zal zien of ik een uurtje kan vrijmaken om iets te maken. Misschien zijn er meer lezers die dit als een leuke uitdaging zien?

[stoner1978]

Geen probleem hoor, ik vindt het wel leuk om er even mee te stoeien.
Door jou opmerking bedenk ik me net dat er geen rekening gehouden wordt met opwarming per uur. Nu kijkt hij alleen naar programma lengte. Dit moet meer dynamisch zijn dan zal de begin tijd en dus eind tijd ook veranderen

KC27 schreef op maandag 14 april 2025 @ 23:48:
[...]


Ik probeer je automation te begrijpen, maar volgens mij zet hij altijd de window_begintijd op 12 uur en window_eindtijd op 16 uur. Ik vrees dat dit zo niet gaat werken.
Ik ben wel druk de komende dagen (o.a. met dit topic), maar ik zal zien of ik een uurtje kan vrijmaken om iets te maken. Misschien zijn er meer lezers die dit als een leuke uitdaging zien?

[Undertilted]

KC27 schreef op maandag 14 april 2025 @ 23:36:
[...]


Dat ziet er inderdaad heel ingewikkeld uit.

KOPEN

NL: kWh prijs = [spotprijs + opslag] * (1+btw)

BE: kWh prijs = [spotprijs*multiplier*(1+btw) + som_opslag_en_heffingen_btw_plichtig*(1+btw) + som_heffingen_zonder_btw

te vereenvoudigen tot

kWh_prijs = spotprijs*X + U

idem met verkopen

punt is gewoon dat je de spotprijs moet kunnen vermenigvuldigen én er bij kunnen optellen.

Ik denk dat de specifieke formule beter in de documentatie terecht komt. Ik wil je daar gerust bij helpen!

[KC27]

stoner1978 schreef op dinsdag 15 april 2025 @ 05:49:
Geen probleem hoor, ik vindt het wel leuk om er even mee te stoeien.
Door jou opmerking bedenk ik me net dat er geen rekening gehouden wordt met opwarming per uur. Nu kijkt hij alleen naar programma lengte. Dit moet meer dynamisch zijn dan zal de begin tijd en dus eind tijd ook veranderen

[...]

Ik heb mbt programmeren hele slechte ervaringen met ChatGPT.
Dat wordt met jouw ervaringen andermaal bevestigd.
Ik heb een begin gemaakt van een template in Home Assistant.
Je kunt deze om te testen kopiëren naar Ontwikkelhulpmiddelen\Sjablonen, je moet dan nog wel de naam van de sensor met de actuele boilertemperatuur aanpassen;

code:

{% set bovengrens = 46 %}
{% set ondergrens = 38 %}
{% set afkoeling = 0.4 %}
{% set huidige_temp = states('sensor.boiler_gemeten') | float(0) %}
{{ huidige_temp }}
{% set delta_tijd = timedelta(hours=(max(huidige_temp, bovengrens) - bovengrens) / afkoeling) %}
{{ delta_tijd }}
{% set verwarmen_vanaf = now() + delta_tijd %}
{{ verwarmen_vanaf }}
{% set x = as_timestamp(verwarmen_vanaf)/900  %}
{% set x  = 900 * (x |round(0, method="floor")) %}
{{ x }}
{% set verwarmen_vanaf = x | timestamp_custom("%H:%M") %}
{{ verwarmen_vanaf }}
{% set delta_tijd = timedelta(hours=(max(huidige_temp, ondergrens) - ondergrens) / afkoeling) %}
{{ delta_tijd }}
{% set verwarmen_tot = now() + delta_tijd %}
{{ verwarmen_tot }}
{% set x = as_timestamp(verwarmen_tot)/900  %}
{% set x  = 900 * (x |round(0, method="floor")) %}
{{ x }}
{% set verwarmen_tot = x | timestamp_custom("%H:%M") %}
{{ verwarmen_tot }}

Je kunt nu hiermee spelen door de bovenegrens, de ondergrens en de afkoeling in te stellen.
De stukken code tussen {{ en }} zijn alleen bedoeld om de berekeningsresulaten rechts af te drukken:

Daarna kun je het eerste stuk en het tweede stuk invullen bij een "value template" voor window_start en window_end in een veel simpeler automation dan die je liet zien..
Misschien kom ik daar vanmiddag nog toe.

[broekieman]

Ik lees alleen nog mee, maar wil speciaal mijn waardering uitspreken naar KC27 voor dit mooie initiatief/project.

Ik ben zo druk met van alles, dus gooi het volgende op. Mijn systeem is zonnepanelen met Enphase micro inverters. 2x 15kwh batterijen aan Victron Multiplus.

Is er iemand die ook zoiets heeft zodat ik de config kan plakken om entities te wijzigen zodat ik er een beeld van krijg om enthousiast te worden en tijd te gaan maken 👍

[Torch1969]

KC27 schreef op maandag 14 april 2025 @ 22:51:
[...]


Volgens mij is alles goed gegaan, ik was alleen vergeten de release te vernieuwen. Maar het ophalen van een nieuwe versie gebeurt niet met de release-data. Versienummer onderin klopt wel.
Die nieuwe release staat er nu!

Jouw foutmelding sqlite3.DatabaseError: database disk image is malformed zegt dat je HA-database is is beschadigd.
Dat kan eigenlijk niet door DAO komen, want DAO leest alleen maar uit de HA database. Dit is dan ook de eerste keer dat ik hiervan hoor/lees.

Je zou eerst het volgende kunnen proberen:

• stop DAO
• stop Home Assistant
• start Home Assistant
• check de system logging van Home Assistant
• start DAO

Als de fout blijft terugkomen dan zal de db moeten worden hersteld met deze commando's/akties:

• stop HA en DAO
• kopieer home-assistant_v2.db uit de config-directory (waar ook configuration.yaml staat) naar een machine waar je sqlite3 op kunt installeren
• run het volgende commando "sqlite3 home-assistant_v2.db ".recover" | sqlite3 ha_new.db". Dat kan (afhankelijk van de grootte) een paar minuten duren.
• kopieer ha_new naar de config-directory en hernoem deze naar home-assistant_v2.db (eerst de oude weghalen)
• start HA en DAO

Het probleem lijkt opgelost. Heb je advies gevolgd om de boel te stoppen en herstarten en de log van HA te bekijken. Daarin geen “sql db malformat” foutmeldingen. Wel een melding over 2 entities die ik ontsluit richting dao. Dit zijn de groep helpers die de 2 tarief kWh tellers sommeert. Die hebben geen stateclass. Ik heb die helpers verwijderd uit de dao config en de oorspronkelijke entiteiten opgenomen. Nu lijkt de report en savings functionaliteit goed te draaien na elk hele uur.
Blijft vreemd dat de fout na herstarten dao niet optrad, maar bij actualisatie na hele uur wel (daarom denk ik ook niet dat mijn HA database corrupt is). Heb je daar een andere manier van uitlezen HA-database?

[KC27]

Torch1969 schreef op dinsdag 15 april 2025 @ 12:47:
[...]


Het probleem lijkt opgelost. Heb je advies gevolgd om de boel te stoppen en herstarten en de log van HA te bekijken. Daarin geen “sql db malformat” foutmeldingen. Wel een melding over 2 entities die ik ontsluit richting dao. Dit zijn de groep helpers die de 2 tarief kWh tellers sommeert. Die hebben geen stateclass. Ik heb die helpers verwijderd uit de dao config en de oorspronkelijke entiteiten opgenomen. Nu lijkt de report en savings functionaliteit goed te draaien na elk hele uur.
Blijft vreemd dat de fout na herstarten dao niet optrad, maar bij actualisatie na hele uur wel (daarom denk ik ook niet dat mijn HA database corrupt is). Heb je daar een andere manier van uitlezen HA-database?

De sensor die de twee tellers/sensoren sommeert wordt waarschijnlijk niet (of later of met een andere datum/tijd) opgeslagen in de HA database.
Hoe heb je het geconfigureerd in het energiedashboard van HA: ook de som of die twee sensoren apart?

Je kunt met DB Browser for SQLite in de database kijken of en hoe die gesommeerde sensor wordt opgeslagen in de tabel "statistics". De tabel "statistics_meta" geeft het id waar je op moet zoeken in "statistics".

Ik werk zelf met mysql, zowel voor HA als voor DAO.
DAO sommeert zelf de twee sensoren zoals ik ze heb opgegeven bij report (en zo staan ze ook in het energiedashboard van HA):

code:

  "report":{
    "entities grid consumption" : [
      "sensor.grid_consumption_low",
      "sensor.grid_consumption_high"
    ],
    "entities grid production" : [
      "sensor.grid_production_low",
      "sensor.grid_production_high"
    ],
   ....

[ Voor 3% gewijzigd door KC27 op 15-04-2025 15:37 ]

[Torch1969]

KC27 schreef op dinsdag 15 april 2025 @ 13:51:
[...]

De sensor die de twee tellers/sensoren sommeert wordt waarschijnlijk niet (of later of met een andere datum/tijd) opgeslagen in de HA database.
Hoe heb je het geconfigureerd in het energiedashboard van HA: ook de som of die twee sensoren apart?

Je kunt met DB Browser for SQLite in de database kijken of en hoe die gesommeerde sensor wordt opgeslagen in de tabel "statistics". De tabel "statistics_meta" geeft het id waar je op moet zoeken in "statistics".

Ik werk zelf met mysql, zowel voor HA als voor DAO.
DAO sommeert zelf de twee sensoren zoals ik ze heb opgegeven bij report (en zo staan ze ook in het energiedashboard van HA):

code:

  "report":{
    "entities grid consumption" : [
      "sensor.grid_consumption_low",
      "sensor.grid_consumption_high"
    ],
    "entities grid production" : [
      "sensor.grid_production_low",
      "sensor.grid_production_high"
    ],
   ....

In energydashboard (en eigen dashboards) gebruik ik die som. Tot nu toe nog geen afwijkingen of fouten mee gehad.
Ik heb dao met standaard instellingen op SQLite zowel voor HA als dao database.
Rondneuzen met SQL in de HA database is iets voor de toekomst. Ik heb nu de afzonderlijke kWh sensoren voor hoog en laag tarief opgenomen en dat werkt prima. Dank voor het meedenken.


@KC27 Nog een andere vraag. Ik zie dat dao de energieprijzen afrond op 3 cijfers achter de komma. Tot nu toe ben ik gewend om dit op 4 cijfers te doen. Zo doet zonneplan app het ook (prijs in centen met 2 cijfers achter de komma). Het lijkt pietluttig, maar op uur en dag (en maand en jaar) niveau geeft dit forse afrond verschillen.

Heb je de keuze voor 3 cijfers (voor energieprijzen) bewust gemaakt en ooit overwogen om dit (als optie) ook op 4 cijfers te doen? Dat zou wel mijn wens zijn. Dan komt de rapportage van dao beter overeen met de zonneplan app en energie afrekening.

[KC27]

KC27 schreef op dinsdag 15 april 2025 @ 12:11:
[...]

Ik heb mbt programmeren hele slechte ervaringen met ChatGPT.
Dat wordt met jouw ervaringen andermaal bevestigd.
Ik heb een begin gemaakt van een template in Home Assistant.
Je kunt deze om te testen kopiëren naar Ontwikkelhulpmiddelen\Sjablonen, je moet dan nog wel de naam van de sensor met de actuele boilertemperatuur aanpassen;

code:

{% set bovengrens = 46 %}
{% set ondergrens = 38 %}
{% set afkoeling = 0.4 %}
{% set huidige_temp = states('sensor.boiler_gemeten') | float(0) %}
{{ huidige_temp }}
{% set delta_tijd = timedelta(hours=(max(huidige_temp, bovengrens) - bovengrens) / afkoeling) %}
{{ delta_tijd }}
{% set verwarmen_vanaf = now() + delta_tijd %}
{{ verwarmen_vanaf }}
{% set x = as_timestamp(verwarmen_vanaf)/900  %}
{% set x  = 900 * (x |round(0, method="floor")) %}
{{ x }}
{% set verwarmen_vanaf = x | timestamp_custom("%H:%M") %}
{{ verwarmen_vanaf }}
{% set delta_tijd = timedelta(hours=(max(huidige_temp, ondergrens) - ondergrens) / afkoeling) %}
{{ delta_tijd }}
{% set verwarmen_tot = now() + delta_tijd %}
{{ verwarmen_tot }}
{% set x = as_timestamp(verwarmen_tot)/900  %}
{% set x  = 900 * (x |round(0, method="floor")) %}
{{ x }}
{% set verwarmen_tot = x | timestamp_custom("%H:%M") %}
{{ verwarmen_tot }}

Je kunt nu hiermee spelen door de bovenegrens, de ondergrens en de afkoeling in te stellen.
De stukken code tussen {{ en }} zijn alleen bedoeld om de berekeningsresulaten rechts af te drukken:
[Afbeelding]
Daarna kun je het eerste stuk en het tweede stuk invullen bij een "value template" voor window_start en window_end in een veel simpeler automation dan die je liet zien..
Misschien kom ik daar vanmiddag nog toe.

@stoner1978
Ik heb een automation gemaakt.
Kun jij hiermee verder?

YAML:

alias: bereken opwarm-window boiler
description: ""
mode: single
triggers:
  - minutes: 59
    seconds: 0
    trigger: time_pattern
conditions:
  - condition: numeric_state
    entity_id: sensor.plug_warmtepomp_power
    below: 5
actions:
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.start_window_wasmachine
    data:
      time: >-
        {% set bovengrens = 43 %}
        {% set afkoeling = 0.4 %}
        {% set huidige_temp = states('sensor.boiler_gemeten') | float(0) %}
        {% set delta_tijd = timedelta(hours=(max(huidige_temp, bovengrens) - bovengrens) / afkoeling) %}
        {% set verwarmen_vanaf = now() + delta_tijd %}
        {% set x = as_timestamp(verwarmen_vanaf)/900  %}
        {% set x  = 900 * (x |round(0, method="floor")) %}
        {% set verwarmen_vanaf = x | timestamp_custom("%H:%M") %}
        {{ verwarmen_vanaf }}
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.end_window_wasmachine
    data:
      time: >-
        {% set ondergrens = 38 %}
        {% set afkoeling = 0.4 %}
        {% set huidige_temp = states('sensor.boiler_gemeten') | float(0) %}       
        {% set delta_tijd = timedelta(hours=(max(huidige_temp, ondergrens) - ondergrens) / afkoeling) %}
        {% set verwarmen_tot = now() + delta_tijd %}
        {% set x = as_timestamp(verwarmen_tot)/900  %}
        {% set x  = 900 * (x |round(0, method="floor")) %}
        {% set verwarmen_tot = x | timestamp_custom("%H:%M") %}
        {{ verwarmen_tot }}

[stoner1978]

Bedankt!
Ik ben wel enig zins genoodzaakt om chatGPT te raadplegen, mijn kennis van programmeren is vrij laag maar sinds Home assistant hier het huis is ingeslopen lukt het mij nu om yaml een beetje te begrijpen, ook icoontjes laten draaien, card mod ed lukt aardig maar templates, jinja sjablonen blijft heel lastig.
Chatgpt heeft mij al vaak geholpen hierin en soms moeten we iets op 2 of 3 manieren proberen als er een foutmelding komt. Blijven voeren heb ik het idee dan komt het goed.

Ik ga er mee aan de slag en zal het een aantal dagen gaan simuleren.
Ik meld me weer, nogmaals dank

KC27 schreef op dinsdag 15 april 2025 @ 19:48:
[...]

@stoner1978
Ik heb een automation gemaakt.
Kun jij hiermee verder?

YAML:

alias: bereken opwarm-window boiler
description: ""
mode: single
triggers:
  - minutes: 59
    seconds: 0
    trigger: time_pattern
conditions:
  - condition: numeric_state
    entity_id: sensor.plug_warmtepomp_power
    below: 5
actions:
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.start_window_wasmachine
    data:
      time: >-
        {% set bovengrens = 43 %}
        {% set afkoeling = 0.4 %}
        {% set huidige_temp = states('sensor.boiler_gemeten') | float(0) %}
        {% set delta_tijd = timedelta(hours=(max(huidige_temp, bovengrens) - bovengrens) / afkoeling) %}
        {% set verwarmen_vanaf = now() + delta_tijd %}
        {% set x = as_timestamp(verwarmen_vanaf)/900  %}
        {% set x  = 900 * (x |round(0, method="floor")) %}
        {% set verwarmen_vanaf = x | timestamp_custom("%H:%M") %}
        {{ verwarmen_vanaf }}
  - service: input_datetime.set_datetime
    target:
      entity_id: input_datetime.end_window_wasmachine
    data:
      time: >-
        {% set ondergrens = 38 %}
        {% set afkoeling = 0.4 %}
        {% set huidige_temp = states('sensor.boiler_gemeten') | float(0) %}       
        {% set delta_tijd = timedelta(hours=(max(huidige_temp, ondergrens) - ondergrens) / afkoeling) %}
        {% set verwarmen_tot = now() + delta_tijd %}
        {% set x = as_timestamp(verwarmen_tot)/900  %}
        {% set x  = 900 * (x |round(0, method="floor")) %}
        {% set verwarmen_tot = x | timestamp_custom("%H:%M") %}
        {{ verwarmen_tot }}

[KC27]

Undertilted schreef op dinsdag 15 april 2025 @ 11:06:
[...]


KOPEN

NL: kWh prijs = [spotprijs + opslag] * (1+btw)

BE: kWh prijs = [spotprijs*multiplier*(1+btw) + som_opslag_en_heffingen_btw_plichtig*(1+btw) + som_heffingen_zonder_btw

te vereenvoudigen tot

kWh_prijs = spotprijs*X + U

idem met verkopen

punt is gewoon dat je de spotprijs moet kunnen vermenigvuldigen én er bij kunnen optellen.

Ik denk dat de specifieke formule beter in de documentatie terecht komt. Ik wil je daar gerust bij helpen!

Dank voor je uitleg.
De huidige tariefberekening is helemaal toegesneden op de Nederlandse situatie met dynamische tarieven.
Er was ook al een vraag van iemand met een vast energiecontract. Dat kan nu ook niet met DAO.

Ik speel nu met de gedachte om het helemaal "open" te maken zodat de gebruikers zelf een formule kunnen definiëren. Bijvoorbeeld NL situatie met een dynamisch contract geven zij op:

code:

tarief_levering = (da_ex + eb_levering + opslag_levering) * (1 + btw_hoog)

BE situatie (jouw voorbeeld):

code:

tarief_levering = da_ex * multiplier * (1 + btw_hoog) + som_opslag_en_heffingen_btw_plichtig*(1+btw) + som_heffingen_zonder_btw

waarbij geldt dat alle gebruikte termen en factoren (behalve da_ex), tijdafhankelijk moeten worden gedefinieerd in de settings.
Dat betekent een aantal zaken:

• Het ophalen van de day-ahead prijzen moet land afhankelijk worden gemaakt (kan nu alleen NL)
• Er zijn wellicht ook een aantal termen of factoren die ook anders zijn bij hoog_tarief (werkdagen tussen 7 en 23uur) en laag tarief (werkdagen tussen 23 en 7uur, zaterdagen en zon- en feestdagen).
• Feestdagen zijn gedeeltelijk ook weer landafhankelijk.

Kortom een omvangrijke klus.
Voordat ik ermee aan de gang ga, wil ik eerst de impact van dit idee goed in beeld hebben.
Ik wil ook deze maand het 15min interval testbaar klaar hebben, dat heeft prioriteit.

Mijn vragen aan jou op dit moment zijn:

• Hoe haal jij nu de Belgische spotprijzen op, bij welke provider (entsoe, nordpool, epex?)
• Zijn er in België tarief-componenten (behalve de spotprijs), die in de tijd variëren (hoog/laag of anderszins) en zo ja welke?

[Undertilted]

Mijn vragen aan jou op dit moment zijn:

• Hoe haal jij nu de Belgische spotprijzen op, bij welke provider (entsoe, nordpool, epex?)

via de ENTSOe, via hun API

• Zijn er in België tarief-componenten (behalve de spotprijs), die in de tijd variëren (hoog/laag of anderszins) en zo ja welke?

Het idee van dynamische contracten is net dat alle kostenvariatie in de spotprijs zit. Maar in principe kan er voor zowel afname als injectie een dag en nacht tarief/formule zijn. Ik denk niet dat er 1 leverancier is die dit aanbiedt. Dit zou niet logisch zijn.

Wij hebben wel een capaciteitstarief waarbij de maand-kwartierpiek (max kWh per kwartier) per maand, en zelfs per jaar wordt afgerekend. Maar dat kunnen users nu al configureren.

[sMoKeFiSh]

Ik probeer nu een automation in HA te maken voor het laden/ontladen van de accu. Klopt het dat DAO het laden/ontladen via de entity gedefinieerd in "entity set operating mode" activeert? Hoe weet ik (HA) of er geladen van GRID of ontladen naar GRID moet worden?

[bvw]

sMoKeFiSh schreef op woensdag 16 april 2025 @ 10:56:
Ik probeer nu een automation in HA te maken voor het laden/ontladen van de accu. Klopt het dat DAO het laden/ontladen via de entity gedefinieerd in "entity set operating mode" activeert? Hoe weet ik (HA) of er geladen van GRID of ontladen naar GRID moet worden?

Ik heb nog geen echte accu, dus probeer het nu met battery_sim. Ik heb t zo geinterpreteerd in m'n automation, ben benieuwd of het klopt.

code:

alias: DAO batterijsturing
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.dao_batterij_vermogen
  - trigger: state
    entity_id:
      - input_boolean.dao_batterij_balancing
    enabled: false
  - trigger: state
    entity_id:
      - input_select.dao_batterij_operating_mode
    enabled: false
conditions: []
actions:
  - if:
      - condition: state
        entity_id: input_boolean.dao_batterij_balancing
        state: "on"
    then:
      - action: number.max
        metadata: {}
        data: {}
        target:
          entity_id:
            - number.battery_sim_zendure_solarflow_2400ac_5_76kwh_charge_limit
      - action: number.max
        metadata: {}
        data: {}
        target:
          entity_id:
            - >-
              number.battery_sim_zendure_solarflow_2400ac_5_76kwh_discharge_limit
      - action: select.select_option
        metadata: {}
        data:
          option: default_mode
        target:
          entity_id:
            - select.battery_sim_zendure_solarflow_2400ac_5_76kwh_battery_mode
  - if:
      - condition: state
        entity_id: input_boolean.dao_batterij_balancing
        state: "off"
      - condition: state
        entity_id: input_select.dao_batterij_operating_mode
        state: Aan
      - condition: template
        value_template: "{{ states('input_number.dao_batterij_vermogen') | int() >= 0 }}"
    then:
      - action: number.set_value
        data:
          value: "{{ states('sensor.dao_batterij_vermogen') | float(0) / 1000 }}"
        target:
          entity_id: number.battery_sim_zendure_solarflow_2400ac_5_76kwh_charge_limit
      - action: select.select_option
        metadata: {}
        data:
          option: force_charge
        target:
          entity_id:
            - select.battery_sim_zendure_solarflow_2400ac_5_76kwh_battery_mode
  - if:
      - condition: state
        entity_id: input_boolean.dao_batterij_balancing
        state: "off"
      - condition: state
        entity_id: input_select.dao_batterij_operating_mode
        state: Aan
      - condition: template
        value_template: "{{ states('input_number.dao_batterij_vermogen') | int() < 0 }}"
    then:
      - action: number.set_value
        data:
          value: "{{ states('sensor.dao_batterij_vermogen') | float(0) / 1000 * -1  }}"
        target:
          entity_id: number.battery_sim_zendure_solarflow_2400ac_5_76kwh_discharge_limit
      - action: select.select_option
        metadata: {}
        data:
          option: force_discharge
        target:
          entity_id:
            - select.battery_sim_zendure_solarflow_2400ac_5_76kwh_battery_mode
mode: single

[Torch1969]

sMoKeFiSh schreef op woensdag 16 april 2025 @ 10:56:
Ik probeer nu een automation in HA te maken voor het laden/ontladen van de accu. Klopt het dat DAO het laden/ontladen via de entity gedefinieerd in "entity set operating mode" activeert? Hoe weet ik (HA) of er geladen van GRID of ontladen naar GRID moet worden?

Daarvoor is toch:

code:

       "entity set power feedin": "input_number.dao_sessy_dllu_power_setpoint",

Die naam van de variabele in HA is uiteraard door mijzelf gekozen.

Mijn aanname, negatieve waarde is laden, positieve waarde is leveren.

[KC27]

Torch1969 schreef op woensdag 16 april 2025 @ 17:34:
[...]


Daarvoor is toch:

code:

       "entity set power feedin": "input_number.dao_sessy_dllu_power_setpoint",

Die naam van de variabele in HA is uiteraard door mijzelf gekozen.

Mijn aanname, negatieve waarde is laden, positieve waarde is leveren.

@sMoKeFiSh
Inderdaad via de entity set power feedin krijg je het door DAO berekende laad- of ontlaadvermogen van de batterij. Maar een positief getal betekent laden en een negatief getal betekent ontladen.
Bij de sessy is dat andersom dus moet je het getal met -1 vermenigvuldigen voordat je het naar de sessy stuurt.
Daarnaast is er nog een optionele entiteit waarmee je de omvormer/inverter aan/uit kunt zetten. Die vul je in bij: entity set operating mode.

[desalnietemin]

KC27 schreef op dinsdag 15 april 2025 @ 12:11:
[...]

Ik heb mbt programmeren hele slechte ervaringen met ChatGPT.
Dat wordt met jouw ervaringen andermaal bevestigd.
Ik heb een begin gemaakt van een template in Home Assistant.
Je kunt deze om te testen kopiëren naar Ontwikkelhulpmiddelen\Sjablonen, je moet dan nog wel de naam van de sensor met de actuele boilertemperatuur aanpassen;

code:

{% set bovengrens = 46 %}
{% set ondergrens = 38 %}
{% set afkoeling = 0.4 %}
{% set huidige_temp = states('sensor.boiler_gemeten') | float(0) %}
{{ huidige_temp }}
{% set delta_tijd = timedelta(hours=(max(huidige_temp, bovengrens) - bovengrens) / afkoeling) %}
{{ delta_tijd }}
{% set verwarmen_vanaf = now() + delta_tijd %}
{{ verwarmen_vanaf }}
{% set x = as_timestamp(verwarmen_vanaf)/900  %}
{% set x  = 900 * (x |round(0, method="floor")) %}
{{ x }}
{% set verwarmen_vanaf = x | timestamp_custom("%H:%M") %}
{{ verwarmen_vanaf }}
{% set delta_tijd = timedelta(hours=(max(huidige_temp, ondergrens) - ondergrens) / afkoeling) %}
{{ delta_tijd }}
{% set verwarmen_tot = now() + delta_tijd %}
{{ verwarmen_tot }}
{% set x = as_timestamp(verwarmen_tot)/900  %}
{% set x  = 900 * (x |round(0, method="floor")) %}
{{ x }}
{% set verwarmen_tot = x | timestamp_custom("%H:%M") %}
{{ verwarmen_tot }}

Je kunt nu hiermee spelen door de bovenegrens, de ondergrens en de afkoeling in te stellen.
De stukken code tussen {{ en }} zijn alleen bedoeld om de berekeningsresulaten rechts af te drukken:
[Afbeelding]
Daarna kun je het eerste stuk en het tweede stuk invullen bij een "value template" voor window_start en window_end in een veel simpeler automation dan die je liet zien..
Misschien kom ik daar vanmiddag nog toe.

Hi @KC27 en @stoner1978,

Super bedankt voor de info. Graag wil ik mijn zeer simpele e-Boiler als eerste apparaat in DAO gaan zetten:

- Het betreft een e-Boiler van 80L als hotfill voor mijn badkamer
- Het is een Mono-Plus (Type: 07.14.28.049 versie: 3) - 2500W van het merk Ithodaalderop, link installatiehandleiding)
- Helaas niet zo'n slim ding, ik kan bijvoorbeeld nergens de temperatuur zien. Ik wil nog een temperatuur sensor op de leiding bevestigen om wat meer inzicht te krijgen (zie: link).

Nu gebruik ik de de AIO Energy Management integratie waarbij ik de 5 goedkoopste uren laat bepalen (ENTSO-E day-ahead). Vervolgens heb ik twee automatiseringen gemaakt die de shelly plug aan of uit zet.
Dat werkt goed, zodra de boiler (in het eerste goedkoopste uur) aan wordt gezet dan gaat deze verwarmen.

Op tijd moment optimaliseert mijn Nibe warmtepomp o.b.v. Smart Price Adaption maar dat wil ik gaan vervangen door eigen aansturing middels Smart Grid Ready sturing.

Aangezien ik dus van steeds meer apparaten (Nibe-WP, Zon-PV, thuislaapunt etc.) het verbruik wil optimaliseren en verplaatsen o.b.v. tarieven en optimalisatie eigen verbruik leek het mij goed om gebruik te gaan maken van DAO.

De vraag is echter hoe kan ik deze het beste in de config zetten. Ik heb de docs helemaal doorgenomen en het lijkt het meest logische om gebruik te gaan maken van de "machines". configuratie.

Daarbij dien ik bij power een lijst van gemiddeld vermogens in watt per kwartier in te vullen.
Onderstaand van een drietal dagen het vermogen, wat ik kan zien is:
- de e-Boiler heeft een gemiddeld vermogen van 2450W
- Het gedrag is nu zo dat zodra deze aan wordt gezet (nu het eerste goedkoopste uur) deze nu gemiddeld zo'n 1 uur en 20 minuten draait. Dan stopt en ongeveer 2 uur en 10 minuten daarna weer 5 minuten aan gaat
- mijn insteek zou zijn om in eerste instantie eens te kijken of ik met een programma van 5 x 15 min. uit de voeten kan?

Hoe zou de code eruit kunnen komen te zien? Aan uitzetten doe ik nu via entiteit: switch.hotfill_badkamers (AAN of UIT)

Alvast hartelijk dank voor jullie hulp.

[ Voor 69% gewijzigd door desalnietemin op 16-04-2025 19:09 ]

[Torch1969]

@KC27 Op basis van welke locatie worden de meteogegevens opgehaald?
Is het mogelijk om een optionele parameter in de config op te nemen met de postcode en die mee te geven in de API van metroserver (ik zie dat dat mogelijk is). Daarmee krijgen we nog betere voorspelling van zon opbrengst op de daadwerkelijke locatie.

En/of locatie in noorderbreedte en oosterlengte opgeven en die dan ook meteen gebruiken voor berekening zonnepanelenopbrengst?

[ Voor 17% gewijzigd door Torch1969 op 16-04-2025 20:03 ]

[stoner1978]

hoi desalniettemin,

met zo'n esphome sensor lees ik de temperatuur ook uit, misschien even onder de kap kijken zoals in de handleiding "vervangen maximaalthermostaat" staat. als het goed is zit er ook al een temperatuurvoeler in, kijk of je daar een eigen voeler bij in kan pielen. dan krijg je de beste meting. je hebt ook kleinere sensoren; https://www.hobbyelectronica.nl/product/ds18b20/
hij komt niet in het water dus hoeft niet waterdicht te zijn.
Als je de temperatuur hebt kan je hem ook bij Boiler invullen volgens mij, hij schakelt gewoon aan/uit. cop op 1.0 zetten, volume 80l, elec. power 2450. bij minimale temperatuur even testen wat minimaal kan zodat je niet koud staat te douchen.

desalnietemin schreef op woensdag 16 april 2025 @ 19:09:
[...]


Hi @KC27 en @stoner1978,

Super bedankt voor de info. Graag wil ik mijn zeer simpele e-Boiler als eerste apparaat in DAO gaan zetten:

- Het betreft een e-Boiler van 80L als hotfill voor mijn badkamer
- Het is een Mono-Plus (Type: 07.14.28.049 versie: 3) - 2500W van het merk Ithodaalderop, link installatiehandleiding)
- Helaas niet zo'n slim ding, ik kan bijvoorbeeld nergens de temperatuur zien. Ik wil nog een temperatuur sensor op de leiding bevestigen om wat meer inzicht te krijgen (zie: link).

Nu gebruik ik de de AIO Energy Management integratie waarbij ik de 5 goedkoopste uren laat bepalen (ENTSO-E day-ahead). Vervolgens heb ik twee automatiseringen gemaakt die de shelly plug aan of uit zet.
Dat werkt goed, zodra de boiler (in het eerste goedkoopste uur) aan wordt gezet dan gaat deze verwarmen.

Op tijd moment optimaliseert mijn Nibe warmtepomp o.b.v. Smart Price Adaption maar dat wil ik gaan vervangen door eigen aansturing middels Smart Grid Ready sturing.

Aangezien ik dus van steeds meer apparaten (Nibe-WP, Zon-PV, thuislaapunt etc.) het verbruik wil optimaliseren en verplaatsen o.b.v. tarieven en optimalisatie eigen verbruik leek het mij goed om gebruik te gaan maken van DAO.

De vraag is echter hoe kan ik deze het beste in de config zetten. Ik heb de docs helemaal doorgenomen en het lijkt het meest logische om gebruik te gaan maken van de "machines". configuratie.

Daarbij dien ik bij power een lijst van gemiddeld vermogens in watt per kwartier in te vullen.
Onderstaand van een drietal dagen het vermogen, wat ik kan zien is:
- de e-Boiler heeft een gemiddeld vermogen van 2450W
- Het gedrag is nu zo dat zodra deze aan wordt gezet (nu het eerste goedkoopste uur) deze nu gemiddeld zo'n 1 uur en 20 minuten draait. Dan stopt en ongeveer 2 uur en 10 minuten daarna weer 5 minuten aan gaat
- mijn insteek zou zijn om in eerste instantie eens te kijken of ik met een programma van 5 x 15 min. uit de voeten kan?

Hoe zou de code eruit kunnen komen te zien? Aan uitzetten doe ik nu via entiteit: switch.hotfill_badkamers (AAN of UIT)

Alvast hartelijk dank voor jullie hulp.


[Afbeelding]

[Afbeelding]

[Afbeelding]

[KC27]

Torch1969 schreef op woensdag 16 april 2025 @ 19:48:
@KC27 Op basis van welke locatie worden de meteogegevens opgehaald?
Is het mogelijk om een optionele parameter in de config op te nemen met de postcode en die mee te geven in de API van metroserver (ik zie dat dat mogelijk is). Daarmee krijgen we nog betere voorspelling van zon opbrengst op de daadwerkelijke locatie.

En/of locatie in noorderbreedte en oosterlengte opgeven en die dan ook meteen gebruiken voor berekening zonnepanelenopbrengst?

Ik haal de locatiegegevens (longitude en altitude) uit Home Assistant.
Als die kloppen dan kloppen de meteogegevens ook (als het knmi en meteoserver hun werk goed doen 😉)

[KC27]

@Torch1969
Als je loglevel op debug zet, zie je in de logging je coördinaten staan.
Ook de tijdzone (nodig voor omrekenen van datum/tijd naar timestamp en vice versa komt uit HomeAssistant.

[desalnietemin]

stoner1978 schreef op woensdag 16 april 2025 @ 20:09:
hoi desalniettemin,

met zo'n esphome sensor lees ik de temperatuur ook uit, misschien even onder de kap kijken zoals in de handleiding "vervangen maximaalthermostaat" staat. als het goed is zit er ook al een temperatuurvoeler in, kijk of je daar een eigen voeler bij in kan pielen. dan krijg je de beste meting. je hebt ook kleinere sensoren; https://www.hobbyelectronica.nl/product/ds18b20/
hij komt niet in het water dus hoeft niet waterdicht te zijn.
Als je de temperatuur hebt kan je hem ook bij Boiler invullen volgens mij, hij schakelt gewoon aan/uit. cop op 1.0 zetten, volume 80l, elec. power 2450. bij minimale temperatuur even testen wat minimaal kan zodat je niet koud staat te douchen.

[...]

@stoner1978 thanks voor het meedenken en wat een tip die handleiding vervangen maximaal thermostaat! Blijkbaar zitten er twee temperatuurvoelers in lees ik (maximaal thermostaat en regelthermostaat). Ik ga even kijken als ik de kap goed eraf kan krijgen (hij is ingebouwd in een zeer kleine ruimte, niet echt handig . Eerst nog even wachten tot mijn nieuwe Dallas DS18b20 temp. sensoren binnen komen van Ali.
To be continued...

[KC27]

@Torch1969
Ik heb het verhaal van docker compose om DAO te installeren in een separate image/container (dus geen addon) opgenomen in de TS.
Zou je een en ander willen checken?

[KC27]

desalnietemin schreef op woensdag 16 april 2025 @ 19:09:
[...]


Hi @KC27 en @stoner1978,

Super bedankt voor de info. Graag wil ik mijn zeer simpele e-Boiler als eerste apparaat in DAO gaan zetten:

- Het betreft een e-Boiler van 80L als hotfill voor mijn badkamer
- Het is een Mono-Plus (Type: 07.14.28.049 versie: 3) - 2500W van het merk Ithodaalderop, link installatiehandleiding)
- Helaas niet zo'n slim ding, ik kan bijvoorbeeld nergens de temperatuur zien. Ik wil nog een temperatuur sensor op de leiding bevestigen om wat meer inzicht te krijgen (zie: link).

Nu gebruik ik de de AIO Energy Management integratie waarbij ik de 5 goedkoopste uren laat bepalen (ENTSO-E day-ahead). Vervolgens heb ik twee automatiseringen gemaakt die de shelly plug aan of uit zet.
Dat werkt goed, zodra de boiler (in het eerste goedkoopste uur) aan wordt gezet dan gaat deze verwarmen.

Op tijd moment optimaliseert mijn Nibe warmtepomp o.b.v. Smart Price Adaption maar dat wil ik gaan vervangen door eigen aansturing middels Smart Grid Ready sturing.

Aangezien ik dus van steeds meer apparaten (Nibe-WP, Zon-PV, thuislaapunt etc.) het verbruik wil optimaliseren en verplaatsen o.b.v. tarieven en optimalisatie eigen verbruik leek het mij goed om gebruik te gaan maken van DAO.

De vraag is echter hoe kan ik deze het beste in de config zetten. Ik heb de docs helemaal doorgenomen en het lijkt het meest logische om gebruik te gaan maken van de "machines". configuratie.

Daarbij dien ik bij power een lijst van gemiddeld vermogens in watt per kwartier in te vullen.
Onderstaand van een drietal dagen het vermogen, wat ik kan zien is:
- de e-Boiler heeft een gemiddeld vermogen van 2450W
- Het gedrag is nu zo dat zodra deze aan wordt gezet (nu het eerste goedkoopste uur) deze nu gemiddeld zo'n 1 uur en 20 minuten draait. Dan stopt en ongeveer 2 uur en 10 minuten daarna weer 5 minuten aan gaat
- mijn insteek zou zijn om in eerste instantie eens te kijken of ik met een programma van 5 x 15 min. uit de voeten kan?

Hoe zou de code eruit kunnen komen te zien? Aan uitzetten doe ik nu via entiteit: switch.hotfill_badkamers (AAN of UIT)

Alvast hartelijk dank voor jullie hulp.


[Afbeelding]

[Afbeelding]

[Afbeelding]

Ik heb zelf een Alpha Innotec (zusje van Nibe) warmtepomp met ook zo'n "smart grid ready" optie.
Maar ik heb daar van afgezien.
Uiteindelijk stuurt die "smart grid ready" de stooklijn in grote stappen omhoog of omlaag.
DAO heeft ook de mogelijkheid om de stooklijn verhoging/verlaging te berekenen. Dit heeft enkele voordelen t.o.v. "smart grid ready":

• Je hoeft geen elektronica te kopen en te installeren (tenminste als je via modbus of anderzins de instellingen van je wp kunt wijzigen)
• Je kunt de stooklijnverschuiving instellen op 0.1 K en dat werkt veel geleidelijker richting je wp, zodat deze minder aan/uit gaat. Minder start/stops betekent minder slijtage.
• DAO berekent ook het verwachte vermogen van je wp zodat je het geheel kunt meenemen in een goede vermogensspreiding.
• Als straks de saldering eraf gaat wil je zo veel mogelijk je eigen pv-productie gebruiken. Hoe gaat "smart-grid ready" daar mee om?

[Torch1969]

KC27 schreef op donderdag 17 april 2025 @ 10:09:
@Torch1969
Ik heb het verhaal van docker compose om DAO te installeren in een separate image/container (dus geen addon) opgenomen in de TS.
Zou je een en ander willen checken?

@KC27 mijn voorstel voor een paar verbeteringen om het nog wat beter en algemener te maken:

- Maak een docker-compose bestand aan met de volgende inhoud, of voeg dit toe aan je bestaande docker compose bestand
- bovenin de code van docker compose bestand nog services: toevoegen
- In het code deel van dockercompose staat een , voor poortnummer, dan moet vast een < zijn

- Er staat nog een aantal keren "ik", voorstel voor andere tekst:
(ik heb de subdirectory dao/data aangemaakt binnen mijn docker directory) => (bijvoorbeeld de subdirectory dao/data binnen je docker directory)
Ports: ik draai docker op een synology Nas, dus poort 5000 (de standaardpoort van dao) is al bezet voor DSM. Daarom verander ik de poort waar ik dao op kan benaderen naar 5009. => dao gebruikt standaard poort 5000. Is deze poort al bezet (b.v. bij Synology NAS voor DSM), dan kun je een andere poort instellen waarop je dao wilt benaderen. Als dat niet nodig is, kun je dit deel verwijderen.

- Onder het Docker Compose build dao commando kun je nog het volgende toevoegen:
Als je een foutmelding krijgt dat het commando "git" niet gevonden kan worden, dan is "git" niet geïnstalleerd op je device waar docker op draait. Installeer hiervoor dan eerst het benodigde pakket (b.v. op een Synology NAS het package Git vanuit synocommunity)

[KC27]

Torch1969 schreef op donderdag 17 april 2025 @ 13:09:
[...]


@KC27 mijn voorstel voor een paar verbeteringen om het nog wat beter en algemener te maken:

- Maak een docker-compose bestand aan met de volgende inhoud, of voeg dit toe aan je bestaande docker compose bestand
- bovenin de code van docker compose bestand nog services: toevoegen
- In het code deel van dockercompose staat een , voor poortnummer, dan moet vast een < zijn

- Er staat nog een aantal keren "ik", voorstel voor andere tekst:
(ik heb de subdirectory dao/data aangemaakt binnen mijn docker directory) => (bijvoorbeeld de subdirectory dao/data binnen je docker directory)
Ports: ik draai docker op een synology Nas, dus poort 5000 (de standaardpoort van dao) is al bezet voor DSM. Daarom verander ik de poort waar ik dao op kan benaderen naar 5009. => dao gebruikt standaard poort 5000. Is deze poort al bezet (b.v. bij Synology NAS voor DSM), dan kun je een andere poort instellen waarop je dao wilt benaderen. Als dat niet nodig is, kun je dit deel verwijderen.

- Onder het Docker Compose build dao commando kun je nog het volgende toevoegen:
Als je een foutmelding krijgt dat het commando "git" niet gevonden kan worden, dan is "git" niet geïnstalleerd op je device waar docker op draait. Installeer hiervoor dan eerst het benodigde pakket (b.v. op een Synology NAS het package Git vanuit synocommunity)

Dank voor je commentaar.
Ik heb het verwerkt, behalve:

- bovenin de code van docker compose bestand nog services: toevoegen

Dat begreep ik niet .
Graag even verduidelijken.

[Bravo]

Ook vanuit mij heel veel lof @KC27
Waar ik mijn tanden heb stukgebeten op EMHASS en EOS (van akkudokter) kreeg ik dit zonder al te veel moeite aan de praat. Met de foutmeldingen kon ik ook de juiste stukken aanpassen zodat het wel zou gaan werken.
Ondertussen heb ik er PV en een SIMbatterij in zitten evenals mijn EV, zodat ik een helder beeld krijg wat een dynamisch contract zou kunnen betekenen.
Waar ik nu mee vastloop is het toevoegen van apparaten. Ik heb behoorlijk lopen stoeien om de helpers in HA in het juist format te krijgen, maar de volgende foutmelding krijg ik er niet uit:

code:

2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3452, in <module>
2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3428, in main
2025-04-17 17:45:53 fout: File: /root/dao/prog/da_base.py, line 479, in run_task_function
2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2866, in calc_optimum
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py, line 28, in call_service
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 68, in _post
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 90, in _process_response
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 95, in _raise_error
2025-04-17 17:45:53 fout: Onverwachte fout: 400 status code returned from http://192.168.1.202:8123/api/services/switch/set_datetime
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 2689, in calc_optimum
    self.call_service(
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 28, in call_service
    self._post(
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 68, in _post
    return self._process_response(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 90, in _process_response
    self._raise_error(response.status_code, response.url)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 95, in _raise_error
    raise error(f"{status_code} status code returned from {url}",)  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hassapi.exceptions.BadRequest: 400 status code returned from http://192.168.1.202:8123/api/services/switch/set_datetime

Het apparaat wordt wel meegenomen in de berekening, maar de output wordt niet weggeschreven naar de helpers in HA.

Wie ziet de fout?

code:

  "machines" : [
   { "name": "vaatwasser",
      "programs": [
        {"name": "off",
         "power": []},
        {"name": "auto2",
         "power": [1300, 220, 45, 200, 2460, 0, 0, 0]
         },
        {"name": "quick 65",
         "power": [560, 1000, 1200, 1520, 0]
         }
       ],
        "entity start window": "input_datetime.start_window_vaatwasser",
        "entity end window": "input_datetime.end_window_vaatwasser",
        "entity selected program": "input_select.program_vaatwasser",
        "entity calculated start": "input_datetime.calculated_start_vaatwasser",
        "entity calculated end": "input_datetime.calculated_stop_vaatwasser"
     }   
 ],

[Torch1969]

Bravo schreef op donderdag 17 april 2025 @ 18:00:
Ook vanuit mij heel veel lof @KC27
Waar ik mijn tanden heb stukgebeten op EMHASS en EOS (van akkudokter) kreeg ik dit zonder al te veel moeite aan de praat. Met de foutmeldingen kon ik ook de juiste stukken aanpassen zodat het wel zou gaan werken.
Ondertussen heb ik er PV en een SIMbatterij in zitten evenals mijn EV, zodat ik een helder beeld krijg wat een dynamisch contract zou kunnen betekenen.
Waar ik nu mee vastloop is het toevoegen van apparaten. Ik heb behoorlijk lopen stoeien om de helpers in HA in het juist format te krijgen, maar de volgende foutmelding krijg ik er niet uit:

code:

2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3452, in <module>
2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3428, in main
2025-04-17 17:45:53 fout: File: /root/dao/prog/da_base.py, line 479, in run_task_function
2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2866, in calc_optimum
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py, line 28, in call_service
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 68, in _post
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 90, in _process_response
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 95, in _raise_error
2025-04-17 17:45:53 fout: Onverwachte fout: 400 status code returned from http://192.168.1.202:8123/api/services/switch/set_datetime
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 2689, in calc_optimum
    self.call_service(
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 28, in call_service
    self._post(
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 68, in _post
    return self._process_response(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 90, in _process_response
    self._raise_error(response.status_code, response.url)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 95, in _raise_error
    raise error(f"{status_code} status code returned from {url}",)  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hassapi.exceptions.BadRequest: 400 status code returned from http://192.168.1.202:8123/api/services/switch/set_datetime

Het apparaat wordt wel meegenomen in de berekening, maar de output wordt niet weggeschreven naar de helpers in HA.

Wie ziet de fout?

code:

  "machines" : [
   { "name": "vaatwasser",
      "programs": [
        {"name": "off",
         "power": []},
        {"name": "auto2",
         "power": [1300, 220, 45, 200, 2460, 0, 0, 0]
         },
        {"name": "quick 65",
         "power": [560, 1000, 1200, 1520, 0]
         }
       ],
        "entity start window": "input_datetime.start_window_vaatwasser",
        "entity end window": "input_datetime.end_window_vaatwasser",
        "entity selected program": "input_select.program_vaatwasser",
        "entity calculated start": "input_datetime.calculated_start_vaatwasser",
        "entity calculated end": "input_datetime.calculated_stop_vaatwasser"
     }   
 ],

[Afbeelding]

Hoe heb je de helpers in HA aangemaakt? Bij een date time helper moet je kiezen uit datum, tijd, datum en tijd. Ik neem aan dat de helpers voor doa datum en tijd moeten zijn.

[Torch1969]

KC27 schreef op donderdag 17 april 2025 @ 14:27:
[...]


Dank voor je commentaar.
Ik heb het verwerkt, behalve:

[...]

Dat begreep ik niet .
Graag even verduidelijken.

Een (nieuw) docker compose bestand begint met “services:”.
Dus zo

code:

services:
   dao:

Maar misschien wordt het dan weer te ingewikkeld. We mogen ervan uitgaan dat de lezer docker al heeft draaien met een bestaande docker-compose file. Je kunt de zin ervoor ook aanpassen naar:
“Voeg de volgende inhoud toe aan je docker compose bestand:”

En dan hoeft “services:” er niet bij te staan. Jij mag kiezen

[RudolfR]

@Bravo

DAO verwacht twee datum+tijd en twee alleen tijd, afgaande op de documentatie.

[Torch1969]

KC27 schreef op woensdag 16 april 2025 @ 21:55:
@Torch1969
Als je loglevel op debug zet, zie je in de logging je coördinaten staan.
Ook de tijdzone (nodig voor omrekenen van datum/tijd naar timestamp en vice versa komt uit HomeAssistant.

Gecontroleerd, klopt als een bus (de locatie)… kon ook niet anders 😉

[Torch1969]

@mgroen81 dank voor het delen van je config met Sessy thuis batterijen. Ik heb die van jou overgenomen omdat de efficiëntie percentage's overeenkomen met deze tabel in het sessy forum (zo te zien gebaseerd op jouw input ;-) ), wat weer gebaseerd is op de grafieken op de site van Sessy.

@stoner1978 en andere toekomstige Sessy & DAO gebruikers: misschien slim om dit ook in jouw configuratie over te nemen. (De waardes die ik in de door jouw gedeelde configuratie zie staan zijn veel te optimistisch in de lagere en hogere vermogens.)

[hemertje]

KC27 schreef op dinsdag 15 april 2025 @ 23:31:
[...]


Dank voor je uitleg.
De huidige tariefberekening is helemaal toegesneden op de Nederlandse situatie met dynamische tarieven.
Er was ook al een vraag van iemand met een vast energiecontract. Dat kan nu ook niet met DAO.

Ik speel nu met de gedachte om het helemaal "open" te maken zodat de gebruikers zelf een formule kunnen definiëren. Bijvoorbeeld NL situatie met een dynamisch contract geven zij op:

code:

tarief_levering = (da_ex + eb_levering + opslag_levering) * (1 + btw_hoog)

BE situatie (jouw voorbeeld):

code:

tarief_levering = da_ex * multiplier * (1 + btw_hoog) + som_opslag_en_heffingen_btw_plichtig*(1+btw) + som_heffingen_zonder_btw

waarbij geldt dat alle gebruikte termen en factoren (behalve da_ex), tijdafhankelijk moeten worden gedefinieerd in de settings.
Dat betekent een aantal zaken:

• Het ophalen van de day-ahead prijzen moet land afhankelijk worden gemaakt (kan nu alleen NL)
• Er zijn wellicht ook een aantal termen of factoren die ook anders zijn bij hoog_tarief (werkdagen tussen 7 en 23uur) en laag tarief (werkdagen tussen 23 en 7uur, zaterdagen en zon- en feestdagen).
• Feestdagen zijn gedeeltelijk ook weer landafhankelijk.

Kortom een omvangrijke klus.
Voordat ik ermee aan de gang ga, wil ik eerst de impact van dit idee goed in beeld hebben.
Ik wil ook deze maand het 15min interval testbaar klaar hebben, dat heeft prioriteit.

Mijn vragen aan jou op dit moment zijn:

• Hoe haal jij nu de Belgische spotprijzen op, bij welke provider (entsoe, nordpool, epex?)
• Zijn er in België tarief-componenten (behalve de spotprijs), die in de tijd variëren (hoog/laag of anderszins) en zo ja welke?

Ter info

In Brabant begint het laagtarief al om 21:00uur

[verguldebarman]

Torch1969 schreef op maandag 14 april 2025 @ 09:05:
Dankzij het voorwerk in dit topic van @KC27 en @bvw (filter dit topic op de zoekterm “docker” en het stappenplan ontvouwt zich als een spannend jongensboek, alle credits voor hen ) en een avondje uitproberen en debuggen, heb ik dao nu ook draaien in een docker container mbv docker compose. . Hieronder mijn HowTo voor wat ik tot nu toe heb gedaan (garantie tot de deur )

HowTo dao met docker compose

Voeg in je docker compose file het volgende toe (en pas dit aan naar je eigen situatie, zie toelichting):

code:

  dao:
    #bron: https://gathering.tweakers.net/forum/list_messages/2293338?data%5Bfilter_keywords%5D=docker
    container_name: dao
    build: 
      context: https://github.com/corneel27/day-ahead.git#main:dao
      dockerfile: Dockerfile
      args:
        - BUILD_ARCH=amd64
        - BUILD_FROM=ghcr.io/hassio-addons/debian-base/amd64:stable
        - BUILD_VERSION=2025.4.0
      tags:
        - "dao:latest"
    volumes:
      - /volume1/docker/homeassistant/config:/homeassistant
      - /volume1/docker/dao/data:/config
    ports:
      - 5009:5000
    restart: unless-stopped
    environment:
      - TZ=Europe/Amsterdam

Toelichting: het build deel bouwt een image op, op basis van de GitHub repository (je hoeft zelf dus niets te downloaden). Hiervoor moet je 3 argumenten instellen die de Dockerfile gebruikt:

• voor BUILD_ARCH moet je de processor invullen van je machine, momenteel worden alleen amd64 (=intel 64 bit), aarch64 (o.a. raspberry pi 4 en 5) en i386 (intel 32 bit)
• voor BUILD_FROM heb je ook weer de keuze uit:
  * ghcr.io/hassio-addons/debian-base/aarch64:stable
  * ghcr.io/hassio-addons/debian-base/amd64:stable
  * ghcr.io/hassio-addons/debian-base/i386:stable
• Voor BUILD_VERSION vul je de huidige versie van de GitHub repository van dao in.

Het resterende deel is nodig voor het opstarten van een container. Belangrijk daarin zijn de instellingen bij volumes en eventueel het poortnummer.

• Volumes: Maak de eerste keer een directory voor dao aan waar dao zijn data kan opslaan buiten de container (ik heb de subdirectory dao/data aangemaakt binnen mijn docker directory).
  Verwijs in het deel volumes naar het pad waar je home assistant database staat, en het pad waar je dao data directory staat. Doe dit in het deel voor de ":", het deel erna is de interne verwijzing binnen de container zelf
• Ports: ik draai docker op een synology Nas, dus poort 5000 (de standaardpoort van dao) is al bezet voor DSM. Daarom verander ik de poort waar ik dao op kan benaderen naar 5009.

Voor bouwen image doe je (dit duurt even):

code:

docker-compose build dao

Voor opstarten container:

code:

docker-compose up -d dao

of in één keer:

code:

docker-compose up -d --build --force-recreate dao

(Alles eventueel voorafgegaan door sudo afhankelijk van je rechten.)

Hierna kun je dao benaderen via <ip-adres docker>:<ingestelde poortnummer> (bijvoorbeeld 192.168.1.123:5009)
Volg verder de handleiding vanaf het kopje instellingen in DOCS.md op GitHub. Belangrijk hierbij is het instellen van de toegang tot homeassistant in de config:

code:

"homeassistant": {
    "ip adress": "<ip adres waar home assistant draait>",
    "ip port": <poort nummer van home asssitant, standaard 8123>,
    "token": "<je long lived access token>"
  },

Er wordt in de handleiding verder verwezen naar herstarten en logboek. Dat moet je uiteraard doen in je eigen docker omgeving (ik gebruik daarvoor nu portainer).

EDIT: environment TZ Amsterdam toegevoegd in docker compose
EDIT 2: privileged: true weggehaald in docker compose

Goed werk! Ik ga er ook mee aan de slag.

Is het een idee om de Docker images te publiceren, zodat je in compose er gewoon naar kunt verwijzen? Dat scheelt voor iedereen een build een maakt het een stuk toegankelijker 💪

[Torch1969]

verguldebarman schreef op vrijdag 18 april 2025 @ 07:00:
[...]

Goed werk! Ik ga er ook mee aan de slag.

Is het een idee om de Docker images te publiceren, zodat je in compose er gewoon naar kunt verwijzen? Dat scheelt voor iedereen een build een maakt het een stuk toegankelijker 💪

Als je het zelf uitprobeert zul je erachter komen dat het niet veel ingewikkelder is om de image zelf te builden dan een regulier docker compose op een bestaande image. Het “moeilijke” werk is al gedaan in de Dockerfile dit op GitHub staat. Het duurt hooguit wat langer.

Scheelt iemand een taak om na elke dao-update 3 (voor 3 architecturen) builds te draaien en publiceren. Zal vast ook geautomatiseerd kunnen, maar daar heb ik geen kennis van.

[Bravo]

Torch1969 schreef op donderdag 17 april 2025 @ 18:26:
[...]


Hoe heb je de helpers in HA aangemaakt? Bij een date time helper moet je kiezen uit datum, tijd, datum en tijd. Ik neem aan dat de helpers voor doa datum en tijd moeten zijn.

De helpers in HA zijn inderdaad als date time helper aangemaakt. De start/end_window als tijd, de calculated_start/stop als datum en tijd zoals op GitHub aangegeven (al had ik het eerst verkeerd, maar dankzij de goede foutmeldingen kon ik dit corrigeren). Als ik een tijd wijzig naar een datum en tijd krijg ik weer een foutmelding over een fout format, maar niet de error 400 over de api:

code:

2025-04-18 08:11:44 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):

  File "/usr/lib/python3.11/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '15:00:00' does not match format '%Y-%m-%d %H:%M:%S'

[Torch1969]

Bravo schreef op vrijdag 18 april 2025 @ 08:20:
[...]

Als ik een tijd wijzig naar een datum en tijd krijg ik weer een foutmelding over een fout format, maar niet de error 400 over de api:

Zoals je in de berichten onder die van mij kunt lezen heb je 2 tijd en 2 datum en tijd helpers nodig:

code:

entity start window string      input_datetime, tijd
entity end window   string      input_datetime, tijd

entity calculated start string  ""  input_datetime, datum en tijd
entity calculated end   string  ""  input_datetime, datum en tijd

Dus je moet niet die 2 tijd helpers (window) naar datum en tijd aanpassen (die aanname van mij was dus niet goed, sorry voor de verwarring).

[Bravo]

Torch1969 schreef op vrijdag 18 april 2025 @ 09:04:
[...]


Zoals je in de berichten onder die van mij kunt lezen heb je 2 tijd en 2 datum en tijd helpers nodig:

code:

entity start window string      input_datetime, tijd
entity end window   string      input_datetime, tijd

entity calculated start string  ""  input_datetime, datum en tijd
entity calculated end   string  ""  input_datetime, datum en tijd

Dus je moet niet die 2 tijd helpers (window) naar datum en tijd aanpassen (die aanname van mij was dus niet goed, sorry voor de verwarring).

Volgens mij zijn de instellingen van de helpers goed, ze zijn zoals aangegeven in DOCS.md. En als ik deze (foutief) wijzig krijg ik daar een andere foutmelding over.

Bravo schreef op vrijdag 18 april 2025 @ 08:20:
[...]

code:

2025-04-18 08:11:44 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):

  File "/usr/lib/python3.11/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '15:00:00' does not match format '%Y-%m-%d %H:%M:%S'

Mijn conclusie: dat gedeelte in de DAO-config is OK.
Als ik de run met debug laat lopen, dan krijg ik ook netjes de waarden te zien voor het starten/stoppen van de machines, geen foutmelding

Ik krijg dus een error 400 bij het wegschrijven van de output calculated_start/stop naar de helper in HA. Bij de anderen werkt dit zonder problemen?

code:

hassapi.exceptions.BadRequest: 400 status code returned from http://192.168.1.202:8123/api/services/switch/set_datetime

[arro3038]

Bravo schreef op vrijdag 18 april 2025 @ 11:05:
[...]

Ik krijg dus een error 400 bij het wegschrijven van de output calculated_start/stop naar de helper in HA. Bij de anderen werkt dit zonder problemen?

Ja werkt hier prima. Weet je heel zeker dat de helper goed gedefinieerd is?

Dit is de mijne

[Bravo]

arro3038 schreef op vrijdag 18 april 2025 @ 11:52:
[...]


Ja werkt hier prima. Weet je heel zeker dat de helper goed gedefinieerd is?

Dit is de mijne

[Afbeelding]

Ik zie geen verschil?

Edit: Na het verwijderen van de verschillende configuratie elementen lijkt het erop dat de fout niet in het gedeelte van de machines zit, maar in de EV en/of Battery. Mogelijk dat ik daar nog wat entiteiten mis die toch aanwezig moeten zijn. Maar eerder niet aangeroepen werden, waardoor de fouten pas begonnen toen ook de machines zijn toegevoegd

[ Voor 22% gewijzigd door Bravo op 18-04-2025 17:58 ]

[verguldebarman]

Torch1969 schreef op vrijdag 18 april 2025 @ 08:14:
[...]

Als je het zelf uitprobeert zul je erachter komen dat het niet veel ingewikkelder is om de image zelf te builden dan een regulier docker compose op een bestaande image. Het “moeilijke” werk is al gedaan in de Dockerfile dit op GitHub staat. Het duurt hooguit wat langer.

Scheelt iemand een taak om na elke dao-update 3 (voor 3 architecturen) builds te draaien en publiceren. Zal vast ook geautomatiseerd kunnen, maar daar heb ik geen kennis van.

Ik had verwacht dat dit wel automatisch zou moeten kunnen en ben even gaan zoeken. Ik kan me namelijk inderdaad goed voorstellen dat iedere developer niet de hele dag Docker images wilt maken..... 😵‍💫

Ik heb er zelf geen ervaring mee, maar ik lees wel dat het geautomatiseerd kan:

https://medium.com/@kicsi...ocker-images-65a038b8ce56

[KC27]

Bravo schreef op vrijdag 18 april 2025 @ 16:54:
[...]


[Afbeelding]
Ik zie geen verschil?

Edit: Na het verwijderen van de verschillende configuratie elementen lijkt het erop dat de fout niet in het gedeelte van de machines zit, maar in de EV en/of Battery. Mogelijk dat ik daar nog wat entiteiten mis die toch aanwezig moeten zijn. Maar eerder niet aangeroepen werden, waardoor de fouten pas begonnen toen ook de machines zijn toegevoegd

Misschien kun je in de logging van een berekening van DAO (niet runnen met debug, want dan schrijft hij niet weg naar HA) zien waar hij de fout ingaat.

[KC27]

verguldebarman schreef op vrijdag 18 april 2025 @ 16:54:
[...]

Ik had verwacht dat dit wel automatisch zou moeten kunnen en ben even gaan zoeken. Ik kan me namelijk inderdaad goed voorstellen dat iedere developer niet de hele dag Docker images wilt maken..... 😵‍💫

Ik heb er zelf geen ervaring mee, maar ik lees wel dat het geautomatiseerd kan:

https://medium.com/@kicsi...ocker-images-65a038b8ce56

@Torch1969
Het kan inderdaad automatisch, maar ik ben er nog niet aan toegekomen (en ben ook nog wel even druk).
Het kan niet met een standaard klik maar met een action flow op github voor de drie ondersteunde architecturen.
Maar die action flow moet gemaakt en getest worden.
Het begin met uitleg staat hier:
https://developers.home-a.../docs/add-ons/publishing/
en hier:
https://github.com/home-assistant/builder

Wie gaat me helpen?
Stuur maar een dm.

[KC27]

Voordat gebruikers gaan klagen over DAO.
Er zijn nog geen prijzen beschikbaar voor morgen.
Dit staat op de site van Nordpool:

Today 13:50
DAY-AHEAD: Further delay of the Market Coupling Session

Please be aware that the Single Day-Ahead Coupling (SDAC)* process is delayed.

Therefore, the Market Coupling Session encounters a risk of Full Decoupling.

If the final market coupling results remain unavailable at 14:20 CET/CEST, a message confirming full decoupling will be sent. Such a message will include further instructions.

[KC27]

Vanaf 14:10 kun je de prijzen voor morgen ophalen:

[balk]

@KC27 Kan je uitleggen wat de logica achter "entity balance switch" is? Stuurt DAO dit aan wanneer de feed-in op 0 staat? Ik heb deze entity nu ingesteld maar er gebeurt niets mee, ondanks dat "entity set power feedin" op 0 staat.

[KC27]

balk schreef op maandag 21 april 2025 @ 09:35:
@KC27 Kan je uitleggen wat de logica achter "entity balance switch" is? Stuurt DAO dit aan wanneer de feed-in op 0 staat? Ik heb deze entity nu ingesteld maar er gebeurt niets mee, ondanks dat "entity set power feedin" op 0 staat.

Deze wordt aangezet als DAO heeft berekend als er geen inkoop en teruglevering is, dus het berekende grid-vermogen is 0. Je kunt daar een automation aanhangen die dan het laad- en/of ontlaadvernogen van de accu bijstuurt als je bijvoorbeeld koffie gaat zetten enz.
Er zijn ook thuisbatterij configuraties met bijvoorbeeld Victron en Deye installaties die dat laten verzorgen door hun omvormer/inverter. Volgens mij kan Sessy dat ook (via hun api).
Dit komt nu alleen voor als je de strategie "minimize consumption" kiest. Maar als vanaf 2027 de saldering eraf gaat zal het ook veel voorkomen bij de strategie "minimize cost".

[ErnstH]

KC27 schreef op maandag 21 april 2025 @ 09:51:
[...]

Deze wordt aangezet als DAO heeft berekend als er geen inkoop en teruglevering is, dus het berekende grid-vermogen is 0. Je kunt daar een automation aanhangen die dan het laad- en/of ontlaadvernogen van de accu bijstuurt als je bijvoorbeeld koffie gaat zetten enz.
Er zijn ook thuisbatterij configuraties met bijvoorbeeld Victron en Deye installaties die dat laten verzorgen door hun omvormer/inverter. Volgens mij kan Sessy dat ook (via hun api).
Dit komt nu alleen voor als je de strategie "minimize consumption" kiest. Maar als vanaf 2027 de saldering eraf gaat zal het ook veel voorkomen bij de strategie "minimize cost".

Bij mij wordt deze variabele ook bij de "minimize cost" setting gebruikt, volgens mij als hij de zonne-energie opwek binnen een uur precies wil gebruiken om te laden. Hier heb ik idd een automation aanhangen die dan mijn Sessy op NoM zet.

[Bravo]

KC27 schreef op vrijdag 18 april 2025 @ 23:12:
[...]

Misschien kun je in de logging van een berekening van DAO (niet runnen met debug, want dan schrijft hij niet weg naar HA) zien waar hij de fout ingaat.

Had je onderstaande logging al gezien? Of moet ik op een andere plek kijken om de logging uit te lezen?

Bravo schreef op donderdag 17 april 2025 @ 18:00:
Ook vanuit mij heel veel lof @KC27
Waar ik mijn tanden heb stukgebeten op EMHASS en EOS (van akkudokter) kreeg ik dit zonder al te veel moeite aan de praat. Met de foutmeldingen kon ik ook de juiste stukken aanpassen zodat het wel zou gaan werken.
Ondertussen heb ik er PV en een SIMbatterij in zitten evenals mijn EV, zodat ik een helder beeld krijg wat een dynamisch contract zou kunnen betekenen.
Waar ik nu mee vastloop is het toevoegen van apparaten. Ik heb behoorlijk lopen stoeien om de helpers in HA in het juist format te krijgen, maar de volgende foutmelding krijg ik er niet uit:

code:

2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3452, in <module>
2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3428, in main
2025-04-17 17:45:53 fout: File: /root/dao/prog/da_base.py, line 479, in run_task_function
2025-04-17 17:45:53 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2866, in calc_optimum
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py, line 28, in call_service
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 68, in _post
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 90, in _process_response
2025-04-17 17:45:53 fout: File: /root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py, line 95, in _raise_error
2025-04-17 17:45:53 fout: Onverwachte fout: 400 status code returned from http://192.168.1.202:8123/api/services/switch/set_datetime
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 2689, in calc_optimum
    self.call_service(
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/services.py", line 28, in call_service
    self._post(
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 68, in _post
    return self._process_response(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 90, in _process_response
    self._raise_error(response.status_code, response.url)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 95, in _raise_error
    raise error(f"{status_code} status code returned from {url}",)  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hassapi.exceptions.BadRequest: 400 status code returned from http://192.168.1.202:8123/api/services/switch/set_datetime

Het apparaat wordt wel meegenomen in de berekening, maar de output wordt niet weggeschreven naar de helpers in HA.

Wie ziet de fout?

code:

  "machines" : [
   { "name": "vaatwasser",
      "programs": [
        {"name": "off",
         "power": []},
        {"name": "auto2",
         "power": [1300, 220, 45, 200, 2460, 0, 0, 0]
         },
        {"name": "quick 65",
         "power": [560, 1000, 1200, 1520, 0]
         }
       ],
        "entity start window": "input_datetime.start_window_vaatwasser",
        "entity end window": "input_datetime.end_window_vaatwasser",
        "entity selected program": "input_select.program_vaatwasser",
        "entity calculated start": "input_datetime.calculated_start_vaatwasser",
        "entity calculated end": "input_datetime.calculated_stop_vaatwasser"
     }   
 ],

[Afbeelding]

[KC27]

Bravo schreef op dinsdag 22 april 2025 @ 09:26:
[...]


Had je onderstaande logging al gezien? Of moet ik op een andere plek kijken om de logging uit te lezen?


[...]

Het gaat fout met "entity stop inverter" van je (sim)batterij.
Als je deze entity meegeeft dat moet het een input_datetime zijn van het type datum én tijd.

[desalnietemin]

KC27 schreef op donderdag 17 april 2025 @ 10:20:
[...]


Ik heb zelf een Alpha Innotec (zusje van Nibe) warmtepomp met ook zo'n "smart grid ready" optie.
Maar ik heb daar van afgezien.
Uiteindelijk stuurt die "smart grid ready" de stooklijn in grote stappen omhoog of omlaag.
DAO heeft ook de mogelijkheid om de stooklijn verhoging/verlaging te berekenen. Dit heeft enkele voordelen t.o.v. "smart grid ready":

• Je hoeft geen elektronica te kopen en te installeren (tenminste als je via modbus of anderzins de instellingen van je wp kunt wijzigen)
• Je kunt de stooklijnverschuiving instellen op 0.1 K en dat werkt veel geleidelijker richting je wp, zodat deze minder aan/uit gaat. Minder start/stops betekent minder slijtage.
• DAO berekent ook het verwachte vermogen van je wp zodat je het geheel kunt meenemen in een goede vermogensspreiding.
• Als straks de saldering eraf gaat wil je zo veel mogelijk je eigen pv-productie gebruiken. Hoe gaat "smart-grid ready" daar mee om?

Thanks @KC27.

Ja er zitten voor- en nadelen aan.
- Het voordeel is dat door SGR sturing de flashregisters van de warmtepomp niet gebruikt worden door de directe interne sturing. Bij sturing via modbus is dat wel het geval en daar zitten ook risico's aan van vroegtijdige slijtage. Met name als je vaker registers set (zie: (https://gathering.tweakers.net/forum/view_message/82190136). De vraag is dus even, hoe vaak pas je gemiddeld zo'n stooklijn aan en dienen er registers geschreven te worden?

- De Smart Grid Ready van Nibe heeft 4 standen die je stuurt obv 2 AUX-contacten die je dan in HASS met een simpel relais bordje van Ali kunt aan/uitzetten. Zoveel mogelijk van je eigen verbruik gebruiken is stand 1 (overproductie). (link documentje).


De mate waarin SGR effect heeft op:
- Verwarming stooklijn, Warmtapwater, Zwembad stooklijn (indien aanwezig) en Actieve koeling (indien aanwezig) kun je instellen op de warmtepomp.

- Aansturing via modbus kan ook, ik denk dat dit voor de Nibe WP ongeveer deze registers zijn:
https://gathering.tweakers.net/forum/view_message/82155496.

- Via AUX-contacten kun je nog meer direct intern sturen. Op mijn Nibe WP zitten 5 AUX-contacten, hierbij een lijstje van de keuzes die ik daarbij hebt: https://gathering.tweakers.net/forum/view_message/82138188.
Dus ook het blokkeren van de compressor, verwarmen of warmtapwater kan is via AUX sturen (en dan hoeft er geen register via modbus gezet te worden).

Ik denk dat je helemaal gelijk hebt dat aansturing via DAO optimaler is aangezien je dan het totaal kunt gaan optimaliseren maar dat zal in mijn geval best een leuke challenge worden die ik wel wil aangaan.

Daarvoor alvast enkele vragen:
- Ik heb mijn Zon-PV toegevoegd aan DAO. Is er een mogelijkheid om de totale PV forecast van vandaag en morgen te kunnen zien?
Ik gebruik nu de Open-Meteo Solar Forecast integratie en wil het e.e.a. kunnen vergelijken.


- Voor aansturing van de warmtepomp via modbus kan ik enkele entiteiten gebruiken:
* Verwarming: verhoging of verlaging van de stooklijn (de standaard stooklijn 5 verhogen of verlagen met + of - ) via entiteit: number.heat_curve_s1_47007

* Warmtapwater: met de entiteit select.hot_water_comfort_mode_47041 kan ik de warmtapwater in Economy, Normal of Luxe modus zetten. Per modus kan ik een Stop - en start temperatuur instellen. Eventueel kan dan de drieweg-klep omgezet worden naar de boiler en de warmtepomp gestart worden met een bepaalde
setpoint temperatuur om de boiler te verwarmen.

* Zwembad: en buffervat voor zwembad met start- en stoptemperatuur die ik kan instellen

Ik heb 3 buffervaten waarbij ik de temperaturen boven, midden en onderin beschikbaar heb in HASS:
- 300L buffervat voor warmteafgiftesysteem parallel geschakeld (vloerverwarming)
- 300L boilervat voor warmtapwater
- 500L buffervat zwembad (met een 9 kW elektrisch element want ik als backup aa/uit kan zetten(

Verder heb ik diverse entiteiten die ik kan uitlezen (zoals: graadminuten, compressor status, of de passieve koelmodus aan/uit is en wat op dit moment prioriteit heeft (verwarmen, zwembad of warm-tapwater).

Dit document geeft wel informatie over Nibe aansturing via modbus: https://www.nibe.eu/downl...lichting_uitleg_aug19.pdf

Ik heb je DAO instructies onder HEATING gelezen maar ik vraag me af waar je ik deze instel informatie vandaag kan halen maar ik duik er wat dieper in. Het is wel zo dat in mijn geval er dus heating dient plaats te vinden van 3 buffervaten/systeem onderdelen. Geen idee hoe dat kan gaan werken?

[Bravo]

KC27 schreef op dinsdag 22 april 2025 @ 11:36:
[...]

Het gaat fout met "entity stop inverter" van je (sim)batterij.
Als je deze entity meegeeft dat moet het een input_datetime zijn van het type datum én tijd.

Dank!
De entities die gebruikt worden zijn dus goed gespecificeerd, ik heb er onvoldoende acht op geslagen bij het invullen van de configuraties. [RTFM ]
Een aantal bestaande entities van de EV en Batterij lijken de rol te vervullen, maar hebben het verkeerde format (switch/boolean/binary) waardoor de foutmeldingen kwamen. Nu alles opnieuw nagelopen, de eerste run levert geen foutmeldingen meer op

[Bravo]

Drie puntjes die mij nog opvallen:
- De knop om de resultaten te verwijderen lijkt bij mij best veel op de knop om tabelweergave te krijgen. Hierdoor al een paar keer aangeklikt op de telefoon.
- Dan krijg je de vraag of je echt de gegevens wil verwijderen, ook bij 'nee' is de output van de run niet meer terug te vinden door te bladeren. Het lijkt toch verwijderd
- De weerprognose is een stuk korter geworden, niet meer meerdere dagen. Is er bij meteoserver iets aan de API veranderd? (ik weet het wachtwoord nu al niet meer )

[KC27]

desalnietemin schreef op dinsdag 22 april 2025 @ 12:34:
[...]


Thanks @KC27.

Ja er zitten voor- en nadelen aan.
- Het voordeel is dat door SGR sturing de flashregisters van de warmtepomp niet gebruikt worden door de directe interne sturing. Bij sturing via modbus is dat wel het geval en daar zitten ook risico's aan van vroegtijdige slijtage. Met name als je vaker registers set (zie: (https://gathering.tweakers.net/forum/view_message/82190136). De vraag is dus even, hoe vaak pas je gemiddeld zo'n stooklijn aan en dienen er registers geschreven te worden?

- De Smart Grid Ready van Nibe heeft 4 standen die je stuurt obv 2 AUX-contacten die je dan in HASS met een simpel relais bordje van Ali kunt aan/uitzetten. Zoveel mogelijk van je eigen verbruik gebruiken is stand 1 (overproductie). (link documentje).
[Afbeelding]

De mate waarin SGR effect heeft op:
- Verwarming stooklijn, Warmtapwater, Zwembad stooklijn (indien aanwezig) en Actieve koeling (indien aanwezig) kun je instellen op de warmtepomp.

- Aansturing via modbus kan ook, ik denk dat dit voor de Nibe WP ongeveer deze registers zijn:
https://gathering.tweakers.net/forum/view_message/82155496.

- Via AUX-contacten kun je nog meer direct intern sturen. Op mijn Nibe WP zitten 5 AUX-contacten, hierbij een lijstje van de keuzes die ik daarbij hebt: https://gathering.tweakers.net/forum/view_message/82138188.
Dus ook het blokkeren van de compressor, verwarmen of warmtapwater kan is via AUX sturen (en dan hoeft er geen register via modbus gezet te worden).

Ik denk dat je helemaal gelijk hebt dat aansturing via DAO optimaler is aangezien je dan het totaal kunt gaan optimaliseren maar dat zal in mijn geval best een leuke challenge worden die ik wel wil aangaan.

Daarvoor alvast enkele vragen:
- Ik heb mijn Zon-PV toegevoegd aan DAO. Is er een mogelijkheid om de totale PV forecast van vandaag en morgen te kunnen zien?
Ik gebruik nu de Open-Meteo Solar Forecast integratie en wil het e.e.a. kunnen vergelijken.
[Afbeelding]

- Voor aansturing van de warmtepomp via modbus kan ik enkele entiteiten gebruiken:
* Verwarming: verhoging of verlaging van de stooklijn (de standaard stooklijn 5 verhogen of verlagen met + of - ) via entiteit: number.heat_curve_s1_47007

* Warmtapwater: met de entiteit select.hot_water_comfort_mode_47041 kan ik de warmtapwater in Economy, Normal of Luxe modus zetten. Per modus kan ik een Stop - en start temperatuur instellen. Eventueel kan dan de drieweg-klep omgezet worden naar de boiler en de warmtepomp gestart worden met een bepaalde
setpoint temperatuur om de boiler te verwarmen.

* Zwembad: en buffervat voor zwembad met start- en stoptemperatuur die ik kan instellen

Ik heb 3 buffervaten waarbij ik de temperaturen boven, midden en onderin beschikbaar heb in HASS:
- 300L buffervat voor warmteafgiftesysteem parallel geschakeld (vloerverwarming)
- 300L boilervat voor warmtapwater
- 500L buffervat zwembad (met een 9 kW elektrisch element want ik als backup aa/uit kan zetten(

Verder heb ik diverse entiteiten die ik kan uitlezen (zoals: graadminuten, compressor status, of de passieve koelmodus aan/uit is en wat op dit moment prioriteit heeft (verwarmen, zwembad of warm-tapwater).

Dit document geeft wel informatie over Nibe aansturing via modbus: https://www.nibe.eu/downl...lichting_uitleg_aug19.pdf

Ik heb je DAO instructies onder HEATING gelezen maar ik vraag me af waar je ik deze instel informatie vandaag kan halen maar ik duik er wat dieper in. Het is wel zo dat in mijn geval er dus heating dient plaats te vinden van 3 buffervaten/systeem onderdelen. Geen idee hoe dat kan gaan werken?

De voorspelling van de pv kun je in HA opvragen met de api (zie DOCS.md). Bijvoorbeeld:
http://192.168.178.36:5000/api/report/pv_ac/vandaag_en morgen
Geeft:

code:

{
  "message": "Success",
  "data": [
    {
      "time_ts": 1745359200000,
      "time": "2025-04-23 00:00",
      "value": 0,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745362800000,
      "time": "2025-04-23 01:00",
      "value": 0,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745366400000,
      "time": "2025-04-23 02:00",
      "value": 0,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745370000000,
      "time": "2025-04-23 03:00",
      "value": 0,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745373600000,
      "time": "2025-04-23 04:00",
      "value": 0,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745377200000,
      "time": "2025-04-23 05:00",
      "value": 0,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745380800000,
      "time": "2025-04-23 06:00",
      "value": 0,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745384400000,
      "time": "2025-04-23 07:00",
      "value": 0.036,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745388000000,
      "time": "2025-04-23 08:00",
      "value": 0.214,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745391600000,
      "time": "2025-04-23 09:00",
      "value": 0.491,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745395200000,
      "time": "2025-04-23 10:00",
      "value": 0.813,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745398800000,
      "time": "2025-04-23 11:00",
      "value": 1.223,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745402400000,
      "time": "2025-04-23 12:00",
      "value": 1.672,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745406000000,
      "time": "2025-04-23 13:00",
      "value": 1.275,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745409600000,
      "time": "2025-04-23 14:00",
      "value": 1.627,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745413200000,
      "time": "2025-04-23 15:00",
      "value": 0.928,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745416800000,
      "time": "2025-04-23 16:00",
      "value": 0.507,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745420400000,
      "time": "2025-04-23 17:00",
      "value": 0.804,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745424000000,
      "time": "2025-04-23 18:00",
      "value": 0.475,
      "datatype": "recorded"
    },
    {
      "time_ts": 1745427600000,
      "time": "2025-04-23 19:00",
      "value": 0.039,
      "datatype": "expected"
    },
    {
      "time_ts": 1745431200000,
      "time": "2025-04-23 20:00",
      "value": 0.013,
      "datatype": "expected"
    },
    {
      "time_ts": 1745434800000,
      "time": "2025-04-23 21:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745438400000,
      "time": "2025-04-23 22:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745442000000,
      "time": "2025-04-23 23:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745445600000,
      "time": "2025-04-24 00:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745449200000,
      "time": "2025-04-24 01:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745452800000,
      "time": "2025-04-24 02:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745456400000,
      "time": "2025-04-24 03:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745460000000,
      "time": "2025-04-24 04:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745463600000,
      "time": "2025-04-24 05:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745467200000,
      "time": "2025-04-24 06:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745470800000,
      "time": "2025-04-24 07:00",
      "value": 0.052,
      "datatype": "expected"
    },
    {
      "time_ts": 1745474400000,
      "time": "2025-04-24 08:00",
      "value": 0.0735868,
      "datatype": "expected"
    },
    {
      "time_ts": 1745478000000,
      "time": "2025-04-24 09:00",
      "value": 0.039,
      "datatype": "expected"
    },
    {
      "time_ts": 1745481600000,
      "time": "2025-04-24 10:00",
      "value": 0.0740228,
      "datatype": "expected"
    },
    {
      "time_ts": 1745485200000,
      "time": "2025-04-24 11:00",
      "value": 0.065,
      "datatype": "expected"
    },
    {
      "time_ts": 1745488800000,
      "time": "2025-04-24 12:00",
      "value": 0.140867,
      "datatype": "expected"
    },
    {
      "time_ts": 1745492400000,
      "time": "2025-04-24 13:00",
      "value": 0.16783,
      "datatype": "expected"
    },
    {
      "time_ts": 1745496000000,
      "time": "2025-04-24 14:00",
      "value": 0.220384,
      "datatype": "expected"
    },
    {
      "time_ts": 1745499600000,
      "time": "2025-04-24 15:00",
      "value": 0.168649,
      "datatype": "expected"
    },
    {
      "time_ts": 1745503200000,
      "time": "2025-04-24 16:00",
      "value": 0.155174,
      "datatype": "expected"
    },
    {
      "time_ts": 1745506800000,
      "time": "2025-04-24 17:00",
      "value": 0.052,
      "datatype": "expected"
    },
    {
      "time_ts": 1745510400000,
      "time": "2025-04-24 18:00",
      "value": 0.052,
      "datatype": "expected"
    },
    {
      "time_ts": 1745514000000,
      "time": "2025-04-24 19:00",
      "value": 0.039,
      "datatype": "expected"
    },
    {
      "time_ts": 1745517600000,
      "time": "2025-04-24 20:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745521200000,
      "time": "2025-04-24 21:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745524800000,
      "time": "2025-04-24 22:00",
      "value": 0,
      "datatype": "expected"
    },
    {
      "time_ts": 1745528400000,
      "time": "2025-04-24 23:00",
      "value": 0,
      "datatype": "expected"
    }
  ]
}

Wat betreft de aansturing van de warmtepomp:
Er zijn nu drie mogelijkheden:

• op aan/uit, maar dat is moeilijk instelbaar
• op vermogen
• op stooklijn-verhoging/ -verlaging

Als je die laatste kiest moet je in HA een automation maken waarbij je de relais schakelt op basis van de verhoging/verlaging.
Mocht je betere ideeën voor aansturing hebben (een vierde stuuroptie?) dan hoor ik het graag.

[Torch1969]

KC27 schreef op woensdag 23 april 2025 @ 19:49:
[...]


De voorspelling van de pv kun je in HA opvragen met de api (zie DOCS.md). Bijvoorbeeld:
http://192.168.178.36:5000/api/report/pv_ac/vandaag_en morgen
Geeft:

Sorry @KC27 , dit staat nog niet in docs.md. Ik was hier ook naar op zoek en kon het ook niet vinden. Fijn dat het al kan 😀👍🏻. Werkt dit ook voor accu_uit, accu_in en EV etc.?

EDIT: al gevonden: bat_out, bat_in, ev, wp werken ook….

[ Voor 6% gewijzigd door Torch1969 op 23-04-2025 20:41 ]

[KC27]

Bravo schreef op woensdag 23 april 2025 @ 09:48:
Drie puntjes die mij nog opvallen:
- De knop om de resultaten te verwijderen lijkt bij mij best veel op de knop om tabelweergave te krijgen. Hierdoor al een paar keer aangeklikt op de telefoon.
- Dan krijg je de vraag of je echt de gegevens wil verwijderen, ook bij 'nee' is de output van de run niet meer terug te vinden door te bladeren. Het lijkt toch verwijderd

Ik heb het even nagedaan en het klopt.
Dat is dus nog een bug.
Ik zal in de volgende dit herstellen en nagaan of ik die twee iconen wat beter onderscheidend kan maken
Dank voor je opmerkzaamheid en het melden!

- De weerprognose is een stuk korter geworden, niet meer meerdere dagen. Is er bij meteoserver iets aan de API veranderd? (ik weet het wachtwoord nu al niet meer )

De weerprognose bij Meteoserver wordt iedere 6 uur ververst en ik raad aan om ook eens in de zes uur de gegevens opnieuw op te halen.
Meteoserver (en KNMI) werken met twee verschillende simulatiemodellen:

1. Harmonie (voor de kortere termijn maar meer gedetailleerd)
2. GFS (voor de langere termijn en minder gedetailleerd)

Meer detailinfo daarover vind je op de sites van Meteoserver en KNMI.
DAO begint met het ophalen van data van het Harmonie-model. Die gaan meestal niet verder dan maximaal 45 uur vooruit. Maar soms zijn er minder dan 39 uurvoorspellingen en dan haalt DAO ook nog de voorspellingen op van het GFS-model en die vullen dan de data van het Harmonie-model aan. Dan heb je een voorspelling van meerdere dagen.
Conclusie: soms is de voorspelling korter, soms langer en dat ligt niet aan DAO, maar aan de beschikbaarheid van voldoende data van het Harmonie-model bij Meteoserver.

Als je je wachtwoord bij Meteoserver bent vergeten kun je een nieuw wachtwoord aanvragen.

[Bravo]

KC27 schreef op woensdag 23 april 2025 @ 22:40:
[...]

De weerprognose bij Meteoserver wordt iedere 6 uur ververst en ik raad aan om ook eens in de zes uur de gegevens opnieuw op te halen.
Meteoserver (en KNMI) werken met twee verschillende simulatiemodellen:

1. Harmonie (voor de kortere termijn maar meer gedetailleerd)
2. GFS (voor de langere termijn en minder gedetailleerd)

Meer detailinfo daarover vind je op de sites van Meteoserver en KNMI.
DAO begint met het ophalen van data van het Harmonie-model. Die gaan meestal niet verder dan maximaal 45 uur vooruit. Maar soms zijn er minder dan 39 uurvoorspellingen en dan haalt DAO ook nog de voorspellingen op van het GFS-model en die vullen dan de data van het Harmonie-model aan. Dan heb je een voorspelling van meerdere dagen.
Conclusie: soms is de voorspelling korter, soms langer en dat ligt niet aan DAO, maar aan de beschikbaarheid van voldoende data van het Harmonie-model bij Meteoserver.

Als je je wachtwoord bij Meteoserver bent vergeten kun je een nieuw wachtwoord aanvragen.

Ah, daarom krijg je de ene keer veel meer weerinformatie als de andere keer.
Ik kijk er vaak even naar om te bepalen of ik de komende 48 uur de auto bewust moet laden, of dat ik wacht op een zonenergieoverschot later in de week waarmee de auto geladen gaat worden (ik heb nog geen dynamisch tarief).
Toevalligerwijs zal ik vaak de aanvulling van GFS hebben gezien, niet alleen de Harmonie data.
Zijn de 6 uurs momenten om de weerinformatie op te halen in de standaard configuratie afgestemd op de momenten dat Meteoserver nieuwe data heeft? Ik heb nog 1 extra weersinformatie toegevoegd om 12:45 om bij de prijsrun de actuele meteodata erbij te hebben, maar als die hetzelfde is als om 10:29 heeft dat weinig nut (en kost een extra api call).

[KC27]

Bravo schreef op donderdag 24 april 2025 @ 08:32:
[...]

Ah, daarom krijg je de ene keer veel meer weerinformatie als de andere keer.
Ik kijk er vaak even naar om te bepalen of ik de komende 48 uur de auto bewust moet laden, of dat ik wacht op een zonenergieoverschot later in de week waarmee de auto geladen gaat worden (ik heb nog geen dynamisch tarief).
Toevalligerwijs zal ik vaak de aanvulling van GFS hebben gezien, niet alleen de Harmonie data.
Zijn de 6 uurs momenten om de weerinformatie op te halen in de standaard configuratie afgestemd op de momenten dat Meteoserver nieuwe data heeft? Ik heb nog 1 extra weersinformatie toegevoegd om 12:45 om bij de prijsrun de actuele meteodata erbij te hebben, maar als die hetzelfde is als om 10:29 heeft dat weinig nut (en kost een extra api call).

Op de site van Meteoserver staat:
Nieuwe data in deze API zijn beschikbaar om 5:30, 11:30, 17:30 en 23:30 Nederlandse tijd.
Mijn ervaring is dat deze dan voor de gebruiker een paar uur later beschikbaar zijn. Daar zijn ook de voorgestelde settings op gebaseerd, maar je mag er zelf mee spelen.

[Torch1969]

Bravo schreef op donderdag 24 april 2025 @ 08:32:
[...]

Ik kijk er vaak even naar om te bepalen of ik de komende 48 uur de auto bewust moet laden, of dat ik wacht op een zonenergieoverschot later in de week waarmee de auto geladen gaat worden (ik heb nog geen dynamisch tarief).

Misschien kan deze site je daar bij helpen: https://ned.nl/nl/energieweerbericht

[hemertje]

KC27 schreef op woensdag 23 april 2025 @ 19:49:
[...]
Mocht je betere ideeën voor aansturing hebben (een vierde stuuroptie?) dan hoor ik het graag.

niet zozeer beter, wel een aanvulling

de Panasonic warmtepompen kunnen dmv MQTT aangestuurd worden

zie Heishamon <> Node Red voor Panasonic warmtepompen

[KC27]

hemertje schreef op donderdag 24 april 2025 @ 20:17:
[...]


niet zozeer beter, wel een aanvulling

de Panasonic warmtepompen kunnen dmv MQTT aangestuurd worden

zie Heishamon <> Node Red voor Panasonic warmtepompen

Ziet er interessant uit.
MQTT is een protocol, maar kun je daarmee alles van je wp aansturen?
Wat zou je vanuit DAO willen aansturen?
Het uitgangspunt van DAO is:

• DAO haalt actuele data van het apparaat op uit/via Home Assitant
• DAO berekent de settings en legt die neer in Home Assistant
• Home Assistant stuurt met die settings het apparaat aan.

Dus alle communicatie via Home Assistant.

Dus in dit geval: MQTT naar je wp vanaf Home Assistant.

[ Voor 14% gewijzigd door KC27 op 24-04-2025 22:45 ]

[hemertje]

KC27 schreef op donderdag 24 april 2025 @ 22:33:
[...]

Ziet er interessant uit.
MQTT is een protocol, maar kun je daarmee alles van je wp aansturen?
Wat zou je vanuit DAO willen aansturen?
Het uitgangspunt van DAO is:

• DAO haalt actuele data van het apparaat op uit/via Home Assitant
• DAO berekent de settings en legt die neer in Home Assistant
• Home Assistant stuurt met die settings het apparaat aan.

Dus alle communicatie via Home Assistant.

Dus in dit geval: MQTT naar je wp vanaf Home Assistant.

https://github.com/edterbak/NodeRed_Heishamon_control

Ed's Node Red stuurt nu aan dmv MQTT
Maar Ed's Node Red is op dit moment statisch
Maakt geen dynamische prijs en/of energetische berekeningen

Zou mooi zijn als die integrale sturing van DAO van en naar Ed's Node Red plaats kan vinden
Dan bundel je de kracht van deze twee ontwikkelingen

[storeman]

Sinds de update naar 2025.4 van DAO krijg ik een melding dat de addon niet goed gestart is, met in het scherm "502: bad gateway"

Wat ik heb geprobeerd:
- addon verwijderd en weer toegevoegd (via de Home Assistant addon library)
- In de logs gekeken, hier zie ik dat ie luistert op poort 5003
- In de config van de addon staat de poort gemapped 5000:5000
- Via de hostip:5000 of hostip:5003 kan ik de addon ook niet bereiken

Iemand nog tips? Voor de upgrade naar 2025.4 had ik wel eea werkend.

[KC27]

hemertje schreef op donderdag 24 april 2025 @ 22:51:
[...]


https://github.com/edterbak/NodeRed_Heishamon_control

Ed's Node Red stuurt nu aan dmv MQTT
Maar Ed's Node Red is op dit moment statisch
Maakt geen dynamische prijs en/of energetische berekeningen

Zou mooi zijn als die integrale sturing van DAO van en naar Ed's Node Red plaats kan vinden
Dan bundel je de kracht van deze twee ontwikkelingen

Als ik het goed begrijp communiceert Ed's Node Red via MQTT met je wp.
Ed's Node Red heeft een eigen dashboard.
Maar is het mogelijk om de belangrijke info en settings via HA uit te lezen en te wijzigen?
In dat geval zouden we beide "werelden" kunnen combineren.

[hemertje]

KC27 schreef op donderdag 24 april 2025 @ 23:06:
[...]

Als ik het goed begrijp communiceert Ed's Node Red via MQTT met je wp.
Ed's Node Red heeft een eigen dashboard.
Maar is het mogelijk om de belangrijke info en settings via HA uit te lezen en te wijzigen?
In dat geval zouden we beide "werelden" kunnen combineren.

je vraagt gaat voor mij te diep in de materie
maar jullie twee werelden combineren levert voor de Panasonic gebruikers veel extra mogelijkheden op



@edterbak , kan jij deze vraag beantwoorden?

[KC27]

storeman schreef op donderdag 24 april 2025 @ 23:02:
Sinds de update naar 2025.4 van DAO krijg ik een melding dat de addon niet goed gestart is, met in het scherm "502: bad gateway"

Wat ik heb geprobeerd:
- addon verwijderd en weer toegevoegd (via de Home Assistant addon library)
- In de logs gekeken, hier zie ik dat ie luistert op poort 5003
- In de config van de addon staat de poort gemapped 5000:5000
- Via de hostip:5000 of hostip:5003 kan ik de addon ook niet bereiken

Iemand nog tips? Voor de upgrade naar 2025.4 had ik wel eea werkend.

Wat heb je staan bij de config van de addon in het volgende scherm:

Je kunt het beste niets veranderen aan de settings van de addon in de json-editor:

code:

"dashboard": {
    "port": 5000
  },

Wellicht ten overvloede:
ook in de config.yaml staat:

code:

ingress_port: 5000

En dan zet je in HA via Instellingen\Add ons\Day Ahead Optimizer\ tabblad Configuratie (zie hierboven) in de rechtse kolom 5003.
Dan moet het goed werken.

[edterbak]

KC27 schreef op donderdag 24 april 2025 @ 23:06:
[...]

Als ik het goed begrijp communiceert Ed's Node Red via MQTT met je wp.
Ed's Node Red heeft een eigen dashboard.
Maar is het mogelijk om de belangrijke info en settings via HA uit te lezen en te wijzigen?
In dat geval zouden we beide "werelden" kunnen combineren.

Node Red heeft een direct lijntje met HA.
Je kunt vanuit Node Red alle entiteiten in HA uitlezen. Het is ook mogelijk om entiteiten aan te passen of te voorzien van data.

@hemertje
Ik ben nog niet heel ingelezen in deze DAO (lees: helemaal niet..) Geef me even tijd om het goed te lezen en te begrijpen wat het kan, wat ik er mee kan, maar ook om te bepalen wat ik zelf wil.

[hemertje]

edterbak schreef op donderdag 24 april 2025 @ 23:43:
[...]

Node Red heeft een direct lijntje met HA.
Je kunt vanuit Node Red alle entiteiten in HA uitlezen. Het is ook mogelijk om entiteiten aan te passen of te voorzien van data.

@hemertje
Ik ben nog niet heel ingelezen in deze DAO (lees: helemaal niet..) Geef me even tijd om het goed te lezen en te begrijpen wat het kan, wat ik er mee kan, maar ook om te bepalen wat ik zelf wil.

Dank voor je reactie en toelichting E.d.
Vooral het laatste is belangrijk!

[KC27]

edterbak schreef op donderdag 24 april 2025 @ 23:43:
[...]

Node Red heeft een direct lijntje met HA.
Je kunt vanuit Node Red alle entiteiten in HA uitlezen. Het is ook mogelijk om entiteiten aan te passen of te voorzien van data.

@hemertje
Ik ben nog niet heel ingelezen in deze DAO (lees: helemaal niet..) Geef me even tijd om het goed te lezen en te begrijpen wat het kan, wat ik er mee kan, maar ook om te bepalen wat ik zelf wil.

@edterbak
Kort gezegd:
DAO bepaalt op basis van

• het verloop van de dynamische prijzen van vandaag en morgen
• de weervoorspelling voor vandaag en morgen
• de settings van de gebruiker

hoeveel warmte de warmtepomp moet produceren en hoe deze productie het beste kan worden gespreid zodat de gebruiker goedkoop uitkomt cq zo weinig mogelijk hoeft in te kopen (gebruik van zonnestroom).
DAO kan voorlopig drie soorten settings voor de wp berekenen:

• voor de komende uren het elektrisch vermogen van de warmtepomp (als deze kan moduleren)
• verhoging en verlaging van de stooklijn (mag ook de kamerthermostaat zijn)
• aan/uit warmtepomp

Dit lijstje kan in overleg desgewenst nog verder worden aangevuld.

[Bravo]

Torch1969 schreef op donderdag 24 april 2025 @ 17:10:
[...]

Misschien kan deze site je daar bij helpen: https://ned.nl/nl/energieweerbericht

Ja, dat kan. Maar dat is weer een website om te openen in plaats van even een paar tikjes om binnen DAO dezelfde informatie te verwerken.

Overigens, in de API van NED.nl zit ook een forecast voor CO2/kWh van het grid van de dag. Is dat nog een parameter om naar te optimaliseren?

[KC27]

Bravo schreef op vrijdag 25 april 2025 @ 09:01:
[...]

Ja, dat kan. Maar dat is weer een website om te openen in plaats van even een paar tikjes om binnen DAO dezelfde informatie te verwerken.

Overigens, in de API van NED.nl zit ook een forecast voor CO2/kWh van het grid van de dag. Is dat nog een parameter om naar te optimaliseren?

Die kende ik nog niet.
Heel goede tip.
Dan kunnen we een derde strategie maken (voor de liefhebbers) "minimize co2 emission".
Ik ga ernaar kijken!

[hemertje]

KC27 schreef op vrijdag 25 april 2025 @ 10:42:
[...]
Dan kunnen we een derde strategie maken (voor de liefhebbers) "minimize co2 emission".
Ik ga ernaar kijken!

De goedkope tijden van de dynamische tarieven zijn per definitie met een lage CO2 emissie

Want hoe duurder de kWh, hoe meer er % aan olie en gas er in de duurzame mix van wind en zon wordt bij gestookt

[Torch1969]

KC27 schreef op woensdag 23 april 2025 @ 19:49:
[...]


De voorspelling van de pv kun je in HA opvragen met de api (zie DOCS.md). Bijvoorbeeld:
http://192.168.178.36:500...t/pv_ac/vandaag_en_morgen

Geïnspireerd door deze (nieuwe) mogelijkheid ben ik aan de slag gegaan met de report api in home assistant.
Uiteindelijk is het me gelukt om de zonnepanelen opwek en voorspelling in te lezen. De volgende stap naar een chart staat nog op mijn todo.

Mijn bevindingen tot nu toe: je kunt via de api report url ook de gegevens opvragen van de volgende variabelen (heb ik gehaald uit de kopjes van de prognose tabel in de gui van , staat niet in DOCS.md):

bat_in bat_out cons prod base boil wp ev pv_ac cost profit

- base geeft een foutmelding @KC27 ik neem aan dat deze wel zou moeten werken? zal ik hiervoor een issue aanmaken op GitHub?
- b_tem geeft een melding dat die niet opgevraagd kan worden

Het aanmaken van de REST sensor in home assistant staat niet goed beschreven in DOCS.md. Waarschijnlijk is dit verouderde informatie. Het JSON pad is niet meer “reported” en “expected”, maar alleen “data” (met daarbinnen een datatype “reported” en “expected”).
Oftewel

code:

 - resource: http://192.168.178.64:5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 3600
    sensor:
      - name: DAO PV AC
        unique_id: dao_pv_ac
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour-1].value) | round(3) }}"
        json_attributes:
          - data

Ik heb het scan interval eerst op 1 x per uur gezet. Tussentijds kun je bijwerken door de actie homeassistant.update_entity.
Door de index [now().hour-1] krijgt de entiteit de waarde van het vorige uur (oftewel de gerapporteerde opwek). Door dit aan te passen naar [now().hour], krijg je de voorspelling (expected) waarde van het huidige uur en als je er een +1 achter zet de voorspelling van het volgende uur (enz.).

[ Voor 10% gewijzigd door Torch1969 op 25-04-2025 12:48 ]

[storeman]

KC27 schreef op donderdag 24 april 2025 @ 23:18:
[...]

Wat heb je staan bij de config van de addon in het volgende scherm:
[Afbeelding]
Je kunt het beste niets veranderen aan de settings van de addon in de json-editor:

code:

"dashboard": {
    "port": 5000
  },

Wellicht ten overvloede:
ook in de config.yaml staat:

code:

ingress_port: 5000

En dan zet je in HA via Instellingen\Add ons\Day Ahead Optimizer\ tabblad Configuratie (zie hierboven) in de rechtse kolom 5003.
Dan moet het goed werken.

Het aanpassen van de addon-configuratie wil niet. Ik kan alleen de poort aan de host-kant aanpassen, niet aan de container-kant.

Ik moest dus op zoek naar de config. Gelukkig kon ik via de Terminal plugin naar het bestand en kon ik deze regel verwijderen. Ik had de config geloof ik van iemand anders gekopieerd. Thanks voor je hulp!

[Bravo]

hemertje schreef op vrijdag 25 april 2025 @ 12:13:
[...]


De goedkope tijden van de dynamische tarieven zijn per definitie met een lage CO2 emissie

Want hoe duurder de kWh, hoe meer er % aan olie en gas er in de duurzame mix van wind en zon wordt bij gestookt

Dat geldt voor de periode overdag meestal wel, maar 's nachts kun je een lage prijs hebben terwijl de CO2 emissie nog behoorlijk hoog is. De fossiele opwekking blijft dan doordraaien op een lager pitje.

Hier de puntenwolk met op de horizontale as de energie prijs (ct/kWh, nordpool, zonder toeslagen) en op de vertikale as de uitstoot/kWh (electricitymaps) voor de maand maart.
De prijs is het hoogst als de ramp up van de fossiele opwek nodig is, maar dan is de uitstoot nog relatief laag.

[KC27]

Torch1969 schreef op vrijdag 25 april 2025 @ 12:27:
[...]


Geïnspireerd door deze (nieuwe) mogelijkheid ben ik aan de slag gegaan met de report api in home assistant.
Uiteindelijk is het me gelukt om de zonnepanelen opwek en voorspelling in te lezen. De volgende stap naar een chart staat nog op mijn todo.

Mijn bevindingen tot nu toe: je kunt via de api report url ook de gegevens opvragen van de volgende variabelen (heb ik gehaald uit de kopjes van de prognose tabel in de gui van , staat niet in DOCS.md):

bat_in bat_out cons prod base boil wp ev pv_ac cost profit

- base geeft een foutmelding @KC27 ik neem aan dat deze wel zou moeten werken? zal ik hiervoor een issue aanmaken op GitHub?
- b_tem geeft een melding dat die niet opgevraagd kan worden

Het aanmaken van de REST sensor in home assistant staat niet goed beschreven in DOCS.md. Waarschijnlijk is dit verouderde informatie. Het JSON pad is niet meer “reported” en “expected”, maar alleen “data” (met daarbinnen een datatype “reported” en “expected”).
Oftewel

code:

 - resource: http://192.168.178.64:5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 3600
    sensor:
      - name: DAO PV AC
        unique_id: dao_pv_ac
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour-1].value) | round(3) }}"
        json_attributes:
          - data

Ik heb het scan interval eerst op 1 x per uur gezet. Tussentijds kun je bijwerken door de actie homeassistant.update_entity.
Door de index [now().hour-1] krijgt de entiteit de waarde van het vorige uur (oftewel de gerapporteerde opwek). Door dit aan te passen naar [now().hour], krijg je de voorspelling (expected) waarde van het huidige uur en als je er een +1 achter zet de voorspelling van het volgende uur (enz.).

Dank voor je inzet en voor het melden van de fouten (met base) en de documentatie.
Inmiddels heb ik de fout opgespoord bij "base". Dit wordt hersteld bij de volgende update.

"b_tem" is de verwachte boiler temperatuur. Die wordt niet opgeslagen en is dus niet opvraagbaar.

Ik zal de documentatie doorlopen en de aanpassingen van de api (bij versie 2025.4.0, zie changelog) verwerken.

[Torch1969]

Torch1969 schreef op vrijdag 25 april 2025 @ 12:27:
[...]

De volgende stap naar een chart staat nog op mijn todo.

De eerste versie van apex-chart met daarin:
- de daadwerkelijke zonopwek (geel) van deze dag
- de voorspelde zonopbrengst (grijs) voor die uren (hiervoor gebruik ik de state van de REST sensor die de report api van DAO aanroept, waarbij ik de index op het huidige uur zet, oftewel de state is steeds de voorspelde opbrengst van het huidige uur. Dit wordt netjes door HA bewaard, dus daarmee heb je meteen historie van de voorspelling)
- de voorspelling van de zonopbrengst (rood) vanaf het huidige uur t/m hoever beschikbaar vanuit DAO. (Dit was even uitzoeken. Hiervoor filter ik het data-attribuut op de waarden met datatype = 'expected')

@KC27 in DOCS.md staat nog een fout in de apex chart configuratie (naast de aanpassing van 'reported' en 'expected' naar 'data'). De tijd die je vanuit de data generator teruggeeft moet in ms zijn, oftewel vanuit de nieuwe json data kun je meteen time_ts gebruiken.

Het ziet er als volgt uit:


De

code:

type: custom:apexcharts-card
update_interval: 1 min
graph_span: 2d
header:
  show: true
  title: Zonopwek en voorspelling vandaag en morgen
  show_states: false
  colorize_states: true
span:
  start: day
now:
  show: true
  label: Nu
  color: rgb(53, 86, 81)
series:
  - entity: sensor.zon_totaal_energie_per_uur
    group_by:
      func: last
      duration: 1h
    type: column
    stroke_width: 3
    name: Zon opwek
  - entity: sensor.dao_pv_ac
    group_by:
      func: last
      duration: 1h
    type: column
    stroke_width: 0
    name: Zon voorspeld
    color: grey
    float_precision: 3
  - entity: sensor.dao_pv_ac
    attribute: data
    group_by:
      func: last
      duration: 1h
    type: column
    stroke_width: 3
    name: Zon voorspelling
    float_precision: 3
    data_generator: |
      let td = entity.attributes.data;
      const tdexpected = td.filter(td => td.datatype === 'expected');
      return tdexpected.map(row => {
              return [row.time_ts, row.value];
            });

[tonvanboven]

hemertje schreef op vrijdag 25 april 2025 @ 12:13:
[...]


De goedkope tijden van de dynamische tarieven zijn per definitie met een lage CO2 emissie

Want hoe duurder de kWh, hoe meer er % aan olie en gas er in de duurzame mix van wind en zon wordt bij gestookt

Dat is niet helemaal waar. De dynamische prijzen zijn gebaseerd op aannames en die kunnen wel eens mis zijn. Met name zon is slechter te voorspellen dan wind. En als er dan, ondanks dat de prijs laag is, er minder aanbod is dan moet er bijgesprongen worden. En dat is meestal minder duurzaam, lees meer CO2.
Het is dus een vuistregel, maar niet 'per definitie' duurzaam. Just my two cents ;-)

[tonvanboven]

KC27 schreef op vrijdag 25 april 2025 @ 10:42:
[...]
Dan kunnen we een derde strategie maken (voor de liefhebbers) "minimize co2 emission".
Ik ga ernaar kijken!

Dat is wel een mooie optie om erbij te krijgen, niet alleen het geld is belangrijk maar duurzaamheid ook.

[KC27]

Morgen zijn - voor het eerst dit kalenderjaar - de all-in prijzen negatief.
DAO zet dan mijn zonnepanelen uit. Ik ga de planning van het laden van mijn hybride auto (6 kWh) verder naar morgen schuiven:

[KC27]

Voor gebruikers die de nieuwe release (voor hij wordt gepubliceerd) willen testen.
In de addon-branche staat versie 2025.4.2.rc1 (edit: inmiddels rc2) daarvoor klaar.
Dit staat er in de changelog:
- Fixed futurewarning dataframe (reported by @Torch1969 )
- Fixed error when deleting an image/log and deny or cancel confirmation (the item was deleted) (reported by @Bravo )
- Fixed error when calling api with data for base (=baseload) (reported by @Torch1969 )
- Adjusted documentation of the api-call

Ik hoor graag jullie bevindingen.

[ Voor 3% gewijzigd door KC27 op 26-04-2025 17:44 ]

[Torch1969]

KC27 schreef op zaterdag 26 april 2025 @ 15:33:
Voor gebruikers die de nieuwe release (voor hij wordt gepubliceerd) willen testen.
In de addon-branche staat versie 2025.4.2.rc1 (edit: inmiddels rc2) daarvoor klaar.
Dit staat er in de changelog:
- Fixed futurewarning dataframe (reported by @Torch1969 )
- Fixed error when deleting an image/log and deny or cancel confirmation (the item was deleted) (reported by @Bravo )
- Fixed error when calling api with data for base (=baseload) (reported by @Torch1969 )
- Adjusted documentation of the api-call

Ik hoor graag jullie bevindingen.

In afwachting van de negatieve prijzen sleutel ik even niet aan mijn dao-container en setup
Heb wel even docs.md gereviewed. Zie er goed uit, alleen in de configuratie voor de apex-chart heb je bij alle vier grafieken de “td.recorded” en “td.expected” variabelen verkeerd staan, achter “const” en achter “return”. vast en copy-paste foutje….

[KC27]

Torch1969 schreef op zaterdag 26 april 2025 @ 20:27:
[...]

In afwachting van de negatieve prijzen sleutel ik even niet aan mijn dao-container en setup
Heb wel even docs.md gereviewed. Zie er goed uit, alleen in de configuratie voor de apex-chart heb je bij alle vier grafieken de “td.recorded” en “td.expected” variabelen verkeerd staan, achter “const” en achter “return”. vast en copy-paste foutje….

Neem ik mee in de definitieve release.

[balk]

KC27 schreef op zaterdag 26 april 2025 @ 14:52:

DAO zet dan mijn zonnepanelen uit. Ik ga de planning van het laden van mijn hybride auto (6 kWh) verder naar morgen schuiven:

Kan je uitleggen hoe DAO dit doet? Is dat niet gewoon een simpele automation in HA? Het was wel een leuke accu dag trouwens.

Ik moet nog een automation maken die bij negatieve prijzen regelt dat:
- accu leeg gaat in de ochtend piek
- accu idle staat tot negatieve prijzen
- accu vol pompt tijdens negatieve prijzen terwijl de PVs uit staan
- daarna PV weer aan, en accu op nom
- daarna Dao weer actief
Binnenkort maar eens aan werken

[DaBit]

balk schreef op zondag 27 april 2025 @ 20:29:
[...]

Kan je uitleggen hoe DAO dit doet? Is dat niet gewoon een simpele automation in HA? Het was wel een leuke accu dag trouwens.

Met "entity pv switch" in je solarsectie. En dan inderdaad een automation die daarop reageert.

Ik moet nog een automation maken die bij negatieve prijzen regelt dat:
- accu leeg gaat in de ochtend piek
- accu idle staat tot negatieve prijzen
- accu vol pompt tijdens negatieve prijzen terwijl de PVs uit staan
- daarna PV weer aan, en accu op nom
- daarna Dao weer actief
Binnenkort maar eens aan werken

Dat is al normaal gedrag voor DAO?

[balk]

DaBit schreef op zondag 27 april 2025 @ 20:57:
[...]


Met "entity pv switch" in je solarsectie. En dan inderdaad een automation die daarop reageert.

[Afbeelding]

Dat is al normaal gedrag voor DAO?

[Afbeelding]

Bedankt voor de hint! Die had ik nog even gemist.
Klopt, normaal gedrag. Alleen heb ik het nu zo geregeld dat bij een setpoint 0 vanuit DAO de Sessy op NoM gaat. Dus daar heb ik nog iets te doen. En nog wat daoisme te leren

[ Voor 3% gewijzigd door balk op 27-04-2025 21:30 ]

[Torch1969]

balk schreef op zondag 27 april 2025 @ 21:29:
[...]

Bedankt voor de hint! Die had ik nog even gemist.
Klopt, normaal gedrag. Alleen heb ik het nu zo geregeld dat bij een setpoint 0 vanuit DAO de Sessy op NoM gaat. Dus daar heb ik nog iets te doen. En nog wat daoisme te leren

Is het niet zo simpel als DAO tijdig op strategie “minimaliseer kosten” zetten en daarna weer “minimaliseer verbruik”?

[KC27]

balk schreef op zondag 27 april 2025 @ 20:29:
[...]

Kan je uitleggen hoe DAO dit doet? Is dat niet gewoon een simpele automation in HA? Het was wel een leuke accu dag trouwens.

Ik moet nog een automation maken die bij negatieve prijzen regelt dat:
- accu leeg gaat in de ochtend piek
- accu idle staat tot negatieve prijzen
- accu vol pompt tijdens negatieve prijzen terwijl de PVs uit staan
- daarna PV weer aan, en accu op nom
- daarna Dao weer actief
Binnenkort maar eens aan werken

Wat jij hierboven beschrijft is precies de strategie die DAO volgt als je die zijn gang laat gaan met de strategie "minimize cost".
Dit was mijn berekende DAO-grafiek van gisteren om 13:00 uur:

Zoals je ziet zijn de groene balken (pv-productie) in de geoptimaliseerde grafiek tussen 12:00 en 15:00 uur verdwenen.
En zo is het ook vandaag gebeurd (grafiek uit Home Assistant):

En ook de batterij heeft zich netjes aan de planning gehouden:

[DaBit]

Ik heb een 100L COP=1 elektrische boiler als voorverwarmer voor mijn tapwater. Die boiler moet gebruikt worden als het uitkan, dus als warmwater breiden met elektriciteit goedkoper is dan gas. Die boiler draait nu buiten DAO om met een stukje nodered dat kijkt of electriciteit goedkoper is dan gas, sorteert op goedkoopste uren en het setpoint aanpast (70C in het goedkoopste uur aflopend naar 45C).

Ideaal is dat niet op dagen zoals gisteren; de stroom was al veel eerder goedkoper dan gas voor-ie negatief ging. Dan is de boiler al een aardig eind op temperatuur. Verder weet DAO niks van de consumptie van die boiler wat de totale oplossing minder optimaal maakt.

Ik probeerde nu dus om die boiler als 2e elektrische auto in de voeren. Dat doet wat ik wil denk ik; de goedkoper-dan-gas boolean kan dienst doen als 'is plugged in', gemeten/gewenste temperatuur is niet anders dan procenten SoC, ik kan opgeven wanneer het klaar moet zijn, en DAO kan het optimaal inplannen.

De nep-auto in de configuratiefile. Daar zitten nog een paar dingetjes in van de echte EV bij de boiler maar die worden toch niet gebruikt (corsae_location is altijd 'home' bijvoorbeeld)

code:

..
..
"electric vehicle": [ 
    {
      "name": "Corsa-E",
      "capacity": 47.0,
      "entity max amperage": "input_number.ev_max_charge_amps",
      "entity position": "input_select.corsae_location",
      "charge three phase": "False",
      "charge stages" : [
      {"ampere":  0, "efficiency" :  1},
            {"ampere":  6, "efficiency": 0.95},
            {"ampere":  7, "efficiency": 0.95},
            {"ampere":  8, "efficiency": 0.95},
            {"ampere":  9, "efficiency": 0.95},
            {"ampere": 10, "efficiency": 0.95},
            {"ampere": 11, "efficiency": 0.95},
      {"ampere": 12, "efficiency": 0.95},
            {"ampere": 13, "efficiency": 0.95},
            {"ampere": 14, "efficiency": 0.95},
            {"ampere": 15, "efficiency": 0.95},
            {"ampere": 16, "efficiency": 0.95},
            {"ampere": 18, "efficiency": 0.95},
            {"ampere": 21, "efficiency": 0.95},
            {"ampere": 24, "efficiency": 0.95},
            {"ampere": 27, "efficiency": 0.95},
      {"ampere": 30, "efficiency": 0.95},
            {"ampere": 33, "efficiency": 0.94},
            {"ampere": 36, "efficiency": 0.93},
            {"ampere": 39, "efficiency": 0.92},
            {"ampere": 42, "efficiency": 0.91}
      ],
      "entity actual level": "sensor.corsa_e_battery_percent",
      "entity plugged in": "binary_sensor.charger_pluggedin",
      "charge scheduler": {
        "entity set level": "input_number.ev_desired_chargelevel",
        "level margin": 1,
        "entity ready datetime": "input_datetime.charge_ready_datetime"
      },
      "charge switch": "input_boolean.corsae_charge_switch",
      "entity set charging ampere": "input_number.dao_laadpaal_amp"
    },
    {
      "name": "boiler",
      "capacity": 11.4,
      "entity max amperage": "input_number.ev_max_charge_amps",
      "entity position": "input_select.corsae_location",
      "charge three phase": "False",
      "charge stages" : [
      {"ampere":  0,  "efficiency":  1},
      {"ampere":  3,  "efficiency": 0.99 },
            {"ampere":  5,  "efficiency": 0.99 },
      {"ampere":  8,  "efficiency": 0.98 },
            {"ampere":  10, "efficiency": 0.98 }
      ],
      "entity actual level": "sensor.boiler_boiler_temperature",
      "entity plugged in": "binary_sensor.electricity_cheaperthangas",
      "charge scheduler": {
        "entity set level": "input_number.boiler_desiredtemperature",
        "level margin": 1,
        "entity ready datetime": "input_datetime.dao_boiler_ready_datetime"
      },
      "charge switch": "input_boolean.dao_boiler_activate",
      "entity set charging ampere": "input_number.dao_boiler_ampsetpoint"
    }
  ],
..
..

Na draaien optimalisatie krijg ik deze foutmeldingen:

code:

..
..
2025-04-28 11:15:07 info: Berekeningsuitkomst voor opladen van Corsa-E:
2025-04-28 11:15:07 info: - aantal ampere 0A (was 0.0A)
2025-04-28 11:15:07 info: - stand schakelaar 'off' (was 'off')
2025-04-28 11:15:07 info: - positie: home
2025-04-28 11:15:07 info: - ingeplugd: True
2025-04-28 11:15:07 info: Evaluatie status laden Corsa-E op 2025-04-28 11:15
2025-04-28 11:15:07 info: - schakelaar laden: off
2025-04-28 11:15:07 info: - aantal ampere: 0.0
2025-04-28 11:15:07 info: Inzet-factor laden boiler per stap
uur   0.0A   3.0A   5.0A   8.0A  10.0A 2025-04-28 11:15:07 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3452, in <module>
2025-04-28 11:15:07 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3426, in main
2025-04-28 11:15:07 fout: File: /root/dao/prog/da_base.py, line 479, in run_task_function
2025-04-28 11:15:07 fout: File: /root/dao/prog/da_base.py, line 410, in calc_optimum_met_debug
2025-04-28 11:15:07 fout: File: /root/dao/prog/day_ahead.py, line 2866, in calc_optimum
2025-04-28 11:15:07 fout: Onverwachte fout: list index out of range
Traceback (most recent call last):
  File "/root/dao/prog/day_ahead.py", line 2441, in calc_optimum
    print(f" {charge_stages[e][cs]['ampere']:4.1f}A", end=" ")
              ~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range

Vast stupid user error, maar waar?

[RudolfR]

@DaBit

Misschien wel een bug.
Zou kunnen dat er per abuis naar de settings van de 1e EV wordt gekeken.

https://github.com/cornee...o/prog/day_ahead.py#L2440

Harde verwijzing naar index 0 in de lijst:

Python:

for cs in range(ECS[0]):
    print(f" {charge_stages[e][cs]['ampere']:4.1f}A", end=" ")

Meestal staat er zoiets:

Python:

for cs in range(ECS[e])

[arro3038]

DaBit schreef op maandag 28 april 2025 @ 11:34:
Ik probeerde nu dus om die boiler als 2e elektrische auto in de voeren. Dat doet wat ik wil denk ik; de goedkoper-dan-gas boolean kan dienst doen als 'is plugged in', gemeten/gewenste temperatuur is niet anders dan procenten SoC, ik kan opgeven wanneer het klaar moet zijn, en DAO kan het optimaal inplannen.

Geen oplossing van je error, maar waarom gebruik je de boiler in DAO niet? DAO geeft aan wanneer je boiler zou moeten gaan verwarmen (op elektra), dan kun je zelf op dat moment in HA of Node red beslissen of je dat op gas of op elektra wilt doen.