• The Source
  • Registratie: April 2000
  • Laatst online: 12-09 19:55
Ik heb Claude Pro (kan ook gratis) via HA-MCP verbonden aan HA, damn erg handig. Pas dit aan, doe dat, het kan het allemaal. Helaas krijg ik steeds minder zicht op hoe het werkt, maar het kan wel alles verwezenlijken wat in mijn hoofd zat, maar mij weken/maanden zou kosten om te maken.

Ik log al jaren alle data in Influx en hier kan Claude ook enorm veel details mee uitrekenen, zoals de COP van mijn warmtepomp en de COP-buckets bepalen, maar bv ook het warmteverlies van de woning.

Helaas kan Claude niet bij de DAO-config, dus dit gedeelte is nog copy/paste. (hint) .

DAO kon vanmiddag geen prijzen ophalen en de auto kon niet ingepland worden. Door logfiles te voeden, zijn een boel dingen opgelost en het lag aan de core-update die ik uitgevoerd had. Vandaag tijd (en zon) gehad om mijn laadpaal te checken en alles een beetje af te stemmen. Nou ja... ik keek, Claude deed het werk.

[ Voor 18% gewijzigd door The Source op 23-08-2026 19:41 ]


  • Tvdl2000
  • Registratie: April 2013
  • Laatst online: 01:30
ben begonnen hoor. maar vrij snel kom ik al in de fout, terwijl ik nog maar weinig heb gedaan. ik voel me echt erg noob nu.
2026-08-23 20:57:07 INFO: Loaded 6 secrets from ../data/secrets.json
2026-08-23 20:57:07 INFO: Validating configuration with ConfigurationV2
2026-08-23 20:57:08 info: Day Ahead Optimalisering versie: 2026.6.0
2026-08-23 20:57:08 info: Day Ahead Optimalisering gestart op: 23-08-2026 20:57:08
2026-08-23 20:57:08 info: Day Ahead Optimalisatie gestart: 23-08-2026 20:57:08 taak: get_day_ahead_prices
2026-08-23 20:57:08 fout: 401 Client Error: Unauthorized for url: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~https://dataportal-api.no...nMinutes=15&indexNames=NL~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Traceback (most recent call last):
File "/root/dao/lib/da_prices.py", line 118, in get_prices
act_spot_prices = prices_spot.fetch(
areas=[self.country], end_date=end_date, resolution=resolution
)
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/nordpool/elspot.py", line 242, in fetch
return self._fetch_json(data_type, end_date, areas, resolution)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/nordpool/elspot.py", line 209, in _fetch_json
response.raise_for_status()
~~~~~~~~~~~~~~~~~~~~~~~~~^^
File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/requests/models.py", line 1167, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 401 Client Error: Unauthorized for url: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~https://dataportal-api.no...nMinutes=15&indexNames=NL~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2026-08-23 20:57:08 fout: Geen data van Nordpool: tussen 2025-01-01 00:00:00 en 2025-01-03 00:00:00
en dit is wat ik heb in de config
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
{
  "config_version": 2,
  "homeassistant": {
    "ip_address": "supervisor",
    "protocol_api": "http"
  },
  "database_ha": {
    "engine": "sqlite",
    "db_path": "/homeassistant",
    "database": "home-assistant_v2.db"
  },
  "database_da": {
    "engine": "sqlite",
    "db_path": "../data",
    "database": "day_ahead.db"
  },
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "energy_taxes_consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161
    },
    "energy_taxes_production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161
    },
    "cost_supplier_consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.01652893
    },
    "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.01652893
    },
    "vat_consumption": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0
    },
    "vat_production": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0
    },
    "multiplier_consumption": {
      "2000-01-01": 1.0
    },
    "multiplier_production": {
      "2000-01-01": 1.0
    },
    "last_invoice": "2025-09-01",
    "tax_refund": true,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },
  "logging_level": "info",
  "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",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": false,
    "prices_spot": true,
    "average_consumption": true,
    "show": "true"
  },
  "interval": "15min",
  "strategy": "minimize cost",
  "max_gap": 0.005,
  "notifications": {
    "opstarten": false,
    "berekening": false
  },
  "grid": {
    "max_power": 17.0
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [],
  "solar": [],
  "electric_vehicle": [],
  "machines": [],
  "boiler": {
    "boiler_present": false,
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater_present": false,
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "tibber": {
    "api_token": "!secret tibber_api_token",
    "api_url": "https://api.tibber.com/v1-beta/gql"
  },
  "xgboost": {
    "tune_hyperparameters": true
  },
  "report": {
    "entities_grid_consumption": [
      "sensor.grid_consumption_low",
      "sensor.grid_consumption_high"
    ],
    "entities_grid_production": [
      "sensor.grid_production_low",
      "sensor.grid_production_high"
    ],
    "entities_solar_production_ac": [
      "sensor.solaredge_woning_ac_energy_kwh"
    ],
    "entities_solar_production_dc": [],
    "entities_ev_consumption": [
      "sensor.laadpunt_total_energy"
    ],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.ess_grid_consumption"
    ],
    "entities_battery_production": [
      "sensor.ess_grid_production"
    ],
    "entities_machine_consumption": []
  },
  "scheduler": {
    "active": false,
    "schedule": [
      {
        "time": "0430",
        "action": "get_meteo_data"
      },
      {
        "time": "1030",
        "action": "get_meteo_data"
      },
      {
        "time": "1630",
        "action": "get_meteo_data"
      },
      {
        "time": "2230",
        "action": "get_meteo_data"
      },
      {
        "time": "1255",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1355",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1455",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1554",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1655",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "xx00",
        "action": "calc_optimum"
      },
      {
        "time": "2359",
        "action": "clean_data"
      }
    ]
  },
  "meteoserver_attempts": 2
}
Qua devices e.d.
zonneplan, kwartierprijzen,
hanchu ESS thuis accu 21.4KWH op een hybride omvormer (ook Hanchu ESS) waar geen panelen aan zitten en 20 van de 24 zonnepanelen meet
Hoymiles DTU met 24 panelen
Polestar 2 Long range Dual motor
geen warmtepomp
shelly thermostaat en regeling van de CV
paar airco's die ook kunnen verwarmen

[ Voor 6% gewijzigd door Tvdl2000 op 23-08-2026 21:38 ]


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
Tvdl2000 schreef op zondag 23 augustus 2026 @ 21:07:
ben begonnen hoor. maar vrij snel kom ik al in de fout, terwijl ik nog maar weinig heb gedaan. ik voel me echt erg noob nu.


[...]


en dit is wat ik heb in de config


[...]


Qua devices e.d.
zonneplan, kwartierprijzen,
hanchu ESS thuis accu 21.4KWH op een hybride omvormer (ook Hanchu ESS) waar geen panelen aan zitten en 20 van de 24 zonnepanelen meet
Hoymiles DTU met 24 panelen
Polestar 2 Long range Dual motor
geen warmtepomp
shelly thermostaat en regeling van de CV
paar airco's die ook kunnen verwarmen
Zo te zien is dit de eerste keer dat je probeert om de day ahead prijzen bij Nordpool op te halen.
De laatste foutmelding geeft een redelijke hint: 2026-08-23 20:57:08 fout: Geen data van Nordpool: tussen 2025-01-01 00:00:00 en 2025-01-03 00:00:00

Bij de allereerste keer moet je, voordat je het vinkje zet, even de datum van vandaag en morgen invullen:
Afbeeldingslocatie: https://tweakers.net/i/vVy82UmDSTGXqfacaIqbF8qrk1I=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/B1gdjyWM3iwJP0889OQcPqxY.png?f=user_large
Hopelijk kom je dan een stapje verder.

  • konehead
  • Registratie: Januari 2005
  • Laatst online: 13:43
Strategie post-saldering: zelfconsumptie + dagelijks batterijoverschot dumpen op EPEX — hoe configureer ik DAO optimaal?

Hallo allemaal,

Met het aflopen van de salderingsregeling per 1 januari 2027 ga ik mijn DAO-setup grondig herzien. Ik wil graag toetsen of mijn redenering klopt en hoe ik dit optimaal in DAO configureer — en of jullie nog andere of betere benaderingen kennen.

Mijn setup
  • Growatt MIN 4600TL-XH hybride omvormer
  • Growatt ARK batterij, 12,8 kWh bruikbare capaciteit
  • 12 zonnepanelen south-facing (30° / 175°), uitbreiding met 10 west-facing panelen (49° / 251°) in planning
  • Zonneplan dynamisch contract (kwartier-EPEX-pricing)
  • ESPHome/Modbus integratie voor directe Growatt-sturing
  • DAO draait als HA addon, kwartier-interval, strategie: "minimize cost"
De nieuwe economische realiteit post-saldering

Zonder saldering is de spread tussen inkopen en terugleveren bij Zonneplan fors:
  • Inkoop = EPEX kwartierprijs + markup + energiebelasting + BTW
  • Teruglevering = EPEX kwartierprijs − €0,019/kWh
Zelfconsumptie levert daarmee structureel meer op dan terugleveren. Maar batterij-naar-net heeft bij voldoende EPEX-piek wél waarde, zeker als die capaciteit anders 's nachts onbenut blijft.

Mijn gewenste dagelijkse strategie

Een typische zomerdag ziet er bij mij zo uit:
  • ~18:00: batterij staat op 100% dankzij dagproductie
  • 18:00 → 10:00: eigen nachtverbruik ≈ 3 kWh
  • Restcapaciteit: ~9,5 kWh (na efficiency-verlies) die ik wil terugleveren op de duurste EPEX-uren in dat venster
  • ~10:00: batterij zo leeg mogelijk, klaar om dagsolar te absorberen
De gedachte: zolang ik toch niet kan zelfconsumeren (ik slaap), kan ik het overschot beter op een EPEX-piek dumpen dan het tot de volgende dag vasthouden. Ik wil absoluut met een lege batterij de dag beginnen zodat alle zonne-energie direct benut of opgeslagen wordt (zodat ik minimaal hoef terug te leveren)

Hoe ik dit wil implementeren in DAO

Post-saldering stel ik tax_refund in op false — teruglevering wordt niet meer verrekend met energiebelasting.

Het lastigste stuk is het dynamisch aansturen van de min_soc. Mijn gedachte:
  • 18:00: input_number.min_soc → 25% (~3,2 kWh buffer voor nachtverbruik)
  • 07:00: input_number.min_soc → 5% — DAO mag de rest dumpen op de beste EPEX-uren
  • 10:00 (of zonsopgang): min_soc terug naar dagwaarde
DAO herberekent elk kwartier, dus na de wijziging om 07:00 verdeelt hij het resterende overschot optimaal over de duurste ochtenduren (07:00–10:00 is vaak een EPEX-piek).

Mijn vragen

1. Klopt deze redenering? Is "minimize cost" met bovenstaande aanpak de juiste strategie voor post-saldering, of zijn er betere benaderingen?

2. Ondersteunt DAO natively een "target SOC op tijdstip X"? Bijv. "zorg dat ik om 10:00 op 5% zit" — zonder dat ik handmatig via een HA-automatisering min_soc moet omzetten?

3. Ziet iemand een probleem met deze aanpak op korte winterdagen? Dan heb ik minder solar en wil ik de batterij misschien juist meer reserveren voor zelfconsumptie in plaats van exporteren.

4. Zijn er DAO-gebruikers die dit "elke ochtend leeg beginnen"-principe al draaien? Hoe hebben jullie dit ingericht?

5. overdag laden van EV: Batterij op neutraal, iig niet ontladen.

Zit ik met bovenstaande in de goede richting of zijn er andere implementaties mogelijk?

Alvast bedankt voor het meedenken!

  • pimNH
  • Registratie: Mei 2011
  • Laatst online: 09:16
Als je nachtverbruik klopt zou DAO hier zelf al rekening mee moeten houden, en dan zelfs op de hogere piek in de avond de meeste stroom verkopen. Mocht je wat zekerder willen zijn van genoeg stroom voor de nacht zou je je nachtverbruik ook wat hoger kunnen zetten.

  • Torch1969
  • Registratie: Juni 2013
  • Laatst online: 09:26
konehead schreef op maandag 24 augustus 2026 @ 22:27:
Strategie post-saldering: zelfconsumptie + dagelijks batterijoverschot dumpen op EPEX — hoe configureer ik DAO optimaal?

Hallo allemaal,

Met het aflopen van de salderingsregeling per 1 januari 2027 ga ik mijn DAO-setup grondig herzien. Ik wil graag toetsen of mijn redenering klopt en hoe ik dit optimaal in DAO configureer — en of jullie nog andere of betere benaderingen kennen.

Mijn setup
  • Growatt MIN 4600TL-XH hybride omvormer
  • Growatt ARK batterij, 12,8 kWh bruikbare capaciteit
  • 12 zonnepanelen south-facing (30° / 175°), uitbreiding met 10 west-facing panelen (49° / 251°) in planning
  • Zonneplan dynamisch contract (kwartier-EPEX-pricing)
  • ESPHome/Modbus integratie voor directe Growatt-sturing
  • DAO draait als HA addon, kwartier-interval, strategie: "minimize cost"
De nieuwe economische realiteit post-saldering

Zonder saldering is de spread tussen inkopen en terugleveren bij Zonneplan fors:
  • Inkoop = EPEX kwartierprijs + markup + energiebelasting + BTW
  • Teruglevering = EPEX kwartierprijs − €0,019/kWh
Zelfconsumptie levert daarmee structureel meer op dan terugleveren. Maar batterij-naar-net heeft bij voldoende EPEX-piek wél waarde, zeker als die capaciteit anders 's nachts onbenut blijft.

Mijn gewenste dagelijkse strategie

Een typische zomerdag ziet er bij mij zo uit:
  • ~18:00: batterij staat op 100% dankzij dagproductie
  • 18:00 → 10:00: eigen nachtverbruik ≈ 3 kWh
  • Restcapaciteit: ~9,5 kWh (na efficiency-verlies) die ik wil terugleveren op de duurste EPEX-uren in dat venster
  • ~10:00: batterij zo leeg mogelijk, klaar om dagsolar te absorberen
De gedachte: zolang ik toch niet kan zelfconsumeren (ik slaap), kan ik het overschot beter op een EPEX-piek dumpen dan het tot de volgende dag vasthouden. Ik wil absoluut met een lege batterij de dag beginnen zodat alle zonne-energie direct benut of opgeslagen wordt (zodat ik minimaal hoef terug te leveren)

Hoe ik dit wil implementeren in DAO

Post-saldering stel ik tax_refund in op false — teruglevering wordt niet meer verrekend met energiebelasting.

Het lastigste stuk is het dynamisch aansturen van de min_soc. Mijn gedachte:
  • 18:00: input_number.min_soc → 25% (~3,2 kWh buffer voor nachtverbruik)
  • 07:00: input_number.min_soc → 5% — DAO mag de rest dumpen op de beste EPEX-uren
  • 10:00 (of zonsopgang): min_soc terug naar dagwaarde
DAO herberekent elk kwartier, dus na de wijziging om 07:00 verdeelt hij het resterende overschot optimaal over de duurste ochtenduren (07:00–10:00 is vaak een EPEX-piek).

Mijn vragen

1. Klopt deze redenering? Is "minimize cost" met bovenstaande aanpak de juiste strategie voor post-saldering, of zijn er betere benaderingen?

2. Ondersteunt DAO natively een "target SOC op tijdstip X"? Bijv. "zorg dat ik om 10:00 op 5% zit" — zonder dat ik handmatig via een HA-automatisering min_soc moet omzetten?

3. Ziet iemand een probleem met deze aanpak op korte winterdagen? Dan heb ik minder solar en wil ik de batterij misschien juist meer reserveren voor zelfconsumptie in plaats van exporteren.

4. Zijn er DAO-gebruikers die dit "elke ochtend leeg beginnen"-principe al draaien? Hoe hebben jullie dit ingericht?

5. overdag laden van EV: Batterij op neutraal, iig niet ontladen.

Zit ik met bovenstaande in de goede richting of zijn er andere implementaties mogelijk?

Alvast bedankt voor het meedenken!
Korte reactie op je teruglever prijs bij zonneplan. Ik heb nagevraagd en ook de btw krijg je (bij zonneplan) terug. Daarnaast krijg je bij zonneplan ook de markup terug. Dus terugleverprijs is epexkwartierprijs + markup + btw. En officieel moet je daar ook de zonnebonus nog bij optelllen (maar dat kunnen we nog niet configureren in DAO).

Ik zou zelf niet teveel dynamisch aan knoppen zitten draaien, maar het (optimalisatie) rekenwerk echt aan DAO over laten. Als het voordeliger is om wat in de batterij te laten zitten, dan is dat maar zo. Maar ik begrijp ook wel weer dat je nog wat slimmer wilt zijn dan de opties nu bieden.

  • TheMystery
  • Registratie: Februari 2004
  • Laatst online: 13:04
konehead schreef op maandag 24 augustus 2026 @ 22:27:
Strategie post-saldering: zelfconsumptie + dagelijks batterijoverschot dumpen op EPEX — hoe configureer ik DAO optimaal?

Hallo allemaal,

Met het aflopen van de salderingsregeling per 1 januari 2027 ga ik mijn DAO-setup grondig herzien. Ik wil graag toetsen of mijn redenering klopt en hoe ik dit optimaal in DAO configureer — en of jullie nog andere of betere benaderingen kennen.

Mijn setup
  • Growatt MIN 4600TL-XH hybride omvormer
  • Growatt ARK batterij, 12,8 kWh bruikbare capaciteit
  • 12 zonnepanelen south-facing (30° / 175°), uitbreiding met 10 west-facing panelen (49° / 251°) in planning
  • Zonneplan dynamisch contract (kwartier-EPEX-pricing)
  • ESPHome/Modbus integratie voor directe Growatt-sturing
  • DAO draait als HA addon, kwartier-interval, strategie: "minimize cost"
De nieuwe economische realiteit post-saldering

Zonder saldering is de spread tussen inkopen en terugleveren bij Zonneplan fors:
  • Inkoop = EPEX kwartierprijs + markup + energiebelasting + BTW
  • Teruglevering = EPEX kwartierprijs − €0,019/kWh
Zelfconsumptie levert daarmee structureel meer op dan terugleveren. Maar batterij-naar-net heeft bij voldoende EPEX-piek wél waarde, zeker als die capaciteit anders 's nachts onbenut blijft.

Mijn gewenste dagelijkse strategie

Een typische zomerdag ziet er bij mij zo uit:
  • ~18:00: batterij staat op 100% dankzij dagproductie
  • 18:00 → 10:00: eigen nachtverbruik ≈ 3 kWh
  • Restcapaciteit: ~9,5 kWh (na efficiency-verlies) die ik wil terugleveren op de duurste EPEX-uren in dat venster
  • ~10:00: batterij zo leeg mogelijk, klaar om dagsolar te absorberen
