Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Vaevictis_]

KC27 schreef op zaterdag 17 januari 2026 @ 17:59:
[...]

Sorry voor mijn onwetendheid maar wat is een TB?

Een thuisbatterij

[Vaevictis_]

KC27 schreef op zaterdag 17 januari 2026 @ 17:59:
[...]

Sorry voor mijn onwetendheid maar wat is een TB?

@KC27 Maar welke stappen moet ik nu minimaal nemen om de TB op basis van tibber tarieven te laten laden cq ontladen?

[KC27]

Vaevictis_ schreef op zaterdag 17 januari 2026 @ 21:35:
[...]


@KC27 Maar welke stappen moet ik nu minimaal nemen om de TB op basis van tibber tarieven te laten laden cq ontladen?

Deze input heeft DAO nodig:

• Je moet DAO toegang geven tot een sensor in HA die de actuele inhoud van je accu presenteert. Die sensor geef je aan met de setting: entity actual level. Bijvoorbeeld:
  
  code:
  

  "entity actual level": "sensor.ess_battery_soc",

• Verder moet je de capaciteit, lower limit, upper limit, max soc, "charge_stages" en "discharge stages" definiëren (zie documentatie in wiki: https://github.com/corneel27/day-ahead/wiki)

Tenslotte zijn er drie entities van belang waarin DAO de belangrijkste resultaten kan wegschrijven. Hiervoor kun je het beste in HA helpers aanmaken. Bij een verandering van state trigger je een automation die de berekende waarde (eventueel omgezet) doorzet naar je TB.

• .
• "entity set operating mode": "input_select.ess_operating_mode",
  Je maakt een input_select met de opties "aan"en "uit". Als je accu niks hoeft te doen gaat ie op "uit", anders op "aan".
• "entity set power feedin": "input_number.dao_set_power_feedin",
  Hierin komt het berekende vermogen in W dat je accu moet gaan opnemen (+) of terugleveren(-). Sommige accu's verwachten het teken andersom. Je kunt dit dus omdraaien in je HA-automation.
• "entity stop inverter": "input_datetime.stop_inverter",
  Hierin komt een datum/tijd te staan waarop je je inverter/accu moet stoppen met laden/ontladen. Deze datum/tijd wordt alleen ingevuld als die stop valt voor de start van de volgende berekening,

Ik weet niet welk merk/type thuisbatterij je hebt. Maar er zijn hier van verschillende merken en typen voorbeeld instellingen gedeeld (vaak als onderdeel van een vraag). Als je op merk en type zoekt zul je ongetwijfeld een een hit vinden. Anders zijn hier veel mensen beschikbaar om je verder te helpen.

[djoenez]

Ik heb de baseload calculaties werkend. Bedankt allen!

Ik heb ook de kosten aangepast (zit bij Tibber) ivm eerdere posts.

code:

  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09157
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09157
    },
    "cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2026-01-01": 0.0
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },

Strategy is: minimize cosr

Ik zie alleen dat de batterij eigenlijk niet meer aan het handelen is sinds deze aanpassing. Hij is alleen mondjes maar aan het laden als er iets van PV is. En dumpt dat ( paar procent?) in de dure avond kwartieren. Zien anderen dit ook? Hij was eerst ook op vol vermogen (12kw) aan het laden en ontladen. Maar dat heb ik niet meer gezien sinds die wijziging ( terwijl de omvormer zeer inefficiënt met lage vermogens laden en ontladen)

[ Voor 14% gewijzigd door djoenez op 18-01-2026 08:15 ]

[Torch1969]

djoenez schreef op zondag 18 januari 2026 @ 08:12:
Ik heb de baseload calculaties werkend. Bedankt allen!

Ik heb ook de kosten aangepast (zit bij Tibber) ivm eerdere posts.
[...]


Strategy is: minimize cosr

Ik zie alleen dat de batterij eigenlijk niet meer aan het handelen is sinds deze aanpassing. Hij is alleen mondjes maar aan het laden als er iets van PV is. En dumpt dat ( paar procent?) in de dure avond kwartieren. Zien anderen dit ook? Hij was eerst ook op vol vermogen (12kw) aan het laden en ontladen. Maar dat heb ik niet meer gezien sinds die wijziging ( terwijl de omvormer zeer inefficiënt met lage vermogens laden en ontladen)

[Afbeelding]

Het verschil in prijs is vandaag te laag. Mijn batterij doet ook amper wat vandaag.
De komende dagen beloven wel de nodige prijsverschillen. Kijk het even aan

Deze grafiek heb ik gemaakt obv Ned.nl data en 2 verschillende prijsvoorspelling.
De Ned.nl data en epexvoorspelling komen uit @Bravo (ook een DAO gebruiker) zijn integratie https://github.com/BravoNLD/NED-forecast.
De epexvoorspelling 2 heb ik hier vandaan bsh10 in "Het grote day ahead / dynamische energieprijzen topic."

[ Voor 7% gewijzigd door Torch1969 op 18-01-2026 09:50 ]

[djoenez]

Torch1969 schreef op zondag 18 januari 2026 @ 09:42:
[...]

Het verschil in prijs is vandaag te laag. Mijn batterij doet ook amper wat vandaag.
De komende dagen beloven wel de nodige prijsverschillen. Kijk het even aan
[Afbeelding]
Deze grafiek heb ik gemaakt obv Ned.nl data en 2 verschillende prijsvoorspelling.
De Ned.nl data en epexvoorspelling komen uit @Bravo (ook een DAO gebruiker) zijn integratie https://github.com/BravoNLD/NED-forecast.
De epexvoorspelling 2 heb ik hier vandaan bsh10 in "Het grote day ahead / dynamische energieprijzen topic."

Bedankt voor het meedenken. En wat een mooie grafiek. Zou je daarvoor de Apex code kunnen delen?

[Torch1969]

djoenez schreef op zondag 18 januari 2026 @ 09:54:
[...]


Bedankt voor het meedenken. En wat een mooie grafiek. Zou je daarvoor de Apex code kunnen delen?

Zie de gelinkte GitHub voor de basis (de integratie is trouwens wel een beetje buggy en de support van bravo op dit moment beperkt, dus je moet zelf wel even aan de hobby hiermee).
Dit is mijn apex chart code:

code:

 type: custom:apexcharts-card
graph_span: 144h
span:
  start: day
header:
  show: true
  title: Epex prijs en duurzame energie forecast
  show_states: false
  colorize_states: true
stacked: true
now:
  show: true
  label: Nu
  color: "#FF6B6B"
yaxis:
  - id: Volume
    decimals: 0
    apex_config:
      tickAmount: 6
      labels:
        formatter: |
          EVAL:function(value) {
            return value.toFixed(0) + ' GW';
          }
  - id: Price
    opposite: true
    decimals: 0
    min: ~0
    max: ~25
    apex_config:
      tickAmount: 6
      labels:
        formatter: |
          EVAL:function(value) {
            return value.toFixed(0) + ' ct/kWh';
          }
apex_config:
  chart:
    height: 400px
    stacked: true
    stackOnlyBar: true
    stackType: normal
  grid:
    show: true
    borderColor: "#e0e0e0"
    strokeDashArray: 3
  xaxis:
    labels:
      datetimeUTC: false
      format: ddd dd MMM
  tooltip:
    enabled: true
    shared: true
    intersect: false
    x:
      format: dd MMM yyyy HH:mm
    Volume:
      formatter: |
        EVAL:function(value) {
          return value.toFixed(0) + ' GW';
        }
  stroke:
    curve: smooth
    width: 2
  fill:
    type: solid
    opacity: 0.85
  legend:
    show: true
    position: bottom
    horizontalAlign: center
series:
  - entity: sensor.ned_forecast_wind_onshore
    name: Wind op land
    type: column
    yaxis_id: Volume
    color: "#0EA5E9"
    unit: GW
    stack_group: renewable
    show:
      legend_value: false
    data_generator: |
      return entity.attributes.forecast.map((entry) => {
        return [new Date(entry.datetime).getTime(), entry.value];
      });
  - entity: sensor.ned_forecast_wind_offshore
    name: Wind op zee
    type: column
    color: "#14B8A6"
    yaxis_id: Volume
    unit: GW
    stack_group: renewable
    show:
      legend_value: false
    data_generator: |
      return entity.attributes.forecast.map((entry) => {
        return [new Date(entry.datetime).getTime(), entry.value];
      });
  - entity: sensor.ned_forecast_solar
    name: Zon
    type: column
    color: "#FBBF24"
    yaxis_id: Volume
    unit: GW
    stack_group: renewable
    show:
      legend_value: false
    data_generator: |
      return entity.attributes.forecast.map((entry) => {
        return [new Date(entry.datetime).getTime(), entry.value];
      });
  - entity: sensor.ned_forecast_consumption
    name: Verbruik
    type: line
    color: red
    yaxis_id: Volume
    unit: GW
    show:
      legend_value: false
    data_generator: |
      return entity.attributes.forecast.map((entry) => {
        return [new Date(entry.datetime).getTime(), entry.value];
      });
  - entity: sensor.ned_forecast_consumption
    name: Verschil
    type: line
    color: darkorange
    unit: GW
    show:
      legend_value: false
    yaxis_id: Volume
    data_generator: >
      const vraag = entity.attributes.forecast; const zon =
      hass.states['sensor.ned_forecast_solar'].attributes.forecast; const
      windland =
      hass.states['sensor.ned_forecast_wind_onshore'].attributes.forecast; const
      windzee =
      hass.states['sensor.ned_forecast_wind_offshore'].attributes.forecast;

      return vraag.map((entry) => {
        const t = new Date(entry.datetime).getTime();
        const zonVal = zon.find(e => e.datetime === entry.datetime)?.value || 0;
        const landVal = windland.find(e => e.datetime === entry.datetime)?.value || 0;
        const zeeVal = windzee.find(e => e.datetime === entry.datetime)?.value || 0;
        return [t, (entry.value - (0.3*zonVal + landVal + zeeVal))];
      });
  - entity: sensor.forecast_epex_price
    name: EPEX Forecast
    type: line
    color: lightgrey
    yaxis_id: Price
    unit: ct/kWh
    stroke_width: 3
    opacity: 1
    show:
      legend_value: false
    data_generator: |
      return entity.attributes.forecast.map((entry) => {
        return [new Date(entry.datetime).getTime(), entry.value];
      });
  - entity: sensor.ned_forecast_consumption
    name: EPEX Forecast_2
    type: line
    color: darkgrey
    unit: ct/kWh
    show:
      legend_value: false
    yaxis_id: Price
    data_generator: >
      const vraag = entity.attributes.forecast; const zon =
      hass.states['sensor.ned_forecast_solar'].attributes.forecast; const
      windland =
      hass.states['sensor.ned_forecast_wind_onshore'].attributes.forecast; const
      windzee =
      hass.states['sensor.ned_forecast_wind_offshore'].attributes.forecast;

      return vraag.map((entry) => {
        const t = new Date(entry.datetime).getTime();
        const zonVal = zon.find(e => e.datetime === entry.datetime)?.value || 0;
        const landVal = windland.find(e => e.datetime === entry.datetime)?.value || 0;
        const zeeVal = windzee.find(e => e.datetime === entry.datetime)?.value || 0;
        const RUVal = entry.value - (0.3*zonVal + landVal + zeeVal)
        const forecastVal = -0.24707292 + (2.68780418 * RUVal) - (0.28737968 * RUVal*RUVal) + (0.01165703 * RUVal*RUVal*RUVal)
        return [t, forecastVal];
      });
  - entity: sensor.nord_pool_dap_totaal
    name: EPEX Price
    type: line
    color: black
    yaxis_id: Price
    unit: cd/kWh
    stroke_width: 3
    opacity: 1
    show:
      legend_value: false
    data_generator: |
      return entity.attributes.data_epex.map((start, index) => {
        return [new Date(start["start"]).getTime(), 100*entity.attributes.data_epex[index]["price"]];
      });

[djoenez]

Torch1969 schreef op zondag 18 januari 2026 @ 10:01:
[...]

Zie de gelinkte GitHub voor de basis (de integratie is trouwens wel een beetje buggy en de support van bravo op dit moment beperkt, dus je moet zelf wel even aan de hobby hiermee).
Dit is mijn apex chart code:

[...]

@KC27 , is het mogelijk om op den duur de langere verwachting van de epex prijs vanuit deze bron mee te nemen in de calculaties?

[Torch1969]

djoenez schreef op zondag 18 januari 2026 @ 10:13:
[...]


@KC27 , is het mogelijk om op den duur de langere verwachting van de epex prijs vanuit deze bron mee te nemen in de calculaties?

Het lastige is dat de precieze bedragen eigenlijk niet te gebruiken zijn, die zitten er bijna altijd wel een beetje of veel naast. Het gaat om de trend. En dan met name voor één, max 2 dagen vooruit waar de prijzen nog niet bekend zijn. Met name om te bepalen of je de accu juist nu moet vullen of legen, en b.v. of je beter nog even kunt wachten met laden van je EV. Dus een indicator “er komen hogere pieken” en “er komen diepere dalen”.

[edterbak]

Hoi,
Ik wil graag mijn vaatwasser laten starten via DAO.
Dit is de code welke ik in het voorbeeld vond.

code:

{ "name": "vaatwasser",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "eco",
           "power": [2000, 2000, 1500, 1000, 500, 500, 1000, 1000]
           }
        ],
        "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"
      }

Mijn vaatwasser heeft een knopje er op waarmij ik aangeef: "Remote starten". Als deze aan is, dan pas kan ik hem starten. (Zonder doet ie gewoon niks natuurlijk.) Als de gebruiker deze knop heeft ingedrukt, dan pas hoeft DAO hem mee te nemen in zijn optimalisatie run. Op dit moment plant hij hem altijd in.
Dat is dus eigenlijk mijn "entity enabled". Ik kan de status uitlezen van dit ding via een binary sensor.

Bestaat voor machines iets als "entity enabled" ?

PS.
Ik heb overigens al getest of het remote starten goed werkt in HA via een script.
Als ik een script nu start, dan 1: Vaatwasser aan, 2: Start vaatwasser met geselecteerde programma.
Dat werkt gewoon. Dus eigenlijk zou ik ook een simpele trigger naar dit script ook voldoende zijn. Maar ik ook weet niet of dat kan.

Iemand tips / advies?

[edterbak]

@hemertje Ter info.
Ik heb het half werkend nu, de integratie met mijn node red flow om een DHW run te plannen.
Voor de geinteresseerden: https://github.com/edterbak/NodeRed_Heishamon_control
Ik heb de Panasonic pomp als boiler ingeplugd.

code:

    "boiler": {
        "boiler present": "True",
        "entity actual temp.": "sensor.panasonic_heat_pump_main_dhw_temp",
        "entity setpoint": "input_number.dao_boiler_entity_setpoint",
        "entity hysterese": "input_number.dao_boiler_entity_hysterese",
        "cop": 4.0,
        "cooling rate": 0.42,
        "volume": 300,
        "heating allowed below": 46,
        "elec. power": 1100,
        "activate service": "press",
        "activate entity": "input_button.node_red_start_dhw_run",
        "boiler heated by heatpump": "True"
    },

In HA heb ik helpers aangemaakt;
"input_button.node_red_start_dhw_run" >>> Deze lees ik uit in Node Red en link deze (straks) door naar de [Start DHW run] link-in node.
"sensor.panasonic_heat_pump_main_dhw_temp" >>> Sensor van Aquara integration
"input_number.dao_boiler_entity_setpoint" >>> HA invul veldje omdat ik niet hard coded een getal kon invullen.
"input_number.dao_boiler_entity_hysterese" >>> HA invul veldje omdat ik niet hard coded een getal kon invullen.

Ik zal de code delen zodra het 100% operationeel is. Op dit moment laat ik DAO alleen een regel in het log schrijven in mijn Node Red flow, en dat komt prima binnen. Ik heb hem nog niet aan het werk gezet. Dus zodra dat draait, zal ik zaken gaan delen hier.

[simnet]

djoenez schreef op zondag 18 januari 2026 @ 10:13:
[...]


@KC27 , is het mogelijk om op den duur de langere verwachting van de epex prijs vanuit deze bron mee te nemen in de calculaties?

Een groot probleem is dat deze bron zijn informatie 'illegaal' verkrijgt. De ned.nl data is namelijk helemaal niet vrij om te gebruiken, helaas.

[Torch1969]

edterbak schreef op zondag 18 januari 2026 @ 10:29:
Hoi,
Ik wil graag mijn vaatwasser laten starten via DAO.
Dit is de code welke ik in het voorbeeld vond.

code:

{ "name": "vaatwasser",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "eco",
           "power": [2000, 2000, 1500, 1000, 500, 500, 1000, 1000]
           }
        ],
        "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"
      }

Mijn vaatwasser heeft een knopje er op waarmij ik aangeef: "Remote starten". Als deze aan is, dan pas kan ik hem starten. (Zonder doet ie gewoon niks natuurlijk.) Als de gebruiker deze knop heeft ingedrukt, dan pas hoeft DAO hem mee te nemen in zijn optimalisatie run. Op dit moment plant hij hem altijd in.
Dat is dus eigenlijk mijn "entity enabled". Ik kan de status uitlezen van dit ding via een binary sensor.

Bestaat voor machines iets als "entity enabled" ?

PS.
Ik heb overigens al getest of het remote starten goed werkt in HA via een script.
Als ik een script nu start, dan 1: Vaatwasser aan, 2: Start vaatwasser met geselecteerde programma.
Dat werkt gewoon. Dus eigenlijk zou ik ook een simpele trigger naar dit script ook voldoende zijn. Maar ik ook weet niet of dat kan.

Iemand tips / advies?

Is het niet zo eenvoudig als op basis van entity enabled het programma op “off” en “eco” omschakelen?

[KC27]

Vanmorgen zijn er nieuwe versies gepubliceerd:

• productie versie: 2026.01.0
• test versie: 2026.01.0.rc9

Beide versies zijn identiek.
Dit staat in de changelog van de productie versie
With this new stable release comes a second optional method for predicting the production of your solar-devices.
This if fully documented in the wiki: https://github.com/cornee...#pv-productie-voorspellen <br>
This module is developed by @simnet and implemented by @KC27 .
Other changes and fixes:

• Updated several used python packages
• charge and discharge of the battery is now fully calculated with "specializes order set" (sos). This gives always the "optimal" (=most efficient) level voor charging and discharging.
• Update README.md with a link to wiki: https://github.com/corneel27/day-ahead/wiki (thanks @Torch1969 )
• From now on new features will only be documented in the wiki, in the future DOCS.md will become deprecated.

[Torch1969]

simnet schreef op zondag 18 januari 2026 @ 10:42:
[...]


Een groot probleem is dat deze bron zijn informatie 'illegaal' verkrijgt. De ned.nl data is namelijk helemaal niet vrij om te gebruiken, helaas.

Is dat zo? Ik dacht dat Ned.nl juist een initiatief is om deze data gratis ter beschikking te stellen ter bevordering van de energie transitie, als ieder van ons met zijn eigen account en api sleutel de data ophaalt, om daarna geautomatiseerd (via een gezamenlijke logica = DAO) slimme keuzes in energieverbruik te maken, dan is dat toch juist de bedoeling?

[KC27]

simnet schreef op zondag 18 januari 2026 @ 10:42:
[...]


Een groot probleem is dat deze bron zijn informatie 'illegaal' verkrijgt. De ned.nl data is namelijk helemaal niet vrij om te gebruiken, helaas.

Heb jij een link naar de pagina waar deze restricties staan vermeld?

[bartzzz]

Vandaag de LM modellen eens geprobeerd.
Het trainen is goed gegaan, echter krijg ik een foutmelding als ik Optimaliseringsberekening met debug run.
Dit is de foutmelding:

code:

ogging van bewerking "Optimaliseringsberekening met debug":

2026-01-18 11:26:16 info: Day Ahead Optimalisering versie: 2026.01.0
2026-01-18 11:26:16 info: Day Ahead Optimalisering gestart op: 18-01-2026 11:26:16
2026-01-18 11:26:16 info: Day Ahead Optimalisatie gestart: 18-01-2026 11:26:16 taak: calc_optimum_met_debug
2026-01-18 11:26:16 info: Debug = True
2026-01-18 11:26:17 info: Baseload uit instellingen
2026-01-18 11:26:17 info: ML prediction pv_woning
                   date_time  prediction
0  2026-01-18 11:00:00+01:00       0.260
1  2026-01-18 12:00:00+01:00       0.435
2  2026-01-18 13:00:00+01:00       0.622
3  2026-01-18 14:00:00+01:00       0.761
4  2026-01-18 15:00:00+01:00       0.693
5  2026-01-18 16:00:00+01:00       0.170
6  2026-01-18 17:00:00+01:00       0.006
7  2026-01-18 18:00:00+01:00       0.005
8  2026-01-18 19:00:00+01:00       0.000
9  2026-01-18 20:00:00+01:00       0.000
10 2026-01-18 21:00:00+01:00       0.000
11 2026-01-18 22:00:00+01:00       0.000
2026-01-18 11:26:17 info: ML prediction pv_garage
                   date_time  prediction
0  2026-01-18 11:00:00+01:00       3.859
1  2026-01-18 12:00:00+01:00       4.435
2  2026-01-18 13:00:00+01:00       4.111
3  2026-01-18 14:00:00+01:00       3.150
4  2026-01-18 15:00:00+01:00       1.772
5  2026-01-18 16:00:00+01:00       0.381
6  2026-01-18 17:00:00+01:00       0.010
7  2026-01-18 18:00:00+01:00       0.009
8  2026-01-18 19:00:00+01:00       0.009
9  2026-01-18 20:00:00+01:00       0.007
10 2026-01-18 21:00:00+01:00       0.007
11 2026-01-18 22:00:00+01:00       0.006
2026-01-18 11:26:17 info: ML prediction pv_tuinhuis
                   date_time  prediction
0  2026-01-18 11:00:00+01:00       0.048
1  2026-01-18 12:00:00+01:00       0.049
2  2026-01-18 13:00:00+01:00       0.055
3  2026-01-18 14:00:00+01:00       0.040
4  2026-01-18 15:00:00+01:00       0.029
5  2026-01-18 16:00:00+01:00       0.011
6  2026-01-18 17:00:00+01:00       0.000
7  2026-01-18 18:00:00+01:00       0.000
8  2026-01-18 19:00:00+01:00       0.000
9  2026-01-18 20:00:00+01:00       0.000
10 2026-01-18 21:00:00+01:00       0.000
11 2026-01-18 22:00:00+01:00       0.000
2026-01-18 11:26:17 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 571, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 311, in calc_optimum
    max(0, getattr(row, self.solar[s]["name"]))
           ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Pandas' object has no attribute 'pv woning'
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4706, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4677, in main
    da_calc.run_task_function("calc_optimum_met_debug")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 571, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 311, in calc_optimum
    max(0, getattr(row, self.solar[s]["name"]))
           ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'Pandas' object has no attribute 'pv woning'

Iemand een idee waar het probleem en de oplossing zit?
(als ik ml_prediction op false zet doet hij het gewoon)
Dit is mijn config:

code:

{
  "homeassistant": { },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09157
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09157
    },
    "cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2025-10-07": 0.00826
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2025-10-07": 0.00826
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
   "last invoice": "2025-10-07",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "Falsh",
  "baseload calc periode": 14,
  "baseload": [
    1.541,  
    1.537,  
    1.503,  
    1.644,  
    2.577,  
    1.391,  
    2.544,  
    1.580,  
    1.682,  
    1.694,  
    2.807,  
    3.813,  
    1.778,  
    1.059,  
    1.713,  
    1.651,  
    4.590,  
    1.893,  
    3.819,  
    1.061,  
    1.113,  
    4.892,  
    1.794,  
    1.696
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "True",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
    "notification entity": "input_text.dao_notificatie",
    "opstarten": "True",
    "berekening": "False",
    "last activity entity": "input_datetime.dao_laatste_activiteit"
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "",
    "entity setpoint": "",
    "entity hysterese": "",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": ""
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "",
    "adjustment factor": 0.04
  },
  "battery": [
  {
    "name": "Thuisbatterij",
    "entity actual level": "sensor.ss_battery_1_soc",
    "capacity": 51.2,                  
    "lower limit": 20,               
    "upper limit": 100,              
    "optimal lower level": 30,       
    "charge stages": [
      { "power": 0.0,   "efficiency": 1.0 },
      { "power": 16000,  "efficiency": 0.99 }   
    ],
    "discharge stages": [
      { "power": 0.0,   "efficiency": 1.0 },
      { "power": 16000,  "efficiency": 0.99 }   
    ],
    "minimum power": 500,             
    "dc_to_bat efficiency": 0.99,
    "bat_to_dc efficiency": 0.99,
    "cycle cost": 0.013,                
    "entity set power feedin": "input_number.batterij_power_feedin",
    "entity calculated soc": "input_number.batterij_calculated_soc",    
    "entity set operating mode": "input_select.batterij_operation_mode",
    "entity stop inverter": "input_datetime.batterij_stop_inverter",
    "entity balance switch": "input_boolean.batterij_balance_switch",
    "solar": []
  } ],

  "solar": [
  {
      "name": "pv woning",
      "ml_prediction": "false",
      "entities sensors": ["sensor.solaredge_zolder_25a_i1_ac_energy_kwh"],
      "tilt": 35,
      "orientation": 85,
      "capacity": 4.8,
      "yield": 0.00863, 
      "entity pv switch": "input_boolean.pv_woning_aan_uit"
  },
  {
     "name": "pv garage",
     "ml_prediction": "false",
     "entities sensors": ["sensor.solaredge_garage_i2_ac_energy_kwh"],
     "tilt": 25,
     "orientation": -5,
     "capacity": 12.95,
     "yield": 0.02884, 
     "entity pv switch": "input_boolean.pv_garage_aan_uit"
  },
  {
     "name": "pv tuinhuis",
     "ml_prediction": "false",
     "entities sensors": ["sensor.ecu_lifetime_energy"],
     "tilt": 5,
     "orientation": -85,
     "capacity": 0.42,
     "yield": 0.0008775,
     "entity pv switch": ""
  }
],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.energy_consumption_tarif_1",
      "sensor.energy_consumption_tarif_2"
    ],
    "entities grid production": [
      "sensor.energy_production_tarif_1",
      "sensor.energy_production_tarif_2"
    ],
    "entities solar production ac": [
      "sensor.solaredge_garage_i2_ac_energy_kwh",
      "sensor.solaredge_zolder_25a_i1_ac_energy_kwh",
      "sensor.ecu_lifetime_energy"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.peblar_ev_charger_lifetime_energy"],
    "entities wp consumption" : ["sensor.kwh_meter_warmtepomp_1_total_power_import"],
    "entities boiler consumption": ["sensor.kwh_meter_warmtepomp_2_total_power_import"],
    "entities battery consumption": ["sensor.ss_total_battery_charge"],
    "entities battery production": ["sensor.ss_total_battery_discharge"]
  },
  "scheduler": {
    "active": "True",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "2230": "calc_baseloads",
    "2240": "train_ml_predictions",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

[balk]

KC27 schreef op zondag 18 januari 2026 @ 11:23:
[...]

Heb jij een link naar de pagina waar deze restricties staan vermeld?

Ik zie hier geen restricties https://ned.nl/nl/algemene-voorwaarden

Artikel 3 en 4 lijken te zeggen dat het gratis is met je eigen api sleutel

[KC27]

bartzzz schreef op zondag 18 januari 2026 @ 11:35:
Vandaag de LM modellen eens geprobeerd.
Het trainen is goed gegaan, echter krijg ik een foutmelding als ik Optimaliseringsberekening met debug run.
Dit is de foutmelding:

[...]


Iemand een idee waar het probleem en de oplossing zit?
(als ik ml_prediction op false zet doet hij het gewoon)
Dit is mijn config:

[...]

Er blijkt dus toch nog een foutje je te zitten door het gebruik van een spatie in de naam.
Ga ik oplossen in de volgende versie.
Dit kun je nu voor de korte termijn oplossen door zelf de spatie(s) te vervangen door een "_" (underscore).

[Bongoarnhem]

simnet schreef op zondag 18 januari 2026 @ 10:42:
[...]


Een groot probleem is dat deze bron zijn informatie 'illegaal' verkrijgt. De ned.nl data is namelijk helemaal niet vrij om te gebruiken, helaas.

Ik heb de algemene voorwaarden doorgenomen en ik lees eigenlijk juist een bevestiging dat het hiermee juist gebruikt wordt zoals het bedoeld wordt.

Kan jij onderbouwen waarom de bron de data illegaal verkrijgt?
Die bewering lijkt mij met mijn beperkte juridische kennis namelijk onjuist.

[KC27]

Er zijn nieuwe versies gepubliceerd:

• productie versie: 2026.01.1
• test versie: 2026.01.1.rc1

Beide versies zijn identiek.
Dit staat in de changelog:
Fix error with space(s) in solar_name (reported by @bartzzz )

[simnet]

De laatste keer dat ik keek (afgelopen zomer, toen in met een ML model bezig was), was er nog geen usage policy. Als data beschikbaar wordt gesteld voor eigen gebruik is dat natuurlijk een ander verhaal.

Al moet je dan wel zorgen dat iedereen de data op zijn eigen manier verwerkt en dus niet zelf de data aan anderen (in een bewerkte vorm) beschikbaar stelt.

Misschien moet ik mn daysahead projectje weer eens afstoffen... 🙈

[KC27]

edterbak schreef op zondag 18 januari 2026 @ 10:29:
Hoi,
Ik wil graag mijn vaatwasser laten starten via DAO.
Dit is de code welke ik in het voorbeeld vond.

code:

{ "name": "vaatwasser",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "eco",
           "power": [2000, 2000, 1500, 1000, 500, 500, 1000, 1000]
           }
        ],
        "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"
      }

Mijn vaatwasser heeft een knopje er op waarmij ik aangeef: "Remote starten". Als deze aan is, dan pas kan ik hem starten. (Zonder doet ie gewoon niks natuurlijk.) Als de gebruiker deze knop heeft ingedrukt, dan pas hoeft DAO hem mee te nemen in zijn optimalisatie run. Op dit moment plant hij hem altijd in.
Dat is dus eigenlijk mijn "entity enabled". Ik kan de status uitlezen van dit ding via een binary sensor.

Bestaat voor machines iets als "entity enabled" ?

PS.
Ik heb overigens al getest of het remote starten goed werkt in HA via een script.
Als ik een script nu start, dan 1: Vaatwasser aan, 2: Start vaatwasser met geselecteerde programma.
Dat werkt gewoon. Dus eigenlijk zou ik ook een simpele trigger naar dit script ook voldoende zijn. Maar ik ook weet niet of dat kan.

Iemand tips / advies?

Zoals @Torch1969 ook al zei:
Je kunt in HA een automation (evt met node red) maken die getriggerd wordt door de sensor die je al hebt waarmee HA weet of je vaatwasser op "remote starten" staat.
Als deze op "remote starten" staat kun je in de input_select die DAO uitleest voor het programma de optie "eco" selecteren. Staat "remote starten" uit dan selecteer je met je automation het programma "off".

[KC27]

simnet schreef op zondag 18 januari 2026 @ 12:56:
De laatste keer dat ik keek (afgelopen zomer, toen in met een ML model bezig was), was er nog geen usage policy. Als data beschikbaar wordt gesteld voor eigen gebruik is dat natuurlijk een ander verhaal.

Al moet je dan wel zorgen dat iedereen de data op zijn eigen manier verwerkt en dus niet zelf de data aan anderen (in een bewerkte vorm) beschikbaar stelt.

Misschien moet ik mn daysahead projectje weer eens afstoffen... 🙈

Ja het project van @Bravo werkt met een zelf bedachte (wel slimme) formule met een paar parameters die op basis van de kleinste kwadraten methode worden geoptimaliseerd (gefit). Ik denk dat de xgboost-methode die we ook gebruiken voor de pv-voorspellingen generieker is en beter gaat werken, maar dan wel met de productie gegevens (historie en voorspelling) van ned.nl.

[Torch1969]

simnet schreef op zondag 18 januari 2026 @ 12:56:
De laatste keer dat ik keek (afgelopen zomer, toen in met een ML model bezig was), was er nog geen usage policy. Als data beschikbaar wordt gesteld voor eigen gebruik is dat natuurlijk een ander verhaal.

Al moet je dan wel zorgen dat iedereen de data op zijn eigen manier verwerkt en dus niet zelf de data aan anderen (in een bewerkte vorm) beschikbaar stelt.

Misschien moet ik mn daysahead projectje weer eens afstoffen... 🙈

Jaaaaa

Ned.nl roept op hun site zelfs op voor suggesties en input voor uitbreiding en gebruik van de data. Ik denk dat ze dit soort initiatieven juist willen stimuleren.

[rescla]

Net de nieuwe release met ML geïnstalleerd. Als ik met run, ML modellen trainen probeer te starten krijg ik na 120 seconden een timeout. Moet nog kijken of het via de scheduler wel werkt.

Scheduler truukje werkt iig.

[ Voor 9% gewijzigd door rescla op 18-01-2026 15:16 ]

[KC27]

rescla schreef op zondag 18 januari 2026 @ 15:04:
Net de nieuwe release met ML geïnstalleerd. Als ik met run, ML modellen trainen probeer te starten krijg ik na 120 seconden een timeout. Moet nog kijken of het via de scheduler wel werkt.

Scheduler truukje werkt iig.

Via het run-menu zit je altijd aan die 120 sec begrenzing. Daar loop je tegenaan bij veel solar-devices en/of tragere hardware.
Bovendien is het aan te bevelen om het model dagelijks via de scheduler te updaten. Dus in de scheduler zetten is sowieso prima (die heeft geen last van die 120 sec grens).

[edterbak]

KC27 schreef op zondag 18 januari 2026 @ 12:57:
[...]

Zoals @Torch1969 ook al zei:
Je kunt in HA een automation (evt met node red) maken die getriggerd wordt door de sensor die je al hebt waarmee HA weet of je vaatwasser op "remote starten" staat.
Als deze op "remote starten" staat kun je in de input_select die DAO uitleest voor het programma de optie "eco" selecteren. Staat "remote starten" uit dan selecteer je met je automation het programma "off".

Mag ik dan concluderen dat ik dit veldje
[code]"name": "off",[/code]
mag vervangen door dit
[code]"name": "input_select.HA_helper_met_templated_programma_naam",[/code]

Dan moet in HA de entiteit aanwezig zijn:
"input_select.HA_helper_met_templated_programma_naam"
value: 'off', 'eco', 'programma x', etc

Is dit wat je bedoeld?

Nog een keer gelezen.

Volgens mij bedoel je dit:
"entity selected program": "input_select.program_vaatwasser",
Programma naam welke opgehaald wordt defineren in de code
off = off
eco = ... programma eco
.. = ..

De waarde van input_select.program_vaatwasser in HA is een helper welke gevuld wordt op basis van de status van 'Remote start = true of false'..
Volgens mij is dit het.. right?

[ Voor 19% gewijzigd door edterbak op 18-01-2026 17:38 ]

[KC27]

edterbak schreef op zondag 18 januari 2026 @ 17:33:
[...]

Mag ik dan concluderen dat ik dit veldje
[code]"name": "off",[/code]
mag vervangen door dit
[code]"name": "input_select.HA_helper_met_templated_programma_naam",[/code]

Dan moet in HA de entiteit aanwezig zijn:
"input_select.HA_helper_met_templated_programma_naam"
value: 'off', 'eco', 'programma x', etc

Is dit wat je bedoeld?

Nog een keer gelezen.

Volgens mij bedoel je dit:
"entity selected program": "input_select.program_vaatwasser",
Programma naam welke opgehaald wordt defineren in de code
off = off
eco = ... programma eco
.. = ..

De waarde van input_select.program_vaatwasser in HA is een helper welke gevuld wordt op basis van de status van 'Remote start = true of false'..
Volgens mij is dit het.. right?

Helemaal goed!

[edterbak]

KC27 schreef op zondag 18 januari 2026 @ 19:30:
[...]

Helemaal goed!

Ik heb net even hier naar gekeken en er wat mee gedaan. Maar ik kom tot het besef dat ik niet begrijp hoe het daadwerkelijk werkt....

Dit heb ik nu.

code:

    "machines": [{
            "name": "Vaatwasser",
            "programs": [
                {
                    "name": "off",
                    "power": []
                }, {
                    "name": "dishcare_dishwasher_program_intensiv_70",
                    "power": [2000, 500, 500, 400, 200, 400, 600, 300]
                }, {
                    "name": "dishcare_dishwasher_program_auto_2",
                    "power": [2000, 500, 500, 400, 200, 400, 600]
                }, {
                    "name": "dishcare_dishwasher_program_eco_50",
                    "power": [2000, 500, 500, 400, 200, 400]
                }, {
                    "name": "dishcare_dishwasher_program_night_wash",
                    "power": [2000, 500, 500, 400, 200, 400]
                }, {
                    "name": "dishcare_dishwasher_program_kurz_60",
                    "power": [2000, 500, 500, 400, 200]
                }, {
                    "name": "dishcare_dishwasher_program_glas_40",
                    "power": [2000, 500, 500, 400, 200]
                }, {
                    "name": "dishcare_dishwasher_program_quick_45",
                    "power": [2000, 500, 400, 200]
                }, {
                    "name": "dishcare_dishwasher_program_pre_rinse",
                    "power": [2000, 500, 500, 400, 200, 400]
                }, {
                    "name": "dishcare_dishwasher_program_machine_care",
                    "power": [2000, 500, 500, 400, 200, 400]
                }

            ],
            "entity start window":      "input_datetime.dao_vaatwasser_start_window",
            "entity end window":        "input_datetime.dao_vaatwasser_end_window",
            "entity selected program":  "input_select.dao_vaatwasser_programma",
            "entity calculated start":  "input_datetime.dao_vaatwasser_calculated_start",
            "entity calculated end":    "input_datetime.dao_vaatwasser_calculated_end"
        }
    ],

Ik heb hiervoor in HA dus 5 helpers aangemaakt. Alle entities aan de onderkant van de code; start/end/select/calculated/calculated end.

Als ik even van afstand kijk naar wat ik nu aan het doen ben, dan lijkt het er niet daadwerkelijk een link is naar het apparaat zelf om hem te starten.
Er zijn bij mij nu alleen maar HA helpers.
Ik heb nu niks dat naar de entity van de vaatwasser linkt om hem daadwerkelijk te starten..

Wat mis ik? Ik heb vast iets niet goed begrepen met "input_select.dao_vaatwasser_programma",
Ik heb hem zo gelezen dat dit een input is voor DAO om het exacte programme te herkennen en te kunnen doorrekenen.

What am i missing

[ Voor 10% gewijzigd door edterbak op 18-01-2026 21:35 ]

[KC27]

edterbak schreef op zondag 18 januari 2026 @ 21:32:
[...]

Ik heb net even hier naar gekeken en er wat mee gedaan. Maar ik kom tot het besef dat ik niet begrijp hoe het daadwerkelijk werkt....

Dit heb ik nu.

[...]

Ik heb hiervoor in HA dus 5 helpers aangemaakt. Alle entities aan de onderkant van de code; start/end/select/calculated/calculated end.

Als ik even van afstand kijk naar wat ik nu aan het doen ben, dan lijkt het er niet daadwerkelijk een link is naar het apparaat zelf om hem te starten.
Er zijn bij mij nu alleen maar HA helpers.
Ik heb nu niks dat naar de entity van de vaatwasser linkt om hem daadwerkelijk te starten..

Wat mis ik? Ik heb vast iets niet goed begrepen met "input_select.dao_vaatwasser_programma",
Ik heb hem zo gelezen dat dit een input is voor DAO om het exacte programme te herkennen en te kunnen doorrekenen.

What am i missing

[Afbeelding]

[Afbeelding]

De volgende stap is dat je met een automation je de vaatwasser gaat starten. Die automation laat je triggeren als de klok gelijk is aan de datum/tijd in de input_datetime.dao_vaatwasser_calculated_start.En die automation zet dan de sensor/entity aan waarmee je vaatwasser daadwerkelijk begint.
Denk je dat kan gaan werken?

[edterbak]

Oke, zo. Ja dat gaat wel werken ja.
Als alternatieve optie dat je zou kunnen verzinnen bij alle machines, een generieke alternatief, is dat je het mogelijk maakt dat dao een knop kan indrukken. a-la boiler

code:

"activate service": "press",
"activate entity": "input_button.xxxxxxxx",

Dit is voor mij gevoelsmatig iets 'directer'.

Maar, jouw suggestie zal werken. So it shall be. thanks

[Psycho_Mantis]

*nevermind

[ Voor 96% gewijzigd door Psycho_Mantis op 19-01-2026 07:31 ]

[KC27]

edterbak schreef op zondag 18 januari 2026 @ 22:49:
Oke, zo. Ja dat gaat wel werken ja.
Als alternatieve optie dat je zou kunnen verzinnen bij alle machines, een generieke alternatief, is dat je het mogelijk maakt dat dao een knop kan indrukken. a-la boiler

code:

"activate service": "press",
"activate entity": "input_button.xxxxxxxx",

Dit is voor mij gevoelsmatig iets 'directer'.

Maar, jouw suggestie zal werken. So it shall be. thanks

Er zijn DAO gebruikers met een interval="1hour", dan komt DAO niet ieder kwartier langs om op de knop te drukken.
Er zijn ook DAO gebruikers die de berekende eindtijd communiceren naar hun machine.
Tenslotte zijn er DAO gebruikers die op hun machine een wachttijd instellen a..d.h.v. de aangegeven starttijd.
Dus deze opzet is generiek en voor iedereen (met of zonder een automation) bruikbaar.
Vandaar dat hier voor gekozen is.

[edterbak]

KC27 schreef op maandag 19 januari 2026 @ 11:07:
[...]

Er zijn DAO gebruikers met een interval="1hour", dan komt DAO niet ieder kwartier langs om op de knop te drukken.
Er zijn ook DAO gebruikers die de berekende eindtijd communiceren naar hun machine.
Tenslotte zijn er DAO gebruikers die op hun machine een wachttijd instellen a..d.h.v. de aangegeven starttijd.
Dus deze opzet is generiek en voor iedereen (met of zonder een automation) bruikbaar.
Vandaar dat hier voor gekozen is.

Ja, ik snap het.
DAO is/ heeft geen service draaien als knoppen drukker op any random calculated time.
Jouw manier werkt gewoon. En ook gewoon prima generieke methode. (Duurde alleen even voor ik hem door had)
Vanaf nu copy/paste.

Vannacht de eerste DAO vaat schoon gemaakt op goedkoop tarief. Yeaahh.
Thank you !

[Deikke]

Ik krijg de volgende error met de 2026.01.1 versie van DAO, enig idee wat hier mis gaat?

code:

2026-01-19 11:15:13 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
    self.dialect.do_execute(
    ~~~~~~~~~~~~~~~~~~~~~~~^
        cursor, str_statement, effective_parameters, context
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/sqlalchemy/engine/default.py", line 952, in do_execute
    cursor.execute(statement, parameters)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.GroupingError: column "values.time" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: ...MM-DD HH24:00') AS uur, min(values.time) AS time, values.tim...

]

[twimj]

Na de update van 2025.12 naar 2026.1.1 het volgende in de log. Iemand een suggestie hoe dit op te lossen, heb helaas geen backup

code:

Setting up watches.
Watches established.
Failed to read config file: gunicorn_config.py
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/gunicorn/app/base.py", line 110, in get_config_from_filename
    spec.loader.exec_module(mod)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^
  File "<frozen importlib._bootstrap_external>", line 1026, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "/root/dao/webserver/gunicorn_config.py", line 4, in <module>
    from dao.prog.da_config import get_config
  File "/root/dao/prog/da_config.py", line 6, in <module>
    from dao.prog.db_manager import DBmanagerObj
  File "/root/dao/prog/db_manager.py", line 1, in <module>
    import pandas as pd
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/__init__.py", line 14, in <module>
    __import__(_dependency)
    ~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/numpy/__init__.py", line 112, in <module>
    from numpy.__config__ import show_config
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/numpy/__config__.py", line 4, in <module>
    from numpy._core._multiarray_umath import (
    ...<3 lines>...
    )
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/numpy/_core/__init__.py", line 22, in <module>
    from . import multiarray
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/numpy/_core/multiarray.py", line 11, in <module>
    from . import _multiarray_umath, overrides
RuntimeError: NumPy was built with baseline optimizations: 
(X86_V2) but your machine doesn't support:
(X86_V2).
Traceback (most recent call last):
  File "/root/dao/prog/da_scheduler.py", line 4, in <module>
    from da_base import DaBase
  File "/root/dao/prog/da_base.py", line 11, in <module>
    import pandas as pd
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/__init__.py", line 14, in <module>
    __import__(_dependency)
    ~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/numpy/__init__.py", line 112, in <module>
    from numpy.__config__ import show_config
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/numpy/__config__.py", line 4, in <module>
    from numpy._core._multiarray_umath import (
    ...<3 lines>...
    )
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/numpy/_core/__init__.py", line 22, in <module>
    from . import multiarray
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/numpy/_core/multiarray.py", line 11, in <module>
    from . import _multiarray_umath, overrides
RuntimeError: NumPy was built with baseline optimizations: 
(X86_V2) but your machine doesn't support:
(X86_V2).

[diamanten]

Na update naar 2026.1.1 probeer ik de ML-functionaliteit. Ik krijg ondermeer deze melding:

code:

2026-01-19 12:25:30,298 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:25:30,302 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:25:30,302 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:25:30,350 info root MainThread : ML prediction Enphase

Ik zie in de grafieken voor bepaalde dagen zoals 16 januari wel een R2-score, maar voor 18 januari bijv. niet overal (of een negatieve). Ook ontbreekt de gemeten straling. Gaat het ophalen van de KNMI-data wel goed? En zo nee: hoe kan ik een ander weerstation selecteren?
Hierbij de complete log:

code:

2026-01-19 07:22:57,786 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-19 00:00:00+01:00    0.000913
1  2026-01-19 01:00:00+01:00    0.000000
2  2026-01-19 02:00:00+01:00    0.000000
3  2026-01-19 03:00:00+01:00    0.000000
4  2026-01-19 04:00:00+01:00    0.000000
5  2026-01-19 05:00:00+01:00    0.000000
6  2026-01-19 06:00:00+01:00    0.000000
7  2026-01-19 07:00:00+01:00    0.000000
8  2026-01-19 08:00:00+01:00    0.003434
9  2026-01-19 09:00:00+01:00    0.370970
10 2026-01-19 10:00:00+01:00    1.212716
11 2026-01-19 11:00:00+01:00    2.240993
12 2026-01-19 12:00:00+01:00    2.744836
13 2026-01-19 13:00:00+01:00    2.862098
14 2026-01-19 14:00:00+01:00    1.113051
15 2026-01-19 15:00:00+01:00    0.485188
16 2026-01-19 16:00:00+01:00    0.170882
17 2026-01-19 17:00:00+01:00    0.003208
18 2026-01-19 18:00:00+01:00    0.003208
19 2026-01-19 19:00:00+01:00    0.002950
20 2026-01-19 20:00:00+01:00    0.002950
21 2026-01-19 21:00:00+01:00    0.002909
22 2026-01-19 22:00:00+01:00    0.002909
23 2026-01-19 23:00:00+01:00    0.002909
2026-01-19 12:25:21,419 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-18 00:00:00+01:00    0.000913
1  2026-01-18 01:00:00+01:00    0.000000
2  2026-01-18 02:00:00+01:00    0.000000
3  2026-01-18 03:00:00+01:00    0.000000
4  2026-01-18 04:00:00+01:00    0.000000
5  2026-01-18 05:00:00+01:00    0.000000
6  2026-01-18 06:00:00+01:00    0.000000
7  2026-01-18 07:00:00+01:00    0.000000
8  2026-01-18 08:00:00+01:00    0.004572
9  2026-01-18 09:00:00+01:00    0.361333
10 2026-01-18 10:00:00+01:00    1.247611
11 2026-01-18 11:00:00+01:00    1.538531
12 2026-01-18 12:00:00+01:00    2.512206
13 2026-01-18 13:00:00+01:00    2.692920
14 2026-01-18 14:00:00+01:00    2.499425
15 2026-01-18 15:00:00+01:00    1.039209
16 2026-01-18 16:00:00+01:00    0.309370
17 2026-01-18 17:00:00+01:00    0.001212
18 2026-01-18 18:00:00+01:00    0.001212
19 2026-01-18 19:00:00+01:00    0.000954
20 2026-01-18 20:00:00+01:00    0.000954
21 2026-01-18 21:00:00+01:00    0.000913
22 2026-01-18 22:00:00+01:00    0.000913
23 2026-01-18 23:00:00+01:00    0.000913
2026-01-19 12:25:25,457 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-17 00:00:00+01:00    0.000855
1  2026-01-17 01:00:00+01:00    0.000000
2  2026-01-17 02:00:00+01:00    0.000000
3  2026-01-17 03:00:00+01:00    0.000000
4  2026-01-17 04:00:00+01:00    0.000000
5  2026-01-17 05:00:00+01:00    0.000000
6  2026-01-17 06:00:00+01:00    0.000000
7  2026-01-17 07:00:00+01:00    0.000000
8  2026-01-17 08:00:00+01:00    0.000000
9  2026-01-17 09:00:00+01:00    0.271581
10 2026-01-17 10:00:00+01:00    0.946445
11 2026-01-17 11:00:00+01:00    1.699747
12 2026-01-17 12:00:00+01:00    2.594838
13 2026-01-17 13:00:00+01:00    2.724475
14 2026-01-17 14:00:00+01:00    2.086650
15 2026-01-17 15:00:00+01:00    1.027768
16 2026-01-17 16:00:00+01:00    0.248253
17 2026-01-17 17:00:00+01:00    0.001240
18 2026-01-17 18:00:00+01:00    0.001060
19 2026-01-17 19:00:00+01:00    0.000954
20 2026-01-17 20:00:00+01:00    0.000954
21 2026-01-17 21:00:00+01:00    0.000913
22 2026-01-17 22:00:00+01:00    0.000913
23 2026-01-17 23:00:00+01:00    0.000913
2026-01-19 12:25:28,467 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:25:28,474 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:25:28,474 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:25:28,527 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-16 00:00:00+01:00    0.000855
1  2026-01-16 01:00:00+01:00    0.000000
2  2026-01-16 02:00:00+01:00    0.000000
3  2026-01-16 03:00:00+01:00    0.000000
4  2026-01-16 04:00:00+01:00    0.000000
5  2026-01-16 05:00:00+01:00    0.000000
6  2026-01-16 06:00:00+01:00    0.000000
7  2026-01-16 07:00:00+01:00    0.000000
8  2026-01-16 08:00:00+01:00    0.000000
9  2026-01-16 09:00:00+01:00    0.353734
10 2026-01-16 10:00:00+01:00    0.353867
11 2026-01-16 11:00:00+01:00    1.023945
12 2026-01-16 12:00:00+01:00    1.785090
13 2026-01-16 13:00:00+01:00    2.028132
14 2026-01-16 14:00:00+01:00    1.393485
15 2026-01-16 15:00:00+01:00    0.558754
16 2026-01-16 16:00:00+01:00    0.197392
17 2026-01-16 17:00:00+01:00    0.001155
18 2026-01-16 18:00:00+01:00    0.001155
19 2026-01-16 19:00:00+01:00    0.000897
20 2026-01-16 20:00:00+01:00    0.000897
21 2026-01-16 21:00:00+01:00    0.000855
22 2026-01-16 22:00:00+01:00    0.000676
23 2026-01-16 23:00:00+01:00    0.000828
2026-01-19 12:25:30,298 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:25:30,302 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:25:30,302 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:25:30,350 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-15 00:00:00+01:00    0.000344
1  2026-01-15 01:00:00+01:00    0.000000
2  2026-01-15 02:00:00+01:00    0.000000
3  2026-01-15 03:00:00+01:00    0.000000
4  2026-01-15 04:00:00+01:00    0.000000
5  2026-01-15 05:00:00+01:00    0.000000
6  2026-01-15 06:00:00+01:00    0.000000
7  2026-01-15 07:00:00+01:00    0.000000
8  2026-01-15 08:00:00+01:00    0.000000
9  2026-01-15 09:00:00+01:00    0.087621
10 2026-01-15 10:00:00+01:00    0.261827
11 2026-01-15 11:00:00+01:00    0.413178
12 2026-01-15 12:00:00+01:00    0.431147
13 2026-01-15 13:00:00+01:00    0.304497
14 2026-01-15 14:00:00+01:00    0.326605
15 2026-01-15 15:00:00+01:00    0.342997
16 2026-01-15 16:00:00+01:00    0.113706
17 2026-01-15 17:00:00+01:00    0.001155
18 2026-01-15 18:00:00+01:00    0.001155
19 2026-01-15 19:00:00+01:00    0.000897
20 2026-01-15 20:00:00+01:00    0.000897
21 2026-01-15 21:00:00+01:00    0.000855
22 2026-01-15 22:00:00+01:00    0.000855
23 2026-01-15 23:00:00+01:00    0.000855
2026-01-19 12:25:36,502 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-17 00:00:00+01:00    0.000855
1  2026-01-17 01:00:00+01:00    0.000000
2  2026-01-17 02:00:00+01:00    0.000000
3  2026-01-17 03:00:00+01:00    0.000000
4  2026-01-17 04:00:00+01:00    0.000000
5  2026-01-17 05:00:00+01:00    0.000000
6  2026-01-17 06:00:00+01:00    0.000000
7  2026-01-17 07:00:00+01:00    0.000000
8  2026-01-17 08:00:00+01:00    0.000000
9  2026-01-17 09:00:00+01:00    0.271581
10 2026-01-17 10:00:00+01:00    0.946445
11 2026-01-17 11:00:00+01:00    1.699747
12 2026-01-17 12:00:00+01:00    2.594838
13 2026-01-17 13:00:00+01:00    2.724475
14 2026-01-17 14:00:00+01:00    2.086650
15 2026-01-17 15:00:00+01:00    1.027768
16 2026-01-17 16:00:00+01:00    0.248253
17 2026-01-17 17:00:00+01:00    0.001240
18 2026-01-17 18:00:00+01:00    0.001060
19 2026-01-17 19:00:00+01:00    0.000954
20 2026-01-17 20:00:00+01:00    0.000954
21 2026-01-17 21:00:00+01:00    0.000913
22 2026-01-17 22:00:00+01:00    0.000913
23 2026-01-17 23:00:00+01:00    0.000913
2026-01-19 12:25:39,203 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-18 00:00:00+01:00    0.000913
1  2026-01-18 01:00:00+01:00    0.000000
2  2026-01-18 02:00:00+01:00    0.000000
3  2026-01-18 03:00:00+01:00    0.000000
4  2026-01-18 04:00:00+01:00    0.000000
5  2026-01-18 05:00:00+01:00    0.000000
6  2026-01-18 06:00:00+01:00    0.000000
7  2026-01-18 07:00:00+01:00    0.000000
8  2026-01-18 08:00:00+01:00    0.004572
9  2026-01-18 09:00:00+01:00    0.361333
10 2026-01-18 10:00:00+01:00    1.247611
11 2026-01-18 11:00:00+01:00    1.538531
12 2026-01-18 12:00:00+01:00    2.512206
13 2026-01-18 13:00:00+01:00    2.692920
14 2026-01-18 14:00:00+01:00    2.499425
15 2026-01-18 15:00:00+01:00    1.039209
16 2026-01-18 16:00:00+01:00    0.309370
17 2026-01-18 17:00:00+01:00    0.001212
18 2026-01-18 18:00:00+01:00    0.001212
19 2026-01-18 19:00:00+01:00    0.000954
20 2026-01-18 20:00:00+01:00    0.000954
21 2026-01-18 21:00:00+01:00    0.000913
22 2026-01-18 22:00:00+01:00    0.000913
23 2026-01-18 23:00:00+01:00    0.000913
2026-01-19 12:25:42,320 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-19 00:00:00+01:00    0.000913
1  2026-01-19 01:00:00+01:00    0.000000
2  2026-01-19 02:00:00+01:00    0.000000
3  2026-01-19 03:00:00+01:00    0.000000
4  2026-01-19 04:00:00+01:00    0.000000
5  2026-01-19 05:00:00+01:00    0.000000
6  2026-01-19 06:00:00+01:00    0.000000
7  2026-01-19 07:00:00+01:00    0.000000
8  2026-01-19 08:00:00+01:00    0.003434
9  2026-01-19 09:00:00+01:00    0.370970
10 2026-01-19 10:00:00+01:00    1.212716
11 2026-01-19 11:00:00+01:00    1.611384
12 2026-01-19 12:00:00+01:00    2.790643
13 2026-01-19 13:00:00+01:00    2.464523
14 2026-01-19 14:00:00+01:00    1.680001
15 2026-01-19 15:00:00+01:00    0.917337
16 2026-01-19 16:00:00+01:00    0.229300
17 2026-01-19 17:00:00+01:00    0.003208
18 2026-01-19 18:00:00+01:00    0.003208
19 2026-01-19 19:00:00+01:00    0.002950
20 2026-01-19 20:00:00+01:00    0.002950
21 2026-01-19 21:00:00+01:00    0.002909
22 2026-01-19 22:00:00+01:00    0.002909
23 2026-01-19 23:00:00+01:00    0.002909
2026-01-19 12:26:02,468 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-17 00:00:00+01:00    0.000855
1  2026-01-17 01:00:00+01:00    0.000000
2  2026-01-17 02:00:00+01:00    0.000000
3  2026-01-17 03:00:00+01:00    0.000000
4  2026-01-17 04:00:00+01:00    0.000000
5  2026-01-17 05:00:00+01:00    0.000000
6  2026-01-17 06:00:00+01:00    0.000000
7  2026-01-17 07:00:00+01:00    0.000000
8  2026-01-17 08:00:00+01:00    0.000000
9  2026-01-17 09:00:00+01:00    0.271581
10 2026-01-17 10:00:00+01:00    0.946445
11 2026-01-17 11:00:00+01:00    1.699747
12 2026-01-17 12:00:00+01:00    2.594838
13 2026-01-17 13:00:00+01:00    2.724475
14 2026-01-17 14:00:00+01:00    2.086650
15 2026-01-17 15:00:00+01:00    1.027768
16 2026-01-17 16:00:00+01:00    0.248253
17 2026-01-17 17:00:00+01:00    0.001240
18 2026-01-17 18:00:00+01:00    0.001060
19 2026-01-17 19:00:00+01:00    0.000954
20 2026-01-17 20:00:00+01:00    0.000954
21 2026-01-17 21:00:00+01:00    0.000913
22 2026-01-17 22:00:00+01:00    0.000913
23 2026-01-17 23:00:00+01:00    0.000913
2026-01-19 12:26:03,620 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:26:03,623 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:26:03,623 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:26:03,657 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-16 00:00:00+01:00    0.000855
1  2026-01-16 01:00:00+01:00    0.000000
2  2026-01-16 02:00:00+01:00    0.000000
3  2026-01-16 03:00:00+01:00    0.000000
4  2026-01-16 04:00:00+01:00    0.000000
5  2026-01-16 05:00:00+01:00    0.000000
6  2026-01-16 06:00:00+01:00    0.000000
7  2026-01-16 07:00:00+01:00    0.000000
8  2026-01-16 08:00:00+01:00    0.000000
9  2026-01-16 09:00:00+01:00    0.353734
10 2026-01-16 10:00:00+01:00    0.353867
11 2026-01-16 11:00:00+01:00    1.023945
12 2026-01-16 12:00:00+01:00    1.785090
13 2026-01-16 13:00:00+01:00    2.028132
14 2026-01-16 14:00:00+01:00    1.393485
15 2026-01-16 15:00:00+01:00    0.558754
16 2026-01-16 16:00:00+01:00    0.197392
17 2026-01-16 17:00:00+01:00    0.001155
18 2026-01-16 18:00:00+01:00    0.001155
19 2026-01-16 19:00:00+01:00    0.000897
20 2026-01-16 20:00:00+01:00    0.000897
21 2026-01-16 21:00:00+01:00    0.000855
22 2026-01-16 22:00:00+01:00    0.000676
23 2026-01-16 23:00:00+01:00    0.000828
2026-01-19 12:43:05,620 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-17 00:00:00+01:00    0.000855
1  2026-01-17 01:00:00+01:00    0.000000
2  2026-01-17 02:00:00+01:00    0.000000
3  2026-01-17 03:00:00+01:00    0.000000
4  2026-01-17 04:00:00+01:00    0.000000
5  2026-01-17 05:00:00+01:00    0.000000
6  2026-01-17 06:00:00+01:00    0.000000
7  2026-01-17 07:00:00+01:00    0.000000
8  2026-01-17 08:00:00+01:00    0.000000
9  2026-01-17 09:00:00+01:00    0.271581
10 2026-01-17 10:00:00+01:00    0.946445
11 2026-01-17 11:00:00+01:00    1.699747
12 2026-01-17 12:00:00+01:00    2.594838
13 2026-01-17 13:00:00+01:00    2.724475
14 2026-01-17 14:00:00+01:00    2.086650
15 2026-01-17 15:00:00+01:00    1.027768
16 2026-01-17 16:00:00+01:00    0.248253
17 2026-01-17 17:00:00+01:00    0.001240
18 2026-01-17 18:00:00+01:00    0.001060
19 2026-01-17 19:00:00+01:00    0.000954
20 2026-01-17 20:00:00+01:00    0.000954
21 2026-01-17 21:00:00+01:00    0.000913
22 2026-01-17 22:00:00+01:00    0.000913
23 2026-01-17 23:00:00+01:00    0.000913
2026-01-19 12:43:20,412 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-17 00:00:00+01:00    0.000855
1  2026-01-17 01:00:00+01:00    0.000000
2  2026-01-17 02:00:00+01:00    0.000000
3  2026-01-17 03:00:00+01:00    0.000000
4  2026-01-17 04:00:00+01:00    0.000000
5  2026-01-17 05:00:00+01:00    0.000000
6  2026-01-17 06:00:00+01:00    0.000000
7  2026-01-17 07:00:00+01:00    0.000000
8  2026-01-17 08:00:00+01:00    0.000000
9  2026-01-17 09:00:00+01:00    0.271581
10 2026-01-17 10:00:00+01:00    0.946445
11 2026-01-17 11:00:00+01:00    1.699747
12 2026-01-17 12:00:00+01:00    2.594838
13 2026-01-17 13:00:00+01:00    2.724475
14 2026-01-17 14:00:00+01:00    2.086650
15 2026-01-17 15:00:00+01:00    1.027768
16 2026-01-17 16:00:00+01:00    0.248253
17 2026-01-17 17:00:00+01:00    0.001240
18 2026-01-17 18:00:00+01:00    0.001060
19 2026-01-17 19:00:00+01:00    0.000954
20 2026-01-17 20:00:00+01:00    0.000954
21 2026-01-17 21:00:00+01:00    0.000913
22 2026-01-17 22:00:00+01:00    0.000913
23 2026-01-17 23:00:00+01:00    0.000913
2026-01-19 12:43:26,582 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-17 00:00:00+01:00    0.000855
1  2026-01-17 01:00:00+01:00    0.000000
2  2026-01-17 02:00:00+01:00    0.000000
3  2026-01-17 03:00:00+01:00    0.000000
4  2026-01-17 04:00:00+01:00    0.000000
5  2026-01-17 05:00:00+01:00    0.000000
6  2026-01-17 06:00:00+01:00    0.000000
7  2026-01-17 07:00:00+01:00    0.000000
8  2026-01-17 08:00:00+01:00    0.000000
9  2026-01-17 09:00:00+01:00    0.271581
10 2026-01-17 10:00:00+01:00    0.946445
11 2026-01-17 11:00:00+01:00    1.699747
12 2026-01-17 12:00:00+01:00    2.594838
13 2026-01-17 13:00:00+01:00    2.724475
14 2026-01-17 14:00:00+01:00    2.086650
15 2026-01-17 15:00:00+01:00    1.027768
16 2026-01-17 16:00:00+01:00    0.248253
17 2026-01-17 17:00:00+01:00    0.001240
18 2026-01-17 18:00:00+01:00    0.001060
19 2026-01-17 19:00:00+01:00    0.000954
20 2026-01-17 20:00:00+01:00    0.000954
21 2026-01-17 21:00:00+01:00    0.000913
22 2026-01-17 22:00:00+01:00    0.000913
23 2026-01-17 23:00:00+01:00    0.000913
2026-01-19 12:43:47,525 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:43:47,529 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:43:47,529 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:43:47,578 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-12 00:00:00+01:00    0.000913
1  2026-01-12 01:00:00+01:00    0.000000
2  2026-01-12 02:00:00+01:00    0.000000
3  2026-01-12 03:00:00+01:00    0.000000
4  2026-01-12 04:00:00+01:00    0.000000
5  2026-01-12 05:00:00+01:00    0.000000
6  2026-01-12 06:00:00+01:00    0.000000
7  2026-01-12 07:00:00+01:00    0.000000
8  2026-01-12 08:00:00+01:00    0.000000
9  2026-01-12 09:00:00+01:00    0.062281
10 2026-01-12 10:00:00+01:00    0.253342
11 2026-01-12 11:00:00+01:00    0.406478
12 2026-01-12 12:00:00+01:00    0.444597
13 2026-01-12 13:00:00+01:00    0.505129
14 2026-01-12 14:00:00+01:00    0.430274
15 2026-01-12 15:00:00+01:00    0.211949
16 2026-01-12 16:00:00+01:00    0.042174
17 2026-01-12 17:00:00+01:00    0.003056
18 2026-01-12 18:00:00+01:00    0.003056
19 2026-01-12 19:00:00+01:00    0.002799
20 2026-01-12 20:00:00+01:00    0.002799
21 2026-01-12 21:00:00+01:00    0.002757
22 2026-01-12 22:00:00+01:00    0.002757
23 2026-01-12 23:00:00+01:00    0.002757
2026-01-19 12:43:49,864 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:43:49,868 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:43:49,868 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:43:49,905 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-13 00:00:00+01:00    0.002757
1  2026-01-13 01:00:00+01:00    0.000000
2  2026-01-13 02:00:00+01:00    0.000000
3  2026-01-13 03:00:00+01:00    0.000000
4  2026-01-13 04:00:00+01:00    0.000000
5  2026-01-13 05:00:00+01:00    0.000000
6  2026-01-13 06:00:00+01:00    0.000000
7  2026-01-13 07:00:00+01:00    0.000000
8  2026-01-13 08:00:00+01:00    0.000278
9  2026-01-13 09:00:00+01:00    0.119911
10 2026-01-13 10:00:00+01:00    0.382304
11 2026-01-13 11:00:00+01:00    0.353777
12 2026-01-13 12:00:00+01:00    0.345313
13 2026-01-13 13:00:00+01:00    0.355625
14 2026-01-13 14:00:00+01:00    0.275083
15 2026-01-13 15:00:00+01:00    0.259460
16 2026-01-13 16:00:00+01:00    0.074665
17 2026-01-13 17:00:00+01:00    0.001213
18 2026-01-13 18:00:00+01:00    0.001213
19 2026-01-13 19:00:00+01:00    0.000955
20 2026-01-13 20:00:00+01:00    0.000955
21 2026-01-13 21:00:00+01:00    0.000913
22 2026-01-13 22:00:00+01:00    0.000913
23 2026-01-13 23:00:00+01:00    0.000913
2026-01-19 12:43:52,342 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:43:52,346 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:43:52,346 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:43:52,380 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-14 00:00:00+01:00    0.000913
1  2026-01-14 01:00:00+01:00    0.000000
2  2026-01-14 02:00:00+01:00    0.000000
3  2026-01-14 03:00:00+01:00    0.000000
4  2026-01-14 04:00:00+01:00    0.000000
5  2026-01-14 05:00:00+01:00    0.000000
6  2026-01-14 06:00:00+01:00    0.000000
7  2026-01-14 07:00:00+01:00    0.000000
8  2026-01-14 08:00:00+01:00    0.000000
9  2026-01-14 09:00:00+01:00    0.196025
10 2026-01-14 10:00:00+01:00    1.235600
11 2026-01-14 11:00:00+01:00    1.715924
12 2026-01-14 12:00:00+01:00    2.250436
13 2026-01-14 13:00:00+01:00    2.827599
14 2026-01-14 14:00:00+01:00    2.602671
15 2026-01-14 15:00:00+01:00    0.599043
16 2026-01-14 16:00:00+01:00    0.151203
17 2026-01-14 17:00:00+01:00    0.000796
18 2026-01-14 18:00:00+01:00    0.000796
19 2026-01-14 19:00:00+01:00    0.000538
20 2026-01-14 20:00:00+01:00    0.000538
21 2026-01-14 21:00:00+01:00    0.000496
22 2026-01-14 22:00:00+01:00    0.000496
23 2026-01-14 23:00:00+01:00    0.000344
2026-01-19 12:44:00,564 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:44:00,567 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:44:00,567 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:44:00,601 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-15 00:00:00+01:00    0.000344
1  2026-01-15 01:00:00+01:00    0.000000
2  2026-01-15 02:00:00+01:00    0.000000
3  2026-01-15 03:00:00+01:00    0.000000
4  2026-01-15 04:00:00+01:00    0.000000
5  2026-01-15 05:00:00+01:00    0.000000
6  2026-01-15 06:00:00+01:00    0.000000
7  2026-01-15 07:00:00+01:00    0.000000
8  2026-01-15 08:00:00+01:00    0.000000
9  2026-01-15 09:00:00+01:00    0.087621
10 2026-01-15 10:00:00+01:00    0.261827
11 2026-01-15 11:00:00+01:00    0.413178
12 2026-01-15 12:00:00+01:00    0.431147
13 2026-01-15 13:00:00+01:00    0.304497
14 2026-01-15 14:00:00+01:00    0.326605
15 2026-01-15 15:00:00+01:00    0.342997
16 2026-01-15 16:00:00+01:00    0.113706
17 2026-01-15 17:00:00+01:00    0.001155
18 2026-01-15 18:00:00+01:00    0.001155
19 2026-01-15 19:00:00+01:00    0.000897
20 2026-01-15 20:00:00+01:00    0.000897
21 2026-01-15 21:00:00+01:00    0.000855
22 2026-01-15 22:00:00+01:00    0.000855
23 2026-01-15 23:00:00+01:00    0.000855
2026-01-19 12:44:11,000 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-19 00:00:00+01:00    0.000913
1  2026-01-19 01:00:00+01:00    0.000000
2  2026-01-19 02:00:00+01:00    0.000000
3  2026-01-19 03:00:00+01:00    0.000000
4  2026-01-19 04:00:00+01:00    0.000000
5  2026-01-19 05:00:00+01:00    0.000000
6  2026-01-19 06:00:00+01:00    0.000000
7  2026-01-19 07:00:00+01:00    0.000000
8  2026-01-19 08:00:00+01:00    0.003434
9  2026-01-19 09:00:00+01:00    0.370970
10 2026-01-19 10:00:00+01:00    1.212716
11 2026-01-19 11:00:00+01:00    1.611384
12 2026-01-19 12:00:00+01:00    2.790643
13 2026-01-19 13:00:00+01:00    2.464523
14 2026-01-19 14:00:00+01:00    1.680001
15 2026-01-19 15:00:00+01:00    0.917337
16 2026-01-19 16:00:00+01:00    0.229300
17 2026-01-19 17:00:00+01:00    0.003208
18 2026-01-19 18:00:00+01:00    0.003208
19 2026-01-19 19:00:00+01:00    0.002950
20 2026-01-19 20:00:00+01:00    0.002950
21 2026-01-19 21:00:00+01:00    0.002909
22 2026-01-19 22:00:00+01:00    0.002909
23 2026-01-19 23:00:00+01:00    0.002909
2026-01-19 12:57:11,803 info root MainThread : ML prediction Enphase
                   date_time  prediction
0  2026-01-19 00:00:00+01:00    0.000913
1  2026-01-19 01:00:00+01:00    0.000000
2  2026-01-19 02:00:00+01:00    0.000000
3  2026-01-19 03:00:00+01:00    0.000000
4  2026-01-19 04:00:00+01:00    0.000000
5  2026-01-19 05:00:00+01:00    0.000000
6  2026-01-19 06:00:00+01:00    0.000000
7  2026-01-19 07:00:00+01:00    0.000000
8  2026-01-19 08:00:00+01:00    0.003434
9  2026-01-19 09:00:00+01:00    0.370970
10 2026-01-19 10:00:00+01:00    1.212716
11 2026-01-19 11:00:00+01:00    1.611384
12 2026-01-19 12:00:00+01:00    2.790643
13 2026-01-19 13:00:00+01:00    2.464523
14 2026-01-19 14:00:00+01:00    1.680001
15 2026-01-19 15:00:00+01:00    0.917337
16 2026-01-19 16:00:00+01:00    0.229300
17 2026-01-19 17:00:00+01:00    0.003208
18 2026-01-19 18:00:00+01:00    0.003208
19 2026-01-19 19:00:00+01:00    0.002950
20 2026-01-19 20:00:00+01:00    0.002950
21 2026-01-19 21:00:00+01:00    0.002909
22 2026-01-19 22:00:00+01:00    0.002909
23 2026-01-19 23:00:00+01:00    0.002909

[Bravo]

KC27 schreef op zondag 18 januari 2026 @ 13:05:
[...]

Ja het project van @Bravo werkt met een zelf bedachte (wel slimme) formule met een paar parameters die op basis van de kleinste kwadraten methode worden geoptimaliseerd (gefit). Ik denk dat de xgboost-methode die we ook gebruiken voor de pv-voorspellingen generieker is en beter gaat werken, maar dan wel met de productie gegevens (historie en voorspelling) van ned.nl.

Als mijn project de inspiratie kan zijn om een forecast te maken voor de komende 3-5 dagen dan ben ik al zeer vereert. Het is een snel probeersel wat in de laatste versies is vastgelopen, terwijl er opeens een kindje geboren werd (onverwacht vroeg), maar het idee staat er in de basis. Als er weer rust in huis is, zal ik het proberen om het project in een werkende staat te brengen.
Bij mij thuis werkt het al wel, momenteel gebruik ik het om (handmatig) de opt.soc high/low te beinvloeden zodat de gesimuleerde batterij over meerdere dagen effectief wordt ingezet bij langdurig hogere prijzen. (eerst volpompen, vervolgens iedere dag een deel vrijgeven).

xgboost is een afhankelijkheid die ik niet wilde introduceren in een integratie, vandaar de fit op basis van een formule die is afgeleid van de data van de afgelopen maanden. Ook de regressiemodellering is nu in python opgenomen om geen afhankelijkheid te krijgen van numpy e.d.
De bedoeling is dat de fit zelf wordt herhaalt om zo seizoensinvloeden mee te nemen. Extremen situaties zullen niet goed voorspeld worden, en momenteel wil ik die niet hardcoded in het model opnemen (max 12,7 GW aan fossiele productie in NL, maar dat moet ook weer bijgehouden worden bij nieuwbouw/afbraak/stillegging).
Als DAO een betere fit kan maken met xgboost is dat alleen maar beter.

Ned.nl data is tegenwoordig voor eigen gebruik vrij te gebruiken, daar voldoe je aan met het gebruiken van je eigen API key. Integraties zoals de mijne moeten wel vermelden dat ze de ned.nl data gebruiken (vandaar de referentie in de Readme).

Als de ned.nl data in DAO wordt opgenomen om meerdaagse voorspellingen te doen (EV vandaag niet opladen als het niet nodig is, want donderdag wordt het echt goedkoop) en de thuisbatterij over meerdere dagen te optimaliseren lijkt mij dat heel tof!

[edterbak]

Gefeliciteerd @Bravo

[KC27]

diamanten schreef op maandag 19 januari 2026 @ 13:04:
Na update naar 2026.1.1 probeer ik de ML-functionaliteit. Ik krijg ondermeer deze melding:

code:

2026-01-19 12:25:30,298 info root MainThread : KNMI-weerstation: 278 HEINO
2026-01-19 12:25:30,302 info root MainThread : Er zijn knmi-data aanwezig vanaf 2023-01-17 01:00:00 tot 2026-01-17 00:00:00
2026-01-19 12:25:30,302 info root MainThread : Er worden geen knmi-data opgehaald
2026-01-19 12:25:30,350 info root MainThread : ML prediction Enphase

Ik zie in de grafieken voor bepaalde dagen zoals 16 januari wel een R2-score, maar voor 18 januari bijv. niet overal (of een negatieve). Ook ontbreekt de gemeten straling. Gaat het ophalen van de KNMI-data wel goed? En zo nee: hoe kan ik een ander weerstation selecteren?
Hierbij de complete log:

[...]


[...]

Volgens mij werkt het wel goed!
Je hebt data van af 2023 tot 17 jan. 2026.
Dus van zaterdag zijn ze er nog niet (en ook nog niet beschikbaar bij het knmi).
De meetgegevens van het knmi zijn er tot eergisteren en later op de dag "tot en met" eergisteren.
Die gegevens worden opgehaald/aangevuld tijdens het trainen van je model (meestal een keer per dag).
Ik heb nog niet door (of ergens gelezen) hoe laat de meetdata van eergisteren beschikbaar zijn.
De ml-voorspeller werkt het best met meetdata over meer dan een jaar. Korter geeft vaak slechtere resultaten.

[KC27]

twimj schreef op maandag 19 januari 2026 @ 11:37:
Na de update van 2025.12 naar 2026.1.1 het volgende in de log. Iemand een suggestie hoe dit op te lossen, heb helaas geen backup


[...]

Waarschijnlijk heb je nog een "oude" processor (van voor 2009?).
Klopt dat?
Ik zal een nieuwe testversie maken die ook "oude hardware" ondersteunt.
Graag even geduld.

[twimj]

Ik heb HA gevirtualiseerd in Proxmox, en daar is de default processor blijkbaar een heel oude variant. Nu de processor "geupgrade" naar de host processor, een I3 8e generatie, en daarna werkte het wel weer.

Achteraf gezien was mijn vraag dus te voorbarig, sorry.

KC27 schreef op maandag 19 januari 2026 @ 16:36:
[...]

Waarschijnlijk heb je nog een "oude" processor (van voor 2009?).
Klopt dat?
Ik zal een nieuwe testversie maken die ook "oude hardware" ondersteunt.
Graag even geduld.

[appsec]

Vanwege het einde van de salderingsregeling in 2027 ben ik mij aan het oriënteren op een kleine thuisbatterij (waarschijnlijk een Marstek Venus E V3) en ik probeer te bedenken hoe ik de boel wil gaan aansturen. Ik denk dat de standaard NOM strategie niet optimaal is en de AI modus lijkt ook niet helemaal betrouwbaar.

Voor mijn werk werk ik aan een EMS voor bedrijven dus het leek mij wel een leuk project om zelf iets te schrijven maar toen kwam ik DAO tegen dus dat maakt het allemaal wat makkelijker.

Ik vroeg me alleen af hoe jullie de aansturing van de batterij precies regelen. DAO is afhankelijk van een voorspelling van de zon opbrengst en je bruto verbruik om een optimaal plan te maken, maar beide voorspellingen zijn erg onbetrouwbaar. Zeker je thuisverbruik is lastig te voorspellen omdat de software niet kan weten of en hoe laat je je grootverbruikers (inductieplaat, oven, etc.) aan gaat zetten. Ik heb daarom het idee dat het niet optimaal is om blind de output van DAO te volgen omdat je dan bijvoorbeeld op dure momenten waar je verbruik hoger dan verwacht is stroom van het net afneemt ipv die uit je batterij te trekken. Zijn er hier al mensen die daar overna hebben gedacht of een oplossing voor hebben? Ik heb wel wat ideeën om te bespreken als er interesse is.

[Vaevictis_]

KC27 schreef op zaterdag 17 januari 2026 @ 23:38:
[...]

Deze input heeft DAO nodig:

• Je moet DAO toegang geven tot een sensor in HA die de actuele inhoud van je accu presenteert. Die sensor geef je aan met de setting: entity actual level. Bijvoorbeeld:
  
  code:
  

  "entity actual level": "sensor.ess_battery_soc",

• Verder moet je de capaciteit, lower limit, upper limit, max soc, "charge_stages" en "discharge stages" definiëren (zie documentatie in wiki: https://github.com/corneel27/day-ahead/wiki)

Tenslotte zijn er drie entities van belang waarin DAO de belangrijkste resultaten kan wegschrijven. Hiervoor kun je het beste in HA helpers aanmaken. Bij een verandering van state trigger je een automation die de berekende waarde (eventueel omgezet) doorzet naar je TB.

• .
• "entity set operating mode": "input_select.ess_operating_mode",
  Je maakt een input_select met de opties "aan"en "uit". Als je accu niks hoeft te doen gaat ie op "uit", anders op "aan".
• "entity set power feedin": "input_number.dao_set_power_feedin",
  Hierin komt het berekende vermogen in W dat je accu moet gaan opnemen (+) of terugleveren(-). Sommige accu's verwachten het teken andersom. Je kunt dit dus omdraaien in je HA-automation.
• "entity stop inverter": "input_datetime.stop_inverter",
  Hierin komt een datum/tijd te staan waarop je je inverter/accu moet stoppen met laden/ontladen. Deze datum/tijd wordt alleen ingevuld als die stop valt voor de start van de volgende berekening,

Ik weet niet welk merk/type thuisbatterij je hebt. Maar er zijn hier van verschillende merken en typen voorbeeld instellingen gedeeld (vaak als onderdeel van een vraag). Als je op merk en type zoekt zul je ongetwijfeld een een hit vinden. Anders zijn hier veel mensen beschikbaar om je verder te helpen.

Dank ga hiermee aan de slag, ik denk niet dat iemand mijn batterij ook heeft. Het is een Sunways hybride omvormer met een Wattsonic 18.5kWh HV LFP batterij.

[KC27]

twimj schreef op maandag 19 januari 2026 @ 17:31:
Ik heb HA gevirtualiseerd in Proxmox, en daar is de default processor blijkbaar een heel oude variant. Nu de processor "geupgrade" naar de host processor, een I3 8e generatie, en daarna werkte het wel weer.

Achteraf gezien was mijn vraag dus te voorbarig, sorry.


[...]

Fijn dat het opgelost is. Scheelt mij weer een extra testversie.

[KC27]

Deikke schreef op maandag 19 januari 2026 @ 11:27:
Ik krijg de volgende error met de 2026.01.1 versie van DAO, enig idee wat hier mis gaat?

code:

2026-01-19 11:15:13 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
    self.dialect.do_execute(
    ~~~~~~~~~~~~~~~~~~~~~~~^
        cursor, str_statement, effective_parameters, context
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/sqlalchemy/engine/default.py", line 952, in do_execute
    cursor.execute(statement, parameters)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.GroupingError: column "values.time" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: ...MM-DD HH24:00') AS uur, min(values.time) AS time, values.tim...

]

Oh, deze moet ik even onderzoeken.
Dit komt alleen bij een postgresql-database voor.
Dank voor hete melden.
Kom ik op terug!

[KC27]

Deikke schreef op maandag 19 januari 2026 @ 11:27:
Ik krijg de volgende error met de 2026.01.1 versie van DAO, enig idee wat hier mis gaat?

code:

2026-01-19 11:15:13 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/sqlalchemy/engine/base.py", line 1967, in _exec_single_context
    self.dialect.do_execute(
    ~~~~~~~~~~~~~~~~~~~~~~~^
        cursor, str_statement, effective_parameters, context
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/sqlalchemy/engine/default.py", line 952, in do_execute
    cursor.execute(statement, parameters)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.GroupingError: column "values.time" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: ...MM-DD HH24:00') AS uur, min(values.time) AS time, values.tim...

]

Heb je voor mij (mag ook via dm) een gehele track-trace van de fout?
Dan kan ik namelijk zien vanaf welke procedure het fout gaat.

[Torch1969]

appsec schreef op maandag 19 januari 2026 @ 17:53:
Vanwege het einde van de salderingsregeling in 2027 ben ik mij aan het oriënteren op een kleine thuisbatterij (waarschijnlijk een Marstek Venus E V3) en ik probeer te bedenken hoe ik de boel wil gaan aansturen. Ik denk dat de standaard NOM strategie niet optimaal is en de AI modus lijkt ook niet helemaal betrouwbaar.

Voor mijn werk werk ik aan een EMS voor bedrijven dus het leek mij wel een leuk project om zelf iets te schrijven maar toen kwam ik DAO tegen dus dat maakt het allemaal wat makkelijker.

Ik vroeg me alleen af hoe jullie de aansturing van de batterij precies regelen. DAO is afhankelijk van een voorspelling van de zon opbrengst en je bruto verbruik om een optimaal plan te maken, maar beide voorspellingen zijn erg onbetrouwbaar. Zeker je thuisverbruik is lastig te voorspellen omdat de software niet kan weten of en hoe laat je je grootverbruikers (inductieplaat, oven, etc.) aan gaat zetten. Ik heb daarom het idee dat het niet optimaal is om blind de output van DAO te volgen omdat je dan bijvoorbeeld op dure momenten waar je verbruik hoger dan verwacht is stroom van het net afneemt ipv die uit je batterij te trekken. Zijn er hier al mensen die daar overna hebben gedacht of een oplossing voor hebben? Ik heb wel wat ideeën om te bespreken als er interesse is.

@appsec welkom, het klinkt alsof je interessante ideeën hebt, die zijn altijd welkom. Zeker als je dan ook nog wat kunt ontwikkelen .
Je moet DAO zien als degene die de strategie voor de komende periode (kwartier of uur) aan je doorgeeft. Je moet in home assistant zelf nog de operatie doen. Daar kun je ook nog gewenste functionaliteit aan toevoegen. Er zit bijvoorbeeld ook een “balanceer” indicatie in DAO bij de batterij aansturing, waarmee je dan zelf een soort NOM regeling kunt starten (zelf te maken via b.v. een automatisering specifiek voor je batterij), maar die kun je zelf ook altijd laten draaien (om pieken op te vangen). Ik heb b.v. een XOM regeling voor laden (bij lage prijzen) en één voor leveren (bij hoge prijzen). Voorspelbare apparaten kun je toevoegen, zeker als je ze wilt laten plannen. Onvoorspelbare apparaten is inderdaad lastig. Hoe pak je zoiets in een EMS bij bedrijven aan?

[diamanten]

KC27 schreef op maandag 19 januari 2026 @ 16:34:
[...]

Volgens mij werkt het wel goed!
Je hebt data van af 2023 tot 17 jan. 2026.
Dus van zaterdag zijn ze er nog niet (en ook nog niet beschikbaar bij het knmi).
De meetgegevens van het knmi zijn er tot eergisteren en later op de dag "tot en met" eergisteren.
Die gegevens worden opgehaald/aangevuld tijdens het trainen van je model (meestal een keer per dag).
Ik heb nog niet door (of ergens gelezen) hoe laat de meetdata van eergisteren beschikbaar zijn.
De ml-voorspeller werkt het best met meetdata over meer dan een jaar. Korter geeft vaak slechtere resultaten.

OK. Dank voor de toelichting, ik zie nu ook dat data van 18 jan 2026 is binnengehaald. De R2 ga ik in de gaten houden.

[storeman]

@appsec Deze "onvoorspelbare" verbruikers kun je natuurlijk verwerken in de baseload en dat zal meestal ook zo zijn. Dat je van plan bent om 's avonds de oven aan te doen bij het eten koken, zou je natuurlijk erin kunnen zetten, maar voor de meeste gebruikers zal dat wat te ver gaan. Dat wij op zondagochtend altijd croissantjes afbakken, zal DAO met de baseload berekening wel meenemen.

Ik heb nog een vraag over de aansturing van de WP. De bovenste grafiek is de DAO stooklijn correctie, de onderste de energieprijs. Bij de rode lijn springt de energieprijs met 10ct omhoog, maar de stooklijn wordt maar een beetje aangepast, terwijl de periode met hogere prijs voortduurt, gaat de stooklijn wel verder naar beneden. Het ziet eruit alsof er een gemiddelde wordt gebruikt waarbij er alleen terug in de tijd wordt gekeken, maar met een stooklijn-aanpassing wil je eigenlijk ook een stukje vooruit kijken omdat een stooklijn wat trager reageert (in ieder geval bij mij).




Gisteravond zag ik nog iets geks, vlak na het ontladen ging hij weer laden met behoorlijk vermogen. Ik zag nog op de laatste 2025.12 release. Kan jij dit verklaren, KC27? In de vergelijking hieronder zie je een duidelijke verspringen, ook qua verdiensten.





Uiteraard in de tussentijd niets aangepast in de config:

Log 19:15: https://appdevtools.com/pastebin/88936G
Log 19:30: https://appdevtools.com/pastebin/X97m4L

[KC27]

storeman schreef op dinsdag 20 januari 2026 @ 09:20:
@appsec Deze "onvoorspelbare" verbruikers kun je natuurlijk verwerken in de baseload en dat zal meestal ook zo zijn. Dat je van plan bent om 's avonds de oven aan te doen bij het eten koken, zou je natuurlijk erin kunnen zetten, maar voor de meeste gebruikers zal dat wat te ver gaan. Dat wij op zondagochtend altijd croissantjes afbakken, zal DAO met de baseload berekening wel meenemen.

Ik heb nog een vraag over de aansturing van de WP. De bovenste grafiek is de DAO stooklijn correctie, de onderste de energieprijs. Bij de rode lijn springt de energieprijs met 10ct omhoog, maar de stooklijn wordt maar een beetje aangepast, terwijl de periode met hogere prijs voortduurt, gaat de stooklijn wel verder naar beneden. Het ziet eruit alsof er een gemiddelde wordt gebruikt waarbij er alleen terug in de tijd wordt gekeken, maar met een stooklijn-aanpassing wil je eigenlijk ook een stukje vooruit kijken omdat een stooklijn wat trager reageert (in ieder geval bij mij).

De stooklijn correctie wordt "gedempt", om te voorkomen dat ie mee schiet met de prijsuitschieters (zeker bij kwartierprijzen). Hij gaat per interval nooit meer dan 10 x de adjustment-factor omhoog of omlaag.

[Afbeelding]


Gisteravond zag ik nog iets geks, vlak na het ontladen ging hij weer laden met behoorlijk vermogen. Ik zag nog op de laatste 2025.12 release. Kan jij dit verklaren, KC27? In de vergelijking hieronder zie je een duidelijke verspringen, ook qua verdiensten.

[Afbeelding]

[Afbeelding]

Uiteraard in de tussentijd niets aangepast in de config:

Log 19:15: https://appdevtools.com/pastebin/88936G
Log 19:30: https://appdevtools.com/pastebin/X97m4L

Het grote verschil zit in de penalty cost:

code:

2026-01-19 19:15:32 info: 
Calculation profit after optimize in €
Cost before optimize              8.71
Cost consumption     14.71
Cycle cost            0.59
Penalty cost          0.00
Battery storage       0.09
Boiler storage        0.49
Profit production    -8.84
Total                 7.04
Cost after optimize               7.04
Profit:                           1.66

code:

2026-01-19 19:30:22 info: 
Calculation profit after optimize in €
Cost before optimize              8.67
Cost consumption     15.25
Cycle cost            0.59
Penalty cost          1.50
Battery storage      -0.27
Boiler storage        0.48
Profit production    -8.64
Total                 8.91
Cost after optimize               8.91
Profit:                          -0.24

Na 19:15 is er te veel uit je accu gehaalden is de SoC lager uitgekomen dan geraamd.
Dat zijn geen echte kosten, maar "virtuele" kosten die DAO berekend om de SoC weer snel boven lower limit te krijgen.
Heb je de capaciteit wel goed ingevuld?
De SoC zou tussen 19:15 en 19:30 uur met 0,68 kWh van 18% naar 13,63 % gaan:

code:

  uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 19:15  -0.68  95.00  -0.71   0.00  -0.71  96.00  -0.74  91.20  13.63

Maar om 19:30 was ie 5%....

[storeman]

@KC27 dank voor het meekijken, fijn dat je dat zo ziet. Ik heb naar de batterij gekeken en daar zie ik ineens een flinke afname (niet geleidelijk) in de SoC, bij lagere SoC's zie ik dat wel eens vaker. Kan met de temperatuur te maken hebben. De capaciteit staat wel goed.

Wat betreft de stooklijn, is het een idee (en mogelijk) om wat voor te sorteren op de trend. Mijn stooklijn vertaalt zich namelijk naar graad minuten, die de WP gebruikt om te sturen. Dit reageert dus vrij traag. Eventueel zelfs met een window (x tijd terug/vooruit)?

[Vaevictis_]

storeman schreef op dinsdag 20 januari 2026 @ 12:43:
@KC27 dank voor het meekijken, fijn dat je dat zo ziet. Ik heb naar de batterij gekeken en daar zie ik ineens een flinke afname (niet geleidelijk) in de SoC, bij lagere SoC's zie ik dat wel eens vaker. Kan met de temperatuur te maken hebben. De capaciteit staat wel goed.

Wat betreft de stooklijn, is het een idee (en mogelijk) om wat voor te sorteren op de trend. Mijn stooklijn vertaalt zich namelijk naar graad minuten, die de WP gebruikt om te sturen. Dit reageert dus vrij traag. Eventueel zelfs met een window (x tijd terug/vooruit)?

Graadminuten? Is dat een NIBE? zag dat laatst op de F1155 @KC27 en ik hebben een alpha innotech WP die stuurt op retourtemperatuur.

[Animal]

Mijn batterij begint zojuist om 18:00 te ontladen maar om 17:00 was de prijs hoger dan die van 18:00. Hebben meer mensen dit?

[konehead]

appsec schreef op maandag 19 januari 2026 @ 17:53:
Vanwege het einde van de salderingsregeling in 2027 ben ik mij aan het oriënteren op een kleine thuisbatterij (waarschijnlijk een Marstek Venus E V3) en ik probeer te bedenken hoe ik de boel wil gaan aansturen. Ik denk dat de standaard NOM strategie niet optimaal is en de AI modus lijkt ook niet helemaal betrouwbaar.

Voor mijn werk werk ik aan een EMS voor bedrijven dus het leek mij wel een leuk project om zelf iets te schrijven maar toen kwam ik DAO tegen dus dat maakt het allemaal wat makkelijker.

Ik vroeg me alleen af hoe jullie de aansturing van de batterij precies regelen. DAO is afhankelijk van een voorspelling van de zon opbrengst en je bruto verbruik om een optimaal plan te maken, maar beide voorspellingen zijn erg onbetrouwbaar. Zeker je thuisverbruik is lastig te voorspellen omdat de software niet kan weten of en hoe laat je je grootverbruikers (inductieplaat, oven, etc.) aan gaat zetten. Ik heb daarom het idee dat het niet optimaal is om blind de output van DAO te volgen omdat je dan bijvoorbeeld op dure momenten waar je verbruik hoger dan verwacht is stroom van het net afneemt ipv die uit je batterij te trekken. Zijn er hier al mensen die daar overna hebben gedacht of een oplossing voor hebben? Ik heb wel wat ideeën om te bespreken als er interesse is.

leuke vraag. Ik heb een soort loadbalancer gemaakt. Een beetje lomp, maar werkt wel. Als ik teruglevering heb op de P1 én A) de zon schijnt én de batterij ontlaadt niet moduleer ik de laadsnelheid obv de opwek. Ik kijk naar de actuele load in huis, de opwek van de panelen (en wat er over het teruglevertelwerk gaat). De laadsnelheid van DAO is leidend, tenzij ik meer zon opwek (of minder vebruik) dan DAO dacht.

Dat ziet er dan zo uit - suggesties/feedback altijd welkom

code:

alias: DAO Batterij laadvermogen = zonne-opwek en load huis
description: load balancing zonopwek/ load huis en nominatieprofiel batterij
triggers:
  - entity_id:
      - sensor.growatt2_pv2_power
    trigger: state
  - trigger: state
    entity_id:
      - sensor.dsmr_reading_electricity_currently_returned_watt
  - trigger: state
    entity_id:
      - sensor.growatt2_ac_load_consumption
conditions:
  - condition: state
    entity_id: switch.growatt2_ac_charge_switch
    state: "off"
    enabled: false
  - condition: state
    entity_id: switch.growatt2_time2_enable
    state: "off"
    enabled: false
  - condition: state
    entity_id: switch.growatt2_time1_enable
    state: "off"
  - condition: numeric_state
    entity_id: sensor.growatt2_battery_soc
    below: 99.99
  - condition: numeric_state
    entity_id: sensor.dsmr_reading_electricity_currently_returned_watt
    above: 0
actions:
  - delay:
      hours: 0
      minutes: 0
      seconds: 5
      milliseconds: 0
  - variables:
      pv_power: "{{ states('sensor.growatt2_pv2_power') | float(0) }}"
      load_power: "{{ states('sensor.growatt2_ac_load_consumption') | float(0) }}"
      dao_power: "{{ pv_power - (load_power + 350) }}"
      max_power: 4600
      returned: >-
        {{ states('sensor.dsmr_reading_electricity_currently_returned_watt') |
        float(0) }}
      feedin_setting: "{{ states('input_number.dao_set_power_feedin') | float(0) }}"
      feedin_threshold: >-
        {{ ((feedin_setting / max_power) * 100) | round(0) if feedin_setting > 0
        else 0 }}
      overschot_pct: "{{ ((dao_power / max_power) * 100) | round(0) }}"
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ feedin_setting > 0 }}"
        sequence:
          - target:
              entity_id: number.growatt2_charge_power_rate
            data:
              value: |-
                {% set val = overschot_pct %}
                {% if val < feedin_threshold %}
                  {% set val = feedin_threshold %}
                {% endif %}
                {% if returned <= 100 and val < feedin_threshold %}
                  {% set val = feedin_threshold %}
                {% endif %}
                {% if val > 100 %}
                  100
                {% else %}
                  {{ val | round(0) }}
                {% endif %}
            action: number.set_value
      - conditions:
          - condition: template
            value_template: "{{ feedin_setting <= 0 }}"
        sequence:
          - target:
              entity_id: number.growatt2_charge_power_rate
            data:
              value: |-
                {% if overschot_pct > 100 %}
                  100
                {% else %}
                  {{ overschot_pct | round(0) }}
                {% endif %}
            action: number.set_value

[KC27]

Animal schreef op dinsdag 20 januari 2026 @ 18:03:
Mijn batterij begint zojuist om 18:00 te ontladen maar om 17:00 was de prijs hoger dan die van 18:00. Hebben meer mensen dit?

Heb je de logging van 17:00 en 18:00 uur (tussen quote-tags)?

[KC27]

storeman schreef op dinsdag 20 januari 2026 @ 12:43:
@KC27 dank voor het meekijken, fijn dat je dat zo ziet. Ik heb naar de batterij gekeken en daar zie ik ineens een flinke afname (niet geleidelijk) in de SoC, bij lagere SoC's zie ik dat wel eens vaker. Kan met de temperatuur te maken hebben. De capaciteit staat wel goed.

Ik heb in HA een bewaking gemaakt, die voorkomt dat mijn batterij onder een bepaald voltage komt.
Ik heb 4 jaar geleden zelf mijn thuisbatterij in elkaar gezet en daar zaten een paar mindere cellen tussen. Zodra een drempel waarde wordt bereikt zakt de cel-spanning van die cellen heel snel. Zoiets zou bij jou ook het geval kunnen zijn.
Met mijn bewaking voorkom ik dat het geheel te ver door de ondergrens zakt.
Ik hou zelf de SoC van de batterij bij in HA.
Alleen in het lage voltage gebied en het hoge voltage gebied kun je na 15 min rust de SoC bepalen uit de spanning. Zo kalibreer ik dus steeds mijn SoC.
Maar dit werkt alleen als je toegang tot al die data hebt. Hoe zit dat bij jou?

Wat betreft de stooklijn, is het een idee (en mogelijk) om wat voor te sorteren op de trend. Mijn stooklijn vertaalt zich namelijk naar graad minuten, die de WP gebruikt om te sturen. Dit reageert dus vrij traag. Eventueel zelfs met een window (x tijd terug/vooruit)?

Voorsorteren zou wel kunnen, ik weet alleen niet direct hoe? Je wilt natuurlijk het laagst mogelijke verbruik bij hoge prijzen en vice versa. Die extra graad minuten gaan hun effect veel later laten zien als een soort mosterd na de maaltijd.
Jij hebt niet direct invloed op de stooklijn?

[Mirabis]

Animal schreef op dinsdag 20 januari 2026 @ 18:03:
Mijn batterij begint zojuist om 18:00 te ontladen maar om 17:00 was de prijs hoger dan die van 18:00. Hebben meer mensen dit?

Dat had ik gisteren ook idd. Goed dat je het zegt, zal ook nog ff de logging boven water halen.

[storeman]

Ik gebruik een Growatt SPH omvormer die ik lokaal uitlees/aanstuur. Hier hangt een batterijpakket van Dyness aan (high voltage). Die SPH doet zelf ook aan bewaking en bij te diepe ontlading heb ik hem ook wel eens betrapt op zelf weer gaan opladen, maar dat was voordat ik DAO gebruikte. Ik zie inderdaad nu wel dat er een flinke dip ook is in de batterijspanning, maar ik kan alleen het pakket monitoren. Ik denk dat ik de ondergrenzen gewoon iets naar boven moet trekken om dit gedrag te voorkomen. Ik had ze recent wat verlaagd waardoor dit gedrag nu ineens zichtbaar werd.


Wat betreft de warmtepomp, ik heb inderdaad een NIBE. Wat ik nu doe is de stooklijn-offset aanpassen aan de hand van twee parameters:
- verschil tussen gewenste en huidige kamertemperatuur
- DAO berekening

Ik heb dus wel direct invloed op de stooklijn, maar de stooklijn resulteert alleen in een snellere/tragere afname/toename van de graadminuten. Nibe regelt nogal conservatief tot mijn grote frustratie, die gaat eigenlijk nooit heel dicht op de gewenste aanvoertemperatuur regelen.

Ik heb nu die factor aangepast, maar dan, naast de snellere aanpassing, wordt de uitslag ook groter, dat is dan niet zo handig.

Ik weet niet precies hoe DAO het nu doet, maar ik denk dat er (onder andere) gekeken wordt naar de huidige prijs tov het daggemiddelde. In plaats van sec de huidige prijs, zou je kunnen zeggen om x-kwartieren ervoor en y-kwartieren erna bij het huidige tarief te betrekken. Indien x en y 0 zijn, gebruik je dan alleen het huidige tarief, maar bij x=1 en y=3 kijk je dan naar het gemiddelde over vijf kwartieren en vergelijk je die met het daggemiddelde.

De demping die nu optreed door de adjustment factor is denk ik niet per se wenselijk, soms zie je ineens scherpe wijziging in de tarieven waardoor het denk ik wel logisch zou zijn om hier krachtig op te reageren. Door middel van de "smoothening" kun je vervolgens hier een eigen draai aan geven.

JSON:

{
....

    "entity adjust heating curve": "input_number.dao_wp_adjust_heating_curve",
    "adjustment factor": 0.12,
    "price smoothening window": [1, 3]
...
}

[Animal]

KC27 schreef op dinsdag 20 januari 2026 @ 20:40:
[...]

Heb je de logging van 17:00 en 18:00 uur (tussen quote-tags)?

Interessant Ik heb logging om 17:00 van de meteo data
en vervolgens een volgende log van 18:00. Daarvoor nog een log van 16:00. Maar geen rapport van 17:00 dus?

[Vaevictis_]

KC27 schreef op maandag 19 januari 2026 @ 18:59:
[...]

Fijn dat het opgelost is. Scheelt mij weer een extra testversie.

Ha @KC27 ik heb de configuratie aangepast, zoals hierboven aangegeven maar zie bij savings - cost overal NaN. Wat gaat hier fout?

Voor de rest heb ik de input helpers nog niet aangemaakt, maar hoe kan ik met een automation op basis van de deze input helpers dan de batterij laden/ontladen? Idem stooklijn WP / DHW.

Hierbij mijn config.

YAML:

{
  "homeassistant": { },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "entsoe",
    "entsoe-api-key": "!secret entsoe-api-key",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
   "last invoice": "2025-08-01",
    "tax refund": "True"
  },
  "logging level" : "debug",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "True",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
    {"name" : "Wattsonic",
     "entity actual level": "sensor.battery_bms_soc",
     "capacity": 18,
     "upper limit": 100,
     "lower limit": 33,
     "charge stages" : [
        {"power": 0.0, "efficiency": 1},
        {"power": 30.0, "efficiency": 0.949},
        {"power": 60.0, "efficiency": 0.950},
        {"power": 90.0, "efficiency": 0.951},
        {"power": 150.0, "efficiency": 0.952},
        {"power": 300.0, "efficiency": 0.953},
        {"power": 600.0, "efficiency": 0.954},
        {"power": 1200.0, "efficiency": 0.955},
        {"power": 2400.0, "efficiency": 0.949},
        {"power": 3600.0, "efficiency": 0.934},
        {"power": 4800.0, "efficiency": 0.92},
        {"power": 5500.0, "efficiency": 0.905}
    ],
     "discharge stages" : [
        {"power": 0.0, "efficiency": 1},
        {"power": 30.0, "efficiency": 0.949},
        {"power": 60.0, "efficiency": 0.950},
        {"power": 90.0, "efficiency": 0.951},
        {"power": 150.0, "efficiency": 0.952},
        {"power": 300.0, "efficiency": 0.953},
        {"power": 600.0, "efficiency": 0.954},
        {"power": 1200.0, "efficiency": 0.955},
        {"power": 2400.0, "efficiency": 0.949},
        {"power": 3600.0, "efficiency": 0.934},
        {"power": 4800.0, "efficiency": 0.92}
    ],
     "minimum power" : 1200,
     "dc_to_bat efficiency" : 0.96,
     "bat_to_dc efficiency": 0.96,
     "cycle cost" : 0.01,
     "entity set power feedin": "input_number.dao_set_power_feedin",
     "entity set operating mode": "input_select.ess_operating_mode",
     "entity stop inverter": "input_datetime.stop_inverter",
     "entity balance switch": "",
     "solar": [ ]
    }
  ],
  "solar": [ ],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.electricity_meter_energy_consumption_tarif_2",
      "sensor.electricity_meter_energy_consumption_tarif_1"
    ],
    "entities grid production": [
      "sensor.electricity_meter_energy_production_tarif_1",
      "sensor.electricity_meter_energy_production_tarif_2"
    ],
    "entities solar production ac": [
      "sensor.solaredge_woning_ac_energy_kwh"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.thuis_energy_meter"],
    "entities wp consumption" : ["sensor.sdm630_import_active_energy"],
    "entities boiler consumption": ["sensor.luxtronik2_dhw_heat_amount"],
    "entities battery consumption": ["sensor.battery_total_energy_charged_to_battery"],
    "entities battery production": ["sensor.battery_total_energy_discharged_from_battery"]
  },
  "scheduler": {
    "active": "false",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

[Animal]

Ik krijg ML prediction helaas niet aan de gang. Ik heb van meerdere jaren data van mijn zonnepanelen.
Na het manueel trainen krijg ik een 504 Gateway Time-out
Ook heb ik een task aangemaakt "2240": "train_ml_predictions",.

Ik denk dat het aan mijn sensor ligt. Ik heb meerde sensoren voor mijn zonnepanelen.
Een Yield per day (De loopt op pet KWh en reset om 0:00 per dag. Deze gebruik ik ook in het energy dashboard denk ik. Ik heb 3 omvormers dus 3 van deze yeilds per day.

code:

state_class: total_increasing
unit_of_measurement: Wh
device_class: energy
friendly_name: Oost-West Oost-West YieldDay

Of een total (niet daily) increasing:

code:

state_class: total_increasing
unit_of_measurement: kWh
device_class: energy
friendly_name: Oost-West Oost-West YieldTotal

Gaat het mis omdat de yield per day in Wh is ipv KWh? Ik gebruik Hoymiles met een openDTU systeem. Best populair. Dus ik wil de unity's het liefst niet wijzigen naar iets anders.

code:

2026-01-21 14:24:38 info: Day Ahead Optimalisering versie: 2026.01.1.rc1
2026-01-21 14:24:38 info: Day Ahead Optimalisering gestart op: 21-01-2026 14:24:38
2026-01-21 14:24:38 info: Day Ahead Optimalisatie gestart: 21-01-2026 14:24:38 taak: calc_optimum
2026-01-21 14:24:38 info: Debug = False
2026-01-21 14:24:38 info: Baseload uit instellingen
2026-01-21 14:24:38 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 251, in calc_optimum
    solar_prog = solar_predictor.predict_solar_device(
        self.solar[s], start_hour_dt, end_prog
    )
  File "/root/dao/prog/solar_predictor.py", line 1036, in predict_solar_device
    raise FileNotFoundError(
        f"Er is geen model aanwezig voor {self.solar_name},svp eerst trainen."
    )
FileNotFoundError: Er is geen model aanwezig voor Oost_West,svp eerst trainen.
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4708, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4681, in main
    da_calc.run_task_function("calc_optimum")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 251, in calc_optimum
    solar_prog = solar_predictor.predict_solar_device(
        self.solar[s], start_hour_dt, end_prog
    )
  File "/root/dao/prog/solar_predictor.py", line 1036, in predict_solar_device
    raise FileNotFoundError(
        f"Er is geen model aanwezig voor {self.solar_name},svp eerst trainen."
    )
FileNotFoundError: Er is geen model aanwezig voor Oost_West,svp eerst trainen.

code:

"solar": [
    { "name" : "Oost West",
      "ml_prediction": "true",
      "entities sensors": "sensor.hms_2000_4t_yieldday",
      "entity pv switch": "input_boolean.oost_west_turn_inverter_on_off",
      "strings": [
        {
        "tilt": 45,
        "orientation": -135,
        "capacity": 0.43,
        "yield": 0.00091375
        },
        {
        "tilt": 45,
        "orientation": -135,
        "capacity": 0.43,
        "yield": 0.00091375
        },
        {
        "tilt": 45,
        "orientation": 45,
        "capacity": 0.43,
        "yield": 0.00091375
        },
        {
        "tilt": 45,
        "orientation": 45,
        "capacity": 0.43,
        "yield": 0.00091375
        }
      ]
    },
    {
      "name": "Zuid paneel",
      "ml_prediction": "true",
      "entities sensors": "sensor.zuid_paneel_yieldday",
      "entity pv switch": "input_boolean.zuid_paneel_on_off",
      "tilt": 60,
      "orientation": -45,
      "capacity": 0.43,
      "yield": 0.00091375
    },
    {
      "name": "Schuine dak",
      "ml_prediction": "true",
      "entities sensors": "sensor.schuine_dak_yieldday",
      "entity pv switch": "input_boolean.schuin_dak_on_off",
      "tilt": 45,
      "orientation": 45,
      "capacity": 0.50,
      "yield": 0.0010625
    }

[ Voor 5% gewijzigd door Animal op 21-01-2026 14:39 ]

[DirkB19]

@KC27 Bedankt voor het mooie project. Is het mogelijk om de berekende winst in Euro via de API te verkrijgen ? Ik had deze graag bijv op een ePaper willen tonen ... Thx.

[Torch1969]

Vaevictis_ schreef op woensdag 21 januari 2026 @ 14:01:
[...]

Ha @KC27 ik heb de configuratie aangepast, zoals hierboven aangegeven maar zie bij savings - cost overal NaN. Wat gaat hier fout?

Voor de rest heb ik de input helpers nog niet aangemaakt, maar hoe kan ik met een automation op basis van de deze input helpers dan de batterij laden/ontladen? Idem stooklijn WP / DHW.

Hierbij mijn config.

YAML:

{
  "homeassistant": { },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "entsoe",
    "entsoe-api-key": "!secret entsoe-api-key",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
   "last invoice": "2025-08-01",
    "tax refund": "True"
  },
  "logging level" : "debug",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "True",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
    {"name" : "Wattsonic",
     "entity actual level": "sensor.battery_bms_soc",
     "capacity": 18,
     "upper limit": 100,
     "lower limit": 33,
     "charge stages" : [
        {"power": 0.0, "efficiency": 1},
        {"power": 30.0, "efficiency": 0.949},
        {"power": 60.0, "efficiency": 0.950},
        {"power": 90.0, "efficiency": 0.951},
        {"power": 150.0, "efficiency": 0.952},
        {"power": 300.0, "efficiency": 0.953},
        {"power": 600.0, "efficiency": 0.954},
        {"power": 1200.0, "efficiency": 0.955},
        {"power": 2400.0, "efficiency": 0.949},
        {"power": 3600.0, "efficiency": 0.934},
        {"power": 4800.0, "efficiency": 0.92},
        {"power": 5500.0, "efficiency": 0.905}
    ],
     "discharge stages" : [
        {"power": 0.0, "efficiency": 1},
        {"power": 30.0, "efficiency": 0.949},
        {"power": 60.0, "efficiency": 0.950},
        {"power": 90.0, "efficiency": 0.951},
        {"power": 150.0, "efficiency": 0.952},
        {"power": 300.0, "efficiency": 0.953},
        {"power": 600.0, "efficiency": 0.954},
        {"power": 1200.0, "efficiency": 0.955},
        {"power": 2400.0, "efficiency": 0.949},
        {"power": 3600.0, "efficiency": 0.934},
        {"power": 4800.0, "efficiency": 0.92}
    ],
     "minimum power" : 1200,
     "dc_to_bat efficiency" : 0.96,
     "bat_to_dc efficiency": 0.96,
     "cycle cost" : 0.01,
     "entity set power feedin": "input_number.dao_set_power_feedin",
     "entity set operating mode": "input_select.ess_operating_mode",
     "entity stop inverter": "input_datetime.stop_inverter",
     "entity balance switch": "",
     "solar": [ ]
    }
  ],
  "solar": [ ],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.electricity_meter_energy_consumption_tarif_2",
      "sensor.electricity_meter_energy_consumption_tarif_1"
    ],
    "entities grid production": [
      "sensor.electricity_meter_energy_production_tarif_1",
      "sensor.electricity_meter_energy_production_tarif_2"
    ],
    "entities solar production ac": [
      "sensor.solaredge_woning_ac_energy_kwh"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.thuis_energy_meter"],
    "entities wp consumption" : ["sensor.sdm630_import_active_energy"],
    "entities boiler consumption": ["sensor.luxtronik2_dhw_heat_amount"],
    "entities battery consumption": ["sensor.battery_total_energy_charged_to_battery"],
    "entities battery production": ["sensor.battery_total_energy_discharged_from_battery"]
  },
  "scheduler": {
    "active": "false",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

Hoi @Vaevictis_ , heb je de wiki al gevonden? Daar staat je vraag uitgelegd: https://github.com/cornee...nt-voor-koppeling-met-dao
En een verzoek, zou je je post willen editen en je code blok binnen een quote blok willen plaatsen (dat scheelt een hoop scroll werk voor de niet geïnteresseerde lezer )

[mistral2]

Ik wil de ml_prediction gaan gebruiken, maar mijn solaredge entity voor de lifetime productie in in Wh in plaats van kWh. Het lijkt erop dat de forecast daardoor de mist in gaat.
Is er een manier om in de config op te nemen dat de entity in Wh is on plaats van kWh?

(ik heb al gekeken of ik een helper i HA kan maken voor de convertie, maar dan wordt de history niet meegenomen, en aangezien de ML predictie 6 maanden history nodig heeft de helper nog geen nut...)

[Animal]

mistral2 schreef op woensdag 21 januari 2026 @ 21:37:
Ik wil de ml_prediction gaan gebruiken, maar mijn solaredge entity voor de lifetime productie in in Wh in plaats van kWh. Het lijkt erop dat de forecast daardoor de mist in gaat.
Is er een manier om in de config op te nemen dat de entity in Wh is on plaats van kWh?

(ik heb al gekeken of ik een helper i HA kan maken voor de convertie, maar dan wordt de history niet meegenomen, en aangezien de ML predictie 6 maanden history nodig heeft de helper nog geen nut...)

Twee posts hierboven heb ik dit probleem ook gemeld. Ik weet niet zeker of het dit is hoor. Mijn daily productie is in mH en mijn lifetime is in kWh. Het is me nog steeds onduidelijk welke je moet toevoegen. Misschien kan dit in de wiki duidelijker

[ Voor 10% gewijzigd door Animal op 21-01-2026 21:46 ]

[mistral2]

Animal schreef op woensdag 21 januari 2026 @ 21:38:
[...]

Twee posts hierboven heb ik dit probleem ook gemeld. Ik weet niet zeker of het dit is hoor.

Dat is ook toevallig... ik had gister nog gekeken of daar al iets over opgemerkt was, maar vandaag niet de resterende posts bekeken ;-)

Maar ik zie dat jij entities voor gebruik per dag invult, terwijl ik de lifetime productie opgeef (dus always increasing...) . Wat is nu het juiste???

[Animal]

mistral2 schreef op woensdag 21 januari 2026 @ 21:47:
[...]

Dat is ook toevallig... ik had gister nog gekeken of daar al iets over opgemerkt was, maar vandaag niet de resterende posts bekeken ;-)

Maar ik zie dat jij entities voor gebruik per dag invult, terwijl ik de lifetime productie opgeef (dus always increasing...) . Wat is nu het juiste???

De wiki zegt dezelfde sensoren als je in je energy dashboard gebruikt. Ik gebruik daarin al zeker 3 jaar de daily sensor (yieldday). Ik ga eens de lifetime yield proberen in DAO (dus ook in kWh)
Edit: nee helpt niet 504 Gateway Time-out

ps: 2026.01.1.rc1

[ Voor 5% gewijzigd door Animal op 21-01-2026 22:00 ]

[djoenez]

Ik heb een potentiële feature request:

Ik heb een thuisbatterij (omvormer 3 fase 12kW), een autolader (3 fase, 12kW) en nog een autolader (1 fase 3.6kW). Nu zie ik in de planning dat er vaak gebruik wordt gemaakt van 2 of 3 tegelijkertijd. Voor de 2 3 fase apparaten geen probleem (worden beide een beetje geknepen). Maar de 1 fase lader geeft een probleem in de planning: ik kan dan nog maar maximaal ~6kW laden met de 3 fase apparaten door mijn max belasting op 1 van de hoofdzekeringen (25A). Maar omdat DAO rekent met een totaal max vermogen (17kW) gaat de planning hierdoor mis.

Is er een mogelijkheid om een logica te verzinnen dat als x laad dat y dan nog maar op z kW kan laden?

[KC27]

Aan allen met een afwijkende dimensie in de Solar sensor:
Ik ga kijken of ik de dimensie uit HA kan ophalen en daarvoor zelf in DAO corrigeren
Verder: DAO heeft liever oplopende meterstanden ( dus geen dagelijks niet opnieuw op nul beginnen), maar dat zou wel moeten werken.

[Animal]

KC27 schreef op woensdag 21 januari 2026 @ 22:11:
Aan allen met een afwijkende dimensie in de Solar sensor:
Ik ga kijken of ik de dimensie uit HA kan ophalen en daarvoor zelf in DAO corrigeren
Verder: DAO heeft liever oplopende meterstanden ( dus geen dagelijks niet opnieuw op nul beginnen), maar dat zou wel moeten werken.

Ik gebruik inmiddels al de oplopende sensor (yieldlifetime in kWh) maar ik vervaar nog steeds dezelfde crash. Ik wacht een update af. Bedankt voor de top software

[appsec]

Torch1969 schreef op maandag 19 januari 2026 @ 19:32:
Er zit bijvoorbeeld ook een “balanceer” indicatie in DAO bij de batterij aansturing, waarmee je dan zelf een soort NOM regeling kunt starten (zelf te maken via b.v. een automatisering specifiek voor je batterij), maar die kun je zelf ook altijd laten draaien (om pieken op te vangen). Ik heb b.v. een XOM regeling voor laden (bij lage prijzen) en één voor leveren (bij hoge prijzen). Voorspelbare apparaten kun je toevoegen, zeker als je ze wilt laten plannen. Onvoorspelbare apparaten is inderdaad lastig. Hoe pak je zoiets in een EMS bij bedrijven aan?

Dat had ik gemist. Hoe wordt bepaald of die flag wordt gezet? Ik ben zelf toch aan het programmeren geslagen om het probleem beter te begrijpen en ik denk dat ik iets vergelijkbaars doe.

Voor bedrijven werkt het energiecontract vaak anders omdat zij zelf onbalansverantwoordelijkheid kunnen dragen dus dan kan je ook op onbalansprijzen inspelen.

konehead schreef op dinsdag 20 januari 2026 @ 20:39:
leuke vraag. Ik heb een soort loadbalancer gemaakt. Een beetje lomp, maar werkt wel. Als ik teruglevering heb op de P1 én A) de zon schijnt én de batterij ontlaadt niet moduleer ik de laadsnelheid obv de opwek. Ik kijk naar de actuele load in huis, de opwek van de panelen (en wat er over het teruglevertelwerk gaat). De laadsnelheid van DAO is leidend, tenzij ik meer zon opwek (of minder vebruik) dan DAO dacht.

Deze logica kan zo te zien best complex worden. Mijn omvormers rapporteren maar eens per kwartier dus dat kan ik niet gebruiken voor realtime aansturing.

De Marstek Venus E V3 heeft een NOM modus die zelf probeert nul op de meter te houden op basis van de P1 meter. Mijn huidige idee is om de optimalisatie dynamisch op kwartierbasis de modus (NOM of batterij setpoint) te laten kiezen en het real time aansturing aan de batterij over te laten. Op die manier kan de batterij onverwachte afwijkingen opvangen zodat je bijvoorbeeld niet ineens ongewenst van het net afneemt om je batterij op te laden als er een wolk voorbij komt. Makkelijker gezegt dan gedaan overigens dus ik.moet er nog mee verder prutsen.

[ Voor 9% gewijzigd door appsec op 21-01-2026 23:40 ]

[edterbak]

Ik wil ook graag de ml Solar optie gebruiken.
Maar ik zie dat mijn sensor gegevens op meerdere momenten de mist in zijn gegaan.
De grafiek over de jaren heen heeft op sommige momenten en jump naar beneden (wat niet kan) van 10 - 30 kWh.
Dus ik ben bang dat het op die dataset sowieso niet gaat werken.

Misschien goed om dit even voor jullie zelf te bekijken. Terug bladeren. . Is de data ok of onjuist

Ik ga dit eerst corrigeren. Maar dat is lastig omdat ik mariadb gebruik

[ Voor 8% gewijzigd door edterbak op 22-01-2026 09:10 ]

[KC27]

DirkB19 schreef op woensdag 21 januari 2026 @ 17:16:
@KC27 Bedankt voor het mooie project. Is het mogelijk om de berekende winst in Euro via de API te verkrijgen ? Ik had deze graag bijv op een ePaper willen tonen ... Thx.

Je kunt in HA via de api de netto kosten opvragen.
Dat kan ook met de kosten ("cost") of de opbrengsten ("profit") of cumulatief.
Bijvoorbeeld:

code:

http://192.168.178.36:5000/api/report/netto_cost/vandaag_en_morgen

Dat levert dan onderstaand antwoord op (geformatteerd):

code:

{
   "message":"Success",
   "data":[
      {
         "time_ts":1769036400000,
         "time":"2026-01-22 00:00",
         "value":0.4664213542,
         "datatype":"recorded"
      },
      {
         "time_ts":1769040000000,
         "time":"2026-01-22 01:00",
         "value":0.2026968011,
         "datatype":"recorded"
      },
      {
         "time_ts":1769043600000,
         "time":"2026-01-22 02:00",
         "value":0.1946280289,
         "datatype":"recorded"
      },
      {
         "time_ts":1769047200000,
         "time":"2026-01-22 03:00",
         "value":0.4897565855,
         "datatype":"recorded"
      },
      {
         "time_ts":1769050800000,
         "time":"2026-01-22 04:00",
         "value":0.3368287021,
         "datatype":"recorded"
      },
      {
         "time_ts":1769054400000,
         "time":"2026-01-22 05:00",
         "value":0.372276041,
         "datatype":"recorded"
      },
      {
         "time_ts":1769058000000,
         "time":"2026-01-22 06:00",
         "value":0.1891912087,
         "datatype":"recorded"
      },
      {
         "time_ts":1769061600000,
         "time":"2026-01-22 07:00",
         "value":0.1773034038,
         "datatype":"recorded"
      },
      {
         "time_ts":1769065200000,
         "time":"2026-01-22 08:00",
         "value":0.0492425314,
         "datatype":"recorded"
      },
      {
         "time_ts":1769068800000,
         "time":"2026-01-22 09:00",
         "value":0.1806176061,
         "datatype":"expected"
      },
      {
         "time_ts":1769072400000,
         "time":"2026-01-22 10:00",
         "value":0.1878327545,
         "datatype":"expected"
      },
      {
         "time_ts":1769076000000,
         "time":"2026-01-22 11:00",
         "value":0.0073373384,
         "datatype":"expected"
      },
      {
         "time_ts":1769079600000,
         "time":"2026-01-22 12:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1769083200000,
         "time":"2026-01-22 13:00",
         "value":-0.0228342313,
         "datatype":"expected"
      },
      {
         "time_ts":1769086800000,
         "time":"2026-01-22 14:00",
         "value":-0.1456209351,
         "datatype":"expected"
      },
      {
         "time_ts":1769090400000,
         "time":"2026-01-22 15:00",
         "value":0.0780352628,
         "datatype":"expected"
      },
      {
         "time_ts":1769094000000,
         "time":"2026-01-22 16:00",
         "value":0.0607844764,
         "datatype":"expected"
      },
      {
         "time_ts":1769097600000,
         "time":"2026-01-22 17:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1769101200000,
         "time":"2026-01-22 18:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1769104800000,
         "time":"2026-01-22 19:00",
         "value":0.1331400998,
         "datatype":"expected"
      },
      {
         "time_ts":1769108400000,
         "time":"2026-01-22 20:00",
         "value":0.2998816872,
         "datatype":"expected"
      },
      {
         "time_ts":1769112000000,
         "time":"2026-01-22 21:00",
         "value":0.2354432808,
         "datatype":"expected"
      },
      {
         "time_ts":1769115600000,
         "time":"2026-01-22 22:00",
         "value":0.3735851902,
         "datatype":"expected"
      },
      {
         "time_ts":1769119200000,
         "time":"2026-01-22 23:00",
         "value":0.2959921036,
         "datatype":"expected"
      }
   ]
}

[simnet]

Er zijn op dit forum een hoop gebruikers met een Marstek battery. Aansturing is echt niet moeilijk of ingewikkeld. Je kunt gewoon het advies van DAO volgen en dat in de battery zetten.

Voor wat de NOM functie betreft, ik meen me te herinneren dat @KC27 het een keer op deze manier heeft uitgelegd:
Als in het komende tijdvak de gepronotiseerde zonopwek - baseload - geplande gebruikers <= 0, dan wordt de NoM entiteit aangezet, mits hier economische meerwaarde in zit (de inhoud van de battery heeft namelijk ook een waarde).

[KC27]

edterbak schreef op donderdag 22 januari 2026 @ 09:09:
Ik wil ook graag de ml Solar optie gebruiken.
Maar ik zie dat mijn sensor gegevens op meerdere momenten de mist in zijn gegaan.
De grafiek over de jaren heen heeft op sommige momenten en jump naar beneden (wat niet kan) van 10 - 30 kWh.
Dus ik ben bang dat het op die dataset sowieso niet gaat werken.

Misschien goed om dit even voor jullie zelf te bekijken. Terug bladeren. . Is de data ok of onjuist

Ik ga dit eerst corrigeren. Maar dat is lastig omdat ik mariadb gebruik

Met HeidiSQL kun je vrij eenvoudig records in mysql/mariadb bekijken en wijzigen of verwijderen.

[KC27]

simnet schreef op donderdag 22 januari 2026 @ 09:26:
Er zijn op dit forum een hoop gebruikers met een Marstek battery. Aansturing is echt niet moeilijk of ingewikkeld. Je kunt gewoon het advies van DAO volgen en dat in de battery zetten.

Voor wat de NOM functie betreft, ik meen me te herinneren dat @KC27 het een keer op deze manier heeft uitgelegd:
Als in het komende tijdvak de gepronotiseerde zonopwek - baseload - geplande gebruikers <= 0, dan wordt de NoM entiteit aangezet, mits hier economische meerwaarde in zit (de inhoud van de battery heeft namelijk ook een waarde).

Voor de mensen die geen NOM functie in hun omvormer hebben (of hun omvormer weet niks van de netto import/export van hun slimme meter): ik heb een simpele automation gemaakt in HA die hetzelfde doet.
Als daar interesse voor is kan ik deze wel delen.

[KC27]

Animal schreef op woensdag 21 januari 2026 @ 22:15:
[...]

Ik gebruik inmiddels al de oplopende sensor (yieldlifetime in kWh) maar ik vervaar nog steeds dezelfde crash. Ik wacht een update af. Bedankt voor de top software

Die crash komt waarschijnlijk omdat de ml+predictor in het run-menu in sommige omstandigheden (meer solar-devices en/of trage hardware) meer rekentijd nodig heeft dan de 120 sec grens van de time-out. In dat geval graag proberen met de ml-preditor in de scheduler.

[KC27]

storeman schreef op dinsdag 20 januari 2026 @ 23:00:
Ik gebruik een Growatt SPH omvormer die ik lokaal uitlees/aanstuur. Hier hangt een batterijpakket van Dyness aan (high voltage). Die SPH doet zelf ook aan bewaking en bij te diepe ontlading heb ik hem ook wel eens betrapt op zelf weer gaan opladen, maar dat was voordat ik DAO gebruikte. Ik zie inderdaad nu wel dat er een flinke dip ook is in de batterijspanning, maar ik kan alleen het pakket monitoren. Ik denk dat ik de ondergrenzen gewoon iets naar boven moet trekken om dit gedrag te voorkomen. Ik had ze recent wat verlaagd waardoor dit gedrag nu ineens zichtbaar werd.


Wat betreft de warmtepomp, ik heb inderdaad een NIBE. Wat ik nu doe is de stooklijn-offset aanpassen aan de hand van twee parameters:
- verschil tussen gewenste en huidige kamertemperatuur
- DAO berekening

Ik heb dus wel direct invloed op de stooklijn, maar de stooklijn resulteert alleen in een snellere/tragere afname/toename van de graadminuten. Nibe regelt nogal conservatief tot mijn grote frustratie, die gaat eigenlijk nooit heel dicht op de gewenste aanvoertemperatuur regelen.

Ik heb nu die factor aangepast, maar dan, naast de snellere aanpassing, wordt de uitslag ook groter, dat is dan niet zo handig.

Ik weet niet precies hoe DAO het nu doet, maar ik denk dat er (onder andere) gekeken wordt naar de huidige prijs tov het daggemiddelde. In plaats van sec de huidige prijs, zou je kunnen zeggen om x-kwartieren ervoor en y-kwartieren erna bij het huidige tarief te betrekken. Indien x en y 0 zijn, gebruik je dan alleen het huidige tarief, maar bij x=1 en y=3 kijk je dan naar het gemiddelde over vijf kwartieren en vergelijk je die met het daggemiddelde.

De demping die nu optreed door de adjustment factor is denk ik niet per se wenselijk, soms zie je ineens scherpe wijziging in de tarieven waardoor het denk ik wel logisch zou zijn om hier krachtig op te reageren. Door middel van de "smoothening" kun je vervolgens hier een eigen draai aan geven.

JSON:

{
....

    "entity adjust heating curve": "input_number.dao_wp_adjust_heating_curve",
    "adjustment factor": 0.12,
    "price smoothening window": [1, 3]
...
}

Ik ga hier nog naar kijken.

[konehead]

appsec schreef op woensdag 21 januari 2026 @ 22:30:
[...]


Dat had ik gemist. Hoe wordt bepaald of die flag wordt gezet? Ik ben zelf toch aan het programmeren geslagen om het probleem beter te begrijpen en ik denk dat ik iets vergelijkbaars doe.

Voor bedrijven werkt het energiecontract vaak anders omdat zij zelf onbalansverantwoordelijkheid kunnen dragen dus dan kan je ook op onbalansprijzen inspelen.


[...]


Deze logica kan zo te zien best complex worden. Mijn omvormers rapporteren maar eens per kwartier dus dat kan ik niet gebruiken voor realtime aansturing.

De Marstek Venus E V3 heeft een NOM modus die zelf probeert nul op de meter te houden op basis van de P1 meter. Mijn huidige idee is om de optimalisatie dynamisch op kwartierbasis de modus (NOM of batterij setpoint) te laten kiezen en het real time aansturing aan de batterij over te laten. Op die manier kan de batterij onverwachte afwijkingen opvangen zodat je bijvoorbeeld niet ineens ongewenst van het net afneemt om je batterij op te laden als er een wolk voorbij komt. Makkelijker gezegt dan gedaan overigens dus ik.moet er nog mee verder prutsen.

Jup, vandaar dat ik op bepaalde punten de bocht heb afgesneden. Wat voor inverters heb je? Ik heb Growatt en sinds ik een eigen Modbus pull interface heb gemaakt krijg ik de data bijna near real time..

[KC27]

Er is een nieuwe testversie gepubliceerd: 2026.01.2.rc1
Dit staat in de changelog:
Correct sensordata from HA with unit_of_measurement="Wh" to "kWh"

Voor gebruikers met unit_of_measurement "Wh" in HA-sensoren is dit goed nieuws.
DAO corrigeert met deze versie nu automatisch naar "kWh".
Dit geldt niet alleen voor de sensoren die nodig zijn voor ml-predictor, maar ook entities in de rapportages en voor de berekening van de baseload (ze maken allemaal gebruik van dezelfde - en nu aangepaste - "ophaalroutine").
Ik zou de gebruikers die om deze functionaliteit gevraagd hebben willen vragen om dit te testen.
Ik hoor graag de resultaten.

[appsec]

konehead schreef op donderdag 22 januari 2026 @ 13:08:
[...]


Jup, vandaar dat ik op bepaalde punten de bocht heb afgesneden. Wat voor inverters heb je? Ik heb Growatt en sinds ik een eigen Modbus pull interface heb gemaakt krijg ik de data bijna near real time..

Ik heb Enphase IQ8+ micro omvormers met een Envoy gatway. De omvormers rapporteren elk eens per kwartier, dus je hebt op elke moment een soort gemiddelde over het laatste kwartier. Voor realtime metingen moet er een losse meter bij komen, maar daar heb ik nog niet echt naar gekeken. Als ik de batterij het grootste deel van de tijd in NOM modus zet dan hoef ik geen real-time metingen van de omvormers te hebben.

[Animal]

KC27 schreef op donderdag 22 januari 2026 @ 11:19:
[...]

Die crash komt waarschijnlijk omdat de ml+predictor in het run-menu in sommige omstandigheden (meer solar-devices en/of trage hardware) meer rekentijd nodig heeft dan de 120 sec grens van de time-out. In dat geval graag proberen met de ml-preditor in de scheduler.

Ik gebruik inmiddels de Lifetimeyield (in kwh) in mijn config maar ik krijg nog steeds deze log:

code:

2026-01-23 01:00:05 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 579, in calc_optimum
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 251, in calc_optimum
    solar_prog = solar_predictor.predict_solar_device(
        self.solar[s], start_hour_dt, end_prog
    )
  File "/root/dao/prog/solar_predictor.py", line 1036, in predict_solar_device
    raise FileNotFoundError(
        f"Er is geen model aanwezig voor {self.solar_name},svp eerst trainen."
    )
FileNotFoundError: Er is geen model aanwezig voor Oost_West,svp eerst trainen.
Er is geen model aanwezig voor Oost_West,svp eerst trainen.
FileNotFoundError: Er is geen model aanwezig voor Oost_West,svp eerst trainen.
Er is geen model aanwezig voor Oost_West,svp eerst trainen.

code:

{
  "homeassistant": { },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21,
      "2025-01-01": 21

    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21,
      "2025-01-01": 21
    },
   "last invoice": "2025-09-01",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.33,
    0.33,
    0.32,
    0.32,
    0.31,
    0.33,
    0.33,
    0.34,
    0.33,
    0.35,
    0.35,
    0.33,
    0.31,
    0.33,
    0.33,
    0.33,
    0.33,
    0.33,
    0.33,
    0.33,
    0.32,
    0.31,
    0.31,
    0.31
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "True",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 8
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
"battery": [
    {
      "name": "Marstek Venus-E 5.12kWh",
      "capacity": 5.12,
      "lower limit": 11,
      "upper limit": 100,
      "optimal lower level": 11,
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 100.0,
          "efficiency": 0.36
        },
        {
          "power": 200.0,
          "efficiency": 0.8221
        },
        {
          "power": 400.0,
          "efficiency": 0.8673
        },
        {
          "power": 600.0,
          "efficiency": 0.8861
        },
        {
          "power": 800.0,
          "efficiency": 0.8975
        },
        {
          "power": 1000.0,
          "efficiency": 0.8933
        },
        {
          "power": 1500.0,
          "efficiency": 0.9015
        },
        {
          "power": 2000.0,
          "efficiency": 0.9010
        },
        {
          "power": 2500.0,
          "efficiency": 0.9017
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 100.0,
          "efficiency": 0.7907
        },
        {
          "power": 200.0,
          "efficiency": 0.8957
        },
        {
          "power": 400.0,
          "efficiency": 0.9581
        },
        {
          "power": 600.0,
          "efficiency": 0.9767
        },
        {
          "power": 800.0,
          "efficiency": 0.9812
        },
        {
          "power": 1000.0,
          "efficiency": 0.9890
        },
        {
          "power": 1500.0,
          "efficiency": 0.9907
        },
        {
          "power": 2000.0,
          "efficiency": 0.9841
        },
        {
          "power": 2500.0,
          "efficiency": 0.9928
        }
      ],
      "reduced hours": {},
      "dc_to_bat max power": 2500.0,
      "bat_to_dc max power": 2500.0,
      "dc_to_bat efficiency": 0.935,
      "bat_to_dc efficiency": 0.935,
      "cycle cost": 0.005,
      "minimum power": 10,
      "entity actual level": "sensor.lilygo_rs485_marstek_battery_state_of_charge",
      "entity set power feedin": "input_number.dao_set_power_feedin",
      "entity set operating mode": "input_select.dao_set_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_marstek",
      "entity balance switch": "input_boolean.dao_balance_grid",
      "entity calculated soc": "input_number.dao_marstek_calculated_soc",
      "solar": []
    }
  ],


  "solar": [
    { "name" : "Oost West",
      "ml_prediction": "true",
      "entities sensors": "sensor.hms_2000_4t_yieldtotal",
      "entity pv switch": "input_boolean.oost_west_turn_inverter_on_off",
      "strings": [
        {
        "tilt": 45,
        "orientation": -135,
        "capacity": 0.43,
        "yield": 0.00091375
        },
        {
        "tilt": 45,
        "orientation": -135,
        "capacity": 0.43,
        "yield": 0.00091375
        },
        {
        "tilt": 45,
        "orientation": 45,
        "capacity": 0.43,
        "yield": 0.00091375
        },
        {
        "tilt": 45,
        "orientation": 45,
        "capacity": 0.43,
        "yield": 0.00091375
        }
      ]
    },
    {
      "name": "Zuid paneel",
      "ml_prediction": "true",
      "entities sensors": "sensor.zuid_paneel_yieldtotal",
      "entity pv switch": "input_boolean.zuid_paneel_on_off",
      "tilt": 60,
      "orientation": -45,
      "capacity": 0.43,
      "yield": 0.00091375
    },
    {
      "name": "Schuine dak",
      "ml_prediction": "true",
      "entities sensors": "sensor.schuine_dak_yieldtotal",
      "entity pv switch": "input_boolean.schuin_dak_on_off",
      "tilt": 45,
      "orientation": 45,
      "capacity": 0.50,
      "yield": 0.0010625
    }
     
  ],
  "electric vehicle": [ ],



  "machines" : [
      { "name": "wasmachine",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "Stand D 40 graden",
           "power": [405, 1782, 398, 158, 142, 123, 104, 253]
           },
          {"name": "Stand A 95 graden",
           "power": [405, 1782, 398, 158, 142, 123, 104, 253]
           }
        ],
        "entity start window": "input_datetime.start_window_wasmachine",
        "entity end window": "input_datetime.end_window_wasmachine",
        "entity selected program": "input_select.program_wasmachine",
        "entity calculated start": "input_datetime.calculated_start_wasmachine",
        "entity calculated end": "input_datetime.calculated_stop_wasmachine"
      },
      { "name": "Droger",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "40 min",
           "power": [1173, 1910, 948]
           },
          {"name": "60 min",
           "power": [1173, 1910, 1910, 948]
           }
        ],
        "entity start window": "input_datetime.start_window_droger",
        "entity end window": "input_datetime.end_window_droger",
        "entity selected program": "input_select.program_droger",
        "entity calculated start": "input_datetime.calculated_start_droger",
        "entity calculated end": "input_datetime.calculated_stop_droger"
      },
      { "name": "vaatwasser",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "70 graden",
           "power": [203, 2000, 62, 49, 0, 0, 0, 0, 1943, 1918, 0, 0]},
          {"name": "eco",
           "power": [203, 2000, 62, 49, 0, 0, 0, 0, 0, 1943, 1918, 0, 0, 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"
      }
  ],



  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.electricity_meter_energieverbruik_tarief_1",
      "sensor.electricity_meter_energieverbruik_tarief_2"
    ],
    "entities grid production": [
      "sensor.electricity_meter_energieproductie_tarief_1",
      "sensor.electricity_meter_energieproductie_tarief_2"
    ],
    "entities solar production ac": [
      "sensor.hms_2000_4t_yieldtotal",
      "sensor.zuid_paneel_yieldtotal",
      "sensor.schuine_dak_yieldtotal"
    ],
    "entities machine consumption": [
      "sensor.0xa4c1382c8e5d5ad5_energy",
      "sensor.0xa4c13863a14fb69f_energy",
      "sensor.0xa4c138ecff011f2e_energy"
    ],
    "entities battery consumption": ["sensor.lilygo_rs485_marstek_total_charging_energy"],
    "entities battery production": ["sensor.lilygo_rs485_marstek_total_discharging_energy"],
    "entity co2-intensity": ["sensor.co2_intensity"]
  },
  "scheduler": {
    "active": "True",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "2240": "train_ml_predictions",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"

  }
}

Daarin heb ik ook een scheduler ingesteld(zoals in de wiki staat) Heb je nog meer informatie nodig?

[ Voor 86% gewijzigd door Animal op 23-01-2026 01:55 ]

[Torch1969]

appsec schreef op donderdag 22 januari 2026 @ 18:46:
[...]

Ik heb Enphase IQ8+ micro omvormers met een Envoy gatway. De omvormers rapporteren elk eens per kwartier, dus je hebt op elke moment een soort gemiddelde over het laatste kwartier. Voor realtime metingen moet er een losse meter bij komen, maar daar heb ik nog niet echt naar gekeken. Als ik de batterij het grootste deel van de tijd in NOM modus zet dan hoef ik geen real-time metingen van de omvormers te hebben.

Er is een manier om Enphase data near realtime binnen te krijgen (zowel zonopwek als p1 (als je een metered gateway hebt)): https://github.com/vk2him/Enphase-Envoy-mqtt-json
Ik draai dit in een docker containertje, maar kan ook als addon in HA.

[Bravo]

Mogelijk interessant voor de mensen die bij Zonneplan zitten en DAO zonder batterij gebruiken, samen met een vriend hebben we de zonnebonus in de tarieven ingebouwd.
Voorwaarde: De zonnebonus van Zonneplan is alleen actief als de zon boven de horizon is, deze formule is altijd actief. Dit is geen probleem als je geen thuisaccu hebt, je teruglevering is dan altijd op de zon momenten.

Tarief incl zonnebonus:

code:

((epex + ZP_opslag) * zonnebonus + energiebelasting) * BTW
((epex + ZP_opslag) * 1,1 + energiebelasting) * 1,21
wordt: 
((epex + ZP_opslag + (energiebelasting/1,1) ) * (1,1 * 1,21)

In DAO vul je dan in:

YAML:

energy taxes production: 0,08328
cost supplier production: 0,0165
VAT: 33,1

Nu de dag- en nachttarieven zo dicht bij elkaar liggen loont het om 's nachts wat meer te verbruiken om overdag tegen een hoger teruglevertarief terug te leveren

[Mirabis]

Bravo schreef op vrijdag 23 januari 2026 @ 08:42:
Mogelijk interessant voor de mensen die bij Zonneplan zitten en DAO zonder batterij gebruiken, samen met een vriend hebben we de zonnebonus in de tarieven ingebouwd.
Voorwaarde: De zonnebonus van Zonneplan is alleen actief als de zon boven de horizon is, deze formule is altijd actief. Dit is geen probleem als je geen thuisaccu hebt, je teruglevering is dan altijd op de zon momenten.

Tarief incl zonnebonus:

code:

((epex + ZP_opslag) * zonnebonus + energiebelasting) * BTW
((epex + ZP_opslag) * 1,1 + energiebelasting) * 1,21
wordt: 
((epex + ZP_opslag + (energiebelasting/1,1) ) * (1,1 * 1,21)

In DAO vul je dan in:

YAML:

energy taxes production: 0,08328
cost supplier production: 0,0165
VAT: 33,1

[Afbeelding]
Nu de dag- en nachttarieven zo dicht bij elkaar liggen loont het om 's nachts wat meer te verbruiken om overdag tegen een hoger teruglevertarief terug te leveren

Dat is niet gelimiteerd tot gebruikers zonder batterij toch? Of heb je al ondervonden dat het problemen met zich meebrengt bij gebruik i.c.m. een batterij? EDIT: Heb blijkbaar het stukje "voorwaarde" over het hoofd gezien.

Ik denk dat in de toekomst een implementatie met optionele "formula": "xxxx" zoals ze dat in EVCC doen het makkelijkst is. Dan is het niet verplicht en de advanced gebruikers kunnen zelf hun formule opstellen om de prijs aan te passen.

[ Voor 10% gewijzigd door Mirabis op 23-01-2026 09:13 ]

[Bravo]

Mirabis schreef op vrijdag 23 januari 2026 @ 09:08:
[...]

Dat is niet gelimiteerd tot gebruikers zonder batterij toch? Of heb je al ondervonden dat het problemen met zich meebrengt bij gebruik i.c.m. een batterij?

Als je een batterij hebt en deze gebruikt om actief terug te leveren, zal DAO een moment kiezen dat het teruglevertarief het hoogste is. Maar op dat moment is de zonnebonus niet van toepassing (want de zon is onder), dus rekent DAO met de verkeerde tarieven.
In het bijgaande voorbeel is het beter om tussen 9.00 en 10.00 terug te leveren incl zonnebonus (0,326), dan voor 9.00 zonder zonnebonus (0,314). In dit geval slechts kruimeltjes, maar ik heb al grotere verschillen voorbij zien komen.

[KC27]

Animal schreef op vrijdag 23 januari 2026 @ 01:39:
[...]

Ik gebruik inmiddels de Lifetimeyield (in kwh) in mijn config maar ik krijg nog steeds deze log:


[...]


[...]


Daarin heb ik ook een scheduler ingesteld(zoals in de wiki staat) Heb je nog meer informatie nodig?

Hij mist de modellen van de training.
In de scheduler staat dat om 22:40 de training gaat draaien /heeft gedraaid. Heb je voor mij de logging van die training?

[Animal]

KC27 schreef op vrijdag 23 januari 2026 @ 09:30:
[...]

Hij mist de modellen van de training.
In de scheduler staat dat om 22:40 de training gaat draaien /heeft gedraaid. Heb je voor mij de logging van die training?

Die tijd is nog niet voorbij gekomen. Ik heb de scheduler weer ingesteld gisteren maar dat was na 22:40. Ik heb de scheduler nu ingesteld op 10:00. Ik kom er straks even op terug
edit: ML data is inmiddels berekend via de scheduler. Ik heb de scheduler inmiddels weer op 22:40 gezet.
Ik gebruik de totalyield(oplopende kWh sensor). Het werkt vooralsnog perfect! Bedankt!

[ Voor 18% gewijzigd door Animal op 23-01-2026 10:03 ]

[appsec]

Torch1969 schreef op vrijdag 23 januari 2026 @ 08:35:
[...]

Er is een manier om Enphase data near realtime binnen te krijgen (zowel zonopwek als p1 (als je een metered gateway hebt)): https://github.com/vk2him/Enphase-Envoy-mqtt-json
Ik draai dit in een docker containertje, maar kan ook als addon in HA.

Ik heb helaas niet de metered gateway. Ik neem aan dat die CT klemmen in de meterkast heeft op de groep waar de zonnepanelen zitten? Dat kan bij mij sowieso niet want ik heb een losse schakelautomaat op zolder zodat de wasmachine op dezelfde groep kon worden aangesloten. Voor real-time metingen zal ik een extra meter op zolder moeten maken.

[DaBit]

Dat zou ik doen, iets van homewizard/shelly/whatever kost ook de wereld niet en integreert lekker met HA.

[Kees Schilder]

Torch1969 schreef op vrijdag 23 januari 2026 @ 08:35:
[...]

Er is een manier om Enphase data near realtime binnen te krijgen (zowel zonopwek als p1 (als je een metered gateway hebt)): https://github.com/vk2him/Enphase-Envoy-mqtt-json
Ik draai dit in een docker containertje, maar kan ook als addon in HA.

Is er een container van? Of moet je die zelf bouwen?
Kan de Docker-container niet vinden namelijk.

[Tommiiee]

Hi,

Ik probeer kennis te maken met DAO. Ik heb zojuist getracht uurprijzen om te zetten naar kwartierprijzen volgens de Wiki op Github, maar ik krijg de melding: "Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken."

Maar ik zie dit terug in de logging, het lijkt erop dat de kwartieren wel goed worden ingelezen:

code:

2026/01/23 13:55:00 stdout      'value': 100.94}]
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 22, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 23, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 103.65},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 22, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 22, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 104.06},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 22, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 22, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 107.25},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 22, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 22, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 109.11},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 21, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 22, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 112.23},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 21, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 21, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 108.11},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 21, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 21, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 111.15},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 21, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 21, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 107.32},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 20, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 21, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 109.74},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 20, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 20, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 111.8},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 20, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 20, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 112.55},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 20, 0, tzinfo=tzutc()),

Wat gaat hier fout?

Edit:

In het Run venster de prijzen van vandaag en morgen opnieuw opgehaald en een nieuwe debug berekening gestart, Ik krijg dan dit:

code:

2026-01-23 14:29:56 info: Day Ahead Optimalisering versie: 2026.01.1
2026-01-23 14:29:56 info: Day Ahead Optimalisering gestart op: 23-01-2026 14:29:56
2026-01-23 14:29:56 info: Day Ahead Optimalisatie gestart: 23-01-2026 14:29:56 taak: calc_optimum_met_debug
2026-01-23 14:29:56 info: Debug = True
2026-01-23 14:29:57 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 571, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 119, in calc_optimum
    prog_data = self.db_da.get_prognose_data(
        start=start_hour, end=None, interval=self.interval
    )
  File "/root/dao/prog/db_manager.py", line 473, in get_prognose_data
    fld_df = interpolate(fld_df, field, False)
  File "/root/dao/prog/utils.py", line 509, in interpolate
    result_df.index = pd.to_datetime(result_df["tijd"])
                                     ~~~~~~~~~^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/frame.py", line 4113, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'tijd'
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4708, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4679, in main
    da_calc.run_task_function("calc_optimum_met_debug")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 571, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 119, in calc_optimum
    prog_data = self.db_da.get_prognose_data(
        start=start_hour, end=None, interval=self.interval
    )
  File "/root/dao/prog/db_manager.py", line 473, in get_prognose_data
    fld_df = interpolate(fld_df, field, False)
  File "/root/dao/prog/utils.py", line 509, in interpolate
    result_df.index = pd.to_datetime(result_df["tijd"])
                                     ~~~~~~~~~^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/frame.py", line 4113, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'tijd'

Ik gebruik versie 2026.01.1

[ Voor 32% gewijzigd door Tommiiee op 23-01-2026 14:31 ]

[jswinkels]

Momenteel gebruik ik EVCC om het laden van mijn elektrische auto's zo efficiënt mogelijk te laten doen. Zowel qua dynamische prijs als qua zonneopbrengst. Tegenwoordig zit ik iets minder op de weg waardoor ik op zoek was om iets langere horizon te gebruiken voor het voorspellen van prijzen en zonneopbrengst. Ik had op ned.nl de zonne energievoorspeller gezien en bedacht dat hier vast ook wel een home assistant integratie voor was. Zodoende kwam ik op de integratie van @Bravo uit en op dit topic en DAO. Inmiddels gebruik ik de voorspelling uit de integratie van @Bravo gecombineerd met de day ahead prijzen om verder vooruit te plannen in EVCC (ik heb daarnaast de api van forecast.solar om ook hier 3 dagen vooruit te kijken) dan 1 tot anderhalve dag. Ik heb inmiddels een auto die meer dan 400km (in de winter) op een lading rijdt en hoef dus niet meer iedere dag te laden thuis. Dan is het wel goed om een indicatie te hebben op welke dag de prijzen hoger of lager zijn.

Is dit mogelijk ook wat voor DAO? Verder vooruit kijken dan vandaag /morgen?

ik ga komend jaar verhuizen en krijg dan ook een warmtepomp en accu. Dit is ook wel te integreren in EVCC, maar zo te zien is de optimalisatie van DAO veel beter. Ik ga me de komende periode hier maar eens wat in verdiepen. In EVCC kan ik mijn laadpaal automatisch laten schakelen naar hoger / lager ampère en 1 of 3 fase op basis van de actuele zonneopbrengst. Zulk soort functionaliteit zit denk ik niet in DAO of wel?

[marten12]

Bravo schreef op vrijdag 23 januari 2026 @ 08:42:
Mogelijk interessant voor de mensen die bij Zonneplan zitten en DAO zonder batterij gebruiken, samen met een vriend hebben we de zonnebonus in de tarieven ingebouwd.

Dank hiervoor, ik was al aan het zoeken of iemand dit 'probleem' al had opgelost. Hoe gaan jullie om met terugleveren boven het salderen?

[DaBit]

jswinkels schreef op vrijdag 23 januari 2026 @ 14:17:
In EVCC kan ik mijn laadpaal automatisch laten schakelen naar hoger / lager ampère en 1 of 3 fase op basis van de actuele zonneopbrengst. Zulk soort functionaliteit zit denk ik niet in DAO of wel?

DAO is de planner, die geeft de wens door aan HA, de uitvoering moet vervolgens in HA geimplementeerd worden. DAO heeft wel notie van 1- en 3-fasen laden, maar kan niet dynamisch wisselen.
Ik heb DAO ingesteld op 1-fase laden met stromen tussen de 6 en 48A. Een stukje NodeRED beslist dan of de gevraagde stroom 1-fase of 3-fase territorium is en stelt de laadpaal als zodanig in. Dus <18A is 1-fase laden met laadstroom = setpoint, 18A of hoger is laadstroom = setpoint/3. NodeRED is niet verplicht; het zal met templates in een HA automatie ook wel prima kunnen.

Het is me afgelopen zomer echter wel opgevallen dat 1-fase laden een beste beperking is voor de rest. Als de electriciteit heel goedkoop of zelfs negatief geprijsd is dan wil je graag richting de 3x25A van het net af trekken om alles waar je energie in kunt stoppen vol te pompen. Boiler, accu, auto, airco/verwarming, etcetera.
Als je dan een auto hebt die 1 fase met 16A extra belast dan gaat het eerder naar 25A voor 1 fase en een Ampere of 10 voor de resterende twee. Dan kan niet meer eenfase-laden en 3x6A als minimum gebruiken een beter idee zijn. Maar jouw situatie is anders dan de mijne, dus die beslissing moet je zelf maken.

[Mirabis]

Tommiiee schreef op vrijdag 23 januari 2026 @ 14:16:
Hi,

Ik probeer kennis te maken met DAO. Ik heb zojuist getracht uurprijzen om te zetten naar kwartierprijzen volgens de Wiki op Github, maar ik krijg de melding: "Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken."

Maar ik zie dit terug in de logging, het lijkt erop dat de kwartieren wel goed worden ingelezen:

code:

2026/01/23 13:55:00 stdout      'value': 100.94}]
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 22, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 23, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 103.65},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 22, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 22, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 104.06},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 22, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 22, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 107.25},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 22, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 22, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 109.11},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 21, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 22, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 112.23},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 21, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 21, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 108.11},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 21, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 21, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 111.15},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 21, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 21, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 107.32},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 20, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 21, 0, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 109.74},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 20, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 20, 45, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 111.8},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 20, 15, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout    { 'end': datetime.datetime(2026, 1, 24, 20, 30, tzinfo=tzutc()),
2026/01/23 13:55:00 stdout      'value': 112.55},
2026/01/23 13:55:00 stdout      'start': datetime.datetime(2026, 1, 24, 20, 0, tzinfo=tzutc()),

Wat gaat hier fout?

Edit:

In het Run venster de prijzen van vandaag en morgen opnieuw opgehaald en een nieuwe debug berekening gestart, Ik krijg dan dit:

code:

2026-01-23 14:29:56 info: Day Ahead Optimalisering versie: 2026.01.1
2026-01-23 14:29:56 info: Day Ahead Optimalisering gestart op: 23-01-2026 14:29:56
2026-01-23 14:29:56 info: Day Ahead Optimalisatie gestart: 23-01-2026 14:29:56 taak: calc_optimum_met_debug
2026-01-23 14:29:56 info: Debug = True
2026-01-23 14:29:57 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 571, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 119, in calc_optimum
    prog_data = self.db_da.get_prognose_data(
        start=start_hour, end=None, interval=self.interval
    )
  File "/root/dao/prog/db_manager.py", line 473, in get_prognose_data
    fld_df = interpolate(fld_df, field, False)
  File "/root/dao/prog/utils.py", line 509, in interpolate
    result_df.index = pd.to_datetime(result_df["tijd"])
                                     ~~~~~~~~~^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/frame.py", line 4113, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'tijd'
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4708, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4679, in main
    da_calc.run_task_function("calc_optimum_met_debug")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 648, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 571, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/day_ahead.py", line 119, in calc_optimum
    prog_data = self.db_da.get_prognose_data(
        start=start_hour, end=None, interval=self.interval
    )
  File "/root/dao/prog/db_manager.py", line 473, in get_prognose_data
    fld_df = interpolate(fld_df, field, False)
  File "/root/dao/prog/utils.py", line 509, in interpolate
    result_df.index = pd.to_datetime(result_df["tijd"])
                                     ~~~~~~~~~^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/frame.py", line 4113, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'tijd'

Ik gebruik versie 2026.01.1

Probeer is de prijzen op te halen van bijv. 3 dagen geleden - tot aan nu/einde dag of morgen. Daarna zou het meer moeten werken

[Tommiiee]

Mirabis schreef op vrijdag 23 januari 2026 @ 14:56:
[...]


Probeer is de prijzen op te halen van bijv. 3 dagen geleden - tot aan nu/einde dag of morgen. Daarna zou het meer moeten werken

Dank voor je suggestie Ik heb de prijzen opgehaald t/m een volledige week terug, vandaag en morgen. Ik krijg helaas nog steeds dezelfde foutmelding.

Edit: na handmatig Meteoprognoses ophalen werkt het weer

[ Voor 7% gewijzigd door Tommiiee op 23-01-2026 15:46 ]

[edterbak]

KC27 schreef op donderdag 22 januari 2026 @ 16:52:
Er is een nieuwe testversie gepubliceerd: 2026.01.2.rc1
Dit staat in de changelog:
Correct sensordata from HA with unit_of_measurement="Wh" to "kWh"

Voor gebruikers met unit_of_measurement "Wh" in HA-sensoren is dit goed nieuws.
DAO corrigeert met deze versie nu automatisch naar "kWh".
Dit geldt niet alleen voor de sensoren die nodig zijn voor ml-predictor, maar ook entities in de rapportages en voor de berekening van de baseload (ze maken allemaal gebruik van dezelfde - en nu aangepaste - "ophaalroutine").
Ik zou de gebruikers die om deze functionaliteit gevraagd hebben willen vragen om dit te testen.
Ik hoor graag de resultaten.

Dank hiervoor.

Ik heb een enphase systeem.
Ik zie in de envoy zelf deze gegevens:
sensor.envoy_121742005031_current_power_production -- in kW
sensor.envoy_121742005031_lifetime_energy_production -- in MWh

In energy tab gebruik ik de onderste, lifetime.
Ter check; Is het de bedoeling dat ik die lifetime sensor inplug voor de ML?

Het lastige vind ik hieraan.
ik heb 1 envoy unit.
hieraan zitten 16 panelen in totaal, maar verdeeld in 2 groepen.
Groep 1 ligt ongunstig, maar heeft wel constant zon
groep 2 ligt nog rukker dan ruk, en heeft namiddag zon only.

De waarde van sensor.envoy_121742005031_lifetime_energy_production is van het geheel.
De ML, hoe duw ik die het handigste in de config, want ik had 2 secties aangemaakt voor solar met 2 verschillende orientaties / tilt etc. .

[ Voor 17% gewijzigd door edterbak op 23-01-2026 16:10 ]