Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[wmc]

Zou in de reports bij productie alle geëxporteerde energie moeten staan? Dus zowel export accu als ook wat door de zonnepanelen wordt opgewekt?

[KC27]

wmc schreef op donderdag 15 januari 2026 @ 19:56:
Zou in de reports bij productie alle geëxporteerde energie moeten staan? Dus zowel export accu als ook wat door de zonnepanelen wordt opgewekt?

Nee, productie is datgene wat je daadwerkelijk hebt teruggeleverd. Als je meer produceert met je accu en je panelen dan al je verbruikers (incl baseload) samen dan ga je het surplus terugleveren via je slimme meter aan het. Dat surplus heet in DAO productie
De export van je accu en de opwekking van je zonnepanelen worden apart gemeten en zie je terug bij Reports/balans.

[Animal]

KC27 schreef op donderdag 15 januari 2026 @ 19:17:
[...]

Bijna altijd is de duurste periode tussen 17:00 en 21:00. Je kunt een window ook over de dagdrempel definiëren. Bijvoorbeeld vanaf 21:00 tot 17:00 uur

[...]

Ik kan hier zo helaas niks over zeggen. Dan heb ik je instellingen en een logging van de berekening nodig (beide graag in tussen quote-tags).

Het maakt mij zelf niet echt uit hoe laat bijvoorbeeld de droger aangaat. Dat mag de komende 24u wel gebeuren. Ik denk dat met meest gebruiksvriendelijke is dat ik kan aangeven dat het de komende 24u mag gebeuren in welk tijdslot dat het voordeligste is. Alleen heb ik het idee dat vanaf 0:00 tot 23:59 niet de beste strategie is.

Welk tijdslot is het handigste tijdslot om in te stellen? (zodat DAO en de meest recente day ahead tijden bekend zijn?

Lastig uit te leggen maar jullie begrijpen wel wat ik bedoel

@KC27 Bijna altijd is de duurste periode tussen 17:00 en 21:00. Je kunt een window ook over de dagdrempel definiëren. Bijvoorbeeld vanaf 21:00 tot 17:00 uur

Er zullen misschien dagen zijn dat ik veel zonne-energie of de day ahead prijs voordelig is dat de machine tussen 17:00 en 21:00 ingepland moet worden. Ik wil eigenlijk een window van de komende 24 of meer aan kunnen geven. Of maak ik een denkfout?

[ Voor 18% gewijzigd door Animal op 16-01-2026 02:33 ]

[Torch1969]

Animal schreef op vrijdag 16 januari 2026 @ 02:31:
[...]

Het maakt mij zelf niet echt uit hoe laat bijvoorbeeld de droger aangaat. Dat mag de komende 24u wel gebeuren. Ik denk dat met meest gebruiksvriendelijke is dat ik kan aangeven dat het de komende 24u mag gebeuren in welk tijdslot dat het voordeligste is. Alleen heb ik het idee dat vanaf 0:00 tot 23:59 niet de beste strategie is.

Welk tijdslot is het handigste tijdslot om in te stellen? (zodat DAO en de meest recente day ahead tijden bekend zijn?

Lastig uit te leggen maar jullie begrijpen wel wat ik bedoel

[...]


Er zullen misschien dagen zijn dat ik veel zonne-energie of de day ahead prijs voordelig is dat de machine tussen 17:00 en 21:00 ingepland moet worden. Ik wil eigenlijk een window van de komende 24 of meer aan kunnen geven. Of maak ik een denkfout?

Als iets lastig is uit te leggen, dan kun je ervan uitgaan dat het ook lastig te programmeren is
“De komende 24 uur” is een glijdende schaal. Op dit moment van schrijven is dit een andere periode dan op het moment dat jij je bericht opstelde. Wat is dan het daadwerkelijke eindpunt? “De komende 24 uur” blijft oneindig doorschuiven en is geen vast gedefinieerde periode.
Wat je waarschijnlijk bedoeld is, de komende 24 uur vanaf nu, waarbij “nu” is het moment dat je die uitspraak doet. Dat kun je in DAO opgeven, voeg dan het datumveld toe en geef echt het moment (datum en tijd) over 24 uur aan waarvoor het apparaat klaar moet zijn.
Nadeel hiervan is, dat als voor een deel van die periode de prijzen nog niet bekend zijn, DAO net zolang wacht met de optimaliseringsberekening voor dat apparaat tot die wel bekend zijn en dan zijn optimalisatie doet. Dus als je pech hebt, heb je de meest optimale periode al gehad.

[diamanten]

Een vraag over de min soc end / lower limit:
ik heb de volgende batterij config:

code:

"battery": [
    {
      "name": "Zinvolt",
      "entity actual level": "sensor.evasoc_dao_waarde",
      "penalty_low_soc": 0.00,
      "capacity": 3,
      "upper limit": 100,
      "lower limit": 15,
      "optimal lower level": 15,
      "entity set operating mode": "input_select.dao_eva_operating_mode",
      "entity set power feedin": "input_number.dao_feedin_grid",
      "entity calculated soc": "input_number.dao_entity_calculated_soc",
      "entity min soc end opt": "input_number.dao_entity_min_soc_end_eva",
      "entity balance switch": "input_boolean.dao_balance_switch_eva",
      "cycle cost": 0.03,
      "dc_to_bat efficiency": 0.95,
      "bat_to_dc efficiency": 0.95,
      "minimum power": 0,
      "charge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 100,
          "efficiency": 0.85
        },
        {
          "power": 200,
          "efficiency": 0.88
        },
        {
          "power": 300,
          "efficiency": 0.90
        },
        {
          "power": 400,
          "efficiency": 0.91
        },
        {
          "power": 1600,
          "efficiency": 0.93
        },
        {
          "power": 2000,
          "efficiency": 0.95
        }
      ],
      "discharge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 100,
          "efficiency": 0.92
        },
        {
          "power": 200,
          "efficiency": 0.93
        },
        {
          "power": 300,
          "efficiency": 0.94
        },
        {
          "power": 400,
          "efficiency": 0.94
        },
        {
          "power": 500,
          "efficiency": 0.95
        },
        {
          "power": 600,
          "efficiency": 0.92
        }
      ],
      "solar": []
    }
  ],