De gedachte: zolang ik toch niet kan zelfconsumeren (ik slaap), kan ik het overschot beter op een EPEX-piek dumpen dan het tot de volgende dag vasthouden. Ik wil absoluut met een lege batterij de dag beginnen zodat alle zonne-energie direct benut of opgeslagen wordt (zodat ik minimaal hoef terug te leveren)

Hoe ik dit wil implementeren in DAO

Post-saldering stel ik tax_refund in op false — teruglevering wordt niet meer verrekend met energiebelasting.

Het lastigste stuk is het dynamisch aansturen van de min_soc. Mijn gedachte:
  • 18:00: input_number.min_soc → 25% (~3,2 kWh buffer voor nachtverbruik)
  • 07:00: input_number.min_soc → 5% — DAO mag de rest dumpen op de beste EPEX-uren
  • 10:00 (of zonsopgang): min_soc terug naar dagwaarde
DAO herberekent elk kwartier, dus na de wijziging om 07:00 verdeelt hij het resterende overschot optimaal over de duurste ochtenduren (07:00–10:00 is vaak een EPEX-piek).

Mijn vragen

1. Klopt deze redenering? Is "minimize cost" met bovenstaande aanpak de juiste strategie voor post-saldering, of zijn er betere benaderingen?

2. Ondersteunt DAO natively een "target SOC op tijdstip X"? Bijv. "zorg dat ik om 10:00 op 5% zit" — zonder dat ik handmatig via een HA-automatisering min_soc moet omzetten?

3. Ziet iemand een probleem met deze aanpak op korte winterdagen? Dan heb ik minder solar en wil ik de batterij misschien juist meer reserveren voor zelfconsumptie in plaats van exporteren.

4. Zijn er DAO-gebruikers die dit "elke ochtend leeg beginnen"-principe al draaien? Hoe hebben jullie dit ingericht?

5. overdag laden van EV: Batterij op neutraal, iig niet ontladen.

Zit ik met bovenstaande in de goede richting of zijn er andere implementaties mogelijk?

Alvast bedankt voor het meedenken!
Zou minimize consumption dan niet beter zijn? Want dan doet ie meer aan zelfconsumptie. Ik gebruik nu ook minimize cost maar in de nacht gebruikt hij altijd het net maar als je geen energiebelasting terug krijgt wordt het misschien anders berekend.

  • thewhi
  • Registratie: April 2021
  • Laatst online: 12-09 23:08
Torch1969 schreef op dinsdag 25 augustus 2026 @ 07:25:
[...]

Korte reactie op je teruglever prijs bij zonneplan. Ik heb nagevraagd en ook de btw krijg je (bij zonneplan) terug. Daarnaast krijg je bij zonneplan ook de markup terug. Dus terugleverprijs is epexkwartierprijs + markup + btw. En officieel moet je daar ook de zonnebonus nog bij optelllen (maar dat kunnen we nog niet configureren in DAO).

Ik zou zelf niet teveel dynamisch aan knoppen zitten draaien, maar het (optimalisatie) rekenwerk echt aan DAO over laten. Als het voordeliger is om wat in de batterij te laten zitten, dan is dat maar zo. Maar ik begrijp ook wel weer dat je nog wat slimmer wilt zijn dan de opties nu bieden.
Heb je contact gehad met iemand bij Zonneplan zelf? Want ben benieuwd hoe lang ze die BTW teruggaaf volhouden en of dat feitelijk wel mag. Want dat is een overheidsbelasting...BTW zouden ze hooguit mogen compenseren, maar niet teruggeven,

  • Torch1969
  • Registratie: Juni 2013
  • Laatst online: 09:26
thewhi schreef op dinsdag 25 augustus 2026 @ 09:17:
[...]


Heb je contact gehad met iemand bij Zonneplan zelf? Want ben benieuwd hoe lang ze die BTW teruggaaf volhouden en of dat feitelijk wel mag. Want dat is een overheidsbelasting...BTW zouden ze hooguit mogen compenseren, maar niet teruggeven,
Ja, tot 2 keer aan toe zelfs. Ik heb dezelfde verbazing, omdat leveranciers hier dus verschillend mee om lijken te gaan vanaf 1-1-2027. Zonneplan stelt duidelijk dat alleen het verrekenen van de energiebelasting (en daarmee uiteraard de btw over de energie belasting) vervalt, maar de btw over de kale prijs en vaste vergoeding krijg je terug. Misschien goed om dit specifieke onderwerp in het daarvoor bestemde topic voort te zetten? (Het grote day ahead / dynamische energieprijzen topic.)

[ Voor 7% gewijzigd door Torch1969 op 25-08-2026 12:52 ]


  • konehead
  • Registratie: Januari 2005
  • Laatst online: 13:43
Torch1969 schreef op dinsdag 25 augustus 2026 @ 07:25:
[...]

Korte reactie op je teruglever prijs bij zonneplan. Ik heb nagevraagd en ook de btw krijg je (bij zonneplan) terug. Daarnaast krijg je bij zonneplan ook de markup terug. Dus terugleverprijs is epexkwartierprijs + markup + btw. En officieel moet je daar ook de zonnebonus nog bij optelllen (maar dat kunnen we nog niet configureren in DAO).

Ik zou zelf niet teveel dynamisch aan knoppen zitten draaien, maar het (optimalisatie) rekenwerk echt aan DAO over laten. Als het voordeliger is om wat in de batterij te laten zitten, dan is dat maar zo. Maar ik begrijp ook wel weer dat je nog wat slimmer wilt zijn dan de opties nu bieden.
Interessant, ik had de markup en btw niet verwacht, nuttige info. Ik heb zeker niet de ambitie om DAO te outperformen maar ben wel benieuwd hoe DAO straks omgaat met zoveel mogelijk zelf verbruiken. In mijn automatisering heb ik nu laden en ontladen en bereken 1x per 15 minuten of ik dit moet bijstellen. Straks wil de load balancer van de batterij aanzetten als ik op zelfconsumptie modus draai en laden (extreem lage prijzen) en ontladen exporteren naar het het. Die load balancer zit nu niet in mijn automatisering..

  • Isdatzo
  • Registratie: November 2005
  • Laatst online: 09:19
Er verandert wat aan de tariefstructuur vanaf 1 januari, daar hoeft DAO niet voor worden aangepast maar slechts de tariefstructuur zoals je die in DOA gedefinieerd hebt.

Vervolgens berekent DAO netjes de optimalisering in de nieuwe omstandigheden.

[ Voor 20% gewijzigd door Isdatzo op 25-08-2026 22:25 ]

Er is een een nieuwe test-release (versie 2026.8.0.rc7) gepubliceerd, maar die blijkt niet te kunnen rekenen.
Dus: deze NIET installeren!
Graag nog even geduld.

[ Voor 8% gewijzigd door KC27 op 26-08-2026 00:33 ]

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

Nu is er wel een goed werkende nieuw test-release: versie 2026.8.0.rc8.

Breaking change
Users with a seperate container (no HA app/addon)change your pull command:
`docker pull ghcr.io/corneel27/dao:testing`

Other changes
  • Update workflows for (test)build images, packages are now oci-compliant
  • Update several python modules
  • Add `battery_next_action` output for standby/sleep automation
  • Route CBC's native solver output into the logger
Korte toelichting:
De bouw van nieuwe packages is geupdate naar de laatste home-assistant builder versie. Hiermee is DAO ook OCI-compliant geworden. Werk je met een eigen container (buiten HA om)dan moet je waarschijnlijk je pull request aanpassen. Je mag geen processor architectuur opgeven, Dit wordt afgehandeld door Docker in combinatie met een manifest op de ghcr-server.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

Nu is ook een nieuwe stabiele versie gepubliceerd: 2026.8.0.
Deze is functioneel identiek aan 2026.8.0.rc8.

Dit staat in de changelog:
Breaking change
Users with a seperate container (no HA app/addon)change your pull command:
code:
1
docker pull ghcr.io/corneel27/dao:latest
This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface.
  2. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  3. @Dogooder has investigated and improved the mip-calculation of the ev-model of DAO. He also have build a test-suite for the ev-module under certain stress-circumstances.
I thank both contributors for their great efforts!!

The other changes in this release:
  • update workflows for (test)build images, packages are now oci-compliant
  • when "stop_inverter" is not configured the calculated bat-power is now spread out over the hole interval.
  • correct stop_omvormer when feedin > 0.0 (suggested by @Dogooder )
  • correct index error with reduce_power_low_soc and reduce_power_high_soc
  • added multithread so it uses all available cores during mip-calculation (thanks @Dogooder )
  • correct baseload calculation for machine usage (thanks @gijsstat)
  • updates of several used python modules
  • Reload changed config for reports (changed watchdog.sh to restart scheduler and reload workers webserver)
  • fixed error if boiler setting gives no optimization room to DAO (setpoint - hysterese <= heating_allowed_below)
  • Add `battery_next_action` output for standby/sleep automation
  • Route CBC's native solver output into the logger
  • Updated several python modules
Zie verder toelichting hierboven: KC27 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • DaBit
  • Registratie: Januari 2000
  • Laatst online: 05-09 08:12
  • Add `battery_next_action` output for standby/sleep automation
Die zou ik mooi kunnen gebruiken om straks in de koude winterperiode de cellen een uurtje voor er geladen moet worden wat voor te verwarmen. Kan er eventueel buiten het tijdstip zelf ook naar buiten komen wat de next_action gaat worden (laden/ontladen/balanceren)?

(overigens totaal geen haast; het zal nog wel een maandje duren voor ik er wat mee ga doen)

  • diamanten
  • Registratie: Juli 2024
  • Laatst online: 09:03
KC27 schreef op woensdag 26 augustus 2026 @ 23:32:
Nu is ook een nieuwe stabiele versie gepubliceerd: 2026.8.0.
Deze is functioneel identiek aan 2026.8.0.rc8.

Dit staat in de changelog:
Breaking change
Users with a seperate container (no HA app/addon)change your pull command:
code:
1
docker pull ghcr.io/corneel27/dao:latest
This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface.
  2. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  3. @Dogooder has investigated and improved the mip-calculation of the ev-model of DAO. He also have build a test-suite for the ev-module under certain stress-circumstances.
I thank both contributors for their great efforts!!

The other changes in this release:
  • update workflows for (test)build images, packages are now oci-compliant
  • when "stop_inverter" is not configured the calculated bat-power is now spread out over the hole interval.
  • correct stop_omvormer when feedin > 0.0 (suggested by @Dogooder )
  • correct index error with reduce_power_low_soc and reduce_power_high_soc
  • added multithread so it uses all available cores during mip-calculation (thanks @Dogooder )
  • correct baseload calculation for machine usage (thanks @gijsstat)
  • updates of several used python modules
  • Reload changed config for reports (changed watchdog.sh to restart scheduler and reload workers webserver)
  • fixed error if boiler setting gives no optimization room to DAO (setpoint - hysterese <= heating_allowed_below)
  • Add `battery_next_action` output for standby/sleep automation
  • Route CBC's native solver output into the logger
  • Updated several python modules
Zie verder toelichting hierboven: KC27 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"
Dank voor de update!
Ik zie bij mij dat na de update deze api calls niet meer werken:
http://.....:5001/api/report/soc_0/vandaag_en_morgen
http://......:5001/api/report/soc_0/vandaag

Deze resulteren in een:
Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

[ Voor 5% gewijzigd door diamanten op 27-08-2026 10:18 ]


  • storeman
  • Registratie: April 2004
  • Laatst online: 10-09 08:03
@diamanten Soms moet je dao een keer herstarten na een update. Bij mij werken die endpoints wel gewoon.

"Chaos kan niet uit de hand lopen"


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
KC27 schreef op woensdag 26 augustus 2026 @ 23:32:
Nu is ook een nieuwe stabiele versie gepubliceerd: 2026.8.0.
Deze is functioneel identiek aan 2026.8.0.rc8.

Dit staat in de changelog:
Breaking change
Users with a seperate container (no HA app/addon)change your pull command:
code:
1
docker pull ghcr.io/corneel27/dao:latest
This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface.
  2. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  3. @Dogooder has investigated and improved the mip-calculation of the ev-model of DAO. He also have build a test-suite for the ev-module under certain stress-circumstances.
I thank both contributors for their great efforts!!

The other changes in this release:
  • update workflows for (test)build images, packages are now oci-compliant
  • when "stop_inverter" is not configured the calculated bat-power is now spread out over the hole interval.
  • correct stop_omvormer when feedin > 0.0 (suggested by @Dogooder )
  • correct index error with reduce_power_low_soc and reduce_power_high_soc
  • added multithread so it uses all available cores during mip-calculation (thanks @Dogooder )
  • correct baseload calculation for machine usage (thanks @gijsstat)
  • updates of several used python modules
  • Reload changed config for reports (changed watchdog.sh to restart scheduler and reload workers webserver)
  • fixed error if boiler setting gives no optimization room to DAO (setpoint - hysterese <= heating_allowed_below)
  • Add `battery_next_action` output for standby/sleep automation
  • Route CBC's native solver output into the logger
  • Updated several python modules
Zie verder toelichting hierboven: KC27 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"
Dank voor de nieuwe release. Snel vraagje mbt
  • Route CBC's native solver output into the logger
Deze native solver output verschijnt alleen als je een handmatige Run (Task) -> Optimaliseringsberekening doet. Niet bij een run van de Scheduler. Is dat "by design" om de output niet al te groot te laten worden?

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
Ik draai nog steeds schaduw, nu met 2026.8.0.rc8, met nog steeds focus op de combinatie van Minimize Consumption + Batterij + EV (ter voorbereiding op afschaffing salderingsregeling). Daarbij zie ik, naast een eerder gemeld issue tomvandepoel3 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO" dat nog steeds zeer regelmatig optreedt en waar @Dogooder naar probeert te kijken, iets nieuws bij hetzelfde scenario:
  • Actuele Baseload & Actuele PV forecast (max 7.0 kW)
  • Actieve Batterij (15.6 kWh)
  • EV (79 kWh) verbonden om 14:00 met entity_actual_level = 10%
  • EV ready datetime 08:00 (volgende ochtend) met entity_set_level = 80%
Het EV laden wordt over 22 kwartier intervallen geoptimaliseerd. Daarbij is de Batterij in de ochtenduren, voordat de EV wordt aangesloten, meestal al flink opgeladen met PV overschot (Batterij SoC ligt om 14:00 meestal ergens tussen de 40% - 60%). In de duurdere avonduren wordt vervolgens regelmatig PARALLEL zowel de EV geladen als de Batterij ONTLADEN (lijkt me OK en logisch).

Maar daarnaast wordt af en toe (in totaal gedurende 5 intervallen met respectievelijk 149W, 328W, 337W, 109W en 1374W in de afgelopen 3 dagen) PARALLEL de EV geladen en ook de Batterij GELADEN. In al deze situaties wordt de EV met 11kW/16A geladen en met max 7kW aan PV vermogen moet het GRID altijd bijspringen. Daarom snap ik niet dat naast de EV in deze situaties ook de Batterij nog extra geladen wordt (terwijl de optimalisatiestrategy Minimize Consumption is). Het parallel laden van de Batterij zorgt dus in deze gevallen ALTIJD voor IMO onnodige extra consumptie (of ik zie iets over het hoofd).

Ter illustratie het gedrag op 24-25 Augustus:
Afbeeldingslocatie: https://tweakers.net/i/r9jUonIqsa5cnyUeP94Oi_AEeyo=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/mYuF946L4jz53EPnuDjXephn.png?f=user_large

OK. Misschien wederom spijkers op laag water; het komt niet vaak voor, de extra Batterij laadvermogens zijn redelijk klein en een eenvoudige HA automation kan voorkomen dat zo'n plan ook echt wordt uitgevoerd. Zou het toch de moeite waard zijn om hier dieper in te duiken?

  • diamanten
  • Registratie: Juli 2024
  • Laatst online: 09:03
storeman schreef op donderdag 27 augustus 2026 @ 10:45:
@diamanten Soms moet je dao een keer herstarten na een update. Bij mij werken die endpoints wel gewoon.
Nee, al geprobeerd, helaas nog steeds een Internal Server Error

  • storeman
  • Registratie: April 2004
  • Laatst online: 10-09 08:03
diamanten schreef op donderdag 27 augustus 2026 @ 12:52:
[...]

Nee, al geprobeerd, helaas nog steeds een Internal Server Error
De rest van de interface werkt? En hij draait ook runs?

"Chaos kan niet uit de hand lopen"

diamanten schreef op donderdag 27 augustus 2026 @ 12:52:
[...]

Nee, al geprobeerd, helaas nog steeds een Internal Server Error
Zou je in dashboard.log willen kijken naar de foutmelding en die hier delen?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Dogooder
  • Registratie: April 2004
  • Nu online

Dogooder

dus...

tomvandepoel3 schreef op donderdag 27 augustus 2026 @ 10:45:
[...]


Dank voor de nieuwe release. Snel vraagje mbt
  • Route CBC's native solver output into the logger
Deze native solver output verschijnt alleen als je een handmatige Run (Task) -> Optimaliseringsberekening doet. Niet bij een run van de Scheduler. Is dat "by design" om de output niet al te groot te laten worden?
Als je debug aanzet in de config, of calc_optimum_met_debug() vanuit de scheduler zal de CBC solver output worden meegenomen. Zoniet, laat het mij weten want dan heb ik ergens wat verkeerd gedaan.
tomvandepoel3 schreef op donderdag 27 augustus 2026 @ 11:46:
Ik draai nog steeds schaduw, nu met 2026.8.0.rc8, met nog steeds focus op de combinatie van Minimize Consumption + Batterij + EV (ter voorbereiding op afschaffing salderingsregeling). Daarbij zie ik, naast een eerder gemeld issue tomvandepoel3 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO" dat nog steeds zeer regelmatig optreedt en waar @Dogooder naar probeert te kijken, iets nieuws bij hetzelfde scenario:
  • Actuele Baseload & Actuele PV forecast (max 7.0 kW)
  • Actieve Batterij (15.6 kWh)
  • EV (79 kWh) verbonden om 14:00 met entity_actual_level = 10%
  • EV ready datetime 08:00 (volgende ochtend) met entity_set_level = 80%
Het EV laden wordt over 22 kwartier intervallen geoptimaliseerd. Daarbij is de Batterij in de ochtenduren, voordat de EV wordt aangesloten, meestal al flink opgeladen met PV overschot (Batterij SoC ligt om 14:00 meestal ergens tussen de 40% - 60%). In de duurdere avonduren wordt vervolgens regelmatig PARALLEL zowel de EV geladen als de Batterij ONTLADEN (lijkt me OK en logisch).

Maar daarnaast wordt af en toe (in totaal gedurende 5 intervallen met respectievelijk 149W, 328W, 337W, 109W en 1374W in de afgelopen 3 dagen) PARALLEL de EV geladen en ook de Batterij GELADEN. In al deze situaties wordt de EV met 11kW/16A geladen en met max 7kW aan PV vermogen moet het GRID altijd bijspringen. Daarom snap ik niet dat naast de EV in deze situaties ook de Batterij nog extra geladen wordt (terwijl de optimalisatiestrategy Minimize Consumption is). Het parallel laden van de Batterij zorgt dus in deze gevallen ALTIJD voor IMO onnodige extra consumptie (of ik zie iets over het hoofd).

Ter illustratie het gedrag op 24-25 Augustus:
[Afbeelding]

OK. Misschien wederom spijkers op laag water; het komt niet vaak voor, de extra Batterij laadvermogens zijn redelijk klein en een eenvoudige HA automation kan voorkomen dat zo'n plan ook echt wordt uitgevoerd. Zou het toch de moeite waard zijn om hier dieper in te duiken?
Dank voor het melden van dit scenario. Ik ben druk bezig om dit soort zaken consistent reproduceerbaar te maken zodat het onderzocht kan worden. Maar dat is nog wel work in progress.

  • diamanten
  • Registratie: Juli 2024
  • Laatst online: 09:03
KC27 schreef op donderdag 27 augustus 2026 @ 13:07:
[...]

Zou je in dashboard.log willen kijken naar de foutmelding en die hier delen?
Runs draaien wel gewoon, ik heb 2 home batteries, hierbij een log:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
2026-08-27 15:00:00 info: Day Ahead Optimalisering versie: 2026.8.0
2026-08-27 15:00:00 info: Day Ahead Optimalisering gestart op: 27-08-2026 15:00:00
2026-08-27 15:00:00 info: Day Ahead Optimalisatie gestart: 27-08-2026 15:00:00 taak: calc_optimum
2026-08-27 15:00:00 info: Debug = False
2026-08-27 15:00:01 info: Zelf berekende baseload
2026-08-27 15:00:02 info: No reduced hours applied for Zinvolt
2026-08-27 15:00:02 info: No reduced power applied during discharging at low soc
2026-08-27 15:00:02 info: No reduced power applied during charging at high soc
2026-08-27 15:00:02 info: Startwaarde SoC Zinvolt: 100.0%

2026-08-27 15:00:02 info: No reduced hours applied for Delta2Max
2026-08-27 15:00:02 info: No reduced power applied during discharging at low soc
2026-08-27 15:00:02 info: No reduced power applied during charging at high soc
2026-08-27 15:00:02 info: Startwaarde SoC Delta2Max: 56.0%

2026-08-27 15:00:02 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2026-08-27 15:00:02 info: Instellingen voor laden van EV: Kia Niro EV
2026-08-27 15:00:02 info: Direct laden is uit
2026-08-27 15:00:02 info:  Ampere  Effic. Grid kW Accu kW
2026-08-27 15:00:02 info:    0.00    1.00    0.00    0.00
2026-08-27 15:00:02 info:    6.00    0.80    4.14    3.31
2026-08-27 15:00:02 info:    7.00    0.80    4.83    3.86
2026-08-27 15:00:02 info:    8.00    0.80    5.52    4.42
2026-08-27 15:00:02 info:    9.00    0.80    6.21    4.97
2026-08-27 15:00:02 info:   10.00    0.90    6.90    6.21
2026-08-27 15:00:02 info:   11.00    0.90    7.59    6.83
2026-08-27 15:00:02 info:   12.00    0.90    8.28    7.45
2026-08-27 15:00:02 info:   13.00    0.90    8.97    8.07
2026-08-27 15:00:02 info: Capaciteit accu: 55.0 kWh
2026-08-27 15:00:02 info: Maximaal laadvermogen: 8.97 kW
2026-08-27 15:00:02 info: Klaar met laden op: 09-08-2026 23:00:00
2026-08-27 15:00:02 info: Huidig laadniveau: 100.0 %
2026-08-27 15:00:02 info: Gewenst laadniveau:90.0 %
2026-08-27 15:00:02 info: Marge voor het laden: 2 %
2026-08-27 15:00:02 info: Locatie: home
2026-08-27 15:00:02 info: Ingeplugged:False
2026-08-27 15:00:02 info: Benodigde netto energie: 0.000 kWh
2026-08-27 15:00:02 info: Tijd nodig om te laden: 0:0 uur
2026-08-27 15:00:02 info: Afgerond naar hele intervallen: 0 kwartier
2026-08-27 15:00:02 info: Stand laden schakelaar: off
2026-08-27 15:00:02 info: Stand aantal ampere laden: 13.0 A
2026-08-27 15:00:02 info: Opladen wordt niet ingepland, omdat werkelijk niveau (100.0%) hoger is of gelijk aan gewenst niveau (90.0% minus de marge 2%), auto is niet ingeplugd, opgegeven tijdstip (2026-08-09 23:00:00) is verouderd.
2026-08-27 15:00:03 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-08-27 15:00:03 info: Apparaat Airco direct starten staat uit
2026-08-27 15:00:03 info: Machine Airco wordt niet ingepland, want er is gekozen voor Uit
2026-08-27 15:00:03 info: Apparaat Afwasmachine direct starten staat uit
2026-08-27 15:00:03 info: Machine Afwasmachine wordt niet ingepland, want er is gekozen voor Uit
2026-08-27 15:00:03 info: Strategie: minimale kosten
2026-08-27 15:00:03 info: Maximale fout (maximal gap): 0.005000 euro
2026-08-27 15:00:36 info: Rekentijd: 33.19 sec
2026-08-27 15:00:36 info: Het programma heeft een optimale oplossing gevonden.
2026-08-27 15:00:37 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      %      %
 15:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 15:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 15:30   0.00     --   0.00   0.00   0.00  95.00   0.00     -- 100.00
 15:45  -0.40  95.00  -0.42   0.00  -0.42  95.00  -0.44  90.25  85.23
 16:00   0.49  94.73   0.47   0.00   0.47  95.00   0.44  89.99 100.00
 16:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:15  -0.08  95.00  -0.08   0.00  -0.08  95.00  -0.08  90.25  97.19
 19:30  -0.17  95.00  -0.17   0.00  -0.17  95.00  -0.18  90.25  91.09
 19:45  -0.03  95.00  -0.03   0.00  -0.03  95.00  -0.03  90.25  90.09
 20:00  -0.01  95.00  -0.01   0.00  -0.01  95.00  -0.01  90.25  89.85
 20:15  -0.02  95.00  -0.02   0.00  -0.02  95.00  -0.02  90.25  89.07
 20:30  -0.02  95.00  -0.03   0.00  -0.03  95.00  -0.03  90.25  88.17
 20:45  -0.09  95.00  -0.09   0.00  -0.09  95.00  -0.10  90.25  84.99
 21:00  -0.13  95.00  -0.14   0.00  -0.14  95.00  -0.15  90.25  80.11
 21:15   0.00     --   0.00   0.00   0.00     --   0.00     --  80.11
 21:30   0.00     --   0.00   0.00   0.00     --   0.00     --  80.11
 21:45  -0.11  95.00  -0.11   0.00  -0.11  95.00  -0.12  90.25  76.12
 22:00   0.00     --   0.00   0.00   0.00     --   0.00     --  76.12
 22:15  -0.11  95.00  -0.11   0.00  -0.11  95.00  -0.12  90.25  72.20
 22:30  -0.10  95.00  -0.11   0.00  -0.11  95.00  -0.11  90.25  68.39
 22:45   0.00     --   0.00   0.00   0.00     --   0.00     --  68.39
 23:00   0.00     --   0.00   0.00   0.00     --   0.00     --  68.39
 23:15   0.00     --   0.00   0.00   0.00     --   0.00     --  68.39
 23:30  -0.11  95.00  -0.11   0.00  -0.11  95.00  -0.12  90.25  64.49
 23:45   0.00     --   0.00   0.00   0.00     --   0.00     --  64.49
 00:00  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.06  90.25  62.60
 00:15  -0.03  95.00  -0.04   0.00  -0.04  95.00  -0.04  90.25  61.34
 00:30  -0.02  95.00  -0.02   0.00  -0.02  95.00  -0.02  90.25  60.70
 00:45  -0.03  95.00  -0.04   0.00  -0.04  95.00  -0.04  90.25  59.43
 01:00  -0.08  95.00  -0.09   0.00  -0.09  95.00  -0.09  90.25  56.44
 01:15  -0.10  95.00  -0.10   0.00  -0.10  95.00  -0.11  90.25  52.83
 01:30  -0.11  95.00  -0.12   0.00  -0.12  95.00  -0.13  90.25  48.60
 01:45  -0.11  95.00  -0.12   0.00  -0.12  95.00  -0.13  90.25  44.40
 02:00  -0.10  95.00  -0.10   0.00  -0.10  95.00  -0.11  90.25  40.72
 02:15  -0.10  95.00  -0.10   0.00  -0.10  95.00  -0.11  90.25  37.08
 02:30   0.00     --   0.00   0.00   0.00     --   0.00     --  37.08
 02:45   0.00     --   0.00   0.00   0.00     --   0.00     --  37.08
 03:00  -0.10  95.00  -0.10   0.00  -0.10  95.00  -0.11  90.25  33.57
 03:15   0.00     --   0.00   0.00   0.00     --   0.00     --  33.57
 03:30   0.00     --   0.00   0.00   0.00     --   0.00     --  33.57
 03:45   0.00     --   0.00   0.00   0.00     --   0.00     --  33.57
 04:00   0.00     --   0.00   0.00   0.00     --   0.00     --  33.57
 04:15   0.00     --   0.00   0.00   0.00     --   0.00     --  33.57
 04:30  -0.08  95.00  -0.08   0.00  -0.08  95.00  -0.09  90.25  30.62
 04:45   0.00     --   0.00   0.00   0.00     --   0.00     --  30.62
 05:00   0.00     --   0.00   0.00   0.00     --   0.00     --  30.62
 05:15   0.00     --   0.00   0.00   0.00     --   0.00     --  30.62
 05:30  -0.09  95.00  -0.10   0.00  -0.10  95.00  -0.10  90.25  27.12
 05:45  -0.09  95.00  -0.09   0.00  -0.09  95.00  -0.09  90.25  23.96
 06:00  -0.07  95.00  -0.08   0.00  -0.08  95.00  -0.08  90.25  21.32
 06:15  -0.06  95.00  -0.06   0.00  -0.06  95.00  -0.07  90.25  19.04
 06:30  -0.05  95.00  -0.05   0.00  -0.05  95.00  -0.06  90.25  17.13
 06:45  -0.02  95.00  -0.02   0.00  -0.02  95.00  -0.02  90.25  16.35
 07:00  -0.01  95.00  -0.01   0.00  -0.01  95.00  -0.01  90.25  16.00
 07:15   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 07:30   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 07:45   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 08:00   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 08:15   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 08:30   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 08:45   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 09:00   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 09:15   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 09:30   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 09:45   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 10:00   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 10:15   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 10:30   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 10:45   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 11:00   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 11:15   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 11:30   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 11:45   0.00     --   0.00   0.00   0.00     --   0.00     --  16.00
 12:00   0.50  95.00   0.47   0.00   0.48  95.00   0.45  90.25  31.04
 12:15   0.50  95.00   0.47   0.00   0.48  95.00   0.45  90.25  46.08
 12:30   0.43  93.00   0.40   0.00   0.40  95.00   0.38  88.35  58.87
 12:45   0.00     --   0.00   0.00   0.00     --   0.00     --  58.87
 13:00   0.50  95.00   0.47   0.00   0.48  95.00   0.45  90.25  73.92
 13:15   0.50  95.00   0.47   0.00   0.48  95.00   0.45  90.25  88.96
 13:30   0.00     --   0.00   0.00   0.00     --   0.00     --  88.96
 13:45   0.30  92.77   0.28   0.00   0.28  95.00   0.26  88.13  97.68
 14:00   0.08  90.24   0.07   0.00   0.07  95.00   0.07  85.73  99.96
 14:15  -0.07  95.00  -0.07   0.00  -0.07  95.00  -0.08  90.25  97.45
 14:30  -0.19  95.00  -0.20   0.00  -0.20  95.00  -0.21  90.25  90.59
 14:45  -0.22  95.00  -0.23   0.00  -0.23  95.00  -0.25  90.25  82.34
 15:00  -0.16  95.00  -0.17   0.00  -0.17  95.00  -0.18  90.25  76.38
 15:15  -0.17  95.00  -0.18   0.00  -0.18  95.00  -0.19  90.25  70.19
 15:30  -0.18  95.00  -0.18   0.00  -0.18  95.00  -0.19  90.25  63.71
 15:45  -0.03  95.00  -0.04   0.00  -0.04  95.00  -0.04  90.25  62.43
 16:00   0.40  93.00   0.37   0.00   0.37  95.00   0.35  88.35  74.21
 16:15   0.45  93.00   0.42   0.00   0.42  95.00   0.40  88.35  87.47
 16:30   0.00     --   0.00   0.00   0.00     --   0.00     --  87.47
 16:45   0.40  93.00   0.37   0.00   0.37  95.00   0.35  88.35  99.25
 17:00   0.03  85.60   0.02   0.00   0.02  95.00   0.02  81.32 100.00
 17:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:30  -0.12  95.00  -0.13   0.00  -0.13  95.00  -0.13  90.25  95.55
 17:45  -0.09  95.00  -0.09   0.00  -0.09  95.00  -0.10  90.25  92.24
 18:00  -0.06  95.00  -0.06   0.00  -0.06  95.00  -0.07  90.25  89.98
 18:15   0.00     --   0.00   0.00   0.00     --   0.00     --  89.98
 18:30   0.00     --   0.00   0.00   0.00     --   0.00     --  89.98
 18:45   0.00     --   0.00   0.00   0.00     --   0.00     --  89.98
 19:00   0.00     --   0.00   0.00   0.00     --   0.00     --  89.98
 19:15   0.00     --   0.00   0.00   0.00     --   0.00     --  89.98
 19:30   0.00     --   0.00   0.00   0.00     --   0.00     --  89.98
 19:45  -0.40  95.00  -0.42   0.00  -0.42  95.00  -0.44  90.25  75.20
 20:00   0.00     --   0.00   0.00   0.00     --   0.00     --  75.20
 20:15  -0.17  95.00  -0.18   0.00  -0.18  95.00  -0.19  90.25  68.96
 20:30  -0.40  95.00  -0.42   0.00  -0.42  95.00  -0.44  90.25  54.19
 20:45  -0.14  95.00  -0.15   0.00  -0.15  95.00  -0.16  90.25  48.95
 21:00  -0.00  95.00  -0.00   0.00  -0.00  95.00  -0.00  90.25  48.78
 21:15  -0.15  95.00  -0.16   0.00  -0.16  95.00  -0.17  90.25  43.15
 21:30  -0.03  95.00  -0.04   0.00  -0.04  95.00  -0.04  90.25  41.87
 21:45   0.00     --   0.00   0.00   0.00     --   0.00     --  41.87
 22:00  -0.13  95.00  -0.13   0.00  -0.13  95.00  -0.14  90.25  37.18
 22:15   0.00     --   0.00   0.00   0.00     --   0.00     --  37.18
 22:30   0.00     --   0.00   0.00   0.00     --   0.00     --  37.18
 22:45  -0.11  95.00  -0.12   0.00  -0.12  95.00  -0.12  90.25  33.14
 23:00  -0.12  95.00  -0.12   0.00  -0.12  95.00  -0.13  90.25  28.85
 23:15  -0.12  95.00  -0.12   0.00  -0.12  95.00  -0.13  90.25  24.57
 23:30  -0.12  95.00  -0.12   0.00  -0.12  95.00  -0.13  90.25  20.28
 23:45  -0.12  95.00  -0.12   0.00  -0.12  95.00  -0.13  90.25  16.00
Totaal  -1.38         -1.97   0.00  -1.97         -2.52              
2026-08-27 15:00:37 info: In- en uitgaande energie per kwartier batterij Delta2Max
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 15:00   0.50  95.00   0.47   0.00   0.47  95.00   0.45  90.25  78.56
 15:15   0.48  94.21   0.45   0.00   0.45  95.00   0.43  89.50 100.00
 15:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 15:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 16:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:45  -0.14  95.00  -0.14   0.00  -0.14  95.00  -0.15  90.25  92.38
 20:00  -0.14  95.00  -0.14   0.00  -0.14  95.00  -0.15  90.25  84.76
 20:15  -0.14  95.00  -0.14   0.00  -0.14  95.00  -0.15  90.25  77.15
 20:30  -0.14  95.00  -0.14   0.00  -0.14  95.00  -0.15  90.25  69.53
 20:45  -0.07  95.00  -0.07   0.00  -0.07  95.00  -0.07  90.25  65.91
 21:00   0.00     --   0.00   0.00   0.00     --   0.00     --  65.91
 21:15  -0.12  95.00  -0.13   0.00  -0.13  95.00  -0.13  90.25  59.17
 21:30  -0.11  95.00  -0.12   0.00  -0.12  95.00  -0.12  90.25  53.00
 21:45   0.00     --   0.00   0.00   0.00     --   0.00     --  53.00
 22:00  -0.11  95.00  -0.12   0.00  -0.12  95.00  -0.12  90.25  46.93
 22:15   0.00     --   0.00   0.00   0.00     --   0.00     --  46.93
 22:30   0.00     --   0.00   0.00   0.00     --   0.00     --  46.93
 22:45   0.00     --   0.00   0.00   0.00     --   0.00     --  46.93
 23:00  -0.11  95.00  -0.11   0.00  -0.11  95.00  -0.12  90.25  40.99
 23:15  -0.11  95.00  -0.11   0.00  -0.11  95.00  -0.12  90.25  35.10
 23:30   0.00     --   0.00   0.00   0.00     --   0.00     --  35.10
 23:45  -0.09  95.00  -0.09   0.00  -0.09  95.00  -0.10  90.25  30.18
 00:00   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 00:15   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 00:30   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 00:45   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 01:00   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 01:15   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 01:30   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 01:45   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 02:00   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 02:15   0.00     --   0.00   0.00   0.00     --   0.00     --  30.18
 02:30  -0.10  95.00  -0.10   0.00  -0.10  95.00  -0.11  90.25  24.77
 02:45   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 03:00   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 03:15   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 03:30   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 03:45   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 04:00   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 04:15   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 04:30   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 04:45   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 05:00   0.00     --   0.00   0.00   0.00     --   0.00     --  24.77
 05:15  -0.09  95.00  -0.09   0.00  -0.09  95.00  -0.10  90.25  20.00
 05:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 05:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 06:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 06:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 06:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 06:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 07:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 07:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 07:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 07:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 08:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 08:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 08:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 08:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 09:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 09:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 09:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 09:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 10:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 10:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 10:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 10:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 11:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 11:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 11:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 11:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 12:00   0.50  95.00   0.47   0.00   0.47  95.00   0.45  90.25  42.56
 12:15   0.44  93.00   0.41   0.00   0.41  95.00   0.39  88.35  62.07
 12:30   0.40  93.00   0.37   0.00   0.37  95.00   0.35  88.35  79.74
 12:45   0.00     --   0.00   0.00   0.00     --   0.00     --  79.74
 13:00   0.15  91.93   0.14   0.00   0.14  95.00   0.13  87.33  86.45
 13:15   0.00 105.26   0.00   0.00   0.00  95.00   0.00 100.00  86.45
 13:30   0.00     --   0.00   0.00   0.00     --   0.00     --  86.45
 13:45   0.00     --   0.00   0.00   0.00     --   0.00     --  86.45
 14:00   0.00     --   0.00   0.00   0.00     --   0.00     --  86.45
 14:15   0.00     --   0.00   0.00   0.00     --   0.00     --  86.45
 14:30  -0.03  95.00  -0.03   0.00  -0.03  95.00  -0.03  90.25  84.80
 14:45   0.00     --   0.00   0.00   0.00     --   0.00     --  84.80
 15:00   0.00     --   0.00   0.00   0.00     --   0.00     --  84.80
 15:15   0.00     --   0.00   0.00   0.00     --   0.00     --  84.80
 15:30   0.00     --   0.00   0.00   0.00     --   0.00     --  84.80
 15:45   0.00     --   0.00   0.00   0.00     --   0.00     --  84.80
 16:00  -0.11  95.00  -0.12   0.00  -0.12  95.00  -0.12  90.25  78.61
 16:15  -0.02  95.00  -0.02   0.00  -0.02  95.00  -0.02  90.25  77.44
 16:30   0.50  95.00   0.47   0.00   0.47  95.00   0.45  90.25 100.00
 16:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:15  -0.12  95.00  -0.12   0.00  -0.12  95.00  -0.13  90.25  93.60
 17:30  -0.14  95.00  -0.14   0.00  -0.14  95.00  -0.15  90.25  85.98
 17:45  -0.14  95.00  -0.14   0.00  -0.14  95.00  -0.15  90.25  78.36
 18:00   0.00     --   0.00   0.00   0.00     --   0.00     --  78.36
 18:15  -0.03  95.00  -0.03   0.00  -0.03  95.00  -0.03  90.25  76.67
 18:30   0.00     --   0.00   0.00   0.00     --   0.00     --  76.67
 18:45   0.00     --   0.00   0.00   0.00     --   0.00     --  76.67
 19:00   0.00     --   0.00   0.00   0.00     --   0.00     --  76.67
 19:15   0.00     --   0.00   0.00   0.00     --   0.00     --  76.67
 19:30   0.00     --   0.00   0.00   0.00     --   0.00     --  76.67
 19:45  -0.15  95.00  -0.16   0.00  -0.16  95.00  -0.17  90.25  68.36
 20:00  -0.10  95.00  -0.10   0.00  -0.10  95.00  -0.11  90.25  63.10
 20:15   0.00     --   0.00   0.00   0.00     --   0.00     --  63.10
 20:30  -0.15  95.00  -0.16   0.00  -0.16  95.00  -0.17  90.25  54.79
 20:45   0.00     --   0.00   0.00   0.00     --   0.00     --  54.79
 21:00  -0.15  95.00  -0.16   0.00  -0.16  95.00  -0.17  90.25  46.48
 21:15   0.00     --   0.00   0.00   0.00     --   0.00     --  46.48
 21:30  -0.11  95.00  -0.12   0.00  -0.12  95.00  -0.12  90.25  40.27
 21:45  -0.14  95.00  -0.15   0.00  -0.15  95.00  -0.15  90.25  32.61
 22:00   0.00     --   0.00   0.00   0.00     --   0.00     --  32.61
 22:15  -0.12  95.00  -0.12   0.00  -0.12  95.00  -0.13  90.25  26.07
 22:30  -0.11  95.00  -0.12   0.00  -0.12  95.00  -0.12  90.25  20.00
 22:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 23:00   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 23:15   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 23:30   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
 23:45   0.00     --   0.00   0.00   0.00     --   0.00     --  20.00
Totaal  -0.08         -0.41   0.00  -0.41         -0.72              
2026-08-27 15:00:51 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 15:00    0.50     0.00   0.00   2.11   0.08   0.00   0.00   0.00   2.69   0.00    0.03  20.00   0.00
 15:15    0.48     0.00   0.00   2.03   0.08   0.00   0.00   0.00   2.59   0.00   -0.02  20.00   0.00
 15:30    0.00     0.00   0.00   2.41   0.07   0.00   0.00   0.00   2.48   0.00   -0.18  20.00   0.00
 15:45    0.00     0.40   0.00   2.71   0.07   0.00   0.00   0.00   2.38   0.00   -0.31  20.00   0.00
 16:00    0.49     0.00   0.00   1.73   0.08   0.00   0.00   0.00   2.30   0.00   -0.11  20.00   0.00
 16:15    0.00     0.00   0.00   2.12   0.08   0.00   0.00   0.00   2.20   0.00   -0.23  20.00   0.00
 16:30    0.00     0.00   0.00   2.01   0.08   0.00   0.00   0.00   2.10   0.00   -0.29  20.00   0.00
 16:45    0.00     0.00   0.00   1.81   0.09   0.00   0.00   0.00   1.89   0.00   -0.31  20.00   0.00
 17:00    0.00     0.00   0.00   1.52   0.09   0.00   0.00   0.00   1.61   0.00   -0.20  20.00   0.00
 17:15    0.00     0.00   0.00   1.31   0.09   0.00   0.00   0.00   1.40   0.00   -0.21  20.00   0.00
 17:30    0.00     0.00   0.00   1.10   0.09   0.00   0.00   0.00   1.20   0.00   -0.21  20.00   0.00
 17:45    0.00     0.00   0.00   0.88   0.11   0.00   0.00   0.00   0.98   0.00   -0.19  20.00   0.00
 18:00    0.00     0.00   0.00   0.61   0.13   0.00   0.00   0.00   0.74   0.00   -0.11  20.00   0.00
 18:15    0.00     0.00   0.00   0.38   0.14   0.00   0.00   0.00   0.53   0.00   -0.08  20.00   0.00
 18:30    0.00     0.00   0.00   0.16   0.16   0.00   0.00   0.00   0.31   0.00   -0.03  20.00   0.00
 18:45    0.00     0.00   0.00   0.06   0.16   0.00   0.00   0.00   0.22   0.00   -0.01  20.00   0.00
 19:00    0.00     0.00   0.00   0.03   0.16   0.00   0.00   0.00   0.18   0.00   -0.01  20.00   0.00
 19:15    0.00     0.08   0.00  -0.00   0.16   0.00   0.00   0.00   0.09   0.00    0.00  20.00   0.00
 19:30    0.00     0.17   0.00  -0.00   0.17   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 19:45    0.00     0.16   0.00  -0.00   0.16   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 20:00    0.00     0.14   0.00  -0.00   0.16   0.00   0.00   0.00   0.02   0.00    0.00  20.00   0.00
 20:15    0.00     0.16   0.00  -0.00   0.16   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 20:30    0.00     0.16   0.00  -0.00   0.16   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 20:45    0.00     0.15   0.00  -0.00   0.15   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 21:00    0.00     0.13   0.00  -0.00   0.13   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 21:15    0.00     0.12   0.00  -0.00   0.12   0.00   0.00   0.00   0.00   0.00    0.00  20.00   0.00
 21:30    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:45    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:00    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:15    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:30    0.00     0.10   0.00   0.00   0.10   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:45    0.00     0.00   0.10   0.00   0.10   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 23:00    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:15    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:30    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:45    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
 00: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
 00:15    0.00     0.03   0.00   0.00   0.03   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 00:30    0.00     0.02   0.00   0.00   0.02   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 00:45    0.00     0.03   0.00   0.00   0.03   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 01:00    0.00     0.08   0.00   0.00   0.08   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 01:15    0.00     0.10   0.00   0.00   0.10   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 01:30    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 01:45    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 02:00    0.00     0.10   0.00   0.00   0.10   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 02:15    0.00     0.10   0.00   0.00   0.10   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 02:30    0.00     0.10   0.00   0.00   0.10   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 02:45    0.00     0.00   0.10   0.00   0.10   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 03:00    0.00     0.10   0.00   0.00   0.10   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 03:15    0.00     0.00   0.09   0.00   0.09   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 03:30    0.00     0.00   0.09   0.00   0.09   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 03:45    0.00     0.00   0.09   0.00   0.09   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 04:00    0.00     0.00   0.09   0.00   0.09   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 04:15    0.00     0.00   0.08   0.00   0.08   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 04:30    0.00     0.08   0.00   0.00   0.08   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 04:45    0.00     0.00   0.08   0.00   0.08   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 05:00    0.00     0.00   0.09   0.00   0.09   0.00   0.00   0.00   0.00   0.03   -0.00  20.00   0.00
 05:15    0.00     0.09   0.01   0.00   0.09   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 05:30    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
 05:45    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
 06: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
 06: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
 06:30    0.00     0.05   0.00   0.00   0.06   0.00   0.00   0.00   0.01   0.00   -0.00  20.00   0.00
 06:45    0.00     0.02   0.00   0.00   0.06   0.00   0.00   0.00   0.04   0.00   -0.00  20.00   0.00
 07:00    0.00     0.01   0.00   0.00   0.07   0.00   0.00   0.00   0.06   0.00   -0.00  20.00   0.00
 07:15    0.00     0.00   0.00   0.02   0.07   0.00   0.00   0.00   0.09   0.00   -0.00  20.00   0.00
 07:30    0.00     0.00   0.00   0.05   0.07   0.00   0.00   0.00   0.12   0.00   -0.01  20.00   0.00
 07:45    0.00     0.00   0.00   0.20   0.08   0.00   0.00   0.00   0.28   0.00   -0.04  20.00   0.00
 08:00    0.00     0.00   0.00   0.44   0.10   0.00   0.00   0.00   0.54   0.00   -0.10  20.00   0.00
 08:15    0.00     0.00   0.00   0.59   0.11   0.00   0.00   0.00   0.70   0.00   -0.12  20.00   0.00
 08:30    0.00     0.00   0.00   0.73   0.12   0.00   0.00   0.00   0.86   0.00   -0.14  20.00   0.00
 08:45    0.00     0.00   0.00   0.90   0.13   0.00   0.00   0.00   1.03   0.00   -0.16  20.00   0.00
 09:00    0.00     0.00   0.00   1.10   0.13   0.00   0.00   0.00   1.23   0.00   -0.20  20.00   0.00
 09:15    0.00     0.00   0.00   1.26   0.13   0.00   0.00   0.00   1.40   0.00   -0.24  20.00   0.00
 09:30    0.00     0.00   0.00   1.43   0.14   0.00   0.00   0.00   1.56   0.00   -0.25  20.00   0.00
 09:45    0.00     0.00   0.00   1.50   0.15   0.00   0.00   0.00   1.64   0.00   -0.25  20.00   0.00
 10:00    0.00     0.00   0.00   1.52   0.16   0.00   0.00   0.00   1.68   0.00   -0.27  20.00   0.00
 10:15    0.00     0.00   0.00   1.59   0.17   0.00   0.00   0.00   1.76   0.00   -0.26  20.00   0.00
 10:30    0.00     0.00   0.00   1.66   0.18   0.00   0.00   0.00   1.84   0.00   -0.25  20.00   0.00
 10:45    0.00     0.00   0.00   1.61   0.18   0.00   0.00   0.00   1.79   0.00   -0.21  20.00   0.00
 11:00    0.00     0.00   0.00   1.50   0.16   0.00   0.00   0.00   1.66   0.00   -0.21  20.00   0.00
 11:15    0.00     0.00   0.00   1.45   0.15   0.00   0.00   0.00   1.61   0.00   -0.19  20.00   0.00
 11:30    0.00     0.00   0.00   1.41   0.15   0.00   0.00   0.00   1.55   0.00   -0.18  20.00   0.00
 11:45    0.00     0.00   0.00   1.28   0.15   0.00   0.00   0.00   1.43   0.00   -0.17  20.00   0.00
 12:00    1.00     0.00   0.00   0.09   0.15   0.00   0.00   0.00   1.24   0.00   -0.01  20.00   0.00
 12:15    0.94     0.00   0.00   0.02   0.15   0.00   0.00   0.00   1.11   0.00   -0.00  20.00   0.00
 12:30    0.83     0.00   0.00  -0.00   0.15   0.00   0.00   0.00   0.99   0.00    0.00  20.00   0.00
 12:45    0.00     0.00   0.00   0.73   0.16   0.00   0.00   0.00   0.89   0.00   -0.10  20.00   0.00
 13:00    0.65     0.00   0.00  -0.00   0.15   0.00   0.00   0.00   0.80   0.00    0.00  20.00   0.00
 13:15    0.50    -0.00   0.00   0.05   0.15   0.00   0.00   0.00   0.70   0.00   -0.01  20.00   0.00
 13:30    0.00     0.00   0.00   0.44   0.15   0.00   0.00   0.00   0.60   0.00   -0.05  20.00   0.00
 13:45    0.30     0.00   0.00  -0.00   0.22   0.00   0.00   0.00   0.52   0.00    0.00  20.00   0.00
 14:00    0.08     0.00   0.00  -0.00   0.35   0.00   0.00   0.00   0.43   0.00    0.00  20.00   0.00
 14:15    0.00     0.07   0.00   0.00   0.41   0.00   0.00   0.00   0.34   0.00   -0.00  20.00   0.00
 14:30    0.00     0.22   0.00   0.00   0.48   0.00   0.00   0.00   0.27   0.00   -0.00  20.00   0.00
 14:45    0.00     0.22   0.00   0.00   0.52   0.00   0.00   0.00   0.30   0.00   -0.00  20.00   0.00
 15:00    0.00     0.16   0.00   0.00   0.55   0.00   0.00   0.00   0.39   0.00   -0.00  20.00   0.00
 15:15    0.00     0.17   0.00   0.00   0.59   0.00   0.00   0.00   0.42   0.00   -0.00  20.00   0.00
 15:30    0.00     0.18   0.00   0.00   0.63   0.00   0.00   0.00   0.46   0.00   -0.00  20.00   0.00
 15:45    0.00     0.03   0.00   0.00   0.60   0.00   0.00   0.00   0.56   0.00   -0.00  20.00   0.00
 16:00    0.40     0.11   0.00   0.00   0.50   0.00   0.00   0.00   0.79   0.00   -0.00  20.00   0.00
 16:15    0.45     0.02   0.00   0.00   0.47   0.00   0.00   0.00   0.90   0.00   -0.00  20.00   0.00
 16:30    0.50     0.00   0.00   0.07   0.44   0.00   0.00   0.00   1.01   0.00   -0.01  20.00   0.00
 16:45    0.40     0.00   0.00   0.03   0.46   0.00   0.00   0.00   0.89   0.00   -0.00  20.00   0.00
 17:00    0.03     0.00   0.00   0.00   0.53   0.00   0.00   0.00   0.56   0.00   -0.00  20.00   0.00
 17:15    0.00     0.12   0.00   0.00   0.55   0.00   0.00   0.00   0.43   0.00   -0.00  20.00   0.00
 17:30    0.00     0.26   0.00   0.00   0.57   0.00   0.00   0.00   0.32   0.00   -0.00  20.00   0.00
 17:45    0.00     0.23   0.00  -0.00   0.57   0.00   0.00   0.00   0.35   0.00    0.00  20.00   0.00
 18:00    0.00     0.06   0.00   0.00   0.57   0.00   0.00   0.00   0.51   0.00   -0.00  20.00   0.00
 18:15    0.00     0.03   0.00  -0.00   0.57   0.00   0.00   0.00   0.54   0.00    0.00  20.00   0.00
 18:30    0.00     0.00   0.00   0.00   0.57   0.00   0.00   0.00   0.57   0.00   -0.00  20.00   0.00
 18:45    0.00     0.00   0.00   0.02   0.52   0.00   0.00   0.00   0.54   0.00   -0.00  20.00   0.00
 19:00    0.00     0.00   0.00   0.04   0.44   0.00   0.00   0.00   0.48   0.00   -0.01  20.00   0.00
 19:15    0.00     0.00   0.00   0.06   0.39   0.00   0.00   0.00   0.45   0.00   -0.01  20.00   0.00
 19:30    0.00     0.00   0.00   0.07   0.34   0.00   0.00   0.00   0.41   0.00   -0.01  20.00   0.00
 19:45    0.00     0.55   0.00   0.57   0.29   0.00   0.00   0.00   0.32   0.00   -0.13  20.00   0.00
 20:00    0.00     0.10   0.00   0.00   0.24   0.00   0.00   0.00   0.15   0.00   -0.00  20.00   0.00
 20:15    0.00     0.17   0.00   0.03   0.20   0.00   0.00   0.00   0.05   0.00   -0.01  20.00   0.00
 20:30    0.00     0.55   0.00   0.40   0.15   0.00   0.00   0.00   0.00   0.00   -0.08  20.00   0.00
 20:45    0.00     0.14   0.00   0.00   0.14   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:00    0.00     0.15   0.00   0.00   0.16   0.00   0.00   0.00   0.01   0.00   -0.00  20.00   0.00
 21:15    0.00     0.15   0.00   0.00   0.15   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:30    0.00     0.15   0.00   0.00   0.15   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 21:45    0.00     0.14   0.00   0.00   0.14   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:00    0.00     0.13   0.00   0.00   0.13   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:15    0.00     0.12   0.00   0.00   0.12   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:30    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 22:45    0.00     0.11   0.00   0.00   0.11   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:00    0.00     0.12   0.00   0.00   0.12   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:15    0.00     0.12   0.00   0.00   0.12   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:30    0.00     0.12   0.00   0.00   0.12   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23:45    0.00     0.12   0.00   0.00   0.12   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
Totaal    7.56     9.02   0.82  45.81  24.49   0.00   0.00   0.00  68.02   0.25   -6.17    NaN   0.00

2026-08-27 15:00:51 info: Consumption               0.82 (kWh)
2026-08-27 15:00:51 info: Cost consumption          0.25 (€)
2026-08-27 15:00:51 info: Tariff consumption        0.303 (€/kWh)
2026-08-27 15:00:51 info: Production               45.81 (kWh)
2026-08-27 15:00:51 info: Profit production        -6.17 (€)
2026-08-27 15:00:51 info: Tariff production         0.135 (€/kWh)

2026-08-27 15:00:51 info: 
Calculation profit after optimize in €
Cost before optimize             -3.99
Cost consumption      0.25
Bat cycle cost        0.28
Bat penalty cost      0.00
EV switch costs       0.00
EV low soc costs      0.00
Battery storage       0.49
Boiler storage        0.00
Profit production    -6.17
Total                -5.16
Cost after optimize              -5.16
Profit:                           1.17
2026-08-27 15:00:51 info: Doorzetten van alle settings naar HA
2026-08-27 15:00:51 info: Grid balanceren: off
2026-08-27 15:00:51 info: Grid set point: -8449.0 W
2026-08-27 15:00:51 info: Laden van Kia Niro EV is niet ingepland
2026-08-27 15:00:51 info: Aantal partial stops:  0
2026-08-27 15:00:51 info: Aantal boundary stops:  0
2026-08-27 15:00:51 info: Aantal start/stops:  0
2026-08-27 15:00:51 info: Penalty per start/stop: 0.000
2026-08-27 15:00:51 info: Totale switch kosten: 0.00
2026-08-27 15:00:51 info: Berekeningsuitkomst voor opladen van Kia Niro EV:
2026-08-27 15:00:51 info: - aantal ampere 0A (was 13.0A)
2026-08-27 15:00:51 info: - stand schakelaar 'off' (was 'off')
2026-08-27 15:00:51 info: - positie: home
2026-08-27 15:00:51 info: - ingeplugd: False
2026-08-27 15:00:51 info: Kia Niro EV is niet thuis of niet ingeplugd
2026-08-27 15:00:51 info: Evaluatie status laden Kia Niro EV op 2026-08-27 15:00
2026-08-27 15:00:51 info: - schakelaar laden: off
2026-08-27 15:00:51 info: - aantal ampere: 13.0
2026-08-27 15:00:51 info: Cycle cost Zinvolt: 0.16 euro
2026-08-27 15:00:51 info: Netto vermogen naar(+)/uit(-) omvormer Zinvolt: 0 W 
2026-08-27 15:00:51 info: Vermogen uit batterij: 0W
2026-08-27 15:00:51 info: Vermogen dat binnenkomt van pv: 0W
2026-08-27 15:00:51 info: Vermogen dat binnenkomt van ac: 0W
2026-08-27 15:00:51 info: Waarde SoC na eerste uur: 100.0%
2026-08-27 15:00:51 info: Cycle cost Delta2Max: 0.12 euro
2026-08-27 15:00:51 info: Netto vermogen naar(+)/uit(-) omvormer Delta2Max: 2000 W 
2026-08-27 15:00:51 info: Vermogen uit batterij: -1900W
2026-08-27 15:00:51 info: Vermogen dat binnenkomt van pv: 0W
2026-08-27 15:00:51 info: Vermogen dat binnenkomt van ac: 1900W
2026-08-27 15:00:51 info: Waarde SoC na eerste uur: 78.6%
2026-08-27 15:00:51 info: Apparaat: Airco
2026-08-27 15:00:51 info: Programma: Uit
2026-08-27 15:00:51 info: Apparaat: Afwasmachine
2026-08-27 15:00:51 info: Programma: Uit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dit zegt AI ervan (voor wat het waard is)
code:
1
2
3
4
5
6
7
8
9
Belangrijk verschil met de oude API:

Oud:
/api/report/soc_0/vandaag

Nieuw:
/v2/api/data/?start=...&end=...&fields=soc_0&aggregate=hour
En de waarde zit niet meer in value, maar in: soc_0.f
Als je ook soc_1 nodig hebt, kopieer dezelfde sensor en vervang overal soc_0 door soc_1.
Deze call werkt inderdaad:
code:
1
http://.....:5001/v2/api/data/?start=2026-08-27T00:00:00&end=2026-08-28T00:00:00&fields=soc_0&aggregate=hour
maar dan moet ik ook de HA-sensor code aanpassen en ik wil even op v1 blijven.
Nog wat meer info van AI over de 'mogelijke' oorzaak:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Oorzaak:

• DAO route doet escape(fld) op soc_0
• Daardoor wordt soc_0 een Markup('soc_0')
• SQLAlchemy/MariaDB compileert dat verkeerd naar SQL met HTML entities:
'soc_0'
• MariaDB klapt daarop met syntax error 1064
• Daarom geeft /api/report/soc_0/vandaag HTTP 500

Belangrijk: intern werkt Report().get_api_data('soc_0','vandaag') wél. Het breekt dus specifiek in de Flask API-route door die escape().

Ook gevonden:

• /reports heeft nog een aparte bug: TypeError: reports() missing 1 required positional argument: 'active_menu'
• /settings/options idem route/signature bug
• /v2/api/data/...fields=soc_0... blijft gewoon werken

Dit is dus vrijwel zeker een DAO 2026.8.0 regressie. Workaround blijft de V2 API; echte fix moet upstream in DAO.
Ik draai dus met MariaDB.

[ Voor 106% gewijzigd door diamanten op 27-08-2026 15:43 ]


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
Dogooder schreef op donderdag 27 augustus 2026 @ 14:23:
[...]

Als je debug aanzet in de config, of calc_optimum_met_debug() vanuit de scheduler zal de CBC solver output worden meegenomen. Zoniet, laat het mij weten want dan heb ik ergens wat verkeerd gedaan.
Werkt idd precies zoals je beschrijft. Ik had de link met debug nog niet gelegd maar is logisch.
Dogooder schreef op donderdag 27 augustus 2026 @ 14:23:
[...]
Dank voor het melden van dit scenario. Ik ben druk bezig om dit soort zaken consistent reproduceerbaar te maken zodat het onderzocht kan worden. Maar dat is nog wel work in progress.
Geen enkel probleem. Ping me als er iets is waarbij ik je kan proberen te ondersteunen.

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
Puur ter info, ik loop net tegen onderstaande crash aan in mijn 2026.8.0 produktie omgeving:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
2026-08-27 16:00:03 info: Strategie: minimale kosten
2026-08-27 16:00:03 info: Maximale fout (maximal gap): 0.005000 euro
python3: /project/Cgl/src/CglPreProcess/CglPreProcess.cpp:1693: OsiSolverInterface* CglPreProcess::preProcessNonDefault(OsiSolverInterface&, int, int, int): Assertion `numberProhibited_ == originalModel_->getNumCols()' failed.
ERROR while running Cbc. Signal SIGABRT caught. Getting stack trace.
/root/dao/venv/day_ahead/lib/python3.13/site-packages/cbcbox/cbc_dist/lib/libCbc.so(_Z15CbcCrashHandleri+0x164) [0x7f839dba58]
linux-vdso.so.1(__kernel_rt_sigreturn+0) [0x7faed33820]
/lib/aarch64-linux-gnu/libc.so.6(+0x87d80) [0x7faea87d80]
/lib/aarch64-linux-gnu/libc.so.6(gsignal+0x20) [0x7faea36940]
/lib/aarch64-linux-gnu/libc.so.6(abort+0x2c) [0x7faea21a84]
/lib/aarch64-linux-gnu/libc.so.6(+0x2f97c) [0x7faea2f97c]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/cbcbox/cbc_dist/lib/libCgl.so.0(_ZN13CglPreProcess20preProcessNonDefaultER18OsiSolverInterfaceiii+0x628) [0x7f836fe960]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/cbcbox/cbc_dist/lib/libCbc.so(_Z8CbcMain1St5dequeISsSaISsEER8CbcModelR13CbcParametersPFiPS2_iEP9ampl_info+0xe740) [0x7f839ed4f8]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/cbcbox/cbc_dist/lib/libCbc.so(Cbc_solve+0x12a8) [0x7f83a81140]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-aarch64-linux-gnu.so(+0x34054) [0x7f9c184054]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-aarch64-linux-gnu.so(+0x30b7c) [0x7f9c180b7c]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-aarch64-linux-gnu.so(cffistatic_ffi_call+0x30) [0x7f9c180bdc]
/root/dao/venv/day_ahead/lib/python3.13/site-packages/_cffi_backend.cpython-313-aarch64-linux-gnu.so(+0x170fc) [0x7f9c1670fc]
python3(_PyObject_MakeTpCall+0x278) [0x4a5640]
python3(_PyEval_EvalFrameDefault+0xf3c) [0x4c259c]
python3(PyEval_EvalCode+0xc0) [0x4bcbe0]
python3() [0x64ac7c]
python3() [0x6466b0]
python3() [0x66a0f0]
python3() [0x669994]
python3() [0x66972c]
python3(Py_RunMain+0x2b8) [0x6679f8]
python3(Py_BytesMain+0x28) [0x6158c8]
/lib/aarch64-linux-gnu/libc.so.6(+0x2225c) [0x7faea2225c]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x9c) [0x7faea2233c]
python3(_start+0x30) [0x6144f0]
./watchdog.sh: line 182:    30 Aborted                 (core dumped) ( cd /root/dao/prog || exit 1; exec python3 da_scheduler.py )
Scheduler crashed with exit code 134
Stopping gunicorn...
[2026-08-27 16:01:12 +0200] [31] [INFO] Handling signal: term
[2026-08-27 16:01:12 +0200] [7405] [info] Worker exiting (pid: 7405)
[2026-08-27 16:01:12 +0200] [27828] [info] Worker exiting (pid: 27828)
[2026-08-27 16:01:15 +0200] [31] [INFO] Shutting down: Master
Scheduler crashed with exit code 134
Scheduler crashed with exit code 134
Scheduler crashed with exit code 134
Scheduler crashed with exit code 134
...
Deze laatste exit code wordt continue herhaald en vult de log file in een hoog tempo.
...
De nieuwe versie heeft probleemloos gedraaid sinds de upgrade eerder vanochtend. Alleen de schedule run net om 16:00 faalde. Na het stoppen en opnieuw starten van de App werkt alles weer.

  • Knielen
  • Registratie: December 2009
  • Laatst online: 13:33
Ik heb DAO al een tijd op de achtergrond meedraaien, vanaf oktober ga ik naar een dynamisch contract en wil dan DAO actief gaan gebruiken. Nu draai ik het liefst met 'minimize consumption' en ben ik op zoek naar een praktisch implementatie:

Ik zie nu dat DAO, in de uren dat er niet extra geladen of ontladen hoeft te worden, probeert om het sluipverbruik te compenseren door mijn voorspelde verbruik mee te geven. Mijn Victron draait dan het liefst met een ESS grid setpoint van 0. Heeft iemand al wat slims bedacht om DAO niet het verbruik uit de accu mee te geven, maar het verbruik uit huis, dus voor de lange nachtelijke uren gewoon de waarde 0? Ik zou dus het liefst alleen waardes vanuit DAO zien als er extra geladen of ontladen moet worden.

  • thomvh
  • Registratie: September 2013
  • Laatst online: 12:05
Knielen schreef op donderdag 27 augustus 2026 @ 19:19:
Ik heb DAO al een tijd op de achtergrond meedraaien, vanaf oktober ga ik naar een dynamisch contract en wil dan DAO actief gaan gebruiken. Nu draai ik het liefst met 'minimize consumption' en ben ik op zoek naar een praktisch implementatie:

Ik zie nu dat DAO, in de uren dat er niet extra geladen of ontladen hoeft te worden, probeert om het sluipverbruik te compenseren door mijn voorspelde verbruik mee te geven. Mijn Victron draait dan het liefst met een ESS grid setpoint van 0. Heeft iemand al wat slims bedacht om DAO niet het verbruik uit de accu mee te geven, maar het verbruik uit huis, dus voor de lange nachtelijke uren gewoon de waarde 0? Ik zou dus het liefst alleen waardes vanuit DAO zien als er extra geladen of ontladen moet worden.
DAO zet de balance switch aan. Is dat niet wat je bedoeld?

  • Knielen
  • Registratie: December 2009
  • Laatst online: 13:33
thomvh schreef op donderdag 27 augustus 2026 @ 19:22:
[...]

DAO zet de balance switch aan. Is dat niet wat je bedoeld?
Ah ja, dat zou hem inderdaad wel eens kunnen zijn, dankjewel!

  • pimNH
  • Registratie: Mei 2011
  • Laatst online: 09:16
Is het ook mogelijk om van een apparaat de entity end window op de volgende dag in te stellen? Ik wil op die manier een apparaat laten kiezen tussen het goedkoopste moment vandaag en morgen. Dus eigenlijk inplannen in een window van bijvoorbeeld vandaag 13.00 (als de prijzen bekend zijn) tot morgen 24.00.

  • diamanten
  • Registratie: Juli 2024
  • Laatst online: 09:03
diamanten schreef op donderdag 27 augustus 2026 @ 15:14:
[...]

Runs draaien wel gewoon, ik heb 2 home batteries, hierbij een log:

[...]


Dit zegt AI ervan (voor wat het waard is)
code:
1
2
3
4
5
6
7
8
9
Belangrijk verschil met de oude API:

Oud:
/api/report/soc_0/vandaag

Nieuw:
/v2/api/data/?start=...&end=...&fields=soc_0&aggregate=hour
En de waarde zit niet meer in value, maar in: soc_0.f
Als je ook soc_1 nodig hebt, kopieer dezelfde sensor en vervang overal soc_0 door soc_1.
Deze call werkt inderdaad:
code:
1
http://.....:5001/v2/api/data/?start=2026-08-27T00:00:00&end=2026-08-28T00:00:00&fields=soc_0&aggregate=hour
maar dan moet ik ook de HA-sensor code aanpassen en ik wil even op v1 blijven.
Nog wat meer info van AI over de 'mogelijke' oorzaak:

[...]

Ik draai dus met MariaDB.
Helaas nog steeds API-problemen na de upgrade. Andere gebruikers op mariadb die geen problemen hiermee hebben?
diamanten schreef op vrijdag 28 augustus 2026 @ 16:24:
[...]

Helaas nog steeds API-problemen na de upgrade. Andere gebruikers op mariadb die geen problemen hiermee hebben?
Ik heb ook mariadb, ik gebruik zelf die functie niet maar ik kan het nadoen.
Ik ga ernaar kijken.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • Dogooder
  • Registratie: April 2004
  • Nu online

Dogooder

dus...

Voor de Deye gebruikers, die niet hun huis op load hebben zitten en andere gebruikers die ook hun systeem in standby willen zetten of opwarmen.
Ik gebruik de volgende twee HA automations op basis van de toegevoegde battery next action entity.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
alias: Sleep battery when confirmed idle for a while
description: >
  Switches the inverter into standby once DAO's plan shows no battery activity
  for at least an hour, avoiding rapid mode-switching on short idle gaps.
triggers:
  - trigger: state
    entity_id: input_datetime.battery_next_action
conditions:
  - condition: template
    value_template: |
      {{ (states('input_datetime.battery_next_action') | as_datetime | as_local)
         - now() > timedelta(hours=1) }}
  - condition: not
    conditions:
      - condition: state
        entity_id: select.ss_battery_type
        state:
          - No Battery
actions:
  - action: select.select_option
    target:
      entity_id: select.ss_battery_type
    data:
      option: No Battery
mode: single
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
alias: Wake battery before next planned action
description: >
  Switches the inverter out of standby about 3 minutes before DAO's next planned
  battery action, so it has time to re-energize. Includes a fallback for when a
  reoptimization suddenly needs the battery sooner than the scheduled offset
  would catch.
triggers:
  - trigger: time
    id: scheduled_wake
    at:
      entity_id: input_datetime.battery_next_action
      offset: "-00:03:00"
  - trigger: state
    id: plan_jumped_imminent
    entity_id: input_datetime.battery_next_action
conditions:
  - condition: state
    entity_id: select.ss_battery_type
    state:
      - No Battery
  - condition: or
    conditions:
      - condition: template
        value_template: "{{ trigger.id == 'scheduled_wake' }}"
      - condition: and
        conditions:
          - condition: template
            value_template: "{{ trigger.id == 'plan_jumped_imminent' }}"
          - condition: template
            value_template: >
              {{ (states('input_datetime.battery_next_action') | as_datetime |
              as_local)
                 - now() <= timedelta(minutes=3) }}
actions:
  - action: select.select_option
    target:
      entity_id: select.ss_battery_type
    data:
      option: Lithium (Use BMS)
mode: single

  • stat
  • Registratie: Mei 2005
  • Laatst online: 12-09 20:24
Ik heb geupdate naar 2026.08 maar kreeg een cbclib error ('cbclib is not defined').
Vervolgens dacht ik dat het een goed idee was om de miplib opnieuw te compileren maar kreeg toen de error 'wget not found').
Dus maar even terug naar 2026.06 ;-).

  • The Source
  • Registratie: April 2000
  • Laatst online: 12-09 19:55
Dogooder schreef op vrijdag 28 augustus 2026 @ 22:21:
Voor de Deye gebruikers, die niet hun huis op load hebben zitten en andere gebruikers die ook hun systeem in standby willen zetten of opwarmen.
Ik gebruik de volgende twee HA automations op basis van de toegevoegde battery next action entity.


[...]
Dank je, ook direct een tracker gemaakt om te bekijken hoeveel stroom dit bespaard :)
Helaas heb ik geen pre-heaters en de eerste winter komt eraan. Hoe doen jullie dit? Met een automation regelen dat charge/dischage langzamer gaat aan de hand van de temperatuur. En als je die dan langzaam gebruikt, dan neem ik aan dat ze opwarmen en je het volle vermogen er tegenaan kunt gooien? Of heeft DAO hier bepaalde functies voor?

  • Frankvbr
  • Registratie: November 2004
  • Laatst online: 12-09 00:44
thomvh schreef op donderdag 27 augustus 2026 @ 19:22:
[...]

DAO zet de balance switch aan. Is dat niet wat je bedoeld?
Ik snap niet wat de balance switch doet. Wellicht is het oplossing voor onderstaande, maar ik snap hem niet.

Op dit moment stuurt DAO het vermogen aan dat de accu moet laden of ontladen (of de accu moet niets doen). Dat werkt best goed, maar het nadeel is dat pieken alsnog via het net lopen. Dus een oven/kookplaat of iets anders wat eventjes of iets langer piekt boven huidige zonne-opwek loopt via het net. Vanaf volgend jaar kan dat zonde zijn, vanwege energiebelasting. Ik heb dan liever dat de accu eventjes iets leegloopt en daarna weer wordt aangevuld.

Mijn idee zou zijn dat DAO doorgeeft of er ontladen 'mag' worden. Als DAO zegt 'JA', dan is er geen reden waarom dat niet mag, maar er kan ook een 'NEE' reden zijn (Heel goedkoop uur, de accu wordt naar verwachting niet meer volgeladen want het is al einde dag, of de zon schijnt uberhaupt niet meer de rest van de dag).

Ik heb echt wat zitten zoeken hier in het topic, maar door de vele comments moeilijk te vinden.
Als er al wel een goede oplossing is, dan voldoet een linkje naar de juiste comment ook hoor, zonde om weer opnieuw uit te leggen.

  • Batavia
  • Registratie: Mei 2011
  • Laatst online: 07:57
Frankvbr schreef op zaterdag 29 augustus 2026 @ 23:05:
[...]

Ik snap niet wat de balance switch doet. Wellicht is het oplossing voor onderstaande, maar ik snap hem niet.

Op dit moment stuurt DAO het vermogen aan dat de accu moet laden of ontladen (of de accu moet niets doen). Dat werkt best goed, maar het nadeel is dat pieken alsnog via het net lopen. Dus een oven/kookplaat of iets anders wat eventjes of iets langer piekt boven huidige zonne-opwek loopt via het net. Vanaf volgend jaar kan dat zonde zijn, vanwege energiebelasting. Ik heb dan liever dat de accu eventjes iets leegloopt en daarna weer wordt aangevuld.

Mijn idee zou zijn dat DAO doorgeeft of er ontladen 'mag' worden. Als DAO zegt 'JA', dan is er geen reden waarom dat niet mag, maar er kan ook een 'NEE' reden zijn (Heel goedkoop uur, de accu wordt naar verwachting niet meer volgeladen want het is al einde dag, of de zon schijnt uberhaupt niet meer de rest van de dag).

Ik heb echt wat zitten zoeken hier in het topic, maar door de vele comments moeilijk te vinden.
Als er al wel een goede oplossing is, dan voldoet een linkje naar de juiste comment ook hoor, zonde om weer opnieuw uit te leggen.
Je balance switch zegt dat ie accu in net balancing mode moet gaan

Daar bovenop kan je altijd eigen automation maken op basis van wat dao zegt. Dao dingen 100% direct laten aansturen is niet altijd een goed idee.

Je kan bijvoorbeeld je accu in net balance mode zetten als de prijs boven het daggemiddelde zit. Heb je verder dao niet voor nodig

[ Voor 4% gewijzigd door Batavia op 30-08-2026 08:49 ]


  • wwouter1000
  • Registratie: Februari 2026
  • Laatst online: 12-09 00:20
stat schreef op zaterdag 29 augustus 2026 @ 17:49:
Ik heb geupdate naar 2026.08 maar kreeg een cbclib error ('cbclib is not defined').
Vervolgens dacht ik dat het een goed idee was om de miplib opnieuw te compileren maar kreeg toen de error 'wget not found').
Dus maar even terug naar 2026.06 ;-).
Ja, ik heb hetzelfde probleem. En voor nu dezelfde oplossing
wwouter1000 schreef op zondag 30 augustus 2026 @ 20:47:
[...]

Ja, ik heb hetzelfde probleem. En voor nu dezelfde oplossing
Sorry. In de volgende (test)versie is wget weer toegevoegd aan de geïnstalleerde packages.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • dannyll
  • Registratie: September 2025
  • Laatst online: 12:40
Zijn er meer mensen die last hebben van het niet kunnen ophalen van prijzen bij Entsoe?
Handmatig werkt ook niet.
503 Server Error: Service Unavailable for url: https://web-api.tp.entsoe.eu/api?documentType=A44&in

edit: ik zie nu dat als ik ik de link invoer in een browser dat ze aangeven dat ze bezig zijn met onderhoud. Wel lastig dat DAO dan er helemaal uitligt. Maar weer handmatig de batterij laden

[ Voor 31% gewijzigd door dannyll op 31-08-2026 09:34 ]

PV Output: SolarEdge SE7K; 19x345Wp West; 8x500Wp Oost. - Enphase; 6x435Wp Zuid; Totaal 10KWp. - Battery: Zinvol Power 6Kwh. - EV: Tesla Model X. - EVcharger: Smart EVSE - Home Assistant beginner

dannyll schreef op maandag 31 augustus 2026 @ 08:15:
Zijn er meer mensen die last hebben van het niet kunnen ophalen van prijzen bij Entsoe?
Handmatig werkt ook niet.
503 Server Error: Service Unavailable for url: https://web-api.tp.entsoe.eu/api?documentType=A44&in

edit: ik zie nu dat als ik ik de link invoer in een browser dat ze aangeven dat ze bezig zijn met onderhoud. Wel lastig dat DAO dan er helemaal uitligt. Maar weer handmatig de batterij laden
Je kunt ook switchen naar Nordpool als databron.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • diotav
  • Registratie: December 2005
  • Laatst online: 11:29
foutje

[ Voor 99% gewijzigd door diotav op 31-08-2026 13:34 ]

dion.dev


  • thunderfury
  • Registratie: Juni 2013
  • Laatst online: 12-09 23:36
dannyll schreef op maandag 31 augustus 2026 @ 08:15:
Zijn er meer mensen die last hebben van het niet kunnen ophalen van prijzen bij Entsoe?
Handmatig werkt ook niet.
503 Server Error: Service Unavailable for url: https://web-api.tp.entsoe.eu/api?documentType=A44&in

edit: ik zie nu dat als ik ik de link invoer in een browser dat ze aangeven dat ze bezig zijn met onderhoud. Wel lastig dat DAO dan er helemaal uitligt. Maar weer handmatig de batterij laden
Ik heb het inderdaad ook gemerkt. Duurt wel bijzonder lang, want is nog steeds een onderhoudsmelding...

  • dannyll
  • Registratie: September 2025
  • Laatst online: 12:40
KC27 schreef op maandag 31 augustus 2026 @ 13:09:
[...]

Je kunt ook switchen naar Nordpool als databron.
Dat heb ik geprobeerd... maar dan krijg ik hele rare voorstellen.....Ik doe iets fout...

Afbeeldingslocatie: https://tweakers.net/i/jManSK69NW1TU12FGA2Nr_eFflU=/x800/filters:strip_exif()/f/image/ReanIP8gpmsjVM65aHTzdC6w.png?f=fotoalbum_large

PV Output: SolarEdge SE7K; 19x345Wp West; 8x500Wp Oost. - Enphase; 6x435Wp Zuid; Totaal 10KWp. - Battery: Zinvol Power 6Kwh. - EV: Tesla Model X. - EVcharger: Smart EVSE - Home Assistant beginner


  • Knielen
  • Registratie: December 2009
  • Laatst online: 13:33
dannyll schreef op maandag 31 augustus 2026 @ 20:05:
[...]

Dat heb ik geprobeerd... maar dan krijg ik hele rare voorstellen.....Ik doe iets fout...

[Afbeelding]
Niks fout mee toch? Zo ziet het er bij mij ook uit morgen.

  • Batavia
  • Registratie: Mei 2011
  • Laatst online: 07:57
KC27 schreef op maandag 31 augustus 2026 @ 13:09:
[...]

Je kunt ook switchen naar Nordpool als databron.
Zou mooi zijn als ik beide kon configureren en dat ze om en om geprobeerd werden

  • dannyll
  • Registratie: September 2025
  • Laatst online: 12:40
Knielen schreef op maandag 31 augustus 2026 @ 20:22:
[...]

Niks fout mee toch? Zo ziet het er bij mij ook uit morgen.
Lijkt mij niet. Om 00.00 uur gaan laden en 09.00 uur laden terwijl de prijzen om 13.00 uur laag zijn. Het klopt niet.

PV Output: SolarEdge SE7K; 19x345Wp West; 8x500Wp Oost. - Enphase; 6x435Wp Zuid; Totaal 10KWp. - Battery: Zinvol Power 6Kwh. - EV: Tesla Model X. - EVcharger: Smart EVSE - Home Assistant beginner


  • Knielen
  • Registratie: December 2009
  • Laatst online: 13:33
dannyll schreef op maandag 31 augustus 2026 @ 21:53:
[...]

Lijkt mij niet. Om 00.00 uur gaan laden en 09.00 uur laden terwijl de prijzen om 13.00 uur laag zijn. Het klopt niet.
Je hebt gelijk inderdaad, de laatste prijs is morgen iets na 14 uur in de middag, hij lijkt bij jou een offset te hebben
dannyll schreef op maandag 31 augustus 2026 @ 21:53:
[...]

Lijkt mij niet. Om 00.00 uur gaan laden en 09.00 uur laden terwijl de prijzen om 13.00 uur laag zijn. Het klopt niet.
DAO importeeert die Nordpool data en zet ze in de database met de tijdstippen omgerekend naar unix-timestamps (seconden gerekend van 1-1-1970).
Bij het ophalen voor de berekening worden ze omgerekend naar datum/tijd conform jouw timezone in HA. Hoe staat die ingesteld?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • itavero
  • Registratie: Oktober 2004
  • Laatst online: 11-09 09:46
Vandaag liep ik met 2026.6.0 weer tegen het probleem aan dat er net niet genoeg tijd was om de auto helemaal tot de gewenste SoC te krijgen.
Het resultaat was dat ik er net achter kwam dat de aansturing al enkele uren was gestopt met een waarschuwing als waarschuwing: Er is te weinig tijd om tot 80.0% te laden en waarschuwing: Geen oplossing voor: minimize cost.

Ik heb even geprobeerd te zoeken in dit topic, maar ik heb echt geen idee hoe ik die zoekmachine van Tweakers goed kan temmen zodat hij op een zin zoekt in plaats van losse woorden.

Is er een manier om DAO te configureren dat hij in deze situatie dan ofwel:
  • de auto direct gaat laden en 'm in ieder geval zo vol mogelijk probeert te krijgen
  • of, de auto negeert en de rest in ieder geval wel aan blijft sturen?
Zelf zou ik de eerste optie prefereren, maar de tweede is een goede fallback wat mij betreft (dan worden de accu's in ieder geval nog wel geladen).

Excuus als dit al eens gevraagd is.

  • Dogooder
  • Registratie: April 2004
  • Nu online

Dogooder

dus...

Voor zover ik weet kijkt DAO bij die eerste waarschuwing hoeveel die dan wel kan laden. En zou daarna met een feasible oplossing moeten komen. Als DAO nog steeds deze fout geeft, zou je dan een keer een debugrun kunnen doen en dan het log hier binnen quote-tags kunnen delen?
itavero schreef op dinsdag 1 september 2026 @ 13:15:
Vandaag liep ik met 2026.6.0 weer tegen het probleem aan dat er net niet genoeg tijd was om de auto helemaal tot de gewenste SoC te krijgen.
Het resultaat was dat ik er net achter kwam dat de aansturing al enkele uren was gestopt met een waarschuwing als waarschuwing: Er is te weinig tijd om tot 80.0% te laden en waarschuwing: Geen oplossing voor: minimize cost.

Ik heb even geprobeerd te zoeken in dit topic, maar ik heb echt geen idee hoe ik die zoekmachine van Tweakers goed kan temmen zodat hij op een zin zoekt in plaats van losse woorden.

Is er een manier om DAO te configureren dat hij in deze situatie dan ofwel:
  • de auto direct gaat laden en 'm in ieder geval zo vol mogelijk probeert te krijgen
  • of, de auto negeert en de rest in ieder geval wel aan blijft sturen?
Zelf zou ik de eerste optie prefereren, maar de tweede is een goede fallback wat mij betreft (dan worden de accu's in ieder geval nog wel geladen).

Excuus als dit al eens gevraagd is.
Volgens mij is deze fout opgelost in versie 2026.8.0.
Zou je dat willen proberen?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • itavero
  • Registratie: Oktober 2004
  • Laatst online: 11-09 09:46
Ik las dat er bij enkelen nog problemen waren met die nieuwe release, dus ik hield het nog een beetje af.
Zal dit weekend eens een testje proberen te doen.

  • The Source
  • Registratie: April 2000
  • Laatst online: 12-09 19:55
Dogooder schreef op vrijdag 28 augustus 2026 @ 22:21:
Voor de Deye gebruikers, die niet hun huis op load hebben zitten en andere gebruikers die ook hun systeem in standby willen zetten of opwarmen.
Ik gebruik de volgende twee HA automations op basis van de toegevoegde battery next action entity.


[...]
Werkt battery next action überhaupt? Ik krijg er geen melding van…? Terwijl feedin wel voor langere tijd 0 is.

  • Dogooder
  • Registratie: April 2004
  • Nu online

Dogooder

dus...

@The Source Draai je de laatste versie? 2026.8.0? Staat hij juist opgenomen in de config? Het is een optioneel, dus als hij niet in de config staat dan doet de code niks. Als hij goed geconfigureerd is dan zou het log elke run de volgende regel moeten zijn:
Volgende actie batterij Deye: 2026-09-01 11:45 (interval 0, SoC-delta 0.539 kWh)

Hij kijkt naar welk eerstvolgende interval een SoC-delta heeft, bovenstaande betekend dat in het huidige interval een soc delta is. Staat er interval 8, dan betekend het dat de eerstvolgende soc delta 8 intervallen later is.

  • Switek
  • Registratie: Augustus 2004
  • Laatst online: 11-09 10:24
Heeft iemand hier een verklaring / oplossing voor. DAO probeert iedere dag te zorgen dat de batterij tot het minimum ontlaad. Hierdoor in de nacht, waar we regelmatig de afwasmachine, wasmachine en warmtepompboiler aan hebben, moet worden ingekocht van het net. Nu is er zelfs niets over voor het sluimerverbruik.

Afbeeldingslocatie: https://tweakers.net/i/ybspqmbnNFbgNGrfzVxc-ZL1FJk=/x800/filters:strip_exif()/f/image/Dbml9mLNTOGDMBidu13D3xm4.png?f=fotoalbum_large

[ Voor 45% gewijzigd door Switek op 02-09-2026 09:15 ]


  • dannyll
  • Registratie: September 2025
  • Laatst online: 12:40
Switek schreef op woensdag 2 september 2026 @ 09:03:
Heeft iemand hier een verklaring / oplossing voor. DAO probeert iedere dag te zorgen dat de batterij tot het minimum ontlaad. Hierdoor in de nacht, waar we regelmatig de afwasmachine, wasmachine en warmtepompboiler aan hebben, moet worden ingekocht van het net. Nu is er zelfs niets over voor het sluimerverbruik.

[Afbeelding]
Je strategy staat dan waarschijnlijk op "minimize cost" en dat is wat hij doet. proberen zoveel mogelijk te "verdienen" De vraag is natuurlijk wat voor soort energiecontract je hebt. Gezien je grafiek verwacht ik wel een dynamisch contract. Als je voor een andere strategie kiest zal het gedrag ook anders worden. Maar beter is natuurlijk de wasmachine etc overdag aan te zetten

PV Output: SolarEdge SE7K; 19x345Wp West; 8x500Wp Oost. - Enphase; 6x435Wp Zuid; Totaal 10KWp. - Battery: Zinvol Power 6Kwh. - EV: Tesla Model X. - EVcharger: Smart EVSE - Home Assistant beginner


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
dannyll schreef op woensdag 2 september 2026 @ 09:41:
[...]

Je strategy staat dan waarschijnlijk op "minimize cost" en dat is wat hij doet. proberen zoveel mogelijk te "verdienen" De vraag is natuurlijk wat voor soort energiecontract je hebt. Gezien je grafiek verwacht ik wel een dynamisch contract. Als je voor een andere strategie kiest zal het gedrag ook anders worden. Maar beter is natuurlijk de wasmachine etc overdag aan te zetten
Je kan DAO ook vragen om deze gebruikers als machines in te plannen ipv van ze in de baseload/sluimerverbruik op te nemen. DAO kan dan bij het plannen van de Batterij rekening houden met deze "gebruikers". In de zomer zullen deze machines dan meestal overdag actief worden (overschot pv en/of lage kosten) en in de winter vaak 's nachts met ondersteuning vanuit de Batterij.

[ Voor 7% gewijzigd door tomvandepoel3 op 02-09-2026 15:18 ]


  • dannyll
  • Registratie: September 2025
  • Laatst online: 12:40
tomvandepoel3 schreef op woensdag 2 september 2026 @ 15:13:
[...]


Je kan DAO ook vragen om deze gebruikers als machines in te plannen ipv van ze in de baseload/sluimerverbruik op te nemen. In de zomer zullen deze machines dan meestal overdag actief worden (overschot pv en/of lage kosten) en in de winter vaak 's nachts.
Mee eens.. maar dat heb ik ook nog niet in gebruik. De vaatwasser is niet zo "slim" en de wasmachine zou eventueel op deze manier aangestuurd kunnen worden, maar dan moet de was er wel inzitten. Thuis met meer mensen te maken dus ik ben al blij als er op de app gekeken wordt wat de goedkope uren zijn en dat dan de apparaten worden aangezet.

PV Output: SolarEdge SE7K; 19x345Wp West; 8x500Wp Oost. - Enphase; 6x435Wp Zuid; Totaal 10KWp. - Battery: Zinvol Power 6Kwh. - EV: Tesla Model X. - EVcharger: Smart EVSE - Home Assistant beginner


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
dannyll schreef op woensdag 2 september 2026 @ 15:19:
[...]

Mee eens.. maar dat heb ik ook nog niet in gebruik. De vaatwasser is niet zo "slim" en de wasmachine zou eventueel op deze manier aangestuurd kunnen worden, maar dan moet de was er wel inzitten. Thuis met meer mensen te maken dus ik ben al blij als er op de app gekeken wordt wat de goedkope uren zijn en dat dan de apparaten worden aangezet.
Volledig begrepen.

Misschien is het voldoende om de apparaten in de DAO planning mee te laten lopen om ze wel in te laten plannen op/rond de tijdstippen waarop je ze nu normaal ook aanzet zonder HA feitelijk de apparaten aan/uit te laten zetten. Op zo'n manier kan DAO, b.v. bij het gebruik van de minimize consumption strategy, er voor zorgen dat er nog wel genoeg energie in de Batterij zit en proberen te voorkomen dat er van het net geladen moet worden.

  • The Source
  • Registratie: April 2000
  • Laatst online: 12-09 19:55
Dogooder schreef op dinsdag 1 september 2026 @ 23:14:
@The Source Draai je de laatste versie? 2026.8.0? Staat hij juist opgenomen in de config? Het is een optioneel, dus als hij niet in de config staat dan doet de code niks. Als hij goed geconfigureerd is dan zou het log elke run de volgende regel moeten zijn:
Volgende actie batterij Deye: 2026-09-01 11:45 (interval 0, SoC-delta 0.539 kWh)

Hij kijkt naar welk eerstvolgende interval een SoC-delta heeft, bovenstaande betekend dat in het huidige interval een soc delta is. Staat er interval 8, dan betekend het dat de eerstvolgende soc delta 8 intervallen later is.
Ja ik draai de laatste versie.
Ik had deze eerst opgenomen als:
"entity_stop_inverter": "input_datetime.battery_next_action",
maar na lezen documentatie zojuist gewijzigd in
"entity_battery_next_action": "input_datetime.battery_next_action",
Ik krijg direct een datum terug, dus nu even afwachten of dit wel klopt en werkt..

[ Voor 12% gewijzigd door The Source op 02-09-2026 21:11 ]

Vanavond is een nieuwe testversie gepubliceerd: 2026.9.0.rc1

Dit staat in de changelog:
  • Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler (reported by @tomvandepoel3)
  • Added "wget" to succeed a local build of miplib (reported by @stat)
  • Corrected the "internal server error" when api called with period "vandaag", "morgen" or "vandaag_en_morgen"
Het is geen grote update t.o.v. de vorige versie, maar alle gemelde foutjes zijn gefixed.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
Ik draai nog steeds schaduw (2026.8.0) met Minimize Consumption + Batterij + EV (ter voorbereiding op afschaffing salderingsregeling).

DAO zet soms grid balanceren op AAN wanneer de EV slechts gedurende een deel van het interval wordt geladen. Ik vraag me af of balanceren ("entity_balance_switch") in zo'n situatie niet beter op UIT gezet kan worden omdat het grid setpoint gedurende het eerste deel van zo'n interval (EV laadt) veel hoger is dan 0W en gedurende het tweede deel van zo'n interval (EV is gestopt met laden) juist veel lager.
Afbeeldingslocatie: https://tweakers.net/i/AdvIOYf10zHA71fsTdIEptraaV4=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/AFz0Syp88qWlsZUGJHjtf0ls.png?f=user_large
Door gedurende het volledige interval met een grid setpoint van 0W te balanceren wordt de Batterij (als ik het goed heb) juist onnodig belast doordat er binnen dat korte interval zowel fors wordt geladen als wordt ontladen (tegen hetzelfde tarief en met aanzienlijke efficiency verliezen).

Gedetaileerd voorbeeld:
Situatie om 07:00 & 07:15 vanochtend: EV laden (+ baseload) is in balans met Batterij ontladen (+ PV) als DAO de EV laat laden met een vermogen van 1.6 kW. Maar omdat de EV hier altijd met minimaal 6A (3 fase) = 4.1 kW laadt gebruikt DAO "entity_stop_charging" om het laden na 5 minuten te stoppen.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 07:00    0.00     0.41   0.00   0.00   0.03   0.00   0.00   0.40   0.01   0.00   -0.00  20.00
...
2026-09-03 07:15:04 info: Grid balanceren: on
...
2026-09-03 07:00:04 info: Berekeningsuitkomst voor opladen van EV:
2026-09-03 07:00:04 info: - aantal ampere 6.0A (was 0.0A)
2026-09-03 07:00:04 info: - stand schakelaar 'on' (was 'off')
2026-09-03 07:00:04 info: - stop laden op 2026-09-03 07:05


   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 07:15    0.00     0.41   0.00   0.00   0.04   0.00   0.00   0.40   0.02   0.00   -0.00  20.00
...
2026-09-03 07:15:04 info: Grid balanceren: on
...
2026-09-03 07:15:04 info: Berekeningsuitkomst voor opladen van EV:
2026-09-03 07:15:04 info: - aantal ampere 6.0A (was 6.0A)
2026-09-03 07:15:04 info: - stand schakelaar 'on' (was 'off')
2026-09-03 07:15:04 info: - stop laden op 2026-09-03 07:20
Dit "EV laden gedurende een deel van een interval in combinatie met Batterij ontladen" komt ook voor bij de andere EV laadstromen (6A,8A,10A,12A,14A&16A). Het toevoegen van extra "charge_stages" (7A,9A, ...) zal de frequentie waarmee dit gebeurt wel wat reduceren maar kan niet voorkomen dat DAO, bij "minimize consumption", ook vaak wil laden met minder dan 4.1 kW zoals in dit voorbeeld. Dus misschien is het beter om niet te balanceren in deze situaties?

Een andere insteek is misschien om de waarde van "entity_stop_charging" te negeren en de EV altijd gedurende een volledig interval te laden (dat is op dit moment nog wat ik doe bij "minimize cost"). Dan wordt er natuurlijk meer geconsumeerd dan strikt noodzakelijk is; iets dat ik vanaf volgend jaar graag wil voorkomen.

Hoe denken anderen hier mee om te gaan?

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
KC27 schreef op woensdag 2 september 2026 @ 23:41:
Vanavond is een nieuwe testversie gepubliceerd: 2026.9.0.rc1

Dit staat in de changelog:
  • Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler (reported by @tomvandepoel3)
  • Added "wget" to succeed a local build of miplib (reported by @stat)
  • Corrected the "internal server error" when api called with period "vandaag", "morgen" or "vandaag_en_morgen"
Het is geen grote update t.o.v. de vorige versie, maar alle gemelde foutjes zijn gefixed.
Misschien zie ik iets over het hoofd maar ik krijg de nieuwe rc niet aan de praat...
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2026-09-03 15:53:17 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/home/tom/day-ahead/dao/prog/da_base.py", line 726, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/tom/day-ahead/dao/prog/da_base.py", line 570, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/home/tom/day-ahead/dao/prog/day_ahead.py", line 3258, in calc_optimum
    max_gap = abs(self.config.max_gap.resolve(ha_getter))
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/home/tom/day-ahead/dao/prog/config/models/base.py", line 173, in resolve
    state_value = ha_state_getter(self.value)
  File "/home/tom/day-ahead/dao/prog/day_ahead.py", line 73, in ha_getter
    return self.get_state(eid).state
           ^^^^
NameError: name 'self' is not defined
tomvandepoel3 schreef op donderdag 3 september 2026 @ 16:03:
[...]

Misschien zie ik iets over het hoofd maar ik krijg de nieuwe rc niet aan de praat...
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2026-09-03 15:53:17 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/home/tom/day-ahead/dao/prog/da_base.py", line 726, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/tom/day-ahead/dao/prog/da_base.py", line 570, in calc_optimum_met_debug
    dacalc.calc_optimum()
    ~~~~~~~~~~~~~~~~~~~^^
  File "/home/tom/day-ahead/dao/prog/day_ahead.py", line 3258, in calc_optimum
    max_gap = abs(self.config.max_gap.resolve(ha_getter))
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/home/tom/day-ahead/dao/prog/config/models/base.py", line 173, in resolve
    state_value = ha_state_getter(self.value)
  File "/home/tom/day-ahead/dao/prog/day_ahead.py", line 73, in ha_getter
    return self.get_state(eid).state
           ^^^^
NameError: name 'self' is not defined
Fijn dat je dit hebt getest.
Ik ga het onderzoeken.
Hoe heb jij gap geconfigureerd in settings?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 12-09 17:01
KC27 schreef op donderdag 3 september 2026 @ 19:19:
[...]

Fijn dat je dit hebt getest.
Ik ga het onderzoeken.
Hoe heb jij gap geconfigureerd in settings?
Als flex setting:
"max_gap": "input_number.dao_max_gap",
Waarde van de HA helper is 0.2
Zojuist is er een nieuwe testversie gepubliceerd: 2026.9.0.rc2.
Hierin is de error gemeld door tomvandepoel3 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO" gerepareerd.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • SnarfW
  • Registratie: September 2026
  • Laatst online: 11-09 16:27
Ik draai DAO nu een aantal dagen. Hoe gaat de tool om met de kostprijs van energie die in de batterij is opgeslagen?

Elk uur of kwartier wordt een nieuwe optimalisatie uitgevoerd. Stel dat de batterij in de vorige periode met energie van het net is opgeladen. Neemt DAO bij de volgende optimalisatie mee dat aan die opgeslagen energie al kosten verbonden zijn? Of weet de tool dat niet en wordt de energie bij de volgende berekening beschouwd als gratis energie?

  • memorynl
  • Registratie: Juni 2010
  • Laatst online: 11:29
SnarfW schreef op vrijdag 4 september 2026 @ 13:29:
Ik draai DAO nu een aantal dagen. Hoe gaat de tool om met de kostprijs van energie die in de batterij is opgeslagen?

Elk uur of kwartier wordt een nieuwe optimalisatie uitgevoerd. Stel dat de batterij in de vorige periode met energie van het net is opgeladen. Neemt DAO bij de volgende optimalisatie mee dat aan die opgeslagen energie al kosten verbonden zijn? Of weet de tool dat niet en wordt de energie bij de volgende berekening beschouwd als gratis energie?
Wat telt is de (geschatte) TOEKOMSTIGE waarde van de energie in de batterij, daarop optimaliseer je.

Is het voordeliger om de energie te laten zitten voor later, of nu het net op sturen. Die vraag wordt continue beantwoord. Ook in het verleden, en blijkbaar was het toen ooit voordeliger (geschat) de energie op te slaan voor later en niet direct te verkopen.

Dit relateert volgens mij aan de sunk cost falacy. Maar dan met opbrengsten ofzo.
@SnarfW @memorynl
Voor de optimalisatie berekening wordt de inhoud van de accu gewaardeerd op de gemiddelde inkoopwaarde over de hele optimalisering periode.
Maar dat gebeurt voor de inhoud van accu aan het einde van die periode.
Na afloop van de salderingsregeling (vanaf 1-1-2027) is die waardering te hoog en zal deze ergens tussen het gemiddelde inkooptarief en het gemiddelde teruglevertarief in moeten liggen. Deze waardering zal instelbaar worden (iedereen heeft daar waarschijnlijk een eigen mening over).
Kies je hem te hoog dan zal de accu aan het einde vol zijn. Kies je hem te laag dan is ie aan het einde leeg.

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

Er zijn geen problemen meer gemeld met testversie 2026.9.0.rc2.
Nu is productieversie 2026.9.0 gepubliceerd.
Functioneel is deze gelijk aan: 2026.9.0.rc2.
Dit staat in de changelog (t.o.v. 2026.8.0):
  • Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler (reported by @tomvandepoel3 )
  • Added "wget" to succeed a local build of miplib (reported by @stat )
  • Corrected the "internal server error" when api called with period "vandaag", "morgen" or "vandaag_en_morgen"

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • stat
  • Registratie: Mei 2005
  • Laatst online: 12-09 20:24
KC27 schreef op vrijdag 4 september 2026 @ 23:27:
Er zijn geen problemen meer gemeld met testversie 2026.9.0.rc2.
Nu is productieversie 2026.9.0 gepubliceerd.
Functioneel is deze gelijk aan: 2026.9.0.rc2.
Dit staat in de changelog (t.o.v. 2026.8.0):
  • Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler (reported by @tomvandepoel3 )
  • Added "wget" to succeed a local build of miplib (reported by @stat )
  • Corrected the "internal server error" when api called with period "vandaag", "morgen" or "vandaag_en_morgen"
Heb hem geinstalleerd, helaas bij builden miplib nu de error dat hij git niet kan vinden.

  • Hvdort
  • Registratie: Mei 2021
  • Laatst online: 10-09 19:56
Ik heb zojuist ook 2026.9.0 getest. Opnieuw een libcbc error. Daarom maar weer roll back gedaan naar 2026.6.0. Ik heb ooit het advies gevolgd om die miplib handmatig te compileren. Zit dat nu in de weg of wordt dat automatisch overschreven bij een nieuwe versie van de container in HA?

  • Dogooder
  • Registratie: April 2004
  • Nu online

Dogooder

dus...

Ik weet niet precies hoe het zit met je eigen miplib compileren en HA containers. Maar in de huidige versie is Python mip hard gepinned op versie 1.17.6/cbcbox 2.929.

Dit omdat de nieuwere versie van cbcbox (2.935) crashed. En ik weet niet of de bug in cbcbox zit of verder upstream in CBC zelf.

  • thewhi
  • Registratie: April 2021
  • Laatst online: 12-09 23:08
KC27 schreef op vrijdag 4 september 2026 @ 21:38:
@SnarfW @memorynl
Voor de optimalisatie berekening wordt de inhoud van de accu gewaardeerd op de gemiddelde inkoopwaarde over de hele optimalisering periode.
Maar dat gebeurt voor de inhoud van accu aan het einde van die periode.
Na afloop van de salderingsregeling (vanaf 1-1-2027) is die waardering te hoog en zal deze ergens tussen het gemiddelde inkooptarief en het gemiddelde teruglevertarief in moeten liggen. Deze waardering zal instelbaar worden (iedereen heeft daar waarschijnlijk een eigen mening over).
Kies je hem te hoog dan zal de accu aan het einde vol zijn. Kies je hem te laag dan is ie aan het einde leeg.
DAO had wel wat moeite om te starten. Handmatige herstart heeft gewerkt

[ Voor 5% gewijzigd door thewhi op 05-09-2026 15:49 ]


  • thewhi
  • Registratie: April 2021
  • Laatst online: 12-09 23:08
De scheduler van de laatste versie lijkt toch niet te werken. Tips?

  • Mvdw
  • Registratie: September 2022
  • Laatst online: 08:27
thewhi schreef op zaterdag 5 september 2026 @ 20:02:
De scheduler van de laatste versie lijkt toch niet te werken. Tips?
Hier ook problemen met de scheduler. Werkt vaker niet dan wel sinds de recente update. Valt mij ook op dat een berekening soms wel 5-10 minuten kan duren waar dit voorheen ruim een minuut duurde.

Draai de laatste versie en de calc_optimum staat ingesteld om elk kwartier te draaien.

Voor nu opgelost door elk kwartier een calc_zonder_debug run via de API aan te roepen. Hiervoor een simpele automatisering gemaakt.

[ Voor 13% gewijzigd door Mvdw op 05-09-2026 22:00 ]


  • rescla
  • Registratie: November 2012
  • Laatst online: 13:41
Bij mij werkt de scheduler wel. Heb eerder, op een oudere versie, wel meerdere keren problemen gehad met de scheduler. Maar daar lag elke keer een probleem met de supervisor aan ten grondslag. Om dat te fixen moet ik in de terminal app of via ssh dan de volgende commands draaien:
code:
1
2
ha supervisor repair 
ha supervisor restart
Edit: ik zit nog op 2026.8.0, logisch dat het nog werkt.

[ Voor 9% gewijzigd door rescla op 05-09-2026 23:29 ]

Als je opstartproblemen met de nieuwe versie hebt helpt het vaak om DAO handmatig te herstarten:
In HA ga naar Instellingen/Apps, kies DAO, klik op "Herstarten".
Je kunt daar ook op het tabblad Logboek kijken. Dat geeft ook vaak informatie wat er aan de hand is

[ Voor 24% gewijzigd door KC27 op 05-09-2026 22:14 ]

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • thewhi
  • Registratie: April 2021
  • Laatst online: 12-09 23:08
Kreeg deze analyse over het niet functioneren van de scheduler:
Uit de changelog: "Moved the runs of scheduler-tasks to a separate process, SIGABRT in CBC killed the scheduler." Voorheen draaide de scheduler elke taak in-process (run_task_function). Nu start hij per taak een subprocess. De nieuwe code in da_scheduler.py:
Python
Waarom de scheduler daardoor vastloopt
stdout=PIPE gecombineerd met proc.wait() zonder de pipe te lezen is een deadlock-patroon waar de Python-docs expliciet voor waarschuwen. De OS-pipebuffer is ~64 kB. Het kindproces (day_ahead.py calc) logt naar het logbestand én via een StreamHandler naar stdout, en sinds 2026.8.0 gaat ook de CBC-solveroutput mee. Een calc_optimum-run produceert daar ruim meer dan 64 kB van. Zodra de buffer vol is blokkeert het kind op een write(), de scheduler blokkeert op wait(), en beide hangen voor eeuwig. De watchdog ziet het schedulerproces nog "leven" en herstart dus niets. Gevolg: de eerste (grotere) run na de update draait nog wel, maar daarna gebeurt er niets meer, ook geen prices/meteo op de volgende tijdstippen.
Twee kleinere bijeffecten van dezelfde wijziging:
De output van runs verschijnt niet meer in de add-on-log (hij verdwijnt in de pipe).
De taak clean werkt nu niet: het cmd stuurt argument clean_data, maar main() in day_ahead.py kijkt naar clean, dus de scheduler-run doet stilletjes niets.
Wat je nu kunt doen
Optie 1 (snelst): terug naar 2026.8.0 tot er een fix is.
Optie 2: zelf patchen in /root/dao/prog/da_scheduler.py

  • Mvdw
  • Registratie: September 2022
  • Laatst online: 08:27
rescla schreef op zaterdag 5 september 2026 @ 22:06:
Bij mij werkt de scheduler wel. Heb eerder, op een oudere versie, wel meerdere keren problemen gehad met de scheduler. Maar daar lag elke keer een probleem met de supervisor aan ten grondslag. Om dat te fixen moet ik in de terminal app of via ssh dan de volgende commands draaien:
code:
1
2
ha supervisor repair 
ha supervisor restart
Geprobeerd, helaas geen oplossing. Dank voor de suggestie!

  • Mvdw
  • Registratie: September 2022
  • Laatst online: 08:27
KC27 schreef op zaterdag 5 september 2026 @ 22:12:
Als je opstartproblemen met de nieuwe versie hebt helpt het vaak om DAO handmatig te herstarten:
In HA ga naar Instellingen/Apps, kies DAO, klik op "Herstarten".
Je kunt daar ook op het tabblad Logboek kijken. Dat geeft ook vaak informatie wat er aan de hand is
Geprobeerd maar lost het niet op. De eerste run gaat goed, daarna niet meer.

2026-09-05 21:29:17 debug: Starting new HTTP connection (1): supervisor:80

2026-09-05 21:29:17 debug: [url="http://supervisor:80"]http://supervisor:80[/url] "POST /core/api/services/input_text/set_value HTTP/1.1" 200 473

2026-09-05 21:29:17 debug: Starting new HTTP connection (1): supervisor:80

2026-09-05 21:29:17 debug: [url="http://supervisor:80"]http://supervisor:80[/url] "GET /core/api/states/input_text.dao_melding HTTP/1.1" 200 471

2026-09-05 21:29:17 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 730 in /root/dao/prog/da_base.py

2026-09-05 21:29:17 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 5146 in /root/dao/webserver/../prog/day_ahead.py

De run komt tot hier.
Mvdw schreef op zaterdag 5 september 2026 @ 23:12:
[...]

Geprobeerd maar lost het niet op. De eerste run gaat goed, daarna niet meer.

2026-09-05 21:29:17 debug: Starting new HTTP connection (1): supervisor:80

2026-09-05 21:29:17 debug: [url="http://supervisor:80"]http://supervisor:80[/url] "POST /core/api/services/input_text/set_value HTTP/1.1" 200 473

2026-09-05 21:29:17 debug: Starting new HTTP connection (1): supervisor:80

2026-09-05 21:29:17 debug: [url="http://supervisor:80"]http://supervisor:80[/url] "GET /core/api/states/input_text.dao_melding HTTP/1.1" 200 471

2026-09-05 21:29:17 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 730 in /root/dao/prog/da_base.py

2026-09-05 21:29:17 debug: Connection status Pool size: 5 Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 5146 in /root/dao/webserver/../prog/day_ahead.py

De run komt tot hier.
Ik wil dit graag op korte termijn oplossen.
Een paar vragen:
  • kun je in je settings "logging_level": "info" zetten, heeft dat effect
  • hoe ziet je "homeassistant" setting eruit?
  • draai je DAO als HA-app(add-on) of in een losse container?

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer

We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:
  • removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
  • added git and nano to installed packages
  • corrected finish day_ahead.py on arm64 to prevent crash with error -4

WP: Alpha Innotec MSW2-6S | PV: 20 x 300 Wp AEG | ACCU: 2x16x280Ah LiFePO4 3 x Multiplus II 48/3000 | DYN: Tibber | Gasloos | Day Ahead Optimizer


  • thewhi
  • Registratie: April 2021
  • Laatst online: 12-09 23:08
KC27 schreef op zaterdag 5 september 2026 @ 23:40:
[...]

Ik wil dit graag op korte termijn oplossen.
Een paar vragen:
  • kun je in je settings "logging_level": "info" zetten, heeft dat effect
  • hoe ziet je "homeassistant" setting eruit?
  • draai je DAO als HA-app(add-on) of in een losse container?
Na aanpassen van logging level naar info deed de scheduler het hier inderdaad weer!

  • stat
  • Registratie: Mei 2005
  • Laatst online: 12-09 20:24
KC27 schreef op zondag 6 september 2026 @ 01:02:
We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:
  • removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
  • added git and nano to installed packages
  • corrected finish day_ahead.py on arm64 to prevent crash with error -4
Ik wil graag testen maar als ik voor het installeren van de testversie als app in HAOS de instructies op de wiki volg dan gaat het mis bij het toevoegen van de repository:
code:
1
Cmd('git') failed due to: exit code(128) cmdline: git clone -v --recursive --branch=addon --depth=1 --shallow-submodules -- https://github.com/corneel27/day-ahead /data/apps/git/c7ff724d stderr: 'Cloning into '/data/apps/git/c7ff724d'... POST git-upload-pack (344 bytes) fatal: Remote branch addon not found in upstream origin '
Kan iemand me verder helpen?

  • Mvdw
  • Registratie: September 2022
  • Laatst online: 08:27
KC27 schreef op zondag 6 september 2026 @ 01:02:
We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:
  • removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
  • added git and nano to installed packages
  • corrected finish day_ahead.py on arm64 to prevent crash with error -4
Bedankt! Ik ga het z.s.m. testen. Logging stond eerder op Info en toen werkte het niet, daarom op debug gezet om te begrijpen waar het misgaat.

DAO draait als add-on.

"config_version": 2,

"homeassistant": {

"ip_address": "supervisor",

"protocol_api": "http"

  • Mvdw
  • Registratie: September 2022
  • Laatst online: 08:27
KC27 schreef op zondag 6 september 2026 @ 01:02:
We hebben vanavond een nieuwe testversie (2026.9.1.rc1) gepubliceerd waarin hopelijk de gemelde problemen zijn opgelost.
Melders: graag testen en deel je bevindingen.
Dit staat in de changelog:
  • removed us of pipe, let the child inherit the scheduler's stdout/stderr: (#812)
  • added git and nano to installed packages
  • corrected finish day_ahead.py on arm64 to prevent crash with error -4
Probleem is opgelost na het installeren van de testversie. De runs worden netjes afgerond binnen ongeveer 1,5 minuut.

  • Frankvbr
  • Registratie: November 2004
  • Laatst online: 12-09 00:44
Batavia schreef op zondag 30 augustus 2026 @ 08:48:
[...]

Je balance switch zegt dat ie accu in net balancing mode moet gaan

Daar bovenop kan je altijd eigen automation maken op basis van wat dao zegt. Dao dingen 100% direct laten aansturen is niet altijd een goed idee.

Je kan bijvoorbeeld je accu in net balance mode zetten als de prijs boven het daggemiddelde zit. Heb je verder dao niet voor nodig
Dank. Uiteindelijk ook gevonden op de wiki, is toch even zoeken ook daar naar de juiste voorbeelden.

Mijn insteek is toch echt wel DAO zoveel mogelijk te laten aansturen, zou ook niet weten waarom je dat niet zou willen? Idee is dat het zoveel mogelijk vanzelf gaat. Ik kan wel met automations gaan werken i.c.m. prijzen, maar DAO moet voorspellen wat mijn resterende accu waarde zal zijn, mijn opwek etc.

Zal natuurlijk wel zoveel mogelijk DAO moeten voeden. Accu en panelen lijken nu wel goed samen te werken. Warmtepomp wordt complex omdat je ook zit met optimale tijden qua verwarmen (warmste momenten van de dag), maar omdat het een propaan warmtepomp is, is het boilervat verwarmen als het buiten te warm is, soms weer nadelig (dan gebruikt hij elektrisch element, dus cop=1).

Voor de vaatwasser wil ik het nu alsvolgt doen:
- Standaard de verwachte begintijd om 22.00 uur zetten in DAO
- Standaard het meest frequent gebruikte programma rekening mee houden.
Als ik de vaatwasser inruim plus 'aanzet' kies ik uitgestelde start (1, 2 of 3 uur) als die niet direct klaar moet zijn.
Dat triggert een automation die vervolgens een nieuwe begintijd aan DAO doorgeeft.
Uitgestelde start 1 uur = Volgende ochtend moet vaatwasser klaar zijn
Uitgestelde start 2 uur = Vaatwasser moet voor 22.30 klaar zijn
Uitgestelde start 3 uur = Vaatwasser moet voor 18.00 klaar zijn
Vervolgens kan DAO bepalen wat de optimale tijd is om te draaien.

Op deze manier houdt DAO in ieder geval altijd rekening met het verbruik.
Als ik dat niet wil (bijvoorbeeld tijdens vakantieperiodes), kan ik dan simpelweg het begin/eindtijdstip leeghouden of beter het programma leeghouden?

Edit: entity calculated end > bij machines lijkt een verplicht veld. Anders dan in de wiki staat. Ik kreeg er een crash op.

[ Voor 3% gewijzigd door Frankvbr op 06-09-2026 23:43 ]


  • anboni
  • Registratie: Maart 2004
  • Nu online
Frankvbr schreef op zondag 6 september 2026 @ 22:45:
[...]

Mijn insteek is toch echt wel DAO zoveel mogelijk te laten aansturen, zou ook niet weten waarom je dat niet zou willen? Idee is dat het zoveel mogelijk vanzelf gaat. Ik kan wel met automations gaan werken i.c.m. prijzen, maar DAO moet voorspellen wat mijn resterende accu waarde zal zijn, mijn opwek etc.
DAO is de dirigent. Die zet de maat, maar de muzikanten (je automations) bedienen de instrumenten. DAO zet de balance switch, je automation triggert daarop om je aansturing van de accu's op Net Zero te zetten.

  • Probydoby
  • Registratie: Januari 2011
  • Laatst online: 10:08
Ik ben er nog niet over uit hoe ik komend stookseizoen de L/L warmtepomp (airco's) will laten aansturen door DAO. Naar wat ik begreep zit er wel een model in die de stooklijn kan sturen van een L/W warmtepomp, maar hoe zou ik deze functionaliteit kunnen gebruiken voor de L/L warmtepomp?

Ik zat eraan te denken om de output van die functionaliteit te gebruiken om de setpoint van de Airco te verhogen en zo mijn huis te veranderen in een soort van thermische batterij. Stroom relatief goedkoop? setpoint omhoog, Relatief duur? Setpoint omlaag.

Heeft iemand inspiratie voor mij hoe je DAO hier het beste voor kan inzetten?

  • marnie
  • Registratie: November 2016
  • Laatst online: 09:48
Hallo, ik probeer DAO te installeren als HA app maar krijg het niet voor elkaar. Ik krijg een database not found error, echter deze database staat netjes in de aangegeven folder. Ik draai HAOS in Proxmox.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
[11:48:52] INFO: => directory dao_data exist
[11:48:52] INFO: => /root/dao/data doesn't exist, made
[11:48:52] INFO: => /root/dao/webserver/app/static/data exist
2026-09-07 11:48:56 INFO: Loaded 6 secrets from ../data/secrets.json
2026-09-07 11:48:56 INFO: Validating configuration with ConfigurationV2
Starting scheduler...
Scheduler PID: 30
Starting gunicorn...
Gunicorn PID: 31
[2026-09-07 11:48:57 +0200] [31] [INFO] Starting gunicorn 26.2.0
[2026-09-07 11:48:57 +0200] [31] [INFO] Listening at: http://0.0.0.0:5000 (31)
[2026-09-07 11:48:57 +0200] [31] [INFO] Using worker: sync
[2026-09-07 11:48:57 +0200] [37] [INFO] Booting worker with pid: 37
[2026-09-07 11:48:57 +0200] [38] [INFO] Booting worker with pid: 38
[2026-09-07 11:48:57 +0200] [31] [INFO] Control socket listening at /root/.gunicorn/gunicorn.ctl
2026-09-07 11:49:04 INFO: Loaded 6 secrets from ../data/secrets.json
2026-09-07 11:49:04 INFO: Validating configuration with ConfigurationV2
2026-09-07 11:49:04 ERROR: Home Assistant database not found: /homeassistant/home-assistant_v2.db
Traceback (most recent call last):
  File "/root/dao/prog/da_scheduler.py", line 74, in <module>
    main()
    ~~~~^^
  File "/root/dao/prog/da_scheduler.py", line 69, in main
    da_sched = DaScheduler("../data/options.json")
  File "/root/dao/prog/da_scheduler.py", line 10, in __init__
    super().__init__(file_name)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 118, in __init__
    raise RuntimeError('No database connection for Home Assistant')
RuntimeError: No database connection for Home Assistant
Scheduler crashed with exit code 1
Stopping gunicorn...
[2026-09-07 11:49:07 +0200] [31] [INFO] Handling signal: term
[2026-09-07 11:49:09 +0200] [37] [INFO] Worker exiting (pid: 37)
[2026-09-07 11:49:09 +0200] [38] [INFO] Worker exiting (pid: 38)
[2026-09-07 11:49:09 +0200] [31] [INFO] Shutting down: Master
Scheduler crashed with exit code 1
Scheduler crashed with exit code 1

2/1-kap 1988 | Extra vloer en muurisolatie | HR++ glas | WTW: Duco Energie Comfort 325 2-zones | WP: Adlar II 6kW | CV wonen: Jaga Strada Hybrid DBH, slapen: traditionele radiatoren | Solar: Enphase oost/west/zuid 4.2kVA | Homeassistant


  • KVan
  • Registratie: April 2015
  • Laatst online: 12-09 21:18
Probydoby schreef op maandag 7 september 2026 @ 10:08:
Ik ben er nog niet over uit hoe ik komend stookseizoen de L/L warmtepomp (airco's) will laten aansturen door DAO. Naar wat ik begreep zit er wel een model in die de stooklijn kan sturen van een L/W warmtepomp, maar hoe zou ik deze functionaliteit kunnen gebruiken voor de L/L warmtepomp?

Ik zat eraan te denken om de output van die functionaliteit te gebruiken om de setpoint van de Airco te verhogen en zo mijn huis te veranderen in een soort van thermische batterij. Stroom relatief goedkoop? setpoint omhoog, Relatief duur? Setpoint omlaag.

Heeft iemand inspiratie voor mij hoe je DAO hier het beste voor kan inzetten?
Ik heb hier hetzelfde. 5 L/L airco's die ik tot voor ik DAO gebruikte aanstuurde zodra ik zonnestroom op overschot had door het setpunt omhoog of omlaag te zetten (winter vs zomer). Hoe eea het best functioneerd in combinatie met batterijen en kosten optimalizatie is me nog ook niet helemaal duidelijk. Ik ga eerst de typische kost curves in de winter eens bestuderen maar wat ik tot nu gezien heb is dat vergelijkbaar met de zomer: goedkoop in de namiddag en snachts. Dus ergens tussen 14 en 17 uur de thermostaat omhoog en de rest van de dag constant laten staan, eventueel aan het eind van de nacht nog even omhoog. Op die manier gaan ze tussen 6 en 11 als de prijs hoog is nauwelijks vermogen trekken en kan vanuit de batterij maximaal teruggelevert worden.

Als volgend jaar de BTW teruggaaf er af gaat verandert het beeld wellicht. Dan wordt terugleveren uit de batterij een stuk minder interessant en ga je vermoed ik juist enkel tijdens de avond vol verwarmen of koelen. De dagen dat terugleveren wel interessant is moetten er dan tussenuit geplukt worden en de strategie er op aangepast.

  • Probydoby
  • Registratie: Januari 2011
  • Laatst online: 10:08
KVan schreef op maandag 7 september 2026 @ 12:00:
[...]

Ik heb hier hetzelfde. 5 L/L airco's die ik tot voor ik DAO gebruikte aanstuurde zodra ik zonnestroom op overschot had door het setpunt omhoog of omlaag te zetten (winter vs zomer). Hoe eea het best functioneerd in combinatie met batterijen en kosten optimalizatie is me nog ook niet helemaal duidelijk. Ik ga eerst de typische kost curves in de winter eens bestuderen maar wat ik tot nu gezien heb is dat vergelijkbaar met de zomer: goedkoop in de namiddag en snachts. Dus ergens tussen 14 en 17 uur de thermostaat omhoog en de rest van de dag constant laten staan, eventueel aan het eind van de nacht nog even omhoog. Op die manier gaan ze tussen 6 en 11 als de prijs hoog is nauwelijks vermogen trekken en kan vanuit de batterij maximaal teruggelevert worden.

Als volgend jaar de BTW teruggaaf er af gaat verandert het beeld wellicht. Dan wordt terugleveren uit de batterij een stuk minder interessant en ga je vermoed ik juist enkel tijdens de avond vol verwarmen of koelen. De dagen dat terugleveren wel interessant is moetten er dan tussenuit geplukt worden en de strategie er op aangepast.
Ik denk dat deze aanpak vooral interessant is in de zomer, althans mijn PV opwek is op moment dat ik intensief moet verwarmen verwaarloosbaar en daar valt weinig te halen. Het zal vooral op basis van de day-ahead prijzen moeten gebeuren.

Het liefst zet ik het volledig in DAO, zodat de airco niet meer onderdeel is van de baseload maar een volledig planbaar apparaat.

  • KVan
  • Registratie: April 2015
  • Laatst online: 12-09 21:18
Probydoby schreef op maandag 7 september 2026 @ 12:24:
[...]


Ik denk dat deze aanpak vooral interessant is in de zomer, althans mijn PV opwek is op moment dat ik intensief moet verwarmen verwaarloosbaar en daar valt weinig te halen. Het zal vooral op basis van de day-ahead prijzen moeten gebeuren.

Het liefst zet ik het volledig in DAO, zodat de airco niet meer onderdeel is van de baseload maar een volledig planbaar apparaat.
Om de airco's uit de baseload to halen plan ik ze elk van een Shelly plug of schakelaar met stroommeting te voorzien. Het moet ook mogelijk zijn om mijn Mitsubishi's via hun interne poort aan te sturen en er een hoop ifo zoals load er uit te halen, echter ik ben er nog niet in geslaagd de ESPhome sketch te compileren (krijg telkens foutmeldingen).

  • Probydoby
  • Registratie: Januari 2011
  • Laatst online: 10:08
KVan schreef op maandag 7 september 2026 @ 13:31:
[...]

Om de airco's uit de baseload to halen plan ik ze elk van een Shelly plug of schakelaar met stroommeting te voorzien. Het moet ook mogelijk zijn om mijn Mitsubishi's via hun interne poort aan te sturen en er een hoop ifo zoals load er uit te halen, echter ik ben er nog niet in geslaagd de ESPhome sketch te compileren (krijg telkens foutmeldingen).
Ja dat kan, maar je moet ze dan ook als planbaar apparaat configureren anders onderschat je je load, immers komen ze dan niet in de baseload voor maar ze worden ook niet gepland ( en ondertussen draai je ze wel). En hoe je dat nou configureert dat je ze ook kan inplannen en aansturen met DAO & HA is de grote vraag. (simpelweg on/off, met de ingebouwde stooklijn functionaliteit en daarop een vertaling naar L/L setpoints binnen HA, enz).

  • CSB
  • Registratie: Juli 2003
  • Laatst online: 12:46

CSB

:D

Interessante discussie over DAO i.c.m. L/L warmtepomp, ik zit met exact hetzelfde, dus ik ga meelezen (en denken). :)

Met zo'n administrator heb je geen users meer nodig...


  • Beekforel
  • Registratie: November 2001
  • Laatst online: 13:16

Beekforel

Is eigenlijk geen vis

The Source schreef op zondag 23 augustus 2026 @ 19:38:
Ik heb Claude Pro (kan ook gratis) via HA-MCP verbonden aan HA, damn erg handig. Pas dit aan, doe dat, het kan het allemaal. Helaas krijg ik steeds minder zicht op hoe het werkt, maar het kan wel alles verwezenlijken wat in mijn hoofd zat, maar mij weken/maanden zou kosten om te maken.

Ik log al jaren alle data in Influx en hier kan Claude ook enorm veel details mee uitrekenen, zoals de COP van mijn warmtepomp en de COP-buckets bepalen, maar bv ook het warmteverlies van de woning.

Helaas kan Claude niet bij de DAO-config, dus dit gedeelte is nog copy/paste. (hint) .

DAO kon vanmiddag geen prijzen ophalen en de auto kon niet ingepland worden. Door logfiles te voeden, zijn een boel dingen opgelost en het lag aan de core-update die ik uitgevoerd had. Vandaag tijd (en zon) gehad om mijn laadpaal te checken en alles een beetje af te stemmen. Nou ja... ik keek, Claude deed het werk.
Ik heb Claude Pro als extension in VSCode server en heb hem een long lived access token naar HA gegeven. Misschien wat roekeloos, maar damn dat is krachtig. Hij kan overal bij.

Hij kan dan dus ook de options.json van DAO aanpassen en alles begrijpen. Ik heb ook best wat jaren data in HA dus daar kan hij ook wel wat mee.

Heb vanavond wat aanpassingen doorgevoerd in de baseload calculatie, nu weer even een paar weken wachten of dat gaat helpen. Claude heeft wel met de data die hij tot zijn beschikking heeft de baseload herberekend en gecorrigeerd, ik had deze veel te voorzichtig ingevuld. Ben benieuwd hoeveel invloed dit heeft op de berekeningen.

Ik heb eerder al eens een CLAUDE.md opgezet in de root van mijn HA bestanden, hier staan wat richtlijnen in over hoe ik wil dat dingen geconfigureerd worden en wat wel en niet mag. Erg nutttig.

  • Frankvbr
  • Registratie: November 2004
  • Laatst online: 12-09 00:44
Ik heb in de zomer een beetje getest met voorkoelen van de woning (dus echt urenlang) en vervolgens tijdelijk uitzetten (we hadden toen paar uur dat dynamische tarief rond een euro lag). De temperatuur ging weer neem rap omhoog.

Denk dat het andersom hetzelfde werkt. Je warmt geen massa op tenzij je misschien zeer langdurig verwarmt. Ik denk dat airco juist goedkoper is als je deze gebruikt als je aanwezig bent (ook snel warm gevoel) en voor de rest uit zet.

  • Probydoby
  • Registratie: Januari 2011
  • Laatst online: 10:08
Frankvbr schreef op dinsdag 8 september 2026 @ 00:19:
Ik heb in de zomer een beetje getest met voorkoelen van de woning (dus echt urenlang) en vervolgens tijdelijk uitzetten (we hadden toen paar uur dat dynamische tarief rond een euro lag). De temperatuur ging weer neem rap omhoog.

Denk dat het andersom hetzelfde werkt. Je warmt geen massa op tenzij je misschien zeer langdurig verwarmt. Ik denk dat airco juist goedkoper is als je deze gebruikt als je aanwezig bent (ook snel warm gevoel) en voor de rest uit zet.
Omdat zelfs een paar uur voorkoelen geen zoden aan de dijk zet en de thermische massa van je meubels + huis de lucht weer verwarmd.

In winter moet je 24/7 het warmteverlies compenseren, met een warmtepomp het liefst zo steady mogelijk, maar met dynamische tarieven wellicht gestuurd door DAO om het zo kosteneffectief mogelijk te doen. Zeker als je niet de hele dag hoeft te verwarmen om het totale warmteverlies te compenseren (in de herfst/lente bijvoorbeeld).
Pagina: 1 ... 48 49 Laatste