dus lower limit op 15, toch ontlaadt de accu tot net onder de 10%, de waarde die ik op de accu zelf heb ingesteld. Waarom houdt DAO geen rekening met de lower limit? De entity Min Soc end staat ook op 15 ingesteld.

code:

2026-01-16 08:30:00 info: Day Ahead Optimalisering versie: 2025.12.1
2026-01-16 08:30:00 info: Day Ahead Optimalisering gestart op: 16-01-2026 08:30:00
2026-01-16 08:30:00 info: Day Ahead Optimalisatie gestart: 16-01-2026 08:30:00 taak: calc_optimum
2026-01-16 08:30:00 info: Debug = False
2026-01-16 08:30:00 info: Baseload uit instellingen
2026-01-16 08:30:00 info: Start waarden: 
      uur                tijd  spot   p_l   p_t  base  pv_ac  pv_dc
0   08:30 2026-01-16 08:30:00 0.106 0.239 0.128 0.056  0.032      0
1   08:45 2026-01-16 08:45:00 0.105 0.238 0.127 0.058  0.060      0
2   09:00 2026-01-16 09:00:00 0.119 0.255 0.144 0.062  0.092      0
3   09:15 2026-01-16 09:15:00 0.116 0.251 0.141 0.064  0.124      0
4   09:30 2026-01-16 09:30:00 0.112 0.247 0.136 0.066  0.155      0
5   09:45 2026-01-16 09:45:00 0.106 0.239 0.128 0.069  0.184      0
6   10:00 2026-01-16 10:00:00 0.116 0.251 0.140 0.073  0.210      0
7   10:15 2026-01-16 10:15:00 0.104 0.236 0.126 0.077  0.233      0
8   10:30 2026-01-16 10:30:00 0.100 0.231 0.121 0.080  0.253      0
9   10:45 2026-01-16 10:45:00 0.097 0.228 0.118 0.080  0.268      0
10  11:00 2026-01-16 11:00:00 0.095 0.226 0.116 0.079  0.282      0
11  11:15 2026-01-16 11:15:00 0.092 0.222 0.111 0.080  0.289      0
12  11:30 2026-01-16 11:30:00 0.092 0.222 0.111 0.081  0.291      0
13  11:45 2026-01-16 11:45:00 0.095 0.226 0.115 0.080  0.286      0
14  12:00 2026-01-16 12:00:00 0.091 0.221 0.111 0.080  0.272      0
15  12:15 2026-01-16 12:15:00 0.094 0.224 0.114 0.079  0.262      0
16  12:30 2026-01-16 12:30:00 0.096 0.226 0.116 0.078  0.251      0
17  12:45 2026-01-16 12:45:00 0.098 0.229 0.118 0.073  0.243      0
18  13:00 2026-01-16 13:00:00 0.092 0.222 0.111 0.063  0.233      0
19  13:15 2026-01-16 13:15:00 0.094 0.224 0.113 0.058  0.215      0
20  13:30 2026-01-16 13:30:00 0.095 0.226 0.115 0.053  0.190      0
21  13:45 2026-01-16 13:45:00 0.097 0.228 0.117 0.055  0.160      0
22  14:00 2026-01-16 14:00:00 0.093 0.223 0.112 0.063  0.122      0
23  14:15 2026-01-16 14:15:00 0.100 0.231 0.121 0.065  0.069      0
24  14:30 2026-01-16 14:30:00 0.110 0.244 0.133 0.067  0.042      0
25  14:45 2026-01-16 14:45:00 0.125 0.262 0.151 0.064  0.036      0
26  15:00 2026-01-16 15:00:00 0.097 0.228 0.118 0.056  0.026      0
27  15:15 2026-01-16 15:15:00 0.125 0.262 0.151 0.053  0.020      0
28  15:30 2026-01-16 15:30:00 0.135 0.274 0.163 0.050  0.132      0
29  15:45 2026-01-16 15:45:00 0.157 0.301 0.191 0.050  0.095      0
30  16:00 2026-01-16 16:00:00 0.128 0.266 0.155 0.047  0.066      0
31  16:15 2026-01-16 16:15:00 0.145 0.286 0.176 0.047  0.030      0
32  16:30 2026-01-16 16:30:00 0.157 0.300 0.189 0.047  0.000      0
33  16:45 2026-01-16 16:45:00 0.200 0.353 0.242 0.068  0.000      0
34  17:00 2026-01-16 17:00:00 0.156 0.299 0.189 0.114  0.006      0
35  17:15 2026-01-16 17:15:00 0.173 0.320 0.209 0.134  0.001      0
36  17:30 2026-01-16 17:30:00 0.177 0.325 0.214 0.155  0.000      0
37  17:45 2026-01-16 17:45:00 0.162 0.306 0.196 0.137  0.000      0
38  18:00 2026-01-16 18:00:00 0.165 0.310 0.200 0.087  0.000      0
39  18:15 2026-01-16 18:15:00 0.157 0.301 0.190 0.069  0.000      0
40  18:30 2026-01-16 18:30:00 0.163 0.308 0.197 0.052  0.000      0
41  18:45 2026-01-16 18:45:00 0.160 0.304 0.193 0.052  0.000      0
42  19:00 2026-01-16 19:00:00 0.164 0.309 0.198 0.066  0.000      0
43  19:15 2026-01-16 19:15:00 0.153 0.296 0.185 0.066  0.000      0
44  19:30 2026-01-16 19:30:00 0.149 0.291 0.180 0.066  0.000      0
45  19:45 2026-01-16 19:45:00 0.147 0.289 0.178 0.063  0.000      0
46  20:00 2026-01-16 20:00:00 0.141 0.281 0.171 0.059  0.000      0
47  20:15 2026-01-16 20:15:00 0.140 0.280 0.169 0.056  0.000      0
48  20:30 2026-01-16 20:30:00 0.135 0.274 0.164 0.054  0.000      0
49  20:45 2026-01-16 20:45:00 0.116 0.251 0.140 0.052  0.000      0
50  21:00 2026-01-16 21:00:00 0.124 0.261 0.150 0.050  0.000      0
51  21:15 2026-01-16 21:15:00 0.124 0.261 0.150 0.048  0.000      0
52  21:30 2026-01-16 21:30:00 0.115 0.250 0.139 0.046  0.000      0
53  21:45 2026-01-16 21:45:00 0.103 0.236 0.125 0.046  0.000      0
54  22:00 2026-01-16 22:00:00 0.125 0.262 0.151 0.046  0.000      0
55  22:15 2026-01-16 22:15:00 0.115 0.250 0.139 0.045  0.000      0
56  22:30 2026-01-16 22:30:00 0.115 0.250 0.140 0.045  0.000      0
57  22:45 2026-01-16 22:45:00 0.109 0.243 0.132 0.044  0.000      0
58  23:00 2026-01-16 23:00:00 0.119 0.255 0.144 0.042  0.000      0
59  23:15 2026-01-16 23:15:00 0.102 0.234 0.123 0.041  0.000      0
60  23:30 2026-01-16 23:30:00 0.095 0.226 0.115 0.039  0.000      0
61  23:45 2026-01-16 23:45:00 0.094 0.225 0.114 0.038  0.000      0
2026-01-16 08:30:00 info: No reduced hours applied for Zinvolt
2026-01-16 08:30:00 info: Startwaarde SoC Zinvolt: 9.2%

2026-01-16 08:30:00 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2026-01-16 08:30:00 info: Instellingen voor laden van EV: Kia Niro EV
2026-01-16 08:30:00 info: Direct laden is uit
2026-01-16 08:30:00 info:  Ampere  Effic. Grid kW Accu kW
2026-01-16 08:30:00 info:    0.00    1.00    0.00    0.00
2026-01-16 08:30:00 info:   16.00    0.95   11.04   10.49
2026-01-16 08:30:00 info: Capaciteit accu: 55 kWh
2026-01-16 08:30:00 info: Maximaal laadvermogen: 11.04 kW
2026-01-16 08:30:00 info: Klaar met laden op: 27-12-2025 12:00:00
2026-01-16 08:30:00 info: Huidig laadniveau: 27.0 %
2026-01-16 08:30:00 info: Gewenst laadniveau:80.0 %
2026-01-16 08:30:00 info: Marge voor het laden: 2 %
2026-01-16 08:30:00 info: Locatie: home
2026-01-16 08:30:00 info: Ingeplugged:True
2026-01-16 08:30:00 waarschuwing: Er is te weinig tijd om tot 80.0% te laden
2026-01-16 08:30:00 info: Bijgesteld gewenst laadniveau:26.0 %
2026-01-16 08:30:00 info: Benodigde netto energie: 0.000 kWh
2026-01-16 08:30:00 info: Tijd nodig om te laden: 0:0 uur
2026-01-16 08:30:00 info: Afgerond naar hele intervallen: 0 kwartier
2026-01-16 08:30:00 info: Stand laden schakelaar: off
2026-01-16 08:30:00 info: Stand aantal ampere laden: 0.0 A
2026-01-16 08:30:00 info: Opladen wordt niet ingepland, omdat werkelijk niveau (27.0%) hoger is of gelijk aan gewenst niveau (26.0% minus de marge 2%), opgegeven tijdstip (2025-12-27 12:00:00) is verouderd.
2026-01-16 08:30:00 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-01-16 08:30:00 info: Apparaat Airco direct starten staat uit
2026-01-16 08:30:00 info: Machine Airco wordt niet ingepland, want er is gekozen voor Uit
2026-01-16 08:30:00 info: Apparaat Afwasmachine direct starten staat uit
2026-01-16 08:30:00 info: Machine Afwasmachine wordt niet ingepland, want het planning-window ligt voorbij einde optimalisering
2026-01-16 08:30:00 info: Machine Afwasmachine wordt niet ingepland, want er is gekozen voor Uit
2026-01-16 08:30:00 info: Strategie: minimale kosten
2026-01-16 08:30:00 info: Maximale fout (maximal gap): 0.005000 euro
2026-01-16 08:30:10 info: Rekentijd: 9.64  sec
2026-01-16 08:30:10 info: Het programma heeft een optimale oplossing gevonden.
2026-01-16 08:30:10 info: In- en uitgaande energie per kwartier batterij Zinvolt
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 08:30   0.00     --   0.00   0.00   0.00     --   0.00     --   9.20
 08:45   0.00     --   0.00   0.00   0.00     --   0.00     --   9.20
 09:00   0.00     --   0.00   0.00   0.00     --   0.00     --   9.20
 09:15   0.00     --   0.00   0.00   0.00     --   0.00     --   9.20
 09:30   0.00     --   0.00   0.00   0.00     --   0.00     --   9.20
 09:45   0.00     --   0.00   0.00   0.00     --   0.00     --   9.20
 10:00   0.00 107.04   0.00   0.00   0.00  95.42   0.00 102.13   9.20
 10:15   0.16  91.96   0.14   0.00   0.14  95.00   0.14  87.37  13.76
 10:30   0.17  92.13   0.16   0.00   0.16  95.00   0.15  87.52  18.82
 10:45   0.19  92.25   0.17   0.00   0.17  95.00   0.16  87.63  24.30
 11:00   0.20  92.35   0.19   0.00   0.19  95.00   0.18  87.73  30.23
 11:15   0.21  92.39   0.19   0.00   0.19  95.00   0.18  87.77  36.35
 11:30   0.21  92.40   0.19   0.00   0.19  95.00   0.18  87.78  42.50
 11:45   0.21  92.37   0.19   0.00   0.19  95.00   0.18  87.76  48.54
 12:00   0.19  92.28   0.18   0.00   0.18  95.00   0.17  87.67  54.17
 12:15   0.18  92.21   0.17   0.00   0.17  95.00   0.16  87.60  59.52
 12:30   0.17  92.12   0.16   0.00   0.16  95.00   0.15  87.51  64.55
 12:45   0.17  92.09   0.16   0.00   0.16  95.00   0.15  87.49  69.49
 13:00   0.17  92.09   0.16   0.00   0.16  95.00   0.15  87.49  74.43
 13:15   0.16  91.96   0.14   0.00   0.14  95.00   0.14  87.36  78.98
 13:30   0.14  91.71   0.12   0.00   0.12  95.00   0.12  87.12  82.94
 13:45   0.10  91.12   0.10   0.00   0.10  95.00   0.09  86.56  85.96
 14:00   0.06  88.90   0.05   0.00   0.05  95.00   0.05  84.45  87.61
 14:15   0.00     --   0.00   0.00   0.00     --   0.00     --  87.61
 14:30  -0.03  93.00  -0.03   0.00  -0.03  95.00  -0.03  88.35  86.65
 14:45  -0.03  93.00  -0.03   0.00  -0.03  95.00  -0.03  88.35  85.58
 15:00   0.00     --   0.00   0.00   0.00     --   0.00     --  85.58
 15:15  -0.03  93.00  -0.04   0.00  -0.04  95.00  -0.04  88.35  84.32
 15:30   0.00     --   0.00   0.00   0.00     --   0.00     --  84.32
 15:45   0.00     --   0.00   0.00   0.00     --   0.00     --  84.32
 16:00   0.00     --   0.00   0.00   0.00     --   0.00     --  84.32
 16:15  -0.02  92.00  -0.02   0.00  -0.02  95.00  -0.02  87.40  83.67
 16:30  -0.05  94.00  -0.05   0.00  -0.05  95.00  -0.06  89.30  81.81
 16:45  -0.12  95.00  -0.13   0.00  -0.13  95.00  -0.14  90.25  77.19
 17:00  -0.11  95.00  -0.11   0.00  -0.11  95.00  -0.12  90.25  73.22
 17:15  -0.12  95.00  -0.13   0.00  -0.13  95.00  -0.14  90.25  68.60
 17:30  -0.14  92.00  -0.15   0.00  -0.15  95.00  -0.16  87.40  63.34
 17:45  -0.12  95.00  -0.13   0.00  -0.13  95.00  -0.14  90.25  58.72
 18:00  -0.09  94.00  -0.09   0.00  -0.09  95.00  -0.10  89.30  55.48
 18:15  -0.07  94.00  -0.07   0.00  -0.07  95.00  -0.08  89.30  52.89
 18:30  -0.05  94.00  -0.06   0.00  -0.06  95.00  -0.06  89.30  50.95
 18:45  -0.05  94.00  -0.06   0.00  -0.06  95.00  -0.06  89.30  49.02
 19:00  -0.07  94.00  -0.07   0.00  -0.07  95.00  -0.07  89.30  46.57
 19:15  -0.07  94.00  -0.07   0.00  -0.07  95.00  -0.07  89.30  44.12
 19:30  -0.07  94.00  -0.07   0.00  -0.07  95.00  -0.07  89.30  41.67
 19:45  -0.06  94.00  -0.07   0.00  -0.07  95.00  -0.07  89.30  39.31
 20:00  -0.06  94.00  -0.06   0.00  -0.06  95.00  -0.07  89.30  37.13
 20:15  -0.06  94.00  -0.06   0.00  -0.06  95.00  -0.06  89.30  35.03
 20:30  -0.05  94.00  -0.06   0.00  -0.06  95.00  -0.06  89.30  33.03
 20:45  -0.05  94.00  -0.06   0.00  -0.06  95.00  -0.06  89.30  31.10
 21:00  -0.05  94.00  -0.05   0.00  -0.05  95.00  -0.06  89.30  29.23
 21:15  -0.05  93.00  -0.05   0.00  -0.05  95.00  -0.05  88.35  27.42
 21:30  -0.05  93.00  -0.05   0.00  -0.05  95.00  -0.05  88.35  25.67
 21:45  -0.04  93.00  -0.04   0.00  -0.04  95.00  -0.04  88.35  24.31
 22:00  -0.05  93.00  -0.05   0.00  -0.05  95.00  -0.05  88.35  22.58
 22:15  -0.05  93.00  -0.05   0.00  -0.05  95.00  -0.05  88.35  20.86
 22:30  -0.04  93.00  -0.05   0.00  -0.05  95.00  -0.05  88.35  19.17
 22:45  -0.04  93.00  -0.05   0.00  -0.05  95.00  -0.05  88.35  17.52
 23:00  -0.04  93.00  -0.05   0.00  -0.05  95.00  -0.05  88.35  15.94
 23:15  -0.03  93.00  -0.03   0.00  -0.03  95.00  -0.03  88.35  15.00
 23:30  -0.00 100.00  -0.00   0.00  -0.00  95.00  -0.00  95.00  15.00
 23:45   0.00     --   0.00   0.00   0.00     --   0.00     --  15.00
Totaal   0.75     --   0.41   0.00   0.41     --   0.17     --       
2026-01-16 08:30:14 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 08:30    0.00     0.00   0.02   0.00   0.06   0.00   0.00   0.00   0.03   0.01   -0.00  20.00   0.00
 08:45    0.00     0.00   0.00   0.00   0.06   0.00   0.00   0.00   0.06   0.00   -0.00  20.00   0.00
 09:00    0.00     0.00   0.00   0.03   0.06   0.00   0.00   0.00   0.09   0.00   -0.00  20.00   0.00
 09:15    0.00     0.00   0.00   0.06   0.06   0.00   0.00   0.00   0.12   0.00   -0.01  20.00   0.00
 09:30    0.00     0.00   0.00   0.09   0.07   0.00   0.00   0.00   0.15   0.00   -0.01  20.00   0.00
 09:45    0.00     0.00   0.00   0.12   0.07   0.00   0.00   0.00   0.18   0.00   -0.01  20.00   0.00
 10:00    0.00    -0.00   0.00   0.14   0.07   0.00   0.00   0.00   0.21   0.00   -0.02  20.00   0.00
 10:15    0.16     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.23   0.00    0.00  20.00   0.00
 10:30    0.17     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.25   0.00    0.00  20.00   0.00
 10:45    0.19     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.27   0.00    0.00  20.00   0.00
 11:00    0.20     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.28   0.00    0.00  20.00   0.00
 11:15    0.21     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.29   0.00    0.00  20.00   0.00
 11:30    0.21     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.29   0.00    0.00  20.00   0.00
 11:45    0.21     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.29   0.00    0.00  20.00   0.00
 12:00    0.19     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.27   0.00    0.00  20.00   0.00
 12:15    0.18     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.26   0.00    0.00  20.00   0.00
 12:30    0.17     0.00   0.00  -0.00   0.08   0.00   0.00   0.00   0.25   0.00    0.00  20.00   0.00
 12:45    0.17     0.00   0.00  -0.00   0.07   0.00   0.00   0.00   0.24   0.00    0.00  20.00   0.00
 13:00    0.17     0.00   0.00  -0.00   0.06   0.00   0.00   0.00   0.23   0.00    0.00  20.00   0.00
 13:15    0.16     0.00   0.00  -0.00   0.06   0.00   0.00   0.00   0.21   0.00    0.00  20.00   0.00
 13:30    0.14     0.00   0.00  -0.00   0.05   0.00   0.00   0.00   0.19   0.00    0.00  20.00   0.00
 13:45    0.10     0.00   0.00  -0.00   0.06   0.00   0.00   0.00   0.16   0.00    0.00  20.00   0.00
 14:00    0.06     0.00   0.00  -0.00   0.06   0.00   0.00   0.00   0.12   0.00    0.00  20.00   0.00
 14:15    0.00     0.00   0.00   0.00   0.07   0.00   0.00   0.00   0.07   0.00   -0.00  20.00   0.00
 14:30    0.00     0.03   0.00   0.00   0.07   0.00   0.00   0.00   0.04   0.00   -0.00  20.00   0.00
 14:45    0.00     0.03   0.00   0.00   0.06   0.00   0.00   0.00   0.04   0.00   -0.00  20.00   0.00
 15:00    0.00     0.00   0.03   0.00   0.06   0.00   0.00   0.00   0.03   0.01   -0.00  20.00   0.00
 15:15    0.00     0.03   0.00   0.00   0.05   0.00   0.00   0.00   0.02   0.00   -0.00  20.00   0.00
 15:30    0.00     0.00   0.00   0.08   0.05   0.00   0.00   0.00   0.13   0.00   -0.01  20.00   0.00
 15:45    0.00     0.00   0.00   0.05   0.05   0.00   0.00   0.00   0.10   0.00   -0.01  20.00   0.00
 16:00    0.00     0.00   0.00   0.02   0.05   0.00   0.00   0.00   0.07   0.00   -0.00  20.00   0.00
 16:15    0.00     0.02   0.00   0.00   0.05   0.00   0.00   0.00   0.03   0.00   -0.00  20.00   0.00
 16:30    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 16:45    0.00     0.12   0.00   0.06   0.07   0.00   0.00   0.00   0.00   0.00   -0.01  20.00   0.00
 17:00    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.01   0.00   -0.00  20.00   0.00
 17:15    0.00     0.12   0.01   0.00   0.13   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 17:30    0.00     0.14   0.02   0.00   0.15   0.00   0.00   0.00   0.00   0.01   -0.00  20.00   0.00
 17:45    0.00     0.12   0.01   0.00   0.14   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 18:00    0.00     0.09   0.00   0.00   0.09   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 18:15    0.00     0.07   0.00   0.00   0.07   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 18:30    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 18:45    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 19:00    0.00     0.07   0.00   0.00   0.07   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 19:15    0.00     0.07   0.00   0.00   0.07   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 19:30    0.00     0.07   0.00   0.00   0.07   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 19:45    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 20:00    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 20:15    0.00     0.06   0.00   0.00   0.06   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 20:30    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 20:45    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:00    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:15    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:30    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:45    0.00     0.04   0.01   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:00    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:15    0.00     0.05   0.00   0.00   0.05   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:30    0.00     0.04   0.00   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:45    0.00     0.04  -0.00   0.00   0.04   0.00   0.00   0.00   0.00  -0.00   -0.00  20.00   0.00
 23:00    0.00     0.04   0.00   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:15    0.00     0.03   0.02   0.00   0.04   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:30    0.00     0.00   0.04   0.00   0.04   0.00   0.00   0.00   0.00   0.01   -0.00  20.00   0.00
 23:45    0.00     0.00   0.04   0.00   0.04   0.00   0.00   0.00   0.00   0.01   -0.00  20.00   0.00
Totaal    2.69     1.94   0.19   0.64   4.03   0.00   0.00   0.00   5.23   0.05   -0.10          0.00

2026-01-16 08:30:14 info: Consumption               0.19 (kWh)
2026-01-16 08:30:14 info: Cost consumption          0.05 (€)
2026-01-16 08:30:14 info: Tariff consumption        0.246 (€/kWh)
2026-01-16 08:30:14 info: Production                0.64 (kWh)
2026-01-16 08:30:14 info: Profit production        -0.10 (€)
2026-01-16 08:30:14 info: Tariff production         0.154 (€/kWh)

2026-01-16 08:30:14 info: 
Calculation profit after optimize in €
Cost before optimize              0.20
Cost consumption      0.05
Cycle cost            0.14
Penalty cost          0.00
Battery storage      -0.02
Boiler storage        0.00
Profit production    -0.10
Total                 0.06
Cost after optimize               0.06
Profit:                           0.14
2026-01-16 08:30:14 info: Doorzetten van alle settings naar HA
2026-01-16 08:30:14 info: Laden van Kia Niro EV is niet ingepland
2026-01-16 08:30:14 info: Berekeningsuitkomst voor opladen van Kia Niro EV:
2026-01-16 08:30:14 info: - aantal ampere 0A (was 0.0A)
2026-01-16 08:30:14 info: - stand schakelaar 'off' (was 'off')
2026-01-16 08:30:14 info: - positie: home
2026-01-16 08:30:14 info: - ingeplugd: True
2026-01-16 08:30:14 info: Evaluatie status laden Kia Niro EV op 2026-01-16 08:30
2026-01-16 08:30:14 info: - schakelaar laden: off
2026-01-16 08:30:14 info: - aantal ampere: 0.0
2026-01-16 08:30:14 info: Grid set point: 98.0 W
2026-01-16 08:30:14 info: Cycle cost Zinvolt: 0.14 euro
2026-01-16 08:30:14 info: Netto vermogen naar(+)/uit(-) omvormer Zinvolt: 0 W
2026-01-16 08:30:14 info: Balanceren: False
2026-01-16 08:30:14 info: Vermogen uit batterij: 0W
2026-01-16 08:30:14 info: Vermogen dat binnenkomt van pv: 0W
2026-01-16 08:30:14 info: Vermogen dat binnenkomt van ac: 0W
2026-01-16 08:30:14 info: Waarde SoC na eerste uur: 9.2%
2026-01-16 08:30:14 info: Apparaat: Airco
2026-01-16 08:30:14 info: Programma: Uit
2026-01-16 08:30:14 info: Apparaat: Afwasmachine
2026-01-16 08:30:14 info: Programma: Uit

[KC27]

Animal schreef op vrijdag 16 januari 2026 @ 02:31:
[...]

Het maakt mij zelf niet echt uit hoe laat bijvoorbeeld de droger aangaat. Dat mag de komende 24u wel gebeuren. Ik denk dat met meest gebruiksvriendelijke is dat ik kan aangeven dat het de komende 24u mag gebeuren in welk tijdslot dat het voordeligste is. Alleen heb ik het idee dat vanaf 0:00 tot 23:59 niet de beste strategie is.

Welk tijdslot is het handigste tijdslot om in te stellen? (zodat DAO en de meest recente day ahead tijden bekend zijn?

Lastig uit te leggen maar jullie begrijpen wel wat ik bedoel

[...]


Er zullen misschien dagen zijn dat ik veel zonne-energie of de day ahead prijs voordelig is dat de machine tussen 17:00 en 21:00 ingepland moet worden. Ik wil eigenlijk een window van de komende 24 of meer aan kunnen geven. Of maak ik een denkfout?

De meeste gebruikers zijn tevreden met de mogelijkheden van de huidige window-settings. Dus dat ga ik niet aanpassen.
Als jij "de komende 24 uur" wil inplannen dan kan dat m.i. prima worden opgelost met een automation in HA.
Maak een knop boven de window-settings en activeer met een knop een automation die de tijden (start: nu, einde over 23:59 minuten, liefst beide wel afgerond op een heel kwartier) in het window plaatst en start met een restcommando een tussentijds berekening van DAO.

[KC27]

diamanten schreef op vrijdag 16 januari 2026 @ 08:45:
Een vraag over de min soc end / lower limit:
ik heb de volgende batterij config:

[...]
dus lower limit op 15, toch ontlaadt de accu tot net onder de 10%, de waarde die ik op de accu zelf heb ingesteld. Waarom houdt DAO geen rekening met de lower limit? De entity Min Soc end staat ook op 15 ingesteld.

[...]

De berekening start met een start_soc van 9,2 %, onder de "lower limit" van 15%. De vraag is: hoe is hij daar gekomen?
Als de actuele start soc lager is dan het minimum "verlaagt" het programma tijdelijk de lower soc om een "infeasable situation" te voorkomen.

[Animal]

KC27 schreef op vrijdag 16 januari 2026 @ 09:40:
[...]

De meeste gebruikers zijn tevreden met de mogelijkheden van de huidige window-settings. Dus dat ga ik niet aanpassen.
Als jij "de komende 24 uur" wil inplannen dan kan dat m.i. prima worden opgelost met een automation in HA.
Maak een knop boven de window-settings en activeer met een knop een automation die de tijden (start: nu, einde over 23:59 minuten, liefst beide wel afgerond op een heel kwartier) in het window plaatst en start met een restcommando een tussentijds berekening van DAO

Top! Ik ga hier even mee aan de slag!

[Kees Schilder]

Kees Schilder schreef op donderdag 15 januari 2026 @ 16:18:
[...]

Dat is een goede, die is natuurlijk niet meer aanwezig in de database.
Heb ik zojuist gedraaid en zal morgen even terugkoppeling geven.

@KC27 Gaat dit nou goed zo?

[Kees Schilder]

KC27 schreef op woensdag 14 januari 2026 @ 23:27:
Ja je hebt de keuze met de instelling "use_calc_baseload": "True" (of "False")
Als je deze op "True" zet gebruikt hij de berekende baseloads op basis van historische gegevens in HA.
[b]Maar controleer de berekende hoeveelheden goed. Er mogen geen negatieve waarden tussen zitten![/b]

Ik heb vrijwel dagelijks negatieve waarden in de baseload.
Ik heb het vermoeden dat het komt door een vertraagde uitlezing, maar weet niet van welk apparaat.
Hierdoor komt het verbruik van 1 of meerdere apparaten op het volgend uur te staan.
Enig idee wat ik hieraan kan doen?

[Torch1969]

Kees Schilder schreef op vrijdag 16 januari 2026 @ 11:04:
[...]


Ik heb vrijwel dagelijks negatieve waarden in de baseload.
Ik heb het vermoeden dat het komt door een vertraagde uitlezing, maar weet niet van welk apparaat.
Hierdoor komt het verbruik van 1 of meerdere apparaten op het volgend uur te staan.
Enig idee wat ik hieraan kan doen?

[Afbeelding]

Zelf gaan debuggen. Loop al je apparaten langs die je hebt geconfigureerd om energie te rapporteren. Kijk met welk interval ze dat doen. Begin dan vanaf het apparaat met het grootste interval en kijk of die steeds na het hele uur rapporteert over een periode die ook voor het hele uur begint en veel energie gebruikt.
De oplossing is dan het rapporteer interval te verkleinen of zorgen dat het dichter bij het hele uur zit. Dat is nog niet zo eenvoudig, want vaak kun je dat niet beïnvloeden. Soms wel via een instelling of zelf een energiemeter helper te maken of het apparaat in HA te herstarten zodat het rapporteer interval beter aansluit bij hele uur overgang of…..
Ik zelf gebruik hierom niet de automatische baseload maar heb het in de configuratie ingesteld en pas dat zo nu en dan aan op basis van een handmatige baseload berekening.

[KC27]

Kees Schilder schreef op vrijdag 16 januari 2026 @ 10:59:
[...]


@KC27 Gaat dit nou goed zo?

[Afbeelding]

Ziet er prima uit. Bij mij ziet het er net zo uit!

[Kees Schilder]

Torch1969 schreef op vrijdag 16 januari 2026 @ 11:41:
[...]

Zelf gaan debuggen. Loop al je apparaten langs die je hebt geconfigureerd om energie te rapporteren. Kijk met welk interval ze dat doen. Begin dan vanaf het apparaat met het grootste interval en kijk of die steeds na het hele uur rapporteert over een periode die ook voor het hele uur begint en veel energie gebruikt.
De oplossing is dan het rapporteer interval te verkleinen of zorgen dat het dichter bij het hele uur zit. Dat is nog niet zo eenvoudig, want vaak kun je dat niet beïnvloeden. Soms wel via een instelling of zelf een energiemeter helper te maken of het apparaat in HA te herstarten zodat het rapporteer interval beter aansluit bij hele uur overgang of…..
Ik zelf gebruik hierom niet de automatische baseload maar heb het in de configuratie ingesteld en pas dat zo nu en dan aan op basis van een handmatige baseload berekening.

Heb er even naar gekeken, blijkt dat warmtepomp het verbruik zelf wel elke 5 minuten registreert, echter met een interval van 2 uur deelt met de API.
Ter info voor diegene met een Alpha Innotec warmtepomp: https://github.com/BenPru/luxtronik/issues/293

[Mirabis]

Torch1969 schreef op vrijdag 16 januari 2026 @ 11:41:
[...]

Zelf gaan debuggen. Loop al je apparaten langs die je hebt geconfigureerd om energie te rapporteren. Kijk met welk interval ze dat doen. Begin dan vanaf het apparaat met het grootste interval en kijk of die steeds na het hele uur rapporteert over een periode die ook voor het hele uur begint en veel energie gebruikt.
De oplossing is dan het rapporteer interval te verkleinen of zorgen dat het dichter bij het hele uur zit. Dat is nog niet zo eenvoudig, want vaak kun je dat niet beïnvloeden. Soms wel via een instelling of zelf een energiemeter helper te maken of het apparaat in HA te herstarten zodat het rapporteer interval beter aansluit bij hele uur overgang of…..
Ik zelf gebruik hierom niet de automatische baseload maar heb het in de configuratie ingesteld en pas dat zo nu en dan aan op basis van een handmatige baseload berekening.

Thanks, ik heb ook al een tijdje problemen met een negatieve baseload. Dit geeft wat richting aan waar het probleem op te sporen

[KC27]

Animal schreef op vrijdag 16 januari 2026 @ 10:37:
[...]

Top! Ik ga hier even mee aan de slag!

Ik zou wel het start-tijdstip van het window afronden op hele kwartieren naar boven en het eindstip op hele kwartieren naar beneden afronden. DAO kan namelijk bij "machines" beter overweg met hele kwartieren.

[djoenez]

Torch1969 schreef op vrijdag 16 januari 2026 @ 11:41:
[...]

Zelf gaan debuggen. Loop al je apparaten langs die je hebt geconfigureerd om energie te rapporteren. Kijk met welk interval ze dat doen. Begin dan vanaf het apparaat met het grootste interval en kijk of die steeds na het hele uur rapporteert over een periode die ook voor het hele uur begint en veel energie gebruikt.
De oplossing is dan het rapporteer interval te verkleinen of zorgen dat het dichter bij het hele uur zit. Dat is nog niet zo eenvoudig, want vaak kun je dat niet beïnvloeden. Soms wel via een instelling of zelf een energiemeter helper te maken of het apparaat in HA te herstarten zodat het rapporteer interval beter aansluit bij hele uur overgang of…..
Ik zelf gebruik hierom niet de automatische baseload maar heb het in de configuratie ingesteld en pas dat zo nu en dan aan op basis van een handmatige baseload berekening.

Ik zie ook veel negatieve waarden jammer genoeg, al mijn kWh meters lopen op, maar doen dit niet per uur. moet ik voor al die units een Utility meter maken die 1 maal per uur reset?

[Torch1969]

djoenez schreef op vrijdag 16 januari 2026 @ 19:55:
[...]


Ik zie ook veel negatieve waarden jammer genoeg, al mijn kWh meters lopen op, maar doen dit niet per uur. moet ik voor al die units een Utility meter maken die 1 maal per uur reset?

Nee, dat probeer ik niet uit te leggen. De meters kunnen (moeten?) oplopen. Het gaat om het moment dat ze hun stand bijwerken. Een p1 meter is vaak per 5 seconden. Van andere apparaten kan dit soms wel 5 of zelfs 10 minuten zijn. Als de update dan net na het hele uur komt, dan telt het verbruik van die hele periode in dat uur, terwijl het echte verbruik grotendeels in het uur ervoor was. En de p1 meter had wel netjes in het juiste uur gerapporteerd. Daarom lopen deze metingen met elkaar uit de pas.

[Vaevictis_]

Beste tweakers, Ik heb al een tijdje DAO geïnstalleerd maar de grote lap configuratie tekst heeft me al een aantal keer doen besluiten om de configuratie uit te stellen. Zeker in de avond als je toch al moe bent of andere dingen aan je hoofd hebt.

Ik heb dus een TB, tibber en wil op basis van de laagste tarieven de DAO inzetten.
PV, laadpaal en warmtepomp laat ik even buiten beschouwing die komen later wel.

Heb al de tibber en meteo api keys ingevuld en dat werkt. Wat is er nog voor nodig om een berekening te kunnen maken om de tb te laden/ontladen? Ik heb de TB via modbus geintegreed dus als ik een switch of automation kan aanroepen gaat het werken.

Wie helpt me op weg?

[ Voor 4% gewijzigd door Vaevictis_ op 17-01-2026 15:10 ]

[KC27]

Vaevictis_ schreef op zaterdag 17 januari 2026 @ 15:09:
Beste tweakers, Ik heb al een tijdje DAO geïnstalleerd maar de grote lap configuratie tekst heeft me al een aantal keer doen besluiten om de configuratie uit te stellen. Zeker in de avond als je toch al moe bent of andere dingen aan je hoofd hebt.

Ik heb dus een TB, tibber en wil op basis van de laagste tarieven de DAO inzetten.
PV, laadpaal en warmtepomp laat ik even buiten beschouwing die komen later wel.

Heb al de tibber en meteo api keys ingevuld en dat werkt. Wat is er nog voor nodig om een berekening te kunnen maken om de tb te laden/ontladen? Ik heb de TB via modbus geintegreed dus als ik een switch of automation kan aanroepen gaat het werken.

Wie helpt me op weg?

Sorry voor mijn onwetendheid maar wat is een TB?

[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..