• storeman
  • Registratie: April 2004
  • Laatst online: 19:50
@hemertje Yes! Daarvoor is de basis gelegd. Ik heb de oude reports nog even in ere hersteld, maar ook een reports V2 toegevoegd, die mijn inziens veel potentie heeft. Er zijn echter veel parameters in de DAO database waarbij sommige alleen in de prognose en andere alleen in de values. Ik ben er nog niet genoeg in thuis om hier helemaal goed een grafiek voor in elkaar te knutselen, dus ik hoor graag feedback op de Reports V2.

Ik heb zojuist nog een en ander aangepast en er is een docker-image beschikbaar (amd64 only). De image is te gebruiken via:
YAML:
1
2
3
....
  dao:
    image: storeman/dao:uiv2
Er wordt hierbij een kolom toegevoegd aan de SQLite database (variabel.aggregate) en de defaults worden ingesteld.

"Chaos kan niet uit de hand lopen"


  • bvdnoort
  • Registratie: Juli 2010
  • Laatst online: 13-07 20:59
KC27 schreef op woensdag 4 maart 2026 @ 19:56:
[...]

Ziet er erg mooi uit! Mijn complimenten _/-\o_
Het staat wel om mijn "to do" lijst, maar is moeilijker dan het lijkt.
De data die getoond worden in de API worden op dezelfde wijze berekend als de data in reports\grid en report\balans.
De geschiedenis van die data staan in de database van HA en de meterstanden daarvan worden maar eens per uur opgeslagen.
Er is ook een short-term tabel maar die werkt weer anders. Dus ik moet nog flink wat omzetten.
De prognose data staan in een tabel in de DAO database. Als je daarmee tevreden bent kan ik dat waarschijnlijk sneller maken met als extra parameter "prognose=1".
Alle data in deze tabel uit de kwartier (of uur)-berekening worden opgeslagen in de prognose tabel:
code:
1
2
3
4
5
6
7
8
9
10
11
12
2026-03-04 19:45:07 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 19:45    0.00     1.01   0.00   0.88   0.08   0.00   0.06   0.00   0.00   0.00   -0.29  50.98   0.00
 20:00    0.00     1.04   0.00   0.91   0.07   0.00   0.06   0.00   0.00   0.00   -0.31  50.85   0.00
 20:15    0.00     0.60   0.00   0.47   0.07   0.00   0.06   0.00   0.00   0.00   -0.15  50.73   0.00
 20:30    0.00     0.12   0.00   0.00   0.07   0.00   0.06   0.00   0.00   0.00   -0.00  50.60   0.00
 20:45    0.00     0.12   0.00   0.00   0.07   0.00   0.06   0.00   0.00   0.00   -0.00  50.48   0.00
 21:00    0.00     0.30   0.00   0.18   0.06   0.00   0.06   0.00   0.00   0.00   -0.05  50.35   0.00
 21:15    0.00     0.12   0.00   0.00   0.06   0.00   0.06   0.00   0.00   0.00   -0.00  50.22   0.00
 21:30    0.00     0.00   0.14   0.00   0.06   0.00   0.08   0.00   0.00   0.04   -0.00  50.10   0.00
 21:45    0.00     0.00   0.13   0.00   0.06   0.00   0.08   0.00   0.00   0.04   -0.00  49.98   0.00
......
Is dat iets?
@KC27 Zou je nog in staat zijn om deze 'prognose=1' optie toe te voegen aan een komende update? Dat zou zeer gewaardeerd worden.
bvdnoort schreef op maandag 13 juli 2026 @ 20:59:
[...]

@KC27 Zou je nog in staat zijn om deze 'prognose=1' optie toe te voegen aan een komende update? Dat zou zeer gewaardeerd worden.
Goed dat je me eraan herinnert.
Ik zet het op mijn todo-lijst.

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


  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
@KC27 @bvdnoort de /v2/api/data endpoint (in de rc voor deze maand) kan data teruggeven in een bepaalde range. Grootste voordeel is de performance, deze data komt heel snel en met een heel dun laagje uit de DAO-database.

/v2/api/data/?aggregate=15min&start=2026-07-13&end=2026-07-14

Voor aggregate kan het zijn: 15min, hour, day, week
Start en end moeten een datum zijn, eventueel inclusief tijd (T00:00)
Optioneel kan er een timezone meegegeven worden, aangezien in de db alles in UTC staat. Standaard wordt er uitgegaan van Europe/Amsterdam.

Deze geeft voor alle velden zowel de value (v) als de forecast (f) terug. Sample:
[
  {
    "ts": "2026-07-01 00:00",
    "bat_in": {
      "f": 0.0,
      "v": null
    },
    "bat_out": {
      "f": 0.29928125,
      "v": null
    },
    "cons": {
      "f": 0.0,
      "v": 0.197
    },
    "cost": {
      "f": 0.0,
      "v": 0.0652561712
    },
    "da": {
      "f": null,
      "v": 0.161625
    },
    "prod": {
      "f": 0.053281249999999954,
      "v": 0.0
    },
    "profit": {
      "f": -0.017482414640624985,
      "v": 0.0
    },
    "pv_ac": {
      "f": 0.0,
      "v": null
    },
    "pv_dc": {
      "f": 0.006675889249891042,
      "v": null
    },
    "soc": {
      "f": 49.0,
      "v": null
    }
  },...
]

[ Voor 6% gewijzigd door storeman op 13-07-2026 23:37 ]

"Chaos kan niet uit de hand lopen"


  • firecaps30
  • Registratie: September 2011
  • Laatst online: 13:35
Bij het uitvoeren van de ML training krijg ik een keyerror UTC, iemand enig idee?
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
2026-07-14 16:52:02 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3641, in get_loc
    return self._engine.get_loc(casted_key)
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  File "pandas/_libs/index.pyx", line 168, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 197, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 7668, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 7676, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'utc'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 696, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 646, in train_ml_predictions
    solar_predictor.run_train()
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/solar_predictor.py", line 1001, in run_train
    self.train_solar_option(weather_data, solar_option, start)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/solar_predictor.py", line 975, in train_solar_option
    solar_data = self.get_solar_data(start=start, entities=self.solar_entities)
  File "/root/dao/prog/solar_predictor.py", line 954, in get_solar_data
    df_solar["utc"] = pd.to_datetime(df_solar["utc"], unit="s", utc=True)
                                     ~~~~~~~~^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/frame.py", line 4378, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3648, in get_loc
    raise KeyError(key) from err
KeyError: 'utc'
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3641, in get_loc
    return self._engine.get_loc(casted_key)
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  File "pandas/_libs/index.pyx", line 168, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 197, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 7668, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 7676, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'utc'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4850, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4844, in main
    da_calc.run_task_function("train_ml_predictions")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 696, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 646, in train_ml_predictions
    solar_predictor.run_train()
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/solar_predictor.py", line 1001, in run_train
    self.train_solar_option(weather_data, solar_option, start)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/solar_predictor.py", line 975, in train_solar_option
    solar_data = self.get_solar_data(start=start, entities=self.solar_entities)
  File "/root/dao/prog/solar_predictor.py", line 954, in get_solar_data
    df_solar["utc"] = pd.to_datetime(df_solar["utc"], unit="s", utc=True)
                                     ~~~~~~~~^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/frame.py", line 4378, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3648, in get_loc
    raise KeyError(key) from err
KeyError: 'utc'
firecaps30 schreef op dinsdag 14 juli 2026 @ 17:00:
Bij het uitvoeren van de ML training krijg ik een keyerror UTC, iemand enig idee?
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
2026-07-14 16:52:02 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3641, in get_loc
    return self._engine.get_loc(casted_key)
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  File "pandas/_libs/index.pyx", line 168, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 197, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 7668, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 7676, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'utc'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 696, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 646, in train_ml_predictions
    solar_predictor.run_train()
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/solar_predictor.py", line 1001, in run_train
    self.train_solar_option(weather_data, solar_option, start)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/solar_predictor.py", line 975, in train_solar_option
    solar_data = self.get_solar_data(start=start, entities=self.solar_entities)
  File "/root/dao/prog/solar_predictor.py", line 954, in get_solar_data
    df_solar["utc"] = pd.to_datetime(df_solar["utc"], unit="s", utc=True)
                                     ~~~~~~~~^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/frame.py", line 4378, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3648, in get_loc
    raise KeyError(key) from err
KeyError: 'utc'
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3641, in get_loc
    return self._engine.get_loc(casted_key)
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  File "pandas/_libs/index.pyx", line 168, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 197, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 7668, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 7676, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'utc'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 4850, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4844, in main
    da_calc.run_task_function("train_ml_predictions")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 696, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/da_base.py", line 646, in train_ml_predictions
    solar_predictor.run_train()
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/prog/solar_predictor.py", line 1001, in run_train
    self.train_solar_option(weather_data, solar_option, start)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/solar_predictor.py", line 975, in train_solar_option
    solar_data = self.get_solar_data(start=start, entities=self.solar_entities)
  File "/root/dao/prog/solar_predictor.py", line 954, in get_solar_data
    df_solar["utc"] = pd.to_datetime(df_solar["utc"], unit="s", utc=True)
                                     ~~~~~~~~^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/frame.py", line 4378, in __getitem__
    indexer = self.columns.get_loc(key)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3648, in get_loc
    raise KeyError(key) from err
KeyError: 'utc'
Het lijkt erop dat de sensor(en) die je hebt opgegeven bij "entities_sensors" geen data bevat(ten).

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


  • firecaps30
  • Registratie: September 2011
  • Laatst online: 13:35
KC27 schreef op dinsdag 14 juli 2026 @ 23:16:
[...]

Het lijkt erop dat de sensor(en) die je hebt opgegeven bij "entities_sensors" geen data bevat(ten).
Inderdaad, verkeerde sensor gekozen voor de opbrengst van de omvormer op de zolder…

Andere vraag, ik kon het niet in de wiki vinden, kloppen de sensoren die ik hier gebruik?

“entities solar production ac”: kWh meter aangesloten op de omvormer, total export waarde in kWh.


“entities solar production dc": waarde van de totale opbrengst zonne energie van de hybride omvormer, in kWh.

"entities battery consumption": waarde battery charge power, in Watt. Dus wat de accu in gaat.

"entities battery production": waarde battery discharge power, in Watt. Wat de accu uit gaat.
firecaps30 schreef op woensdag 15 juli 2026 @ 09:12:
[...]

Inderdaad, verkeerde sensor gekozen voor de opbrengst van de omvormer op de zolder…

Andere vraag, ik kon het niet in de wiki vinden, kloppen de sensoren die ik hier gebruik?

“entities solar production ac”: kWh meter aangesloten op de omvormer, total export waarde in kWh.


“entities solar production dc": waarde van de totale opbrengst zonne energie van de hybride omvormer, in kWh.

"entities battery consumption": waarde battery charge power, in Watt. Dus wat de accu in gaat.

"entities battery production": waarde battery discharge power, in Watt. Wat de accu uit gaat.
Volgens mij kloppen ze allemaal.

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


  • thomvh
  • Registratie: September 2013
  • Laatst online: 18:27
@KC27 Is er een DB trucje hoe ik dit kan oplossen? De waarde is al gefixt in Home Assistant maar DAO lijkt er nog wel mee te rekenen.
Afbeeldingslocatie: https://tweakers.net/i/u6DHeaoONEwWdmB3qOxF8Bb9OFs=/800x/filters:strip_exif()/f/image/KK9mzFZTJedOOdfOmcHXHNKU.png?f=fotoalbum_large

  • thewhi
  • Registratie: April 2021
  • Laatst online: 07:55
thomvh schreef op donderdag 16 juli 2026 @ 10:58:
@KC27 Is er een DB trucje hoe ik dit kan oplossen? De waarde is al gefixt in Home Assistant maar DAO lijkt er nog wel mee te rekenen.
[Afbeelding]
Probeer eens een herstart van de App binnen Home Assistant. Dat heeft bij mij al een paar keer de reporting hersteld.

  • thomvh
  • Registratie: September 2013
  • Laatst online: 18:27
thewhi schreef op donderdag 16 juli 2026 @ 14:11:
[...]


Probeer eens een herstart van de App binnen Home Assistant. Dat heeft bij mij al een paar keer de reporting hersteld.
Helaas... Al geprobeerd.
thomvh schreef op donderdag 16 juli 2026 @ 16:13:
[...]

Helaas... Al geprobeerd.
Misschien moet je ook HA herstarten. Als de gecorrigeerde waarden van HA nog in de write-buffer zitten?

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


  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
@thomvh Heb je de reporting zelf aangepast in de database? Dat is echt wel stoeien, het is mij wel eens gelukt, maar was behoorlijk gepriegel aangezien er een state is en een sum. Bovendien worden recente waardes vanuit de stages bijgewerkt naar de statistics. Het is zeker mogelijk, maar alle waardes moeten wel goed aansluiten. Ook tussen statistics en states, is mijn ervaring.

Ik heb ook nog een issue in mijn data doordat io aan het spelen was en de dongel in een andere omvormer prikte: alles in de war!

"Chaos kan niet uit de hand lopen"


  • stat
  • Registratie: Mei 2005
  • Laatst online: 27-07 14:25
Vraagje: ik wil mijn domme afwasmachine zo goedkoop mogelijk laten draaien. Ik heb hem 'slim' gemaakt door een shelly stekker ervoor te zetten, die meet wanneer hij wil starten en homeassistant zet hem dan uit in een soort pauzestand en laat DAO plannen. Als hij weer aan gezet wordt dan gaat het programma verder.

Werkt allemaal prima als machine in DAO, maar waar ik tegenaan loop is dat ik op de dagen dat wij overdag thuis zijn het fijner zou zijn als hij wat eerder zou draaien. Ik doe dat nu met de macro 'cheap_energy_prices', als het verschil < 10 cent is dan draait hij eerder.
Alleen: dat houdt dan weer geen rekening met de geplande opbrengst van de panelen, vanaf volgend jaar is dat relevant.
Het liefst zou ik dit in DAO regelen, die heeft alle info. Is het een idee een optie in te bouwen dat hij zo vroeg mogelijk draait en dat je een bedrag op kunt geven (als flex-setting) dat hij accepteert als nog optimaal?
Lijkt me leuk dit zelf proberen in te bouwen maar als het niet gewenst is kan ik die tijd beter gebruiken ;-).
Volgens mij heb ik een keer in dit topic iets gelezen over een penalty-idee maar ik kan het niet terugvinden.

  • Bravo
  • Registratie: Augustus 2005
  • Laatst online: 29-07 19:59

Bravo

Second Best

stat schreef op vrijdag 17 juli 2026 @ 08:37:
Vraagje: ik wil mijn domme afwasmachine zo goedkoop mogelijk laten draaien. Ik heb hem 'slim' gemaakt door een shelly stekker ervoor te zetten, die meet wanneer hij wil starten en homeassistant zet hem dan uit in een soort pauzestand en laat DAO plannen. Als hij weer aan gezet wordt dan gaat het programma verder.

Werkt allemaal prima als machine in DAO, maar waar ik tegenaan loop is dat ik op de dagen dat wij overdag thuis zijn het fijner zou zijn als hij wat eerder zou draaien. Ik doe dat nu met de macro 'cheap_energy_prices', als het verschil < 10 cent is dan draait hij eerder.
Alleen: dat houdt dan weer geen rekening met de geplande opbrengst van de panelen, vanaf volgend jaar is dat relevant.
Het liefst zou ik dit in DAO regelen, die heeft alle info. Is het een idee een optie in te bouwen dat hij zo vroeg mogelijk draait en dat je een bedrag op kunt geven (als flex-setting) dat hij accepteert als nog optimaal?
Lijkt me leuk dit zelf proberen in te bouwen maar als het niet gewenst is kan ik die tijd beter gebruiken ;-).
Volgens mij heb ik een keer in dit topic iets gelezen over een penalty-idee maar ik kan het niet terugvinden.
Als je wil dat hij eerder klaar is, dan verschuif je toch het 'end_window_machine' tot het tijdstip dat de machine klaar moet zijn en laat je DAO verder zijn ding doen?

🚗 Ioniq 6 LR Lounge 20" 🔌⚡ Elli Pro gestuurd door evcc
🔋 Victron 6k5 + 16kWh | ☀️ 2700Wp SSW 30° @ SE2200 | ☀️ 1720Wp SSW 5° @ HM-1500
📷 Canon 6D | 🔭 17-40mm f/4 + 50mm f/1.8 II + 70-200mm f/4 | 💥 2x 430EX II | 🎛️ Sirui T005 + C10


  • thomvh
  • Registratie: September 2013
  • Laatst online: 18:27
KC27 schreef op donderdag 16 juli 2026 @ 23:19:
[...]

Misschien moet je ook HA herstarten. Als de gecorrigeerde waarden van HA nog in de write-buffer zitten?
Allebei gedaan.

  • thomvh
  • Registratie: September 2013
  • Laatst online: 18:27
storeman schreef op donderdag 16 juli 2026 @ 23:23:
@thomvh Heb je de reporting zelf aangepast in de database? Dat is echt wel stoeien, het is mij wel eens gelukt, maar was behoorlijk gepriegel aangezien er een state is en een sum. Bovendien worden recente waardes vanuit de stages bijgewerkt naar de statistics. Het is zeker mogelijk, maar alle waardes moeten wel goed aansluiten. Ook tussen statistics en states, is mijn ervaring.

Ik heb ook nog een issue in mijn data doordat io aan het spelen was en de dongel in een andere omvormer prikte: alles in de war!
Nee, ik heb alleen in HA vanuit de developer tools de verkeerde waarde gereset. De laadpaal integratie die geeft die gekke waarde neer wanneer er tijdens het laden HA herstart wordt.

  • itavero
  • Registratie: Oktober 2004
  • Laatst online: 15:29
stat schreef op vrijdag 17 juli 2026 @ 08:37:
Vraagje: ik wil mijn domme afwasmachine zo goedkoop mogelijk laten draaien. Ik heb hem 'slim' gemaakt door een shelly stekker ervoor te zetten, die meet wanneer hij wil starten en homeassistant zet hem dan uit in een soort pauzestand en laat DAO plannen. Als hij weer aan gezet wordt dan gaat het programma verder.

Werkt allemaal prima als machine in DAO, maar waar ik tegenaan loop is dat ik op de dagen dat wij overdag thuis zijn het fijner zou zijn als hij wat eerder zou draaien. Ik doe dat nu met de macro 'cheap_energy_prices', als het verschil < 10 cent is dan draait hij eerder.
Alleen: dat houdt dan weer geen rekening met de geplande opbrengst van de panelen, vanaf volgend jaar is dat relevant.
Het liefst zou ik dit in DAO regelen, die heeft alle info. Is het een idee een optie in te bouwen dat hij zo vroeg mogelijk draait en dat je een bedrag op kunt geven (als flex-setting) dat hij accepteert als nog optimaal?
Lijkt me leuk dit zelf proberen in te bouwen maar als het niet gewenst is kan ik die tijd beter gebruiken ;-).
Volgens mij heb ik een keer in dit topic iets gelezen over een penalty-idee maar ik kan het niet terugvinden.
Ik geloof dat iemand laatst iets vergelijkbaars opperde voor het EV laden, waarbij de voorkeur van deze persoon was dit zo vroeg mogelijk te doen. Daar was het idee om een penalty voor later laden toe te voegen (e.g. hoger penalty naar mate de vertrektijd/eindtijd dichterbij komt).

  • stat
  • Registratie: Mei 2005
  • Laatst online: 27-07 14:25
Bravo schreef op vrijdag 17 juli 2026 @ 08:58:
[...]

Als je wil dat hij eerder klaar is, dan verschuif je toch het 'end_window_machine' tot het tijdstip dat de machine klaar moet zijn en laat je DAO verder zijn ding doen?
Dat bereikt niet hetzelfde. Als het verschil in kosten groot genoeg is dan mag hij van mij wat later klaar zijn, maar soms maakt het zo goed als niets uit, en dan heb ik liever dat hij eerder draait.
itavero schreef op vrijdag 17 juli 2026 @ 10:06:
[...]

Ik geloof dat iemand laatst iets vergelijkbaars opperde voor het EV laden, waarbij de voorkeur van deze persoon was dit zo vroeg mogelijk te doen. Daar was het idee om een penalty voor later laden toe te voegen (e.g. hoger penalty naar mate de vertrektijd/eindtijd dichterbij komt).
Ik ga eens kijken of ik zoiets in machines kan bouwen!

Edit: Met heel veel hulp van Claude tot een PR gekomen die doet wat ik wil. Heb 2 opties ingebouwd:
- een met een lineaire penalty
- een waarbij een max waarde wordt gegeven, waarop er een zo vroeg mogelijk tijdstip wordt gekozen zodanig dat het verschil met de optimale oplossing niet groter is dan de opgegeven waarde.

Beide als flex-setting, dus in HAOS te configureren.

Ook helemaal goed als je besluit dit niet over te nemen hoor, heb er in elk geval een hoop van geleerd. Ook bv dat dit soort dingen met copilot vrijwel onmogelijk zijn om te doen.

[ Voor 28% gewijzigd door stat op 18-07-2026 22:22 ]


  • sMoKeFiSh
  • Registratie: Februari 2003
  • Laatst online: 01-08 21:10
Ik heb sterk het vermoeden dat DAO mijn laadpalen door elkaar haalt. Nu staat de Tesla en de Kia aangesloten (2 verschillende laadpalen). Set charging ready op de Tesla (in DAO) staat ingesteld dat hij om 16:00 klaar moet zijn. Set charging ready op de Kia (in DAO) staat ingesteld dat hij gisteren om 18:00 klaar moet zijn. Result DAO (Geen oplossing minimize cost). Dit issue lijkt allen voor te komen als beide auto's zitten aagesloten.
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
2026-07-20 14:24:02 INFO: Loaded 6 secrets from ../data/secrets.json
2026-07-20 14:24:02 INFO: Validating configuration with ConfigurationV2
2026-07-20 14:24:02 info: Day Ahead Optimalisering versie: 2026.6.0
2026-07-20 14:24:02 info: Day Ahead Optimalisering gestart op: 20-07-2026 14:24:02
2026-07-20 14:24:02 info: Day Ahead Optimalisatie gestart: 20-07-2026 14:24:02 taak: calc_optimum
2026-07-20 14:24:02 info: Debug = False
2026-07-20 14:24:02 info: Baseload uit instellingen
2026-07-20 14:24:03 info: Start waarden: 
       uur                tijd  spot   p_l   p_t  base  pv_ac  pv_dc
0    14:15 2026-07-20 14:15:00 0.009 0.142 0.143 0.275      0  1.553
1    14:30 2026-07-20 14:30:00 0.009 0.142 0.143 0.275      0  3.850
2    14:45 2026-07-20 14:45:00 0.011 0.144 0.146 0.275      0  3.797
3    15:00 2026-07-20 15:00:00 0.004 0.135 0.136 0.270      0  3.761
4    15:15 2026-07-20 15:15:00 0.005 0.137 0.137 0.270      0  3.707
5    15:30 2026-07-20 15:30:00 0.010 0.143 0.144 0.270      0  3.654
6    15:45 2026-07-20 15:45:00 0.010 0.143 0.144 0.289      0  3.533
7    16:00 2026-07-20 16:00:00 0.011 0.144 0.146 0.327      0  3.370
8    16:15 2026-07-20 16:15:00 0.011 0.145 0.146 0.345      0  3.247
9    16:30 2026-07-20 16:30:00 0.023 0.159 0.162 0.364      0  3.127
10   16:45 2026-07-20 16:45:00 0.062 0.206 0.214 0.364      0  2.973
11   17:00 2026-07-20 17:00:00 0.027 0.163 0.166 0.350      0  2.798
12   17:15 2026-07-20 17:15:00 0.080 0.228 0.237 0.350      0  2.644
13   17:30 2026-07-20 17:30:00 0.092 0.243 0.254 0.350      0  2.491
14   17:45 2026-07-20 17:45:00 0.108 0.262 0.275 0.350      0  2.331
15   18:00 2026-07-20 18:00:00 0.102 0.254 0.267 0.350      0  2.163
16   18:15 2026-07-20 18:15:00 0.112 0.266 0.280 0.350      0  2.004
17   18:30 2026-07-20 18:30:00 0.133 0.292 0.308 0.350      0  1.842
18   18:45 2026-07-20 18:45:00 0.145 0.306 0.324 0.350      0  1.688
19   19:00 2026-07-20 19:00:00 0.142 0.303 0.320 0.350      0  1.548
20   19:15 2026-07-20 19:15:00 0.153 0.316 0.334 0.350      0  1.395
21   19:30 2026-07-20 19:30:00 0.162 0.327 0.347 0.350      0  1.242
22   19:45 2026-07-20 19:45:00 0.178 0.346 0.368 0.350      0  1.062
23   20:00 2026-07-20 20:00:00 0.162 0.327 0.346 0.355      0  0.854
24   20:15 2026-07-20 20:15:00 0.170 0.336 0.357 0.355      0  0.675
25   20:30 2026-07-20 20:30:00 0.180 0.349 0.371 0.355      0  0.498
26   20:45 2026-07-20 20:45:00 0.192 0.363 0.387 0.336      0  0.369
27   21:00 2026-07-20 21:00:00 0.180 0.349 0.370 0.298      0  0.252
28   21:15 2026-07-20 21:15:00 0.180 0.349 0.371 0.280      0  0.124
29   21:30 2026-07-20 21:30:00 0.180 0.349 0.370 0.261      0  0.000
30   21:45 2026-07-20 21:45:00 0.178 0.346 0.368 0.261      0  0.000
31   22:00 2026-07-20 22:00:00 0.186 0.356 0.379 0.275      0  0.029
32   22:15 2026-07-20 22:15:00 0.176 0.344 0.365 0.275      0  0.006
33   22:30 2026-07-20 22:30:00 0.172 0.339 0.360 0.275      0  0.000
34   22:45 2026-07-20 22:45:00 0.165 0.330 0.350 0.275      0  0.000
35   23:00 2026-07-20 23:00:00 0.168 0.335 0.355 0.275      0  0.000
36   23:15 2026-07-20 23:15:00 0.162 0.327 0.347 0.275      0  0.000
37   23:30 2026-07-20 23:30:00 0.158 0.323 0.342 0.275      0  0.000
38   23:45 2026-07-20 23:45:00 0.149 0.312 0.330 0.275      0  0.000
39   00:00 2026-07-21 00:00:00 0.155 0.318 0.337 0.275      0  0.000
40   00:15 2026-07-21 00:15:00 0.151 0.313 0.332 0.275      0  0.000
41   00:30 2026-07-21 00:30:00 0.147 0.309 0.326 0.275      0  0.000
42   00:45 2026-07-21 00:45:00 0.146 0.307 0.325 0.275      0  0.000
43   01:00 2026-07-21 01:00:00 0.152 0.315 0.333 0.275      0  0.000
44   01:15 2026-07-21 01:15:00 0.151 0.313 0.332 0.275      0  0.000
45   01:30 2026-07-21 01:30:00 0.150 0.312 0.330 0.275      0  0.000
46   01:45 2026-07-21 01:45:00 0.147 0.309 0.326 0.275      0  0.000
47   02:00 2026-07-21 02:00:00 0.147 0.309 0.327 0.275      0  0.000
48   02:15 2026-07-21 02:15:00 0.145 0.306 0.323 0.275      0  0.000
49   02:30 2026-07-21 02:30:00 0.144 0.305 0.322 0.275      0  0.000
50   02:45 2026-07-21 02:45:00 0.140 0.301 0.318 0.275      0  0.000
51   03:00 2026-07-21 03:00:00 0.141 0.301 0.318 0.275      0  0.000
52   03:15 2026-07-21 03:15:00 0.138 0.298 0.315 0.275      0  0.000
53   03:30 2026-07-21 03:30:00 0.139 0.298 0.315 0.275      0  0.000
54   03:45 2026-07-21 03:45:00 0.139 0.299 0.316 0.275      0  0.000
55   04:00 2026-07-21 04:00:00 0.135 0.294 0.311 0.275      0  0.000
56   04:15 2026-07-21 04:15:00 0.138 0.297 0.314 0.275      0  0.000
57   04:30 2026-07-21 04:30:00 0.141 0.302 0.319 0.275      0  0.000
58   04:45 2026-07-21 04:45:00 0.144 0.305 0.323 0.275      0  0.000
59   05:00 2026-07-21 05:00:00 0.141 0.302 0.319 0.275      0  0.000
60   05:15 2026-07-21 05:15:00 0.144 0.305 0.323 0.275      0  0.000
61   05:30 2026-07-21 05:30:00 0.147 0.309 0.327 0.275      0  0.000
62   05:45 2026-07-21 05:45:00 0.150 0.312 0.330 0.275      0  0.029
63   06:00 2026-07-21 06:00:00 0.155 0.318 0.337 0.275      0  0.077
64   06:15 2026-07-21 06:15:00 0.160 0.324 0.343 0.275      0  0.113
65   06:30 2026-07-21 06:30:00 0.160 0.324 0.344 0.275      0  0.148
66   06:45 2026-07-21 06:45:00 0.157 0.320 0.339 0.275      0  0.231
67   07:00 2026-07-21 07:00:00 0.167 0.333 0.353 0.275      0  0.333
68   07:15 2026-07-21 07:15:00 0.159 0.324 0.343 0.275      0  0.415
69   07:30 2026-07-21 07:30:00 0.155 0.318 0.337 0.275      0  0.498
70   07:45 2026-07-21 07:45:00 0.136 0.296 0.312 0.275      0  0.636
71   08:00 2026-07-21 08:00:00 0.165 0.330 0.350 0.275      0  0.807
72   08:15 2026-07-21 08:15:00 0.149 0.311 0.329 0.275      0  0.946
73   08:30 2026-07-21 08:30:00 0.142 0.303 0.320 0.275      0  1.086
74   08:45 2026-07-21 08:45:00 0.126 0.283 0.298 0.275      0  1.267
75   09:00 2026-07-21 09:00:00 0.153 0.316 0.335 0.275      0  1.473
76   09:15 2026-07-21 09:15:00 0.120 0.276 0.291 0.275      0  1.655
77   09:30 2026-07-21 09:30:00 0.107 0.261 0.274 0.275      0  1.836
78   09:45 2026-07-21 09:45:00 0.078 0.225 0.234 0.275      0  2.048
79   10:00 2026-07-21 10:00:00 0.101 0.253 0.265 0.275      0  2.276
80   10:15 2026-07-21 10:15:00 0.083 0.231 0.241 0.275      0  2.486
81   10:30 2026-07-21 10:30:00 0.072 0.218 0.226 0.275      0  2.696
82   10:45 2026-07-21 10:45:00 0.057 0.200 0.207 0.275      0  2.921
83   11:00 2026-07-21 11:00:00 0.058 0.202 0.209 0.275      0  3.174
84   11:15 2026-07-21 11:15:00 0.054 0.196 0.202 0.275      0  3.398
85   11:30 2026-07-21 11:30:00 0.034 0.172 0.176 0.275      0  3.622
86   11:45 2026-07-21 11:45:00 0.015 0.149 0.151 0.275      0  3.778
87   12:00 2026-07-21 12:00:00 0.017 0.152 0.154 0.275      0  3.905
88   12:15 2026-07-21 12:15:00 0.009 0.142 0.143 0.275      0  4.062
89   12:30 2026-07-21 12:30:00 0.007 0.140 0.141 0.275      0  4.219
90   12:45 2026-07-21 12:45:00 0.006 0.138 0.139 0.275      0  4.293
91   13:00 2026-07-21 13:00:00 0.005 0.137 0.137 0.275      0  4.330
92   13:15 2026-07-21 13:15:00 0.004 0.136 0.136 0.275      0  4.404
93   13:30 2026-07-21 13:30:00 0.004 0.136 0.137 0.275      0  4.479
94   13:45 2026-07-21 13:45:00 0.003 0.135 0.135 0.275      0  4.465
95   14:00 2026-07-21 14:00:00 0.000 0.131 0.131 0.275      0  4.399
96   14:15 2026-07-21 14:15:00 0.001 0.132 0.132 0.275      0  4.384
97   14:30 2026-07-21 14:30:00 0.001 0.132 0.132 0.275      0  4.370
98   14:45 2026-07-21 14:45:00 0.004 0.136 0.136 0.275      0  4.295
99   15:00 2026-07-21 15:00:00 0.003 0.134 0.135 0.270      0  4.189
100  15:15 2026-07-21 15:15:00 0.006 0.138 0.139 0.270      0  4.113
101  15:30 2026-07-21 15:30:00 0.010 0.143 0.144 0.270      0  4.038
102  15:45 2026-07-21 15:45:00 0.029 0.166 0.169 0.289      0  3.910
103  16:00 2026-07-21 16:00:00 0.026 0.163 0.166 0.327      0  3.751
104  16:15 2026-07-21 16:15:00 0.056 0.199 0.206 0.345      0  3.622
105  16:30 2026-07-21 16:30:00 0.064 0.208 0.215 0.364      0  3.494
106  16:45 2026-07-21 16:45:00 0.074 0.221 0.230 0.364      0  3.330
107  17:00 2026-07-21 17:00:00 0.068 0.213 0.221 0.350      0  3.147
108  17:15 2026-07-21 17:15:00 0.085 0.233 0.244 0.350      0  2.983
109  17:30 2026-07-21 17:30:00 0.106 0.260 0.273 0.350      0  2.820
110  17:45 2026-07-21 17:45:00 0.124 0.281 0.296 0.350      0  2.624
111  18:00 2026-07-21 18:00:00 0.113 0.268 0.281 0.350      0  2.404
112  18:15 2026-07-21 18:15:00 0.129 0.288 0.303 0.350      0  2.209
113  18:30 2026-07-21 18:30:00 0.141 0.302 0.319 0.350      0  2.013
114  18:45 2026-07-21 18:45:00 0.153 0.316 0.335 0.350      0  1.813
115  19:00 2026-07-21 19:00:00 0.142 0.302 0.319 0.350      0  1.608
116  19:15 2026-07-21 19:15:00 0.151 0.313 0.332 0.350      0  1.409
117  19:30 2026-07-21 19:30:00 0.158 0.322 0.342 0.350      0  1.210
118  19:45 2026-07-21 19:45:00 0.165 0.330 0.350 0.350      0  1.019
119  20:00 2026-07-21 20:00:00 0.165 0.331 0.351 0.355      0  0.823
120  20:15 2026-07-21 20:15:00 0.171 0.338 0.359 0.355      0  0.634
121  20:30 2026-07-21 20:30:00 0.174 0.341 0.363 0.355      0  0.444
122  20:45 2026-07-21 20:45:00 0.175 0.342 0.364 0.336      0  0.324
123  21:00 2026-07-21 21:00:00 0.177 0.345 0.366 0.298      0  0.228
124  21:15 2026-07-21 21:15:00 0.176 0.344 0.365 0.280      0  0.107
125  21:30 2026-07-21 21:30:00 0.175 0.342 0.364 0.261      0  0.000
126  21:45 2026-07-21 21:45:00 0.170 0.336 0.357 0.261      0  0.000
127  22:00 2026-07-21 22:00:00 0.176 0.344 0.365 0.275      0  0.023
128  22:15 2026-07-21 22:15:00 0.169 0.335 0.356 0.275      0  0.004
129  22:30 2026-07-21 22:30:00 0.172 0.338 0.359 0.275      0  0.000
130  22:45 2026-07-21 22:45:00 0.159 0.324 0.343 0.275      0  0.000
131  23:00 2026-07-21 23:00:00 0.166 0.332 0.352 0.275      0  0.000
132  23:15 2026-07-21 23:15:00 0.156 0.320 0.339 0.275      0  0.000
133  23:30 2026-07-21 23:30:00 0.154 0.317 0.336 0.275      0  0.000
134  23:45 2026-07-21 23:45:00 0.146 0.308 0.326 0.275      0  0.000
2026-07-20 14:24:03 info: No reduced hours applied for Accu
2026-07-20 14:24:03 info: No reduced power applied during discharging at low soc
2026-07-20 14:24:03 info: No reduced power applied during charging at high soc
2026-07-20 14:24:03 info: Startwaarde SoC Accu: 50.0%

2026-07-20 14:24:04 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2026-07-20 14:24:04 info: Instellingen voor laden van EV: Tesla Model 3
2026-07-20 14:24:04 info: Direct laden is uit
2026-07-20 14:24:04 info:  Ampere  Effic. Grid kW Accu kW
2026-07-20 14:24:04 info:    0.00    1.00    0.00    0.00
2026-07-20 14:24:04 info:   10.00    1.00    6.90    6.90
2026-07-20 14:24:04 info:   12.00    1.00    8.28    8.28
2026-07-20 14:24:04 info:   14.00    1.00    9.66    9.66
2026-07-20 14:24:04 info:   16.00    0.99   11.04   10.93
2026-07-20 14:24:04 info: Capaciteit accu: 75.0 kWh
2026-07-20 14:24:04 info: Maximaal laadvermogen: 11.04 kW
2026-07-20 14:24:04 info: Klaar met laden op: 20-07-2026 16:00:00
2026-07-20 14:24:04 info: Huidig laadniveau: 49.0 %
2026-07-20 14:24:04 info: Gewenst laadniveau:90.0 %
2026-07-20 14:24:04 info: Marge voor het laden: 0 %
2026-07-20 14:24:04 info: Locatie: home
2026-07-20 14:24:04 info: Ingeplugged:True
2026-07-20 14:24:04 waarschuwing: Er is te weinig tijd om tot 90.0% te laden
2026-07-20 14:24:04 info: Bijgesteld gewenst laadniveau:72.3 %
2026-07-20 14:24:04 info: Benodigde netto energie: 17.481 kWh
2026-07-20 14:24:04 info: Tijd nodig om te laden: 1:36 uur
2026-07-20 14:24:04 info: Afgerond naar hele intervallen: 7 kwartier
2026-07-20 14:24:04 info: Stand laden schakelaar: on
2026-07-20 14:24:04 info: Stand aantal ampere laden: 14.0 A
2026-07-20 14:24:04 info: Opladen wordt ingepland.
2026-07-20 14:24:04 info: Instellingen voor laden van EV: Kia EV6
2026-07-20 14:24:04 info: Direct laden is uit
2026-07-20 14:24:04 info:  Ampere  Effic. Grid kW Accu kW
2026-07-20 14:24:04 info:    0.00    1.00    0.00    0.00
2026-07-20 14:24:04 info:   10.00    1.00    6.90    6.90
2026-07-20 14:24:04 info:   12.00    1.00    8.28    8.28
2026-07-20 14:24:04 info:   14.00    1.00    9.66    9.66
2026-07-20 14:24:04 info:   16.00    0.99   11.04   10.93
2026-07-20 14:24:04 info: Capaciteit accu: 80.0 kWh
2026-07-20 14:24:04 info: Maximaal laadvermogen: 11.04 kW
2026-07-20 14:24:04 info: Klaar met laden op: 19-07-2026 18:00:00
2026-07-20 14:24:04 info: Huidig laadniveau: 89.0 %
2026-07-20 14:24:04 info: Gewenst laadniveau:100.0 %
2026-07-20 14:24:04 info: Marge voor het laden: 0 %
2026-07-20 14:24:04 info: Locatie: home
2026-07-20 14:24:04 info: Ingeplugged:True
2026-07-20 14:24:04 waarschuwing: Er is te weinig tijd om tot 100.0% te laden
2026-07-20 14:24:04 info: Bijgesteld gewenst laadniveau:89.0 %
2026-07-20 14:24:04 info: Benodigde netto energie: 0.000 kWh
2026-07-20 14:24:04 info: Tijd nodig om te laden: 0:0 uur
2026-07-20 14:24:04 info: Afgerond naar hele intervallen: 0 kwartier
2026-07-20 14:24:04 info: Stand laden schakelaar: off
2026-07-20 14:24:04 info: Stand aantal ampere laden: 0.0 A
2026-07-20 14:24:04 info: Opladen wordt niet ingepland, omdat werkelijk niveau (89.0%) hoger is of gelijk aan gewenst niveau (89.0% minus de marge 0%), opgegeven tijdstip (2026-07-19 18:00:00) is verouderd.
2026-07-20 14:24:04 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-07-20 14:24:04 info: Strategie: minimale kosten
2026-07-20 14:24:04 info: Maximale fout (maximal gap): 0.005000 euro
2026-07-20 14:24:04 info: Rekentijd: 0.07  sec
2026-07-20 14:24:04 waarschuwing: Geen oplossing voor: minimize cost

Full Electric | 2x Deye 12KSG04LP3 met 1.680Ah LFP 51,2V (4x Seplos Mason 280, 2x Seplos vertical 280) | 23,3 kWp PV


  • Dogooder
  • Registratie: April 2004
  • Laatst online: 19:36

Dogooder

dus...

Er lijkt inderdaad een bug te zitten in de ev setup loop waarbij de ready waarde niet per EV wordt bijgehouden. De solver pakt dus altijd de waarde van de laatste EV in de lijst.

Ik zal even kijken of ik een PR kan aanmaken met een fix

Update: Ik heb het issue kunnen reproduceren, maar dit is meer dan een incorrecte ready waarde. Lijkt een floating point precision dingetje. Maar het is reproduceerbaar, dus een eventuele fix valt te testen :)

[ Voor 31% gewijzigd door Dogooder op 21-07-2026 12:26 ]


  • Frankvbr
  • Registratie: November 2004
  • Laatst online: 03-08 20:35
Ik ben sinds kort begonnen met DAO. Met de insteek alles optimaal te hebben voor volgend jaar.
Inmiddels ook een 5khw accu, maar nog niet aangesloten aangezien dit met nog geen geld oplevert/kost (per 1 januari 2027 pas switch naar dynamisch tarief). In Home Assistant al wel een virtuele accu toegevoegd om aan te sturen.

Zit nu te sukkelen met de accu, maar ik denk dat ik iets totaal niet begrijp.

Vanaf een uur of 21.00 uur verwacht ik dat de accu moet ontladen. Alleen ik krijg een positieve waarde terug (400w) in plaats van een negatieve. Wat doe ik fout?

De entity set power feedin voedt mijn input helper. Deze wordt echter alleen geupdate indien deze een positieve waarde heeft. Bij een (verwachte) negatieve waarde wordt deze niet aangepast, maar als ik kijk naar de logging zie ik ook geen negatieve waarde. Wat mis ik?
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
2026-07-23 22:00:00 info: Day Ahead Optimalisering versie: 2026.6.0
2026-07-23 22:00:00 info: Day Ahead Optimalisering gestart op: 23-07-2026 22:00:00
2026-07-23 22:00:00 info: Day Ahead Optimalisatie gestart: 23-07-2026 22:00:00 taak: calc_optimum
2026-07-23 22:00:00 info: Debug = False
2026-07-23 22:00:00 info: Baseload uit instellingen
2026-07-23 22:00:00 info: Start waarden: 
      uur                tijd  spot   p_l   p_t  base  pv_ac  pv_dc
0   22:00 2026-07-23 22:00:00 0.187 0.361 0.250 0.300  0.000      0
1   23:00 2026-07-23 23:00:00 0.170 0.341 0.230 0.280  0.000      0
2   00:00 2026-07-24 00:00:00 0.161 0.330 0.219 0.240  0.000      0
3   01:00 2026-07-24 01:00:00 0.157 0.325 0.214 0.240  0.000      0
4   02:00 2026-07-24 02:00:00 0.150 0.317 0.206 0.240  0.018      0
5   03:00 2026-07-24 03:00:00 0.153 0.320 0.209 0.240  0.000      0
6   04:00 2026-07-24 04:00:00 0.154 0.321 0.210 0.240  0.000      0
7   05:00 2026-07-24 05:00:00 0.162 0.331 0.220 0.240  0.000      0
8   06:00 2026-07-24 06:00:00 0.173 0.345 0.234 0.240  0.105      0
9   07:00 2026-07-24 07:00:00 0.168 0.338 0.227 0.280  0.197      0
10  08:00 2026-07-24 08:00:00 0.160 0.329 0.218 0.280  0.482      0
11  09:00 2026-07-24 09:00:00 0.135 0.299 0.188 0.240  1.433      0
12  10:00 2026-07-24 10:00:00 0.113 0.271 0.161 0.240  0.591      0
13  11:00 2026-07-24 11:00:00 0.086 0.240 0.129 0.240  1.466      0
14  12:00 2026-07-24 12:00:00 0.059 0.206 0.095 0.240  4.503      0
15  13:00 2026-07-24 13:00:00 0.031 0.172 0.062 0.240  1.089      0
16  14:00 2026-07-24 14:00:00 0.010 0.148 0.037 0.280  2.745      0
17  15:00 2026-07-24 15:00:00 0.018 0.157 0.046 0.280  4.611      0
18  16:00 2026-07-24 16:00:00 0.063 0.211 0.100 0.300  3.477      0
19  17:00 2026-07-24 17:00:00 0.109 0.267 0.156 0.300  3.045      0
20  18:00 2026-07-24 18:00:00 0.152 0.319 0.208 0.300  2.165      0
21  19:00 2026-07-24 19:00:00 0.180 0.352 0.241 0.300  1.392      0
22  20:00 2026-07-24 20:00:00 0.201 0.378 0.267 0.300  0.570      0
23  21:00 2026-07-24 21:00:00 0.204 0.382 0.271 0.300  0.072      0
24  22:00 2026-07-24 22:00:00 0.195 0.371 0.260 0.300  0.000      0
25  23:00 2026-07-24 23:00:00 0.180 0.353 0.242 0.280  0.000      0
2026-07-23 22:00:00 info: No reduced hours applied for VirtueelMarstek
2026-07-23 22:00:00 info: No reduced power applied during discharging at low soc
2026-07-23 22:00:00 info: No reduced power applied during charging at high soc
2026-07-23 22:00:00 info: Startwaarde SoC VirtueelMarstek: 5.117%

2026-07-23 22:00:00 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2026-07-23 22:00:00 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-07-23 22:00:00 info: Strategie: minimale kosten
2026-07-23 22:00:00 info: Maximale fout (maximal gap): 0.005000 euro
2026-07-23 22:00:00 info: Rekentijd: 0.03  sec
2026-07-23 22:00:00 info: Het programma heeft een optimale oplossing gevonden.
2026-07-23 22:00:00 info: Laad volume in uur 0 22:00 0.0 kWh
2026-07-23 22:00:00 info: 0 0.839813818181643 0.0
2026-07-23 22:00:00 info: 1 0.160186181818357 2.5
2026-07-23 22:00:00 info: Laad volume in uur 15 13:00 0.0 kWh
2026-07-23 22:00:00 info: 0 0.9380000000001765 0.0
2026-07-23 22:00:00 info: 1 0.06199999999982374 2.5
2026-07-23 22:00:00 info: Laad volume in uur 16 14:00 0.0 kWh
2026-07-23 22:00:00 info: 0 0.014000000000000212 0.0
2026-07-23 22:00:00 info: 1 0.9859999999999998 2.5
2026-07-23 22:00:00 info: Laad volume in uur 17 15:00 0.0 kWh
2026-07-23 22:00:00 info: 1 1.0 2.5
2026-07-23 22:00:00 info: Ontlaad volume in uur 23 21:00 0.228 kWh
2026-07-23 22:00:00 info: 1 0.09120000000000002 2.5
2026-07-23 22:00:00 info: Ontlaad volume in uur 24 22:00 0.29999999999999993 kWh
2026-07-23 22:00:00 info: 1 0.11999999999999997 2.5
2026-07-23 22:00:00 info: Ontlaad volume in uur 25 23:00 0.28 kWh
2026-07-23 22:00:00 info: 1 0.11200000000000002 2.5
2026-07-23 22:00:00 info: In- en uitgaande energie per uur batterij VirtueelMarstek
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 22:00   0.40  88.00   0.35   0.00   0.35 100.00   0.35  88.00  12.00
 23:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 00:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 01:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 02:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 03:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 04:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 05:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 06:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 07:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 08:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 09:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 10:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 11:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 12:00   0.00     --   0.00   0.00   0.00     --   0.00     --  12.00
 13:00   0.15  88.00   0.14   0.00   0.14 100.00   0.14  88.00  14.66
 14:00   2.46  88.00   2.17   0.00   2.17 100.00   2.17  88.00  57.03
 15:00   2.50  88.00   2.20   0.00   2.20 100.00   2.20  88.00 100.00
 16:00   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
 18:00   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
 20:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 21:00  -0.23  88.00  -0.26   0.00  -0.26 100.00  -0.26  88.00  94.94
 22:00  -0.30  88.00  -0.34   0.00  -0.34 100.00  -0.34  88.00  88.28
 23:00  -0.28  88.00  -0.32   0.00  -0.32 100.00  -0.32  88.00  82.07
Totaal   4.71          3.94   0.00   3.94          3.94              
2026-07-23 22:00:00 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 22:00    0.40     0.00   0.70   0.00   0.30   0.00   0.00   0.00   0.00   0.25   -0.00  20.00
 23:00    0.00     0.00   0.28   0.00   0.28   0.00   0.00   0.00   0.00   0.10   -0.00  20.00
 00:00    0.00     0.00   0.24   0.00   0.24   0.00   0.00   0.00   0.00   0.08   -0.00  20.00
 01:00    0.00     0.00   0.24   0.00   0.24   0.00   0.00   0.00   0.00   0.08   -0.00  20.00
 02:00    0.00     0.00   0.22   0.00   0.24   0.00   0.00   0.00   0.02   0.07   -0.00  20.00
 03:00    0.00     0.00   0.24   0.00   0.24   0.00   0.00   0.00   0.00   0.08   -0.00  20.00
 04:00    0.00     0.00   0.24   0.00   0.24   0.00   0.00   0.00   0.00   0.08   -0.00  20.00
 05:00    0.00     0.00   0.24   0.00   0.24   0.00   0.00   0.00   0.00   0.08   -0.00  20.00
 06:00    0.00     0.00   0.13   0.00   0.24   0.00   0.00   0.00   0.11   0.05   -0.00  20.00
 07:00    0.00     0.00   0.08   0.00   0.28   0.00   0.00   0.00   0.20   0.03   -0.00  20.00
 08:00    0.00     0.00   0.00   0.20   0.28   0.00   0.00   0.00   0.48   0.00   -0.04  20.00
 09:00    0.00     0.00   0.00   1.19   0.24   0.00   0.00   0.00   1.43   0.00   -0.22  20.00
 10:00    0.00     0.00   0.00   0.35   0.24   0.00   0.00   0.00   0.59   0.00   -0.06  20.00
 11:00    0.00     0.00   0.00   1.23   0.24   0.00   0.00   0.00   1.47   0.00   -0.16  20.00
 12:00    0.00     0.00   0.00   4.26   0.24   0.00   0.00   0.00   4.50   0.00   -0.41  20.00
 13:00    0.15     0.00   0.00   0.69   0.24   0.00   0.00   0.00   1.09   0.00   -0.04  20.00
 14:00    2.46     0.00   0.00   0.00   0.28   0.00   0.00   0.00   2.74   0.00   -0.00  20.00
 15:00    2.50     0.00   0.00   1.83   0.28   0.00   0.00   0.00   4.61   0.00   -0.08  20.00
 16:00    0.00     0.00   0.00   3.18   0.30   0.00   0.00   0.00   3.48   0.00   -0.32  20.00
 17:00    0.00     0.00   0.00   2.75   0.30   0.00   0.00   0.00   3.04   0.00   -0.43  20.00
 18:00    0.00     0.00   0.00   1.86   0.30   0.00   0.00   0.00   2.17   0.00   -0.39  20.00
 19:00    0.00     0.00   0.00   1.09   0.30   0.00   0.00   0.00   1.39   0.00   -0.26  20.00
 20:00    0.00     0.00   0.00   0.27   0.30   0.00   0.00   0.00   0.57   0.00   -0.07  20.00
 21:00    0.00     0.23   0.00   0.00   0.30   0.00   0.00   0.00   0.07   0.00   -0.00  20.00
 22:00    0.00     0.30   0.00   0.00   0.30   0.00   0.00   0.00   0.00   0.00   -0.00  20.00
 23:00    0.00     0.28   0.00   0.00   0.28   0.00   0.00   0.00   0.00   0.00   -0.00  20.00
Totaal    5.52     0.81   2.62  18.91   6.96   0.00   0.00   0.00  27.96   0.88   -2.49    NaN

2026-07-23 22:00:00 info: Consumption               2.62 (kWh)
2026-07-23 22:00:00 info: Cost consumption          0.88 (€)
2026-07-23 22:00:00 info: Tariff consumption        0.337 (€/kWh)
2026-07-23 22:00:00 info: Production               18.91 (kWh)
2026-07-23 22:00:00 info: Profit production        -2.49 (€)
2026-07-23 22:00:00 info: Tariff production         0.131 (€/kWh)

2026-07-23 22:00:00 info: 
Calculation profit after optimize in €
Cost before optimize             -1.66
Cost consumption      0.88
Cycle cost            0.06
Penalty cost          0.02
EV switch costs       0.00
Battery storage      -1.04
Boiler storage        0.00
Profit production    -2.49
Total                -2.57
Cost after optimize              -2.57
Profit:                           0.90
2026-07-23 22:00:00 info: Doorzetten van alle settings naar HA
2026-07-23 22:00:00 info: Grid balanceren: off
2026-07-23 22:00:00 info: Grid set point: 700.0 W
2026-07-23 22:00:00 info: Cycle cost VirtueelMarstek: 0.06 euro
2026-07-23 22:00:00 info: Netto vermogen naar(+)/uit(-) omvormer VirtueelMarstek: 400 W 
2026-07-23 22:00:00 info: Vermogen uit batterij: -352W
2026-07-23 22:00:00 info: Vermogen dat binnenkomt van pv: 0W
2026-07-23 22:00:00 info: Vermogen dat binnenkomt van ac: 352W
2026-07-23 22:00:00 info: Waarde SoC na eerste uur: 12.0%
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
{
  "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.00000
    },
    "cost_supplier_consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2026-01-01": 0.020000
    },
    "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.02000
    },
    "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.24, 0.24, 0.24, 0.24, 0.24, 0.24, 0.24, 0.28, 0.28, 0.24, 0.24, 0.24, 0.24, 0.24, 0.28, 0.28, 0.30, 0.30, 0.30, 0.30, 0.30, 0.30, 0.30, 0.28],
  "graphical_backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": false,
    "prices_spot": true,
    "average_consumption": true,
    "show": "true"
  },
  "interval": "1hour",
  "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": [
    {
      "name": "VirtueelMarstek",
      "entity actual level": "sensor.marstek_venus_e_5_12kwh_3nd_gen",
      "capacity": 5.12,
      "upper limit": 100,
      "lower limit": 12,
      "optimal lower level": 12,
      "minimum power": 0,
      "cycle cost": 0.01,
      "dc_to_bat efficiency": 1.0,
      "bat_to_dc efficiency": 1.0,
      "entity set power feedin": "input_number.marstek_acc_power_feed",
      "charge stages": [
        { "power": 0.0, "efficiency": 1.0 },
        { "power": 2500, "efficiency": 0.88 }
      ],
      "discharge stages": [
        { "power": 0.0, "efficiency": 1.0 },
        { "power": 2500, "efficiency": 0.88 }
      ]
    }
  ],
  "solar": [
    {
      "name": "WoonkamerPlatDak",
      "entities sensor": [
        "sensor.sonoff_zonnepanelen_links_totaal",
        "sensor.sonoff_zonnepanelen_rechts_totaal"
      ],
      "strings": [
        { "tilt": 15, "orientation": -105, "capacity": 2.58, "yield": 0.004515 },
        { "tilt": 15, "orientation": 75, "capacity": 2.58, "yield": 0.004515 },
        { "tilt": 0, "orientation": -135, "capacity": 0.68, "yield": 0.00085 }
      ]
    },
    {
      "name": "Garage",
      "entities sensor": [
        "sensor.kwh_meter_5c2faf0e3906_total_power_export"
      ],
      "strings": [
        { "tilt": 15, "orientation": -105, "capacity": 1.7, "yield": 0.0031875 },
        { "tilt": 15, "orientation": 75, "capacity": 1.7, "yield": 0.0031875 }
      ]
    },
    {
      "name": "Tuinhuis",
      "entities sensor": [
        "sensor.kwh_meter_tuinhuis_zonnepanelen_energie_export_3"
      ],
      "tilt": 25,
      "orientation": -25,
      "capacity": 0.86,
      "yield": 0.001849
    }
  ],
  "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": true,
    "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
}
Afbeeldingslocatie: https://tweakers.net/i/PTnyz0ldD-apT5MwGOAteiY1nD0=/x800/filters:strip_exif()/f/image/vnAh34KuxqaL4KI2sVrHxSYX.png?f=fotoalbum_large

  • Out.of.Control
  • Registratie: Augustus 2012
  • Laatst online: 16:24
Ik heb (nog) geen ervaring met DAO of met gesimuleerde accu's, maar bij echte accu's betekent een positieve waarde dat hij aan het ontladen is. Eigenlijk zelfde als PV, een positieve waarde betekent energie die naar je huis vloeit. En daarvan kan een deel weer richting het net gaan.

  • thomvh
  • Registratie: September 2013
  • Laatst online: 18:27
Frankvbr schreef op vrijdag 24 juli 2026 @ 17:30:
Ik ben sinds kort begonnen met DAO. Met de insteek alles optimaal te hebben voor volgend jaar.
Inmiddels ook een 5khw accu, maar nog niet aangesloten aangezien dit met nog geen geld oplevert/kost (per 1 januari 2027 pas switch naar dynamisch tarief). In Home Assistant al wel een virtuele accu toegevoegd om aan te sturen.

Zit nu te sukkelen met de accu, maar ik denk dat ik iets totaal niet begrijp.

Vanaf een uur of 21.00 uur verwacht ik dat de accu moet ontladen. Alleen ik krijg een positieve waarde terug (400w) in plaats van een negatieve. Wat doe ik fout?

De entity set power feedin voedt mijn input helper. Deze wordt echter alleen geupdate indien deze een positieve waarde heeft. Bij een (verwachte) negatieve waarde wordt deze niet aangepast, maar als ik kijk naar de logging zie ik ook geen negatieve waarde. Wat mis ik?


[...]


[...]


[...]
DAO werkt gewoon goed zie:
code:
1
Vermogen uit batterij: -352W
Daarbij zie je hem in de grafiek terugleveren in de avond.

[ Voor 3% gewijzigd door thomvh op 24-07-2026 18:42 ]


  • Frankvbr
  • Registratie: November 2004
  • Laatst online: 03-08 20:35
thomvh schreef op vrijdag 24 juli 2026 @ 18:31:
[...]

DAO werkt gewoon goed zie:
code:
1
Vermogen uit batterij: -352W
Daarbij zie je hem in de grafiek terugleveren in de avond.
Eens in de grafiek. Maar de helper wordt niet gevoed met een negatief getal. Ook al heeft die gewoon een range van -2500 tot 2500

  • thomvh
  • Registratie: September 2013
  • Laatst online: 18:27
Frankvbr schreef op vrijdag 24 juli 2026 @ 18:54:
[...]

Eens in de grafiek. Maar de helper wordt niet gevoed met een negatief getal. Ook al heeft die gewoon een range van -2500 tot 2500
Hij doet het wel goed. Je batterij is leeg. Zie helemaal links op de grafiek. Hij wil dus bijladen om die 12% te komen die je hebt ingesteld.

De feedin verander alleen als je ook de berekening laat doen. Dus pas wanneer de scheduler de berekening draait om idk 22 uur de volgende dag zul je die waarde negatief zien.

[ Voor 19% gewijzigd door thomvh op 24-07-2026 21:53 ]


  • The Source
  • Registratie: April 2000
  • Laatst online: 05-08 20:16
Ik heb mijn batterij in DAO en ben nu mijn EVCC laadpaal aan het toevoegen. Probleem: Op dit moment gaat EVCC laden zodra mijn batterij aan het net begint terug te leveren, EVCC denkt solar beschikbaar :) . Nu kan ik dit makkelijk in het script stoppen, echter... kan DAO plannen dat de EV uit de batterij opgeladen moet worden? Of komt dat nooit voor?

Ik zit hier denk ik een beetje in dubio wie controle heeft over de laadpaal, DAO of EVCC... Enige praktijk tips (en automations ! ) zijn uiteraard welkom!

[ Voor 25% gewijzigd door The Source op 27-07-2026 21:13 ]


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
The Source schreef op maandag 27 juli 2026 @ 21:11:
Ik heb mijn batterij in DAO en ben nu mijn EVCC laadpaal aan het toevoegen. Probleem: Op dit moment gaat EVCC laden zodra mijn batterij aan het net begint terug te leveren, EVCC denkt solar beschikbaar :) . Nu kan ik dit makkelijk in het script stoppen, echter... kan DAO plannen dat de EV uit de batterij opgeladen moet worden? Of komt dat nooit voor?

Ik zit hier denk ik een beetje in dubio wie controle heeft over de laadpaal, DAO of EVCC... Enige praktijk tips (en automations ! ) zijn uiteraard welkom!
Als je jouw batterij ook in EVCC zet kan je instellen of je wel/niet vanuit je thuisbatterij wil laden. Dan is het toch opgelost? Ik gebruik EVCC voor het laden van mijn auto en DAO voor het aansturen van mijn thuisbatterij en heb hier nooit problemen mee.

Technisch gezien heb ik wel een fallback automation in HomeAssistant die ervoor zorgt dat de batterij niet kan ontladen als mijn auto laadt (mocht dat op hetzelfde tijdstip gepland worden).

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh

Er is een nieuwe testversie gepubliceerd: 2026.7.0.rc1

Dit staat in de changelog:

This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  2. @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:
- 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 @gijs)
- updates of several used python modules

Je vindt de bijdrage van@storeman in het dashboard onder de optie "UI V2" (op je mobiel moet je misschien je scherm even draaien).
Dit is "work in progress". Er zitten nog een paar foutjes in (zoals bovenstaande), maar het geeft een goed indicatie welke kant het opgaat met het dashboard.
Graag testen en geef hier je commentaar: wat vind je leuk, fijn, slecht en wat moet/mag anders?

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: 11:58
Icoontjes lijken niet te werken bij mij (er vanuit gaande dat daar icoontjes moesten komen)

Grafiek is 'dark mode', UI niet (van die grafieken ooit iets met apexcharts ofzo maken zou best een leuke verbetering zijn trouwens. Bij Reports is dat al wel gedaan dus het zal nog wel komen).

Afbeeldingslocatie: https://tweakers.net/i/4tCYs48tqdPpYVuusxIzMy-tK2U=/800x/filters:strip_exif()/f/image/TIWZDUboNw21zae91LDHKmTO.png?f=fotoalbum_large

Update tibber kan opzich best weg als je geen Tibber gebruikt.

Misschien hier geen 'Run' van maken maar 'Tasks'? Dan kun je daar ook eventuele toekomstige taken die niet direct 'run' zijn in kwijt. En als we toch aan het copuleren zijn met kleine ijverige beestjes: misschien is 'Execute' een betere term dan 'Run'?

Afbeeldingslocatie: https://tweakers.net/i/W6lfkzOOF8jmRWKmY4bXKSqNjYA=/800x/filters:strip_exif()/f/image/U1FmZYotijLWWk4IYPIhgGg5.png?f=fotoalbum_largeHet is goed werk in ieder geval!

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 18:55
Mirabis schreef op maandag 27 juli 2026 @ 22:07:
[...]

Als je jouw batterij ook in EVCC zet kan je instellen of je wel/niet vanuit je thuisbatterij wil laden. Dan is het toch opgelost? Ik gebruik EVCC voor het laden van mijn auto en DAO voor het aansturen van mijn thuisbatterij en heb hier nooit problemen mee.

Technisch gezien heb ik wel een fallback automation in HomeAssistant die ervoor zorgt dat de batterij niet kan ontladen als mijn auto laadt (mocht dat op hetzelfde tijdstip gepland worden).
Samen met @hemertje heb ik in de Wiki wat extra voorbeeld automations rond om dit thema toegevoegd.. Misschien helpt dit je nog een stapje verder Potentieel Conflict Battery + Electric Vehicle

Aanvullingen, suggesties, etc. blijven van harte welkom.

  • Mirabis
  • Registratie: Juli 2013
  • Niet online
KC27 schreef op maandag 27 juli 2026 @ 23:45:
Er is een nieuwe testversie gepubliceerd: 2026.7.0.rc1

Dit staat in de changelog:

This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  2. @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:
- 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 @gijs)
- updates of several used python modules

Je vindt de bijdrage van@storeman in het dashboard onder de optie "UI V2" (op je mobiel moet je misschien je scherm even draaien).
Dit is "work in progress". Er zitten nog een paar foutjes in (zoals bovenstaande), maar het geeft een goed indicatie welke kant het opgaat met het dashboard.
Graag testen en geef hier je commentaar: wat vind je leuk, fijn, slecht en wat moet/mag anders?
Proxmox LXC met docker geupdatet van 2026.6.0.rc1 naar 2026.7.0.rc1 geeft
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
2026-07-28 13:21:38 fout: An error occurred while loading the CBC library:   cannot load library '/root/dao/prog/miplib/lib/libCbc.so': libnauty-2.8.9.so: cannot open shared object file: No such file or directory.  Additionally, ctypes.util.find_library() did not manage to locate a library called '/root/dao/prog/miplib/lib/libCbc.so'

2026-07-28 13:21:38 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 726, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 384, in calc_optimum
    model = Model()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/model.py", line 107, in __init__
    self.solver = mip.cbc.SolverCbc(self, name, sense)
                  ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/cbc.py", line 637, in __init__
    self._model = cbclib.Cbc_newModel()
                  ^^^^^^
NameError: name 'cbclib' is not defined
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 5007, in <module>
    main()
    ~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 4980, in main
    da_calc.run_task_function("calc_optimum")
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_base.py", line 726, in run_task_function
    getattr(self, run_task["function"])()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 384, in calc_optimum
    model = Model()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/model.py", line 107, in __init__
    self.solver = mip.cbc.SolverCbc(self, name, sense)
                  ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/cbc.py", line 637, in __init__
    self._model = cbclib.Cbc_newModel()
                  ^^^^^^
NameError: name 'cbclib' is not defined
Exception ignored in: <function SolverCbc.__del__ at 0x75eb9046cc20>
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/mip/cbc.py", line 1642, in __del__
    cbclib.Cbc_deleteModel(self._model)
NameError: name 'cbclib' is not defined
Lijkt gerelateerd aan https://github.com/corneel27/day-ahead/pull/410

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • Dogooder
  • Registratie: April 2004
  • Laatst online: 19:36

Dogooder

dus...

Mirabis schreef op dinsdag 28 juli 2026 @ 13:25:
[...]

Proxmox LXC met docker geupdatet van 2026.6.0.rc1 naar 2026.7.0.rc1 geeft


[...]

Lijkt gerelateerd aan https://github.com/corneel27/day-ahead/pull/410
Interessant, ik heb ook net mijn docker in lxc in proxmox geupdate naar 2026.7.0.rc1 maar ik heb dit niet.

Ik maak gebruik van dao-amd64:2026.7.0.rc1

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 18:55
KC27 schreef op maandag 27 juli 2026 @ 23:45:
Er is een nieuwe testversie gepubliceerd: 2026.7.0.rc1

Dit staat in de changelog:

This release contains two big changes/improvements:
  1. @storeman is started with the rewriting of the user-interface. You can find his proceedings with the menu-option "UI V2". It is mostly written in javascript.
  2. @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:
- 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 @gijs)
- updates of several used python modules

Je vindt de bijdrage van@storeman in het dashboard onder de optie "UI V2" (op je mobiel moet je misschien je scherm even draaien).
Dit is "work in progress". Er zitten nog een paar foutjes in (zoals bovenstaande), maar het geeft een goed indicatie welke kant het opgaat met het dashboard.
Graag testen en geef hier je commentaar: wat vind je leuk, fijn, slecht en wat moet/mag anders?
@KC27 , ik zie dat je, naast de dingen uit de change log, ook het EV laadgedrag dat ik in deze post had beschreven hebt verbeterd. Dank daarvoor.
Alles werkt nu zoals verwacht. Het valt me op dat er nu geen kleine stage factoren (0.0001) meer worden aangemaakt. Ook zie ik geen situaties meer waarbij meerdere laadstappen (b.v. 8A en 14A) tegelijk actief zijn. Uit het commentaar in de code begrijp ik dat dit komt door de introductie van een nieuwe exclusiviteits constraint. Mocht deze situaties onverhoopt toch nog een keer voorkomen dan worden beide zaken nu prima afgevangen. Super.
Daarnaast is ook de stop_laden logica aangepast aan de duur van het actieve interval. Zelf dacht ik hier naast de minuten ook de seconden (strftime("%Y-%m-%d %H:%M:%S")) nog nodig te hebben. Maar bij nader inzien verwacht ik dat de meeste gebruikers die 15min intervallen gebruiken het EV laden niet zullen gaan stoppen gedurende zo'n kort interval. Dus die seconden mogen met een gerust hart achterwege blijven.

Tenslotte kan ik bevestigen dat ook de "correct index error with reduce_power_low_soc and reduce_power_high_soc" waar ik eerder tegenaan liep nu is opgelost.

Nogmaals dank !!

  • balk
  • Registratie: Januari 2000
  • Laatst online: 19:40
@storeman mooi werk! Wat observaties van mijn kant
  • Ik doe een "Calc Optimize Debug" met missende data. Dat geeft keurig een groene balk met "optimize_debug: done, Started: 2026-07-28 17:01:50 || 4 seconds". Groen suggereert goed, en er zijn ook geen logs. Op de logs pagina zie ik wel een foutmelding. Hier kan nog wat gestroomlijnd worden
  • Icoontjes doen het bij mij wel
  • Reports V2 is nice!
  • ophalen Day Ahead prices heeft niet de mogelijkheid om datum op te geven. Na ophalen prijzen krijg ik dit in de log:
    2026-07-28 17:12:15 info: Day Ahead Optimalisatie gestart: 28-07-2026 17:12:15 taak: get_day_ahead_prices
    2026-07-28 17:12:15 info: Day ahead data already present

    en dan een debug run:
    2026-07-28 17:13:03 info: Day Ahead Optimalisering versie: 2026.7.0.rc1
    2026-07-28 17:13:03 info: Day Ahead Optimalisering gestart op: 28-07-2026 17:13:03
    2026-07-28 17:13:03 info: Day Ahead Optimalisatie gestart: 28-07-2026 17:13:03 taak: calc_optimum_met_debug
    2026-07-28 17:13:03 info: Debug = True
    2026-07-28 17:13:03 fout: Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken

  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
Dank voor de feedback zover. Ik ga proberen om een en ander vanavond op te pakken.

@balk welke datum zou je dan willen/moeten opgeven?

@DaBit om de grafieken van de runs interactief te maken, is er veel werk te verzetten. Dan moeten alle data punten opgeslagen worden in de database en gekoppeld aan een run worden. Ik zie hier zeker meerwaarde, maar daar zullen wel een paar iteraties overheen gaan. Ik denk wel dat het wat data problemen uit de Reports V2 kan tackelen. Prognosewaardes lopen hier soms vreemd uit de pas, wat zou kunnen komen door een soort 'voortschrijdend inzicht' welke elk kwartier/uur er is.

"Chaos kan niet uit de hand lopen"


  • balk
  • Registratie: Januari 2000
  • Laatst online: 19:40
storeman schreef op dinsdag 28 juli 2026 @ 17:27:
Dank voor de feedback zover. Ik ga proberen om een en ander vanavond op te pakken.

@balk welke datum zou je dan willen/moeten opgeven?

@DaBit om de grafieken van de runs interactief te maken, is er veel werk te verzetten. Dan moeten alle data punten opgeslagen worden in de database en gekoppeld aan een run worden. Ik zie hier zeker meerwaarde, maar daar zullen wel een paar iteraties overheen gaan. Ik denk wel dat het wat data problemen uit de Reports V2 kan tackelen. Prognosewaardes lopen hier soms vreemd uit de pas, wat zou kunnen komen door een soort 'voortschrijdend inzicht' welke elk kwartier/uur er is.
De data voor vandaag mist in de SQLite database. Morgen zit er wel in. Ik heb deze test-app normaal uit staan en dus wordt er normaal geen data opgehaald. Bij een run gaat het dan fout (vanzelfsprekend).
tomvandepoel3 schreef op dinsdag 28 juli 2026 @ 15:42:
[...]


@KC27 , ik zie dat je, naast de dingen uit de change log, ook het EV laadgedrag dat ik in deze post had beschreven hebt verbeterd. Dank daarvoor.
Alles werkt nu zoals verwacht. Het valt me op dat er nu geen kleine stage factoren (0.0001) meer worden aangemaakt. Ook zie ik geen situaties meer waarbij meerdere laadstappen (b.v. 8A en 14A) tegelijk actief zijn. Uit het commentaar in de code begrijp ik dat dit komt door de introductie van een nieuwe exclusiviteits constraint. Mocht deze situaties onverhoopt toch nog een keer voorkomen dan worden beide zaken nu prima afgevangen. Super.
Daarnaast is ook de stop_laden logica aangepast aan de duur van het actieve interval. Zelf dacht ik hier naast de minuten ook de seconden (strftime("%Y-%m-%d %H:%M:%S")) nog nodig te hebben. Maar bij nader inzien verwacht ik dat de meeste gebruikers die 15min intervallen gebruiken het EV laden niet zullen gaan stoppen gedurende zo'n kort interval. Dus die seconden mogen met een gerust hart achterwege blijven.

Tenslotte kan ik bevestigen dat ook de "correct index error with reduce_power_low_soc and reduce_power_high_soc" waar ik eerder tegenaan liep nu is opgelost.

Nogmaals dank !!
Blij dat het allemaal beter werkt!
Het meeste rewrite-work van de ev-module is gedaan door @Dogooder , dus alle credits voor hem.

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


  • wmc
  • Registratie: November 2012
  • Laatst online: 09:26

wmc

Ik kom interessant gedrag tegen het instellen van een vermogenslimiet als functie van de SOC. Het gedrag dat ik wil instelllen is:

SOC <= 94% P = 7200W
SOC>95% P=1800W

Zoals in de wiki nu interpreteer wordt er geëxtrapoleerd voorbij de ingestelde SOC waarde, oftewel, de helling die ik nu instel is (7200-1800) = 5400 W / % SOC, wat betekent dat er effectief boven de 95% SOC niet geladen wordt. Ik heb daarom een extra punt toegevoegd op 100% SOC, dat hetzelfde vermogen geeft als SOC 95%. De instelling die ik daarvoor heb gezet is:
code:
1
2
3
4
5
      "reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800},
        { "soc": 100, "power": 1800}],
Dit levert hetvolgende gedrag op:

Afbeeldingslocatie: https://tweakers.net/i/RDkEFWlbSX_ShEwMkkLDXtGmHss=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/zpLFD2LObWtztG2WnRwOwAIK.png?f=user_large

Als ik de 100% SOC weghaal en dus de volgende instelling gebruik
code:
1
2
3
4
      "reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800}],
krijg ik hetvolgende gedrag.

Afbeeldingslocatie: https://tweakers.net/i/LWPP35ruNAlDsK-8Z374eq0KVxU=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/CoJ0JC1Vil6uyheoKGrvxLLy.png?f=user_large


Waar zit mijn denkfout? Het lijkt er namelijk op dat met de eerste instelling het totale vermogen wordt beperkt op 1800W voor het hele SOC bereik.

  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
balk schreef op dinsdag 28 juli 2026 @ 19:00:
[...]

De data voor vandaag mist in de SQLite database. Morgen zit er wel in. Ik heb deze test-app normaal uit staan en dus wordt er normaal geen data opgehaald. Bij een run gaat het dan fout (vanzelfsprekend).
Ik heb dit net geprobeerd te reproduceren. Als ik de day-ahead data ophaal (zonder datums op te geven), dan wordt de data van vandaag (en morgen indien beschikbaar) gewoon opgehaald. Aan de run-logica zelf is niets gewijzigd. Het enige wat ik kan bedenken is dat bij het opgeven van datums, dat er geforceerd wordt opgehaald?

[ Voor 17% gewijzigd door storeman op 29-07-2026 10:10 ]

"Chaos kan niet uit de hand lopen"


  • balk
  • Registratie: Januari 2000
  • Laatst online: 19:40
storeman schreef op woensdag 29 juli 2026 @ 10:09:
[...]

Ik heb dit net geprobeerd te reproduceren. Als ik de day-ahead data ophaal (zonder datums op te geven), dan wordt de data van vandaag (en morgen indien beschikbaar) gewoon opgehaald. Aan de run-logica zelf is niets gewijzigd. Het enige wat ik kan bedenken is dat bij het opgeven van datums, dat er geforceerd wordt opgehaald?
@KC27 weet jij hoe dit werkt? Ik heb dit getest in de avond. Hierbij werden de prijzen van die dag niet opgehaald. @storeman heeft het zojuist getest en dan werkt het wel. Enig idee?

  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 18:55
@storeman ziet er strak uit! Wat kleine observaties van mijn kant

Als je naar de laatste beschikbare Chart/Log kijkt zijn de "Next", "+6h" en "Last" buttons insensitive (logisch). Maar als je een kwartier wacht, en er dus ondertussen een nieuwe Chart/Log beschikbaar is gekomen, dan blijven deze buttons insensitive en moet je dus eerst ergens een refresh forceren voordat je de meest recente details kunt bekijken.

Bij het bekijken van de reporting charts zie ik af en toe waarschuwingen in de achtergrond langs komen (de data in mijn test database vertoont wat gaten...).
code:
1
2
/home/tom/day-ahead/dao/lib/da_graph.py:360: UserWarning: Attempting to set identical low and high ylims makes transformation singular; automatically expanding.
  ax.set_ylim([min(0, ymin_left), ymax_left])
Dit gebeurt vooral in deze situatie (waarbij ik niet snap waarom de chart leeg is):
Afbeeldingslocatie: https://tweakers.net/i/CFDF1YRHQpL_GbkQhK-qQ7goSZ0=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/rqz5lpnvgmv2PUj154oBXqRS.png?f=user_large

Nog zoiets onbelangrijks, de chart titels zijn in het Nederlands (b.v. Verbruik en kosten vandaag) terwijl de pull-down opties in het Engels zijn (b.v. Today).

Bij het bekijken van de "Last year" Grid Chart, krijg ik een reproduceerbare internal error (mijn test database zal geen data van vorig jaar bevatten...):
Afbeeldingslocatie: https://tweakers.net/i/dIqSMKWDjMMwS64CGwz5eOhkCOU=/800x/filters:strip_exif()/f/image/FepreQ4MLv1ZNfJ300kKQUvr.png?f=fotoalbum_large

Afbeeldingslocatie: https://tweakers.net/i/bvk11c_aHhchnFBbuH-7ncyqtr0=/800x/filters:strip_exif()/f/image/MH8qA0LVKe2XTyO4NdY134f8.png?f=fotoalbum_large

Bij de Savings tables zie ik regelmatig Not A Number (NaN) waarden voor de totalen (hierbij zijn de waarden (die waarschijnlijk ontbreken in de DB) in de tabel 0 ipv 0.000 overal elders):
Afbeeldingslocatie: https://tweakers.net/i/Y8nZLUAnLBdorj9kPVvyDX2HloM=/800x/filters:strip_exif()/f/image/rRZ3QlJvidOpbPdesWJuVmWQ.png?f=fotoalbum_large

Nogmaals enkel klein bier. Dank voor je inspanningen.

  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 12:34
Ik heb de DHW-COP voor DAO dynamisch gemaakt. In plaats van een vaste COP 3.7 meet ik nu wekelijks de echte COP via de S0-meters en HeishaMon.

De thermische productie reken ik uit uit temperatuurverschil en flow, het elektrische verbruik komt van de pulsmeters.

Elke maandag wordt het weekgemiddelde bijgewerkt (75% oud, 25% nieuw) zodat de COP tbv de DHW het seizoen meebeweegt.

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


  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
tomvandepoel3 schreef op woensdag 29 juli 2026 @ 15:37:
@storeman ziet er strak uit! Wat kleine observaties van mijn kant

Als je naar de laatste beschikbare Chart/Log kijkt zijn de "Next", "+6h" en "Last" buttons insensitive (logisch). Maar als je een kwartier wacht, en er dus ondertussen een nieuwe Chart/Log beschikbaar is gekomen, dan blijven deze buttons insensitive en moet je dus eerst ergens een refresh forceren voordat je de meest recente details kunt bekijken.

Bij het bekijken van de reporting charts zie ik af en toe waarschuwingen in de achtergrond langs komen (de data in mijn test database vertoont wat gaten...).
code:
1
2
/home/tom/day-ahead/dao/lib/da_graph.py:360: UserWarning: Attempting to set identical low and high ylims makes transformation singular; automatically expanding.
  ax.set_ylim([min(0, ymin_left), ymax_left])
Dit gebeurt vooral in deze situatie (waarbij ik niet snap waarom de chart leeg is):
[Afbeelding]

Nog zoiets onbelangrijks, de chart titels zijn in het Nederlands (b.v. Verbruik en kosten vandaag) terwijl de pull-down opties in het Engels zijn (b.v. Today).

Bij het bekijken van de "Last year" Grid Chart, krijg ik een reproduceerbare internal error (mijn test database zal geen data van vorig jaar bevatten...):
[Afbeelding]

[Afbeelding]

Bij de Savings tables zie ik regelmatig Not A Number (NaN) waarden voor de totalen (hierbij zijn de waarden (die waarschijnlijk ontbreken in de DB) in de tabel 0 ipv 0.000 overal elders):
[Afbeelding]

Nogmaals enkel klein bier. Dank voor je inspanningen.
Ik zal kijken of ik de knoppen automatisch kan enabelen bij nieuwe data. Voordeel nu is wel dat een F5 gewoon werkt zonder heraccordering van de POST. En, hoevaak zit je live naar deze output te kijken?

Qua gerenderde charts en de saving-table: werkt dit in de oude interface wel goed? Ik heb hier technisch geen wijzigingen in gemaakt. Hooguit parameters zouden incorrect doorgegeven kunnen worden. Dus hoe zie je die zaken in de oude setup?:
  • Foutmelding op achtergrond
  • Time-out data last year
  • NaN in de savings-tabel
Wat betreft namen: Nederlands en Engels lopen nog wat door elkaar. We moeten met elkaar en @KC27 afspreken wat we willen. Mijn voorkeur zou zijn alles in het Engels. Aan de andere kant is het project vooralsnog gefocused op NL/BE en wordt internationalisering niet per se eenvoudig, met alle verschillende regels.

"Chaos kan niet uit de hand lopen"


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 18:55
storeman schreef op donderdag 30 juli 2026 @ 10:23:
[...]

Ik zal kijken of ik de knoppen automatisch kan enabelen bij nieuwe data. Voordeel nu is wel dat een F5 gewoon werkt zonder heraccordering van de POST. En, hoevaak zit je live naar deze output te kijken?

Qua gerenderde charts en de saving-table: werkt dit in de oude interface wel goed? Ik heb hier technisch geen wijzigingen in gemaakt. Hooguit parameters zouden incorrect doorgegeven kunnen worden. Dus hoe zie je die zaken in de oude setup?:
  • Foutmelding op achtergrond
  • Time-out data last year
  • NaN in de savings-tabel
Wat betreft namen: Nederlands en Engels lopen nog wat door elkaar. We moeten met elkaar en @KC27 afspreken wat we willen. Mijn voorkeur zou zijn alles in het Engels. Aan de andere kant is het project vooralsnog gefocused op NL/BE en wordt internationalisering niet per se eenvoudig, met alle verschillende regels.
Zoals gezegd: allemaal klein bier.

Goede suggestie om het gedrag even te vergelijken met de oude setup (had ik natuurlijk zelf ook kunnen bedenken :( ):
- Foutmelding op de achtergrond is identiek in oude & nieuwe setup
- Time-out data last year; ook de oude setup geeft internal error
- NaN in savings-tabel; ook de oude setup geeft NaN waarden

Dus identiek gedrag
Er is een nieuwe testversie gepubliceerd: 2026.7.0.rc2
Daarin zijn een aantal fouten in rc1 opgelost.
Dit staat er in de changelog:

A number of found issues in rc1 are fixed:
  • the combination of Instant start and a very tiny window from entity_ready_datetime from home assistant could let the CBC solver crash.
  • also the entity_ready_datetime still influenced the amount to charge at instant charge. Now it's behaving like described in the wiki.
  • support light/dark mode
  • fix legacy topnav on mobile
  • rename run to tasks
  • added date-picker on savings
  • fix error reduce_power_low_soc/reduce_power_high_soc "SocPowerLimit"

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


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
Dogooder schreef op dinsdag 28 juli 2026 @ 14:43:
[...]

Interessant, ik heb ook net mijn docker in lxc in proxmox geupdate naar 2026.7.0.rc1 maar ik heb dit niet.

Ik maak gebruik van dao-amd64:2026.7.0.rc1
Hmm vreemd ik heb het ook op 2026.7.0.rc2. Zou je wat over je Proxmox omgeving willen delen? Mijn omgeving:
code:
1
2
3
4
5
i5-13500 (20x 13th Gen Intel (R) Core
Kernel Linux 7.0.14-5-pve (2026-07-14T12:32Z)
Boot Manager EFI
Proxmox Manager Version pve-manager/9.2.5/20242970da7fbcef
LXC 14 CPUs / 8GB Mem / 2GB Swap / 60GB Bootdisk / Privileged

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
@Mirabis Kun je eens de exacte docker compose configuratie delen? Er is wel een en ander gewijzigd in de image build (multi-staged). Maar aangezien ik in ieder geval iets van 5 werkende situaties zie in dit draadje met RC1/2, moeten we goed naar de details gaan kijken.

Of heb je toevallig iets van een grafische kaart beschikbaar gesteld aan de machine/container waardoor het een wat specifiekere setup kan zijn?

"Chaos kan niet uit de hand lopen"


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
storeman schreef op donderdag 30 juli 2026 @ 21:51:
@Mirabis Kun je eens de exacte docker compose configuratie delen? Er is wel een en ander gewijzigd in de image build (multi-staged). Maar aangezien ik in ieder geval iets van 5 werkende situaties zie in dit draadje met RC1/2, moeten we goed naar de details gaan kijken.

Of heb je toevallig iets van een grafische kaart beschikbaar gesteld aan de machine/container waardoor het een wat specifiekere setup kan zijn?
Zie bijgevoegd. En nee, aan deze specifieke LXC geen /dev/dri e.d. Het draait alleen HomeAssistant + DAO
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
version: "3"
services:
  dao:
    image: ghcr.io/corneel27/dao-amd64:2026.7.0.rc2
    volumes:      
      - /root/hass_config/_data:/homeassistant
      - /root/dao_config:/config
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 5000:5000
    restart: unless-stopped
    env_file:
      - TZ=Europe/Amsterdam
PS: Ik heb het zojuist werkend gekregen door zelf de mips te compileren via exec in de container en het onderstaande toe te voegen. Waarom de defaults dan niet werken weet ik ook niet.
code:
1
2
LD_LIBRARY_PATH=/root/build/prog//lib
DYLD_LIBRARY_PATH=/root/build/prog//lib
EDIT 2: Iets te enthousiast. Krijg "geen oplsosing voor: minimize cost" met wat stack traces. Ik ga weer terug naar de laatst werkende versie. Logs van debug calc: https://pastebin.com/TkukHaSS

[ Voor 16% gewijzigd door Mirabis op 30-07-2026 22:32 ]

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • Dogooder
  • Registratie: April 2004
  • Laatst online: 19:36

Dogooder

dus...

@Mirabis ik zie in je log wel dat jouw systeem 20 CBC threads opstart. Bij komt hij maar tot 2. Dat is wel een risico multiplier. CBC was orgineel single threaded.

Misschien multi threading een setting maken ipv altijd max? Of uit veiligheidsoverwegingen toch maar weer terug naar single? @KC27 jij een idee?

  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
Ik heb nog een ander vermoeden. Zou jij, @Mirabis er nog eens een nieuwe container er naast kunnen zetten? Met de testing image? Configuratie mag gewoon hetzelfde zijn (wel exclusief je env-fix), en de reguliere container stoppen.

"Chaos kan niet uit de hand lopen"


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
storeman schreef op vrijdag 31 juli 2026 @ 00:09:
Ik heb nog een ander vermoeden. Zou jij, @Mirabis er nog eens een nieuwe container er naast kunnen zetten? Met de testing image? Configuratie mag gewoon hetzelfde zijn (wel exclusief je env-fix), en de reguliere container stoppen.
Ik zal dat morgenochtend doen. Nog iets anders waar ik rekening mee moet houden? 'testing' is op moment van schrijven identiek aan 2026.7.0.rc2. Kan het gewoon naar dezelfde config e.d. wijzen of liever fresh?

Wat betreft de 20 threads, mijn LXCs hebben:
code:
1
2
Cores=blank (-> unlimited)
CPU_Limit=14

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
Mirabis schreef op vrijdag 31 juli 2026 @ 01:36:
[...]

Ik zal dat morgenochtend doen. Nog iets anders waar ik rekening mee moet houden? 'testing' is op moment van schrijven identiek aan 2026.7.0.rc2. Kan het gewoon naar dezelfde config e.d. wijzen of liever fresh?

Wat betreft de 20 threads, mijn LXCs hebben:
code:
1
2
Cores=blank (-> unlimited)
CPU_Limit=14
Dat is afhankelijk van wanneer je die cbc fout kreeg. Als het bij het starten van de container al was, dan graag fresh. Als het bij een run was, dan graag met (een kopie van) je DAO config/data map.

Proxmox kan niet direct docker containers draaien toch? (Omdat je het over LXCs hebt)

"Chaos kan niet uit de hand lopen"


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
storeman schreef op vrijdag 31 juli 2026 @ 07:34:
[...]

Dat is afhankelijk van wanneer je die cbc fout kreeg. Als het bij het starten van de container al was, dan graag fresh. Als het bij een run was, dan graag met (een kopie van) je DAO config/data map.

Proxmox kan niet direct docker containers draaien toch? (Omdat je het over LXCs hebt)
Ik heb even met Claude gekeken naar een oplossing.

1. Maak ik gebruik van eigen miplib dan krijg ik bij startup "[10:14:57] INFO: Copying saved miplib-binaries" en verder geen errors bij startup. Dus wanneer /root/dao_config/miplib bestaat in mijn mounted docker container.
2. Doe ik vervolgens een run dan krijg ik de eerder gedeelde error.
3. Als ik via de thread detectie aanpas van -1 naar 1 zijn de errors bij de runs verholpen. Het kan nogsteeds geen solution vinden maar de crashes zijn weg.
code:
1
sed -i 's/model\.threads = 1.*/model.threads = -1/' /root/dao/prog/day_ahead.py
4. Haal ik de hele /root/dao_config/miplib folder en envs weg dan krijg ik bij container start de onderstaande foutmelding mbt supervisor API dat het zoekt. Met HomeAssistant Container is er geen supervisor dus geen idee waarom het ernaar zoekt bij ontbreken van de mips folder. Zonder de folder is WebUI niet bruikbaar want dan zijn de checkboxes uitgeschakeld.
code:
1
2
3
4
5
6
7
8
9
[10:13:02] INFO: => directory dao_data exist
[10:13:02] INFO: => /root/dao/data exist
[10:13:02] INFO: => /root/dao/webserver/app/static/data exist
2026-07-31 10:13:05 INFO: Loaded 4 secrets from ../data/secrets.json
2026-07-31 10:13:05 INFO: Validating configuration with ConfigurationV2
curl: (6) Could not resolve host: supervisor
[10:13:13] ERROR: Something went wrong contacting the API
[10:13:13] ERROR: Failed to get addon config from Supervisor API
Starting scheduler...
Excuus voor het warrige verhaal... beetje tijdgebrek en heen en weer gecopy-paste. Ik zal kijken of ik van het weekend wat meer tijd heb om erin te duiken. Voor nu ben ik terug naar de stable versie.

[ Voor 5% gewijzigd door Mirabis op 31-07-2026 10:41 ]

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 18:55
Ik heb een nieuw hoofdstuk Notificaties voor beginnende DAO/HA gebruikers aan de Wiki pagina met voorbeelden toegevoegd.

Ik hoop dat het van waarde is.
Suggesties over zowel de structuur als de inhoud zijn wederom van harte welkom.

  • jeroenribbink
  • Registratie: November 2003
  • Laatst online: 05-08 20:27
Is er iemand die kan verklaren waarom er bij boiler_present=true soms geen oplossing gevonden kan worden ondanks dat er ook andere apparaten (meestal de batterij) gepland kunnen worden. als boiler_present op false zet dan kan hij wel een oplossing vinden.

Ik snap dat het een variabele in de reeks is, maar de boiler niet doen en de batterij wel is toch ook een oplossing (in mijn ogen dan)

Heeft iemand hier een logische verklaring voor?
of is het handig om bijvoorbeeld de hysterese te verlagen?

  • storeman
  • Registratie: April 2004
  • Laatst online: 19:50
Mirabis schreef op vrijdag 31 juli 2026 @ 10:23:
[...]

Ik heb even met Claude gekeken naar een oplossing.

1. Maak ik gebruik van eigen miplib dan krijg ik bij startup "[10:14:57] INFO: Copying saved miplib-binaries" en verder geen errors bij startup. Dus wanneer /root/dao_config/miplib bestaat in mijn mounted docker container.
2. Doe ik vervolgens een run dan krijg ik de eerder gedeelde error.
3. Als ik via de thread detectie aanpas van -1 naar 1 zijn de errors bij de runs verholpen. Het kan nogsteeds geen solution vinden maar de crashes zijn weg.
code:
1
sed -i 's/model\.threads = 1.*/model.threads = -1/' /root/dao/prog/day_ahead.py
4. Haal ik de hele /root/dao_config/miplib folder en envs weg dan krijg ik bij container start de onderstaande foutmelding mbt supervisor API dat het zoekt. Met HomeAssistant Container is er geen supervisor dus geen idee waarom het ernaar zoekt bij ontbreken van de mips folder. Zonder de folder is WebUI niet bruikbaar want dan zijn de checkboxes uitgeschakeld.
code:
1
2
3
4
5
6
7
8
9
[10:13:02] INFO: => directory dao_data exist
[10:13:02] INFO: => /root/dao/data exist
[10:13:02] INFO: => /root/dao/webserver/app/static/data exist
2026-07-31 10:13:05 INFO: Loaded 4 secrets from ../data/secrets.json
2026-07-31 10:13:05 INFO: Validating configuration with ConfigurationV2
curl: (6) Could not resolve host: supervisor
[10:13:13] ERROR: Something went wrong contacting the API
[10:13:13] ERROR: Failed to get addon config from Supervisor API
Starting scheduler...
Excuus voor het warrige verhaal... beetje tijdgebrek en heen en weer gecopy-paste. Ik zal kijken of ik van het weekend wat meer tijd heb om erin te duiken. Voor nu ben ik terug naar de stable versie.
Ik vind het moeilijk hier wat zinnigs over te zeggen en zou graag willen beginnen bij de basis: een kale, nieuwe container. Het hele idee van de containerization gaat nu een beetje onderuit, dat moet te verklaren zijn :).

Mocht de nieuwe container niet willen starten, zou je in de container dan eens kunnen doen:
apt-get update && apt-get install libnauty-2.8.9
En checken of dit de fix is?

"Chaos kan niet uit de hand lopen"

Dogooder schreef op donderdag 30 juli 2026 @ 23:58:
@Mirabis ik zie in je log wel dat jouw systeem 20 CBC threads opstart. Bij komt hij maar tot 2. Dat is wel een risico multiplier. CBC was orgineel single threaded.

Misschien multi threading een setting maken ipv altijd max? Of uit veiligheidsoverwegingen toch maar weer terug naar single? @KC27 jij een idee?
Ik vind wel dat we multi threading moeten blijven ondersteunen omdat daarmee de berekening bij veel gebruikers een stuk (geen procenten maar factoren) sneller gaat. Die snelheid hebben we straks nodig als we de"reken horizon" gaan uitbreiden met (betrouwbare) voorspellingen van de day-ahead tarieven.
Ik stel voor om er een optionele setting van te maken: default "max" of een getal tussen 1 en 20.
Wat vinden jullie daarvan?

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

Mirabis schreef op vrijdag 31 juli 2026 @ 10:23:
[...]

Ik heb even met Claude gekeken naar een oplossing.

1. Maak ik gebruik van eigen miplib dan krijg ik bij startup "[10:14:57] INFO: Copying saved miplib-binaries" en verder geen errors bij startup. Dus wanneer /root/dao_config/miplib bestaat in mijn mounted docker container.
2. Doe ik vervolgens een run dan krijg ik de eerder gedeelde error.
3. Als ik via de thread detectie aanpas van -1 naar 1 zijn de errors bij de runs verholpen. Het kan nogsteeds geen solution vinden maar de crashes zijn weg.
code:
1
sed -i 's/model\.threads = 1.*/model.threads = -1/' /root/dao/prog/day_ahead.py
4. Haal ik de hele /root/dao_config/miplib folder en envs weg dan krijg ik bij container start de onderstaande foutmelding mbt supervisor API dat het zoekt. Met HomeAssistant Container is er geen supervisor dus geen idee waarom het ernaar zoekt bij ontbreken van de mips folder. Zonder de folder is WebUI niet bruikbaar want dan zijn de checkboxes uitgeschakeld.
code:
1
2
3
4
5
6
7
8
9
[10:13:02] INFO: => directory dao_data exist
[10:13:02] INFO: => /root/dao/data exist
[10:13:02] INFO: => /root/dao/webserver/app/static/data exist
2026-07-31 10:13:05 INFO: Loaded 4 secrets from ../data/secrets.json
2026-07-31 10:13:05 INFO: Validating configuration with ConfigurationV2
curl: (6) Could not resolve host: supervisor
[10:13:13] ERROR: Something went wrong contacting the API
[10:13:13] ERROR: Failed to get addon config from Supervisor API
Starting scheduler...
Excuus voor het warrige verhaal... beetje tijdgebrek en heen en weer gecopy-paste. Ik zal kijken of ik van het weekend wat meer tijd heb om erin te duiken. Voor nu ben ik terug naar de stable versie.
Een paar opmerkingen/observaties van mijn kant:

Als je eigen gecompileerde mip-binaries gaat gebruiken dan worden tijdens de compilatie de gegenereerde binaries afgestemd op de cpu-configuratie. Als je daarna deze binaries gaat gebruiken in een gewijzigde cpu-configuratie dan zou het heel goed kunnen dat dit om deze reden fouten oplevert zoals in de gedeelde logging.

De melding
curl: (6) Could not resolve host: supervisor
duidt erop dat in je config het adres van je HA-container niet is opgenomen.
Dus neem of ip-adres of de dns-hostname van je HA-container op in de config van 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

jeroenribbink schreef op vrijdag 31 juli 2026 @ 20:58:
Is er iemand die kan verklaren waarom er bij boiler_present=true soms geen oplossing gevonden kan worden ondanks dat er ook andere apparaten (meestal de batterij) gepland kunnen worden. als boiler_present op false zet dan kan hij wel een oplossing vinden.

Ik snap dat het een variabele in de reeks is, maar de boiler niet doen en de batterij wel is toch ook een oplossing (in mijn ogen dan)

Heeft iemand hier een logische verklaring voor?
of is het handig om bijvoorbeeld de hysterese te verlagen?
Als het wel werkt als je boiler_present=false zet komt waarschijnlijk omdat er singulariteit (=ongerijmdheid) is in je actuele boiler situatie en je boiler-settings.
Kun je je boiler settings en de logging van een berekening zonder oplossing hier delen (met code en quote-tags)?

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


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
--delete--

[ Voor 98% gewijzigd door Mirabis op 01-08-2026 04:23 ]

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • Mirabis
  • Registratie: Juli 2013
  • Niet online
--delete--

[ Voor 100% gewijzigd door Mirabis op 01-08-2026 04:23 ]

1x Venus-E v153 +LilyGo HA, CT003 V117 | 5040Wp ZO + 4200Wp NW | Zonneplan, 3x25A, Easee Charge Lite | EV 98kWh


  • The Source
  • Registratie: April 2000
  • Laatst online: 05-08 20:16
jeroenribbink schreef op vrijdag 31 juli 2026 @ 20:58:
Is er iemand die kan verklaren waarom er bij boiler_present=true soms geen oplossing gevonden kan worden ondanks dat er ook andere apparaten (meestal de batterij) gepland kunnen worden. als boiler_present op false zet dan kan hij wel een oplossing vinden.

Ik snap dat het een variabele in de reeks is, maar de boiler niet doen en de batterij wel is toch ook een oplossing (in mijn ogen dan)

Heeft iemand hier een logische verklaring voor?
of is het handig om bijvoorbeeld de hysterese te verlagen?
Heel toevallig heb ik hetzelfde probleem.
Boiler = true , geen foutmelding, maar geen nieuwe grafiek op het homescherm.
Boiler = false, geen foutmelding, maar wel een nieuwe grafiek op het scherm.
Ik snap dat er geen planning voor de boiler is, deze hoeft niet opgewarmd te worden, maar ik verwacht dan welk een nieuwe planning voor mijn batterij en laadpaal.

Mijn config:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
  "boiler": {
    "boiler present": false,
    "entity actual temp.": "sensor.warmtepomp_ecodan_sww_huidige_temp",
    "entity setpoint": "sensor.warmtepomp_ecodan_sww_setpoint_waarde",
    "entity hysterese": "input_number.dao_hysterese_dhw",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 43,
    "elec. power": 2000,
    "activate service": "turn_on",
    "activate entity": "switch.ecodan_heatpump_force_dhw"
  },
waardes:
sensor.warmtepomp_ecodan_sww_huidige_temp = 54.5
sensor.warmtepomp_ecodan_sww_setpoint_waarde = 55.0
input_number.dao_hysterese_dhw = 0.0

[ Voor 9% gewijzigd door The Source op 02-08-2026 15:47 ]

The Source schreef op zondag 2 augustus 2026 @ 15:40:
[...]

Heel toevallig heb ik hetzelfde probleem.
Boiler = true , geen foutmelding, maar geen nieuwe grafiek op het homescherm.
Boiler = false, geen foutmelding, maar wel een nieuwe grafiek op het scherm.
Ik snap dat er geen planning voor de boiler is, deze hoeft niet opgewarmd te worden, maar ik verwacht dan welk een nieuwe planning voor mijn batterij en laadpaal.

Mijn config:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
  "boiler": {
    "boiler present": false,
    "entity actual temp.": "sensor.warmtepomp_ecodan_sww_huidige_temp",
    "entity setpoint": "sensor.warmtepomp_ecodan_sww_setpoint_waarde",
    "entity hysterese": "input_number.dao_hysterese_dhw",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 43,
    "elec. power": 2000,
    "activate service": "turn_on",
    "activate entity": "switch.ecodan_heatpump_force_dhw"
  },
waardes:
sensor.warmtepomp_ecodan_sww_huidige_temp = 54.5
sensor.warmtepomp_ecodan_sww_setpoint_waarde = 55.0
input_number.dao_hysterese_dhw = 0.0
Waarom heb je hysterese op 0 gezet?
Hysterese op 0 betekent dat er direct opgewarmd moet worden van 54.5 naar 55.0.
Wat staat er in de logging?

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


  • jeroenribbink
  • Registratie: November 2003
  • Laatst online: 05-08 20:27
KC27 schreef op vrijdag 31 juli 2026 @ 23:00:
[...]

Als het wel werkt als je boiler_present=false zet komt waarschijnlijk omdat er singulariteit (=ongerijmdheid) is in je actuele boiler situatie en je boiler-settings.
Kun je je boiler settings en de logging van een berekening zonder oplossing hier delen (met code en quote-tags)?
Dank voor je reactie.
je bent wel voor iedereen het zo aan het analyseren, wordt erg gewaardeerd ;)

Settings:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
  "boiler": {
    "boiler_present": true,
    "entity actual temp.": "sensor.wemosd1mini_vissen_temperatuur", // 57 op het moment. dus binnen hysteres
    "entity setpoint": "input_number.dao_boiler_keuken_setpoint", // 60
    "entity hysterese": "input_number.dao_boiler_setpoint_afwijking", // 5, heb ook 10 gehad
    "entity boiler enabled": "input_boolean.dao_boiler_planning_ingeschakeld", // true
    "cop": 1,
    "cooling rate": 0.9,
    "volume": 10,
    "heating allowed below": 55,
    "elec. power": 400,
    "activate service": "turn_on",
    "activate entity": "switch.bedden"
  },
Logging:
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
2026-08-02 20:57:53 INFO: Loaded 6 secrets from ../data/secrets.json
2026-08-02 20:57:53 INFO: Validating configuration with ConfigurationV2
2026-08-02 20:57:53 info: Day Ahead Optimalisering versie: 2026.6.0
2026-08-02 20:57:53 info: Day Ahead Optimalisering gestart op: 02-08-2026 20:57:53
2026-08-02 20:57:53 info: Day Ahead Optimalisatie gestart: 02-08-2026 20:57:53 taak: calc_optimum
2026-08-02 20:57:53 info: Debug = False
2026-08-02 20:57:53 info: Baseload uit instellingen
2026-08-02 20:57:54 info: ML prediction Enphase
                   date_time  prediction
0  2026-08-02 20:00:00+02:00       0.445
1  2026-08-02 21:00:00+02:00       0.049
2  2026-08-02 22:00:00+02:00       0.048
3  2026-08-02 23:00:00+02:00       0.048
4  2026-08-03 00:00:00+02:00       0.048
5  2026-08-03 01:00:00+02:00       0.048
6  2026-08-03 02:00:00+02:00       0.000
7  2026-08-03 03:00:00+02:00       0.000
8  2026-08-03 04:00:00+02:00       0.000
9  2026-08-03 05:00:00+02:00       0.000
10 2026-08-03 06:00:00+02:00       0.057
11 2026-08-03 07:00:00+02:00       0.291
12 2026-08-03 08:00:00+02:00       0.538
13 2026-08-03 09:00:00+02:00       1.249
14 2026-08-03 10:00:00+02:00       1.269
15 2026-08-03 11:00:00+02:00       2.349
16 2026-08-03 12:00:00+02:00       3.586
17 2026-08-03 13:00:00+02:00       3.930
18 2026-08-03 14:00:00+02:00       3.817
19 2026-08-03 15:00:00+02:00       3.745
20 2026-08-03 16:00:00+02:00       3.157
21 2026-08-03 17:00:00+02:00       2.075
22 2026-08-03 18:00:00+02:00       1.471
23 2026-08-03 19:00:00+02:00       0.632
24 2026-08-03 20:00:00+02:00       0.350
25 2026-08-03 21:00:00+02:00       0.080
26 2026-08-03 22:00:00+02:00       0.063
27 2026-08-03 23:00:00+02:00       0.063
2026-08-02 20:57:54 info: Start waarden: 
       uur                tijd   spot   p_l   p_t  base  pv_ac  pv_dc
0    20:45 2026-08-02 20:45:00  0.192 0.364 0.344 0.218  0.010      0
1    21:00 2026-08-02 21:00:00  0.191 0.362 0.342 0.205  0.043      0
2    21:15 2026-08-02 21:15:00  0.182 0.350 0.330 0.195  0.018      0
3    21:30 2026-08-02 21:30:00  0.175 0.342 0.322 0.186  0.000      0
4    21:45 2026-08-02 21:45:00  0.165 0.331 0.311 0.164  0.000      0
5    22:00 2026-08-02 22:00:00  0.182 0.351 0.331 0.127  0.012      0
6    22:15 2026-08-02 22:15:00  0.169 0.335 0.315 0.105  0.012      0
7    22:30 2026-08-02 22:30:00  0.165 0.330 0.310 0.084  0.012      0
8    22:45 2026-08-02 22:45:00  0.158 0.322 0.302 0.084  0.012      0
9    23:00 2026-08-02 23:00:00  0.162 0.327 0.307 0.100  0.012      0
10   23:15 2026-08-02 23:15:00  0.156 0.320 0.300 0.100  0.012      0
11   23:30 2026-08-02 23:30:00  0.154 0.317 0.297 0.100  0.012      0
12   23:45 2026-08-02 23:45:00  0.144 0.306 0.286 0.100  0.012      0
13   00:00 2026-08-03 00:00:00  0.147 0.309 0.289 0.100  0.012      0
14   00:15 2026-08-03 00:15:00  0.143 0.304 0.284 0.100  0.012      0
15   00:30 2026-08-03 00:30:00  0.138 0.298 0.278 0.100  0.012      0
16   00:45 2026-08-03 00:45:00  0.135 0.294 0.274 0.100  0.012      0
17   01:00 2026-08-03 01:00:00  0.138 0.298 0.278 0.100  0.013      0
18   01:15 2026-08-03 01:15:00  0.135 0.294 0.274 0.100  0.013      0
19   01:30 2026-08-03 01:30:00  0.137 0.296 0.276 0.100  0.013      0
20   01:45 2026-08-03 01:45:00  0.134 0.293 0.273 0.100  0.010      0
21   02:00 2026-08-03 02:00:00  0.135 0.294 0.274 0.100  0.004      0
22   02:15 2026-08-03 02:15:00  0.133 0.292 0.272 0.100  0.001      0
23   02:30 2026-08-03 02:30:00  0.132 0.291 0.271 0.100  0.000      0
24   02:45 2026-08-03 02:45:00  0.132 0.290 0.270 0.100  0.000      0
25   03:00 2026-08-03 03:00:00  0.130 0.288 0.268 0.100  0.000      0
26   03:15 2026-08-03 03:15:00  0.129 0.287 0.267 0.100  0.000      0
27   03:30 2026-08-03 03:30:00  0.130 0.288 0.268 0.100  0.000      0
28   03:45 2026-08-03 03:45:00  0.132 0.291 0.271 0.100  0.000      0
29   04:00 2026-08-03 04:00:00  0.129 0.287 0.267 0.100  0.000      0
30   04:15 2026-08-03 04:15:00  0.132 0.290 0.270 0.100  0.000      0
31   04:30 2026-08-03 04:30:00  0.134 0.293 0.273 0.100  0.000      0
32   04:45 2026-08-03 04:45:00  0.138 0.298 0.278 0.100  0.000      0
33   05:00 2026-08-03 05:00:00  0.138 0.297 0.278 0.095  0.000      0
34   05:15 2026-08-03 05:15:00  0.142 0.302 0.282 0.095  0.000      0
35   05:30 2026-08-03 05:30:00  0.145 0.307 0.287 0.095  0.000      0
36   05:45 2026-08-03 05:45:00  0.152 0.315 0.295 0.114  0.003      0
37   06:00 2026-08-03 06:00:00  0.162 0.327 0.307 0.152  0.006      0
38   06:15 2026-08-03 06:15:00  0.170 0.336 0.316 0.170  0.010      0
39   06:30 2026-08-03 06:30:00  0.170 0.337 0.317 0.189  0.013      0
40   06:45 2026-08-03 06:45:00  0.165 0.330 0.310 0.189  0.028      0
41   07:00 2026-08-03 07:00:00  0.171 0.338 0.318 0.177  0.051      0
42   07:15 2026-08-03 07:15:00  0.166 0.332 0.312 0.177  0.065      0
43   07:30 2026-08-03 07:30:00  0.162 0.327 0.307 0.177  0.080      0
44   07:45 2026-08-03 07:45:00  0.156 0.319 0.299 0.168  0.095      0
45   08:00 2026-08-03 08:00:00  0.167 0.333 0.313 0.148  0.104      0
46   08:15 2026-08-03 08:15:00  0.157 0.321 0.301 0.139  0.120      0
47   08:30 2026-08-03 08:30:00  0.150 0.313 0.293 0.130  0.135      0
48   08:45 2026-08-03 08:45:00  0.126 0.283 0.263 0.133  0.180      0
49   09:00 2026-08-03 09:00:00  0.163 0.328 0.308 0.145  0.256      0
50   09:15 2026-08-03 09:15:00  0.135 0.294 0.274 0.148  0.301      0
51   09:30 2026-08-03 09:30:00  0.126 0.283 0.263 0.152  0.345      0
52   09:45 2026-08-03 09:45:00  0.120 0.277 0.257 0.155  0.346      0
53   10:00 2026-08-03 10:00:00  0.129 0.287 0.267 0.159  0.299      0
54   10:15 2026-08-03 10:15:00  0.117 0.272 0.253 0.162  0.300      0
55   10:30 2026-08-03 10:30:00  0.109 0.263 0.243 0.165  0.301      0
56   10:45 2026-08-03 10:45:00  0.089 0.239 0.219 0.165  0.369      0
57   11:00 2026-08-03 11:00:00  0.075 0.221 0.201 0.154  0.484      0
58   11:15 2026-08-03 11:15:00  0.037 0.176 0.156 0.154  0.551      0
59   11:30 2026-08-03 11:30:00  0.010 0.143 0.123 0.154  0.619      0
60   11:45 2026-08-03 11:45:00 -0.000 0.131 0.111 0.188  0.696      0
61   12:00 2026-08-03 12:00:00  0.031 0.168 0.148 0.257  0.795      0
62   12:15 2026-08-03 12:15:00  0.007 0.140 0.120 0.291  0.872      0
63   12:30 2026-08-03 12:30:00  0.000 0.131 0.111 0.326  0.949      0
64   12:45 2026-08-03 12:45:00  0.000 0.131 0.111 0.326  0.971      0
65   13:00 2026-08-03 13:00:00 -0.000 0.131 0.111 0.300  0.957      0
66   13:15 2026-08-03 13:15:00 -0.001 0.130 0.110 0.300  0.979      0
67   13:30 2026-08-03 13:30:00 -0.000 0.131 0.111 0.300  1.000      0
68   13:45 2026-08-03 13:45:00 -0.002 0.129 0.109 0.300  0.993      0
69   14:00 2026-08-03 14:00:00  0.000 0.131 0.111 0.295  0.964      0
70   14:15 2026-08-03 14:15:00  0.000 0.131 0.111 0.295  0.957      0
71   14:30 2026-08-03 14:30:00  0.001 0.132 0.112 0.295  0.950      0
72   14:45 2026-08-03 14:45:00  0.011 0.145 0.125 0.314  0.945      0
73   15:00 2026-08-03 15:00:00  0.001 0.132 0.112 0.339  0.951      0
74   15:15 2026-08-03 15:15:00  0.039 0.178 0.158 0.358  0.947      0
75   15:30 2026-08-03 15:30:00  0.056 0.199 0.179 0.377  0.942      0
76   15:45 2026-08-03 15:45:00  0.071 0.217 0.197 0.427  0.905      0
77   16:00 2026-08-03 16:00:00  0.088 0.238 0.218 0.513  0.852      0
78   16:15 2026-08-03 16:15:00  0.096 0.247 0.227 0.562  0.815      0
79   16:30 2026-08-03 16:30:00  0.107 0.261 0.241 0.613  0.779      0
80   16:45 2026-08-03 16:45:00  0.121 0.277 0.258 0.613  0.711      0
81   17:00 2026-08-03 17:00:00  0.117 0.273 0.253 0.592  0.613      0
82   17:15 2026-08-03 17:15:00  0.124 0.281 0.261 0.592  0.545      0
83   17:30 2026-08-03 17:30:00  0.146 0.307 0.287 0.592  0.477      0
84   17:45 2026-08-03 17:45:00  0.172 0.339 0.319 0.523  0.440      0
85   18:00 2026-08-03 18:00:00  0.150 0.312 0.292 0.391  0.428      0
86   18:15 2026-08-03 18:15:00  0.162 0.326 0.306 0.322  0.390      0
87   18:30 2026-08-03 18:30:00  0.168 0.334 0.314 0.253  0.353      0
88   18:45 2026-08-03 18:45:00  0.187 0.357 0.337 0.234  0.300      0
89   19:00 2026-08-03 19:00:00  0.173 0.340 0.320 0.248  0.228      0
90   19:15 2026-08-03 19:15:00  0.189 0.359 0.339 0.230  0.176      0
91   19:30 2026-08-03 19:30:00  0.205 0.379 0.359 0.211  0.123      0
92   19:45 2026-08-03 19:45:00  0.237 0.418 0.398 0.211  0.105      0
93   20:00 2026-08-03 20:00:00  0.200 0.373 0.353 0.227  0.114      0
94   20:15 2026-08-03 20:15:00  0.197 0.369 0.349 0.227  0.096      0
95   20:30 2026-08-03 20:30:00  0.194 0.366 0.346 0.227  0.079      0
96   20:45 2026-08-03 20:45:00  0.201 0.374 0.354 0.218  0.062      0
97   21:00 2026-08-03 21:00:00  0.198 0.370 0.350 0.205  0.041      0
98   21:15 2026-08-03 21:15:00  0.190 0.361 0.341 0.195  0.024      0
99   21:30 2026-08-03 21:30:00  0.185 0.355 0.335 0.186  0.008      0
100  21:45 2026-08-03 21:45:00  0.173 0.340 0.320 0.164  0.007      0
101  22:00 2026-08-03 22:00:00  0.185 0.354 0.334 0.127  0.017      0
102  22:15 2026-08-03 22:15:00  0.176 0.344 0.324 0.105  0.016      0
103  22:30 2026-08-03 22:30:00  0.174 0.341 0.321 0.084  0.015      0
104  22:45 2026-08-03 22:45:00  0.166 0.331 0.311 0.084  0.015      0
105  23:00 2026-08-03 23:00:00  0.167 0.333 0.313 0.100  0.016      0
106  23:15 2026-08-03 23:15:00  0.161 0.325 0.305 0.100  0.016      0
107  23:30 2026-08-03 23:30:00  0.156 0.320 0.300 0.100  0.016      0
108  23:45 2026-08-03 23:45:00  0.147 0.309 0.289 0.100  0.016      0
2026-08-02 20:57:54 info: No reduced hours applied for Marstek Venus-E
2026-08-02 20:57:54 info: No reduced power applied during discharging at low soc
2026-08-02 20:57:54 info: No reduced power applied during charging at high soc
2026-08-02 20:57:54 info: Startwaarde SoC Marstek Venus-E: 74.1%

2026-08-02 20:57:54 info: Boiler direct opwarmen staat uit
2026-08-02 20:57:54 info: Boiler setpoint 60.0 °C
2026-08-02 20:57:54 info: Boiler hysterese 5.0 K
2026-08-02 20:57:54 info: Boiler cooling rate 0.9 K/uur
2026-08-02 20:57:54 info: Boiler heating allowed below 55 °C
2026-08-02 20:57:54 info: Boiler opwarmen wordt ingepland tussen: 2026-08-02 23:00 en 2026-08-02 23:15
2026-08-02 20:57:54 info: Boiler verbruik in 1 kwartier: 0.1 kWh
2026-08-02 20:57:54 info: Prognose boiler:
                   tijd  act_temp  heat  elec  interval  cost  end_temp  end_value  netto_cost
0   2026-08-02 20:45:00    57.125 0.081 0.181         2 0.065    35.925     -0.171       0.235
1   2026-08-02 21:00:00    56.900 0.087 0.187         2 0.067    36.150     -0.169       0.236
2   2026-08-02 21:15:00    56.675 0.093 0.193         2 0.067    36.375     -0.167       0.234
3   2026-08-02 21:30:00    56.450 0.100 0.200         2 0.067    36.600     -0.165       0.233
4   2026-08-02 21:45:00    56.225 0.106 0.206         3 0.070    37.050     -0.162       0.232
5   2026-08-02 22:00:00    56.000 0.112 0.212         3 0.073    37.275     -0.160       0.233
6   2026-08-02 22:15:00    55.775 0.119 0.219         3 0.073    37.500     -0.158       0.231
7   2026-08-02 22:30:00    55.550 0.125 0.225         3 0.073    37.725     -0.156       0.230
8   2026-08-02 22:45:00    55.325 0.131 0.231         3 0.075    37.950     -0.154       0.229
9   2026-08-02 23:00:00    55.100 0.138 0.238         3 0.077    38.175     -0.153       0.229
10  2026-08-02 23:15:00    54.875 0.144 0.244         3 0.077    38.400     -0.151       0.228
11  2026-08-02 23:30:00    54.650 0.150 0.250         3 0.078    38.625     -0.149       0.227
12  2026-08-02 23:45:00    54.425 0.157 0.257         3 0.079    38.850     -0.147       0.226
13  2026-08-03 00:00:00    54.200 0.163 0.263         3 0.080    39.075     -0.145       0.225
14  2026-08-03 00:15:00    53.975 0.169 0.269         3 0.081    39.300     -0.144       0.224
15  2026-08-03 00:30:00    53.750 0.176 0.276         3 0.082    39.525     -0.142       0.224
16  2026-08-03 00:45:00    53.525 0.182 0.282         3 0.083    39.750     -0.140       0.223
17  2026-08-03 01:00:00    53.300 0.188 0.288         3 0.085    39.975     -0.138       0.224
18  2026-08-03 01:15:00    53.075 0.195 0.295         3 0.087    40.200     -0.136       0.223
19  2026-08-03 01:30:00    52.850 0.201 0.301         4 0.089    40.650     -0.133       0.221
20  2026-08-03 01:45:00    52.625 0.207 0.307         4 0.090    40.875     -0.131       0.221
21  2026-08-03 02:00:00    52.400 0.214 0.314         4 0.092    41.100     -0.129       0.221
22  2026-08-03 02:15:00    52.175 0.220 0.320         4 0.093    41.325     -0.127       0.220
23  2026-08-03 02:30:00    51.950 0.226 0.326         4 0.094    41.550     -0.125       0.220
24  2026-08-03 02:45:00    51.725 0.233 0.333         4 0.096    41.775     -0.124       0.220
25  2026-08-03 03:00:00    51.500 0.239 0.339         4 0.098    42.000     -0.122       0.220
26  2026-08-03 03:15:00    51.275 0.245 0.345         4 0.100    42.225     -0.120       0.220
27  2026-08-03 03:30:00    51.050 0.252 0.352         4 0.102    42.450     -0.118       0.220
28  2026-08-03 03:45:00    50.825 0.258 0.358         4 0.104    42.675     -0.116       0.220
29  2026-08-03 04:00:00    50.600 0.264 0.364         4 0.106    42.900     -0.115       0.221
30  2026-08-03 04:15:00    50.375 0.271 0.371         4 0.109    43.125     -0.113       0.222
31  2026-08-03 04:30:00    50.150 0.277 0.377         4 0.112    43.350     -0.111       0.223
32  2026-08-03 04:45:00    49.925 0.283 0.383         4 0.115    43.575     -0.109       0.224
33  2026-08-03 05:00:00    49.700 0.290 0.390         4 0.119    43.800     -0.107       0.226
34  2026-08-03 05:15:00    49.475 0.296 0.396         4 0.124    44.025     -0.106       0.229
35  2026-08-03 05:30:00    49.250 0.302 0.402         5 0.129    44.475     -0.102       0.231
36  2026-08-03 05:45:00    49.025 0.309 0.409         5 0.134    44.700     -0.100       0.234
37  2026-08-03 06:00:00    48.800 0.315 0.415         5 0.138    44.925     -0.098       0.236
38  2026-08-03 06:15:00    48.575 0.321 0.421         5 0.141    45.150     -0.096       0.238
39  2026-08-03 06:30:00    48.350 0.327 0.427         5 0.143    45.375     -0.095       0.237
40  2026-08-03 06:45:00    48.125 0.334 0.434         5 0.143    45.600     -0.093       0.236
41  2026-08-03 07:00:00    47.900 0.340 0.440         5 0.145    45.825     -0.091       0.236
42  2026-08-03 07:15:00    47.675 0.346 0.446         5 0.146    46.050     -0.089       0.235
43  2026-08-03 07:30:00    47.450 0.353 0.453         5 0.146    46.275     -0.087       0.234
44  2026-08-03 07:45:00    47.225 0.359 0.459         5 0.145    46.500     -0.086       0.231
45  2026-08-03 08:00:00    47.000 0.365 0.465         5 0.146    46.725     -0.084       0.230
46  2026-08-03 08:15:00    46.775 0.372 0.472         5 0.146    46.950     -0.082       0.227
47  2026-08-03 08:30:00    46.550 0.378 0.478         5 0.144    47.175     -0.080       0.224
48  2026-08-03 08:45:00    46.325 0.384 0.484         5 0.142    47.400     -0.078       0.220
49  2026-08-03 09:00:00    46.100 0.391 0.491         5 0.144    47.625     -0.077       0.221
50  2026-08-03 09:15:00    45.875 0.397 0.497         5 0.141    47.850     -0.075       0.215
51  2026-08-03 09:30:00    45.650 0.403 0.503         6 0.139    48.300     -0.071       0.210
52  2026-08-03 09:45:00    45.425 0.410 0.510         6 0.136    48.525     -0.069       0.205
53  2026-08-03 10:00:00    45.200 0.416 0.516         6 0.131    48.750     -0.067       0.199
54  2026-08-03 10:15:00    44.975 0.422 0.522         6 0.120    48.975     -0.066       0.186
55  2026-08-03 10:30:00    44.750 0.429 0.529         6 0.108    49.200     -0.064       0.172
56  2026-08-03 10:45:00    44.525 0.435 0.535         6 0.097    49.425     -0.062       0.159
57  2026-08-03 11:00:00    44.300 0.441 0.541         6 0.090    49.650     -0.060       0.150
58  2026-08-03 11:15:00    44.075 0.448 0.548         6 0.082    49.875     -0.058       0.140
59  2026-08-03 11:30:00    43.850 0.454 0.554         6 0.078    50.100     -0.057       0.135
60  2026-08-03 11:45:00    43.625 0.460 0.560         6 0.078    50.325     -0.055       0.133
61  2026-08-03 12:00:00    43.400 0.467 0.567         6 0.079    50.550     -0.053       0.132
62  2026-08-03 12:15:00    43.175 0.473 0.573         6 0.076    50.775     -0.051       0.127
63  2026-08-03 12:30:00    42.950 0.479 0.579         6 0.076    51.000     -0.049       0.125
64  2026-08-03 12:45:00    42.725 0.486 0.586         6 0.076    51.225     -0.048       0.124
65  2026-08-03 13:00:00    42.500 0.492 0.592         6 0.077    51.450     -0.046       0.123
66  2026-08-03 13:15:00    42.275 0.498 0.598         6 0.078    51.675     -0.044       0.122
67  2026-08-03 13:30:00    42.050 0.505 0.605         7 0.080    52.125     -0.040       0.121
68  2026-08-03 13:45:00    41.825 0.511 0.611         7 0.082    52.350     -0.038       0.120
69  2026-08-03 14:00:00    41.600 0.517 0.617         7 0.088    52.575     -0.037       0.125
70  2026-08-03 14:15:00    41.375 0.524 0.624         7 0.097    52.800     -0.035       0.132
71  2026-08-03 14:30:00    41.150 0.530 0.630         7 0.107    53.025     -0.033       0.140
72  2026-08-03 14:45:00    40.925 0.536 0.636         7 0.120    53.250     -0.031       0.151
73  2026-08-03 15:00:00    40.700 0.543 0.643         7 0.132    53.475     -0.029       0.162
74  2026-08-03 15:15:00    40.475 0.549 0.649         7 0.148    53.700     -0.028       0.175
75  2026-08-03 15:30:00    40.250 0.555 0.655         7 0.159    53.925     -0.026       0.185
76  2026-08-03 15:45:00    40.025 0.562 0.662         7 0.169    54.150     -0.024       0.193
77  2026-08-03 16:00:00    39.800 0.568 0.668         7 0.179    54.375     -0.022       0.201
78  2026-08-03 16:15:00    39.575 0.574 0.674         7 0.190    54.600     -0.020       0.210
79  2026-08-03 16:30:00    39.350 0.580 0.680         7 0.199    54.825     -0.019       0.218
80  2026-08-03 16:45:00    39.125 0.587 0.687         7 0.207    55.050     -0.017       0.224
81  2026-08-03 17:00:00    38.900 0.593 0.693         7 0.215    55.275     -0.015       0.230
82  2026-08-03 17:15:00    38.675 0.599 0.699         7 0.226    55.500     -0.013       0.239
83  2026-08-03 17:30:00    38.450 0.606 0.706         8 0.234    55.950     -0.009       0.243
84  2026-08-03 17:45:00    38.225 0.612 0.712         8 0.241    56.175     -0.008       0.249
85  2026-08-03 18:00:00    38.000 0.618 0.718         8 0.248    56.400     -0.006       0.254
86  2026-08-03 18:15:00    37.775 0.625 0.725         8 0.261    56.625     -0.004       0.265
87  2026-08-03 18:30:00    37.550 0.631 0.731         8 0.267    56.850     -0.002       0.270
88  2026-08-03 18:45:00    37.325 0.637 0.737         8 0.273    57.075     -0.000       0.274
89  2026-08-03 19:00:00    37.100 0.644 0.744         8 0.277    57.300      0.001       0.275
90  2026-08-03 19:15:00    36.875 0.650 0.750         8 0.282    57.525      0.003       0.279
91  2026-08-03 19:30:00    36.650 0.656 0.756         8 0.285    57.750      0.005       0.280
92  2026-08-03 19:45:00    36.425 0.663 0.763         8 0.285    57.975      0.007       0.278
93  2026-08-03 20:00:00    36.200 0.669 0.769         8 0.280    58.200      0.009       0.272
94  2026-08-03 20:15:00    35.975 0.675 0.775         8 0.280    58.425      0.010       0.270
95  2026-08-03 20:30:00    35.750 0.682 0.782         8 0.280    58.650      0.012       0.268
96  2026-08-03 20:45:00    35.525 0.688 0.788         8 0.280    58.875      0.014       0.266
97  2026-08-03 21:00:00    35.300 0.694 0.794         8 0.278    59.100      0.016       0.262
98  2026-08-03 21:15:00    35.075 0.701 0.801         9 0.276    59.550      0.020       0.257
99  2026-08-03 21:30:00    34.850 0.707 0.807         9 0.275    59.775      0.021       0.253
100 2026-08-03 21:45:00    34.625 0.713 0.813         9 0.273    60.000      0.023       0.250
101 2026-08-03 22:00:00    34.400 0.000 0.000         0 0.000     0.000      0.000       0.000
102 2026-08-03 22:15:00    34.175 0.000 0.000         0 0.000     0.000      0.000       0.000
103 2026-08-03 22:30:00    33.950 0.000 0.000         0 0.000     0.000      0.000       0.000
104 2026-08-03 22:45:00    33.725 0.000 0.000         0 0.000     0.000      0.000       0.000
105 2026-08-03 23:00:00    33.500 0.000 0.000         0 0.000     0.000      0.000       0.000
106 2026-08-03 23:15:00    33.275 0.000 0.000         0 0.000     0.000      0.000       0.000
107 2026-08-03 23:30:00    33.050 0.000 0.000         0 0.000     0.000      0.000       0.000
108 2026-08-03 23:45:00    32.825 0.000 0.000         0 0.000     0.000      0.000       0.000

2026-08-02 20:57:54 info: Instellingen voor laden van EV: Skoda
2026-08-02 20:57:54 info: Direct laden is uit
2026-08-02 20:57:54 info:  Ampere  Effic. Grid kW Accu kW
2026-08-02 20:57:54 info:    0.00    0.00    0.00    0.00
2026-08-02 20:57:54 info:   16.00    1.00   11.04   11.04
2026-08-02 20:57:54 info: Capaciteit accu: 54.0 kWh
2026-08-02 20:57:54 info: Maximaal laadvermogen: 11.04 kW
2026-08-02 20:57:54 info: Klaar met laden op: 03-08-2026 17:00:00
2026-08-02 20:57:54 info: Huidig laadniveau: 93.0 %
2026-08-02 20:57:54 info: Gewenst laadniveau:85.0 %
2026-08-02 20:57:54 info: Marge voor het laden: 0 %
2026-08-02 20:57:54 info: Locatie: home
2026-08-02 20:57:54 info: Ingeplugged:False
2026-08-02 20:57:54 info: Benodigde netto energie: 0.000 kWh
2026-08-02 20:57:54 info: Tijd nodig om te laden: 0:0 uur
2026-08-02 20:57:54 info: Afgerond naar hele intervallen: 0 kwartier
2026-08-02 20:57:54 info: Stand laden schakelaar: off
2026-08-02 20:57:54 info: Stand aantal ampere laden: 0.0 A
2026-08-02 20:57:54 info: Opladen wordt niet ingepland, omdat werkelijk niveau (93.0%) hoger is of gelijk aan gewenst niveau (85.0% minus de marge 0%), auto is niet ingeplugd.
2026-08-02 20:57:54 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-08-02 20:57:54 info: Apparaat Wasmachine direct starten staat uit
2026-08-02 20:57:55 info: Machine Wasmachine wordt niet ingepland, want er is gekozen voor Uit
2026-08-02 20:57:55 info: Strategie: minimale kosten
2026-08-02 20:57:55 info: Maximale fout (maximal gap): 0.005000 euro
2026-08-02 20:57:55 info: Rekentijd: 0.04  sec
2026-08-02 20:57:55 waarschuwing: Geen oplossing voor: minimize cost
jeroenribbink schreef op zondag 2 augustus 2026 @ 21:04:
...
Settings:
"entity setpoint": "input_number.dao_boiler_keuken_setpoint", // 60
"entity hysterese": "input_number.dao_boiler_setpoint_afwijking", // 5, heb ook 10 gehad
...
"heating allowed below": 55,
...
Met deze settings geef je DAO geen speelruimte:
De boiler gaat sowieso opwarmen als hij 55°C (= 60°C - 5 K hysterese) aantikt, maar DAO mag de boiler pas gaan opwarmen als hij onder de 55°C (=heating allowed below) is. Dus je geeft DAO geen speelruimte.
Vandaar geen oplossing.
Als dit je echte settings zijn kun je de boiler beter buiten DAO houden (boiler_present=false).

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


  • wmc
  • Registratie: November 2012
  • Laatst online: 09:26

wmc

wmc schreef op woensdag 29 juli 2026 @ 09:30:
Ik kom interessant gedrag tegen het instellen van een vermogenslimiet als functie van de SOC. Het gedrag dat ik wil instelllen is:

SOC <= 94% P = 7200W
SOC>95% P=1800W

Zoals in de wiki nu interpreteer wordt er geëxtrapoleerd voorbij de ingestelde SOC waarde, oftewel, de helling die ik nu instel is (7200-1800) = 5400 W / % SOC, wat betekent dat er effectief boven de 95% SOC niet geladen wordt. Ik heb daarom een extra punt toegevoegd op 100% SOC, dat hetzelfde vermogen geeft als SOC 95%. De instelling die ik daarvoor heb gezet is:
code:
1
2
3
4
5
      "reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800},
        { "soc": 100, "power": 1800}],
Dit levert hetvolgende gedrag op:

[Afbeelding]

Als ik de 100% SOC weghaal en dus de volgende instelling gebruik
code:
1
2
3
4
      "reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800}],
krijg ik hetvolgende gedrag.

[Afbeelding]


Waar zit mijn denkfout? Het lijkt er namelijk op dat met de eerste instelling het totale vermogen wordt beperkt op 1800W voor het hele SOC bereik.
Iemand een idee hoe het vermogenslimiet voor hoge SOC te implementeren?

  • The Source
  • Registratie: April 2000
  • Laatst online: 05-08 20:16
KC27 schreef op zondag 2 augustus 2026 @ 16:13:
[...]

Waarom heb je hysterese op 0 gezet?
Hysterese op 0 betekent dat er direct opgewarmd moet worden van 54.5 naar 55.0.
Wat staat er in de logging?
Top, dat was het probleem inderdaad.
Nu finetunen! Niet makkelijk om de cooling rate en het stroomverbruik te bepalen omdat deze onderdeel van een warmtepomp is.
The Source schreef op maandag 3 augustus 2026 @ 10:12:
[...]

Top, dat was het probleem inderdaad.
Nu finetunen! Niet makkelijk om de cooling rate en het stroomverbruik te bepalen omdat deze onderdeel van een warmtepomp is.
De cooling-rate kun je bepalen uit de HA-grafiek van de boiler-temperatuur:
Afbeeldingslocatie: https://tweakers.net/i/d4f9AlByTr8quGI5ZFsGmBYMNaU=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/KaMYuApEQTZATENThaO1q6rZ.png?f=user_large

Het stroomverbruik heb ik bepaald door het elektriciteitsverbruik van de warmtepomp uit te splitsen in het verbruik in de "statussen" ("heating", "hot water", "cooling", "no request") van de warmtepomp met behulp van een "utility meter" van HA en dan te kijken naar het verbruik tijdens de status "hot water".

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

wmc schreef op maandag 3 augustus 2026 @ 07:46:
[...]
code:
1
2
3
4
5
"reduce_power_high_soc": [        
        { "soc": 0, "power": 7200},
        { "soc": 94, "power": 7200},
        { "soc": 95, "power": 1800},
        { "soc": 100, "power": 1800}],
Je maakt in deze instelling twee fouten:
De regel bij "soc" = 0 hoort er niet, maar zou wel kunnen, maar de de regel "soc"=100 moet of weg of de power moet een stuk lager zijn.
Als je deze waarden in een grafiek zet zou je een "bolle" lijn moeten krijgen, maar nu krijg je een holle aan het einde afgeplatte lijn. Dat laatste stuk afgeplatte lijn domineert nu het hele plaatje en dus zal het vermogen nooit boven de 1800 W komen.

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


  • wmc
  • Registratie: November 2012
  • Laatst online: 09:26

wmc

KC27 schreef op dinsdag 4 augustus 2026 @ 10:01:
[...]

Je maakt in deze instelling twee fouten:
De regel bij "soc" = 0 hoort er niet, maar zou wel kunnen, maar de de regel "soc"=100 moet of weg of de power moet een stuk lager zijn.
Als je deze waarden in een grafiek zet zou je een "bolle" lijn moeten krijgen, maar nu krijg je een holle aan het einde afgeplatte lijn. Dat laatste stuk afgeplatte lijn domineert nu het hele plaatje en dus zal het vermogen nooit boven de 1800 W komen.
De holle lijn zoals je hem beschrijft is wel het gedrag dat de batterij laat zien. Boven de 95% SOC accepteert hij minder vermogen (~1800W). Daaronder accepteert hij meer, ik heb die waarde op 7200W gecapt. Ik zit dus met een dilemma, of de SOC komt nooit boven de ~96%, omdat de lijn wordt geëxtrapoleerd, waardoor het laadvermogen boven de 95% zo goed als nul is, of hij wordt geinterpoleerd, waardoor het laadvermogen <95% SOC nooit hoger wordt dan de 1800W die ik opgeef tussen de 95 en 100% SOC.


De plot hieronder is van een van de drie batterijen in de stack:
Afbeeldingslocatie: https://tweakers.net/i/ZqEXaDDpThVAvvqLjnoYzOGTmfo=/800x/filters:strip_exif()/f/image/NJQScE5iqBP3oNJiPmps02fJ.png?f=fotoalbum_large
Vanaf de 80% is dit toch een bolle lijn.
Ik zou dus zeggen:
  • "soc": 80, "power": 1850
  • "soc": 90, "power": 1800
  • "soc": 93, "power": 1500
  • "soc": 95, "power": 500
De volgende hoef je niet meer in te vullen want als je de lijn van 93 naar 95 doortrekt is ie al bij 96 op 0 (daar zorgt DAO dan weer voor).
In grafiek:
Afbeeldingslocatie: https://tweakers.net/i/PZcNcxv-1vyJrR9WZuwsZCyxmdU=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/af8MApwEH57Pu3E0zOOYjl2n.png?f=user_large
Het mip-algoritme van DAO werkt in deze situatie met begrenzingen (constraints). Ieder lijnstuk is een begrenzing die niet alleen geldt tussen de twee opgegeven SoC's maar over het hele SoC-gebied (0 - 100%): voor iedere SoC geldt dat het vermogen altijd kleiner of gelijk moet zijn aan de overeenkomende waarde bij een gegeven SoC.
Maar omdat er buiten de opgegeven grenzen vaak andere begrenzingen gelden (vandaar die bolle lijn) is de opgegeven begrenzing daar niet limiterend.

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


  • jeroenribbink
  • Registratie: November 2003
  • Laatst online: 05-08 20:27
KC27 schreef op zondag 2 augustus 2026 @ 22:09:
[...]

Met deze settings geef je DAO geen speelruimte:
De boiler gaat sowieso opwarmen als hij 55°C (= 60°C - 5 K hysterese) aantikt, maar DAO mag de boiler pas gaan opwarmen als hij onder de 55°C (=heating allowed below) is. Dus je geeft DAO geen speelruimte.
Vandaar geen oplossing.
Als dit je echte settings zijn kun je de boiler beter buiten DAO houden (boiler_present=false).
Dank je wel, maar waar ik niet bij kan is dat hij dan helemaal geen oplossing kan vinden.In mijn ogen zou hij dan de boiler kunnen uitsluiten van plannen, maar wel de batterij inplannen.
jeroenribbink schreef op dinsdag 4 augustus 2026 @ 20:25:
[...]

Dank je wel, maar waar ik niet bij kan is dat hij dan helemaal geen oplossing kan vinden.In mijn ogen zou hij dan de boiler kunnen uitsluiten van plannen, maar wel de batterij inplannen.
Ik zal kijken of ik in dit soort situaties een warning en uitsluiting van inplanning kan genereren.

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

@jeroenribbink
Zo wordt dus een prive project, dat ik deel zodat anderen er gebruik van kunnen maken, steeds meer een (exusez les mots) monkey proof project.

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


  • jeroenribbink
  • Registratie: November 2003
  • Laatst online: 05-08 20:27
KC27 schreef op dinsdag 4 augustus 2026 @ 22:48:
@jeroenribbink
Zo wordt dus een prive project, dat ik deel zodat anderen er gebruik van kunnen maken, steeds meer een (exusez les mots) monkey proof project.
Vind je dat erg? je bent erg betrokken bij de casussen of ideeën die mensen posten. ;)
jeroenribbink schreef op dinsdag 4 augustus 2026 @ 22:50:
[...]

Vind je dat erg? je bent erg betrokken bij de casussen of ideeën die mensen posten. ;)
Nee dat vind ik juist leuk: eerst had ik de lol om met die software de processen in mijn eigen huis te kunnen besturen.
Dat heb ik nu al vier jaar onder controle en nu heb ik lol om die software verder te professionaliseren. Ik ben geen echte software professional, maar met de steun en feedback hier van andere tweakers maken we er een mooi product van.

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


  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 19:45
BBuilds schreef op donderdag 16 oktober 2025 @ 22:00:
@Bravo Bedankt voor de hulp. Ik begrijp de logica achter de naamgeving * production/consumption nog steeds niet 100%, maar door jouw hulp staat het nu goed geconfigureerd, waarvoor dank.

Ik heb ondertussen ook de calc_baseload functie in orde gekregen door mijn solar productie bij entities solar production ac te plaatsen ipv bij entities solar production dc (trial and error), ookal heb ik een hybride solar omvormer met dc gekoppelde batterij.
Heb ik de config daarvan verkeerd begrepen? Welk soort solar moet er dan bij Solar DC geconfigureerd worden?

Als ik m'n solar bij entities solar production dc vermeld krijg ik overdag allemaal negatieve waarden:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2025-10-16 21:11:26 info: Day Ahead Optimalisering versie: 2025.10.4
2025-10-16 21:11:26 info: Day Ahead Optimalisering gestart op: 16-10-2025 21:11:26
2025-10-16 21:11:26 info: Day Ahead Optimalisatie gestart: 16-10-2025 21:11:26 taak: calc_baseloads
2025-10-16 21:11:26 waarschuwing: "last invoice" (2022-09-01) is verouderd en moet worden bijgewerkt
2025-10-16 21:11:36 info: baseload voor weekdag 0 :
2025-10-16 21:11:36 info: 0.347 0.297 0.347 0.335 0.309 0.309 0.335 0.184 -0.202 -0.855 -0.999 -1.269 -1.756 -2.742 -2.449 -1.991 -2.022 -1.62 -0.166 0.976 0.697 0.771 0.641 0.635 
2025-10-16 21:11:46 info: baseload voor weekdag 1 :
2025-10-16 21:11:46 info: 0.646 0.609 0.585 0.61 0.621 0.592 0.334 0.083 -0.228 -0.616 -0.873 -1.376 -1.643 -1.975 -2.257 -1.966 -1.916 -1.179 -0.093 0.711 0.659 0.584 0.372 0.422 
2025-10-16 21:11:56 info: baseload voor weekdag 2 :
2025-10-16 21:11:56 info: 0.285 0.322 0.335 0.272 0.31 0.285 0.322 0.284 -0.017 -0.551 -0.997 -1.237 -1.558 -1.641 -1.908 -1.678 -1.556 -0.501 0.012 0.422 0.497 0.434 0.359 0.384 
2025-10-16 21:12:07 info: baseload voor weekdag 3 :
2025-10-16 21:12:07 info: 0.347 0.347 0.347 0.31 0.322 0.322 0.297 0.132 -0.255 -0.789 -1.161 -1.351 -1.482 -1.427 -2.04 -2.14 -2.518 -1.265 -0.404 0.358 0.485 0.572 0.447 0.335 
2025-10-16 21:12:17 info: baseload voor weekdag 4 :
2025-10-16 21:12:17 info: 0.31 0.31 0.322 0.297 0.322 0.334 0.372 0.158 -0.34 -0.688 -1.075 -1.348 -1.661 -2.18 -2.053 -1.39 -2.306 -1.48 0.083 0.572 0.572 0.584 0.497 0.697 
2025-10-16 21:12:27 info: baseload voor weekdag 5 :
2025-10-16 21:12:27 info: 0.809 0.634 0.547 0.634 0.447 0.322 0.347 0.434 -0.117 -0.473 -1.015 -1.704 -2.136 -2.499 -2.901 -2.215 -1.878 -1.672 -0.275 0.455 0.359 0.397 0.384 0.659 
2025-10-16 21:12:37 info: baseload voor weekdag 6 :
2025-10-16 21:12:37 info: 0.659 0.684 0.409 0.334 0.297 0.285 0.31 0.134 -0.235 -0.866 -1.248 -1.303 -1.823 -2.48 -2.677 -2.911 -2.603 -1.612 -0.304 0.492 0.584 0.872 0.622 0.471 
<sys>:0: ResourceWarning: unclosed database in <sqlite3.Connection object at 0x7ffee3cd6e30>
Als ik dezelfde entiteit bij entities solar production ac vermeld in de config komen er wel allemaal geloofwaardige positieve waardes
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2025-10-16 21:22:10 info: Day Ahead Optimalisering versie: 2025.10.4
2025-10-16 21:22:10 info: Day Ahead Optimalisering gestart op: 16-10-2025 21:22:10
2025-10-16 21:22:10 info: Day Ahead Optimalisatie gestart: 16-10-2025 21:22:10 taak: calc_baseloads
2025-10-16 21:22:10 waarschuwing: "last invoice" (2022-09-01) is verouderd en moet worden bijgewerkt
2025-10-16 21:22:21 info: baseload voor weekdag 0 :
2025-10-16 21:22:21 info: 0.347 0.297 0.347 0.335 0.309 0.309 0.335 0.26 0.385 0.745 1.126 1.393 1.081 1.145 1.339 1.347 1.09 1.13 0.896 1.101 0.697 0.771 0.641 0.635 
2025-10-16 21:22:31 info: baseload voor weekdag 1 :
2025-10-16 21:22:31 info: 0.646 0.609 0.585 0.61 0.621 0.592 0.334 0.295 0.397 0.796 0.764 0.799 0.932 1.3 1.455 1.109 0.572 0.896 0.582 0.861 0.671 0.584 0.372 0.422 
2025-10-16 21:22:41 info: baseload voor weekdag 2 :
2025-10-16 21:22:41 info: 0.285 0.322 0.335 0.272 0.31 0.285 0.322 0.372 0.258 0.399 0.628 0.775 1.067 1.296 0.867 0.935 0.832 0.724 0.575 0.596 0.522 0.434 0.359 0.384 
2025-10-16 21:22:52 info: baseload voor weekdag 3 :
2025-10-16 21:22:52 info: 0.347 0.347 0.347 0.31 0.322 0.322 0.297 0.283 0.533 0.611 0.989 1.186 1.68 1.648 1.072 0.622 0.52 0.798 0.858 0.571 0.498 0.572 0.447 0.335 
2025-10-16 21:23:02 info: baseload voor weekdag 4 :
2025-10-16 21:23:02 info: 0.31 0.31 0.322 0.297 0.322 0.334 0.372 0.371 0.685 0.987 1.162 1.19 1.176 1.244 1.135 1.547 1.169 0.995 1.07 0.797 0.61 0.584 0.497 0.697 
2025-10-16 21:23:12 info: baseload voor weekdag 5 :
2025-10-16 21:23:12 info: 0.809 0.634 0.547 0.634 0.447 0.322 0.347 0.534 0.708 1.114 0.835 0.772 0.764 0.576 0.661 0.985 0.959 0.74 0.775 0.58 0.384 0.397 0.384 0.659 
2025-10-16 21:23:22 info: baseload voor weekdag 6 :
2025-10-16 21:23:22 info: 0.659 0.684 0.409 0.334 0.297 0.285 0.31 0.284 0.653 0.972 1.152 1.385 1.289 1.307 1.398 0.951 0.822 0.825 0.708 0.567 0.597 0.872 0.622 0.471 
<sys>:0: ResourceWarning: unclosed database in <sqlite3.Connection object at 0x7fff3c7f6e30>
Ziet er veel beter uit zo! d:)b
[Afbeelding]
Tenzij ik er overheen gelezen heb, heeft @BBuilds nooit een antwoord gekregen op deze post van 16 oktober. Ik loop tegen hetzelfde probleem aan. Mijn zonnepanelen zijn aangesloten op een hybride omvormer (AlphaESS Smile-G3-T10) met DC-gekoppelde accu. Ik heb dus (lijkt me) alleen maar "entities_solar_production_dc" en géén "entities_solar_production_ac", en dat heb ik ook als zodanig ingevuld in mijn DAO options bestand. Maar dit zorgt ervoor dat mijn baseload calculation voor geen meter klopt, daar komen negatieve waarden uit. De workaround hiervoor is, net zoals bij @BBuilds, om de sensor voor PV productie dan maar onder "entities_solar_production_ac" te zetten. Maar eigenlijk is dit toch niet correct? En ik zal toch niet de enige persoon hier zijn met een hybride omvormer?

Dus, mis ik iets, of is dit een bugje dat wel eens gefikst mag worden? :)

Hoe dan ook, hartelijk dank voor deze software, ook al heeft ie me tot nu toe meer hoofdpijn gebracht dan me lief is |:( :+

Only connect...


  • wmc
  • Registratie: November 2012
  • Laatst online: 09:26

wmc

KC27 schreef op dinsdag 4 augustus 2026 @ 15:42:
Vanaf de 80% is dit toch een bolle lijn.
Ik zou dus zeggen:
  • "soc": 80, "power": 1850
  • "soc": 90, "power": 1800
  • "soc": 93, "power": 1500
  • "soc": 95, "power": 500
De volgende hoef je niet meer in te vullen want als je de lijn van 93 naar 95 doortrekt is ie al bij 96 op 0 (daar zorgt DAO dan weer voor).
In grafiek:
[Afbeelding]
Het mip-algoritme van DAO werkt in deze situatie met begrenzingen (constraints). Ieder lijnstuk is een begrenzing die niet alleen geldt tussen de twee opgegeven SoC's maar over het hele SoC-gebied (0 - 100%): voor iedere SoC geldt dat het vermogen altijd kleiner of gelijk moet zijn aan de overeenkomende waarde bij een gegeven SoC.
Maar omdat er buiten de opgegeven grenzen vaak andere begrenzingen gelden (vandaar die bolle lijn) is de opgegeven begrenzing daar niet limiterend.
Dat komt deels overeen met het echte gedrag, hierbij een zoom op 90-100% SOC

Afbeeldingslocatie: https://tweakers.net/i/Ws4ql6UPMZ0uV3KcAECq1Mto9xQ=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/9rZHYBSY8YuKVY1wCryAljZw.png?f=user_large

De rode lijnen zijn grove benaderingen van de limieten die ik wil instellen. Dat hij bij 96% nul wordt is precies niet wat ik wil.

Opmerking bij deze data: De temperatuur van de omvormer heeft ook nog invloed op het maximale vermogen, vandaar dat er enigszins spreiding te zien is. Ook draait de batterij zo nu en dan op NOM modus in plaats van maximaal ontladen, dat heb ik er niet uitgefilterd.

  • Dogooder
  • Registratie: April 2004
  • Laatst online: 19:36

Dogooder

dus...

@vlix Nee je bent niet de enige, ik heb ook een hybride omvormer met mijn zonnepanelen op dc en mijn baseload wordt ook meer negatief naarmate ik meer zon overschot heb.

Ik heb er eerder even vluchtig naar gekeken en kon de "bug" zo snel niet vinden.

Maar ik wil hier binnenkort wel even dieper naar kijken om te kijken of ik tot een oplossing kan komen.
@vlix en @Dogooder
Kunnen jullie hier je settings (m.n. van de batterij, je solar en je reports) hier delen, liefst tussen quote- en code=json tags?

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

wmc schreef op woensdag 5 augustus 2026 @ 09:19:
[...]


Dat komt deels overeen met het echte gedrag, hierbij een zoom op 90-100% SOC

[Afbeelding]

De rode lijnen zijn grove benaderingen van de limieten die ik wil instellen. Dat hij bij 96% nul wordt is precies niet wat ik wil.

Opmerking bij deze data: De temperatuur van de omvormer heeft ook nog invloed op het maximale vermogen, vandaar dat er enigszins spreiding te zien is. Ook draait de batterij zo nu en dan op NOM modus in plaats van maximaal ontladen, dat heb ik er niet uitgefilterd.
Met het mip-algoritme is het niet mogelijk om de vlakke lijn boven 97% SoC te implementeren.
Misschien moet je dat ook niet willen.
Weet je wat de cel-spanning is als de 97% wordt bereikt?
Als de cel-spanning boven de 3,45 V komt is eigenlijk de verzadiging bereikt en ben je alleen maar de cellen aan het opwarmen, de balancering aan het voeden (tenminste als er een top-balancering in je bms zit) en schade aan de cellen aan het toebrengen.

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


  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 19:45
KC27 schreef op woensdag 5 augustus 2026 @ 10:49:
@vlix en @Dogooder
Kunnen jullie hier je settings (m.n. van de batterij, je solar en je reports) hier delen, liefst tussen quote- en code=json tags?
Bij deze:
JSON:
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
{
  "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_attempts": 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.020496,
      "2026-08-03": 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-08-03": 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": "2026-08-03",
    "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.35,
  0.35,
  0.35,
  0.35,
  0.35,
  0.35,
  0.38,
  0.42,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.45,
  0.50,
  0.50,
  0.50,
  0.50,
  0.50,
  0.42,
  0.38
],
  "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": "input_select.dao_strategy",
  "max_gap": 0.005,
  "notifications": {
    "opstarten": false,
    "berekening": false
  },
  "grid": {
    "max_power": 17.0
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },


"battery": [
  {
    "name": "AlphaESS Smile-G3-T10",

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

    "capacity": 9.3,
    "upper limit": "input_number.dao_upper_limit",
    "lower limit": "input_number.dao_lower_limit",
    "optimal lower level": "input_number.dao_optimal_lower_level",
    "entity min soc end opt": "input_number.dao_min_soc_einde",
    "entity max soc end opt": "input_number.dao_max_soc_einde",
    
    "charge stages": [
      { "power": 0,    "efficiency": 1.0 },
      { "power": 1000, "efficiency": 0.965 },
      { "power": 2500, "efficiency": 0.960 },
      { "power": 4000, "efficiency": 0.955 },
      { "power": 5000, "efficiency": 0.950 }
    ],

    "discharge stages": [
      { "power": 0,    "efficiency": 1.0 },
      { "power": 1000, "efficiency": 0.965 },
      { "power": 2500, "efficiency": 0.960 },
      { "power": 4000, "efficiency": 0.955 },
      { "power": 5000, "efficiency": 0.950 }
    ],

    "minimum power": 100,

    "dc_to_bat efficiency": 0.968,
    "dc_to_bat max power": 5000,

    "bat_to_dc efficiency": 0.968,
    "bat_to_dc max power": 5000,

    "cycle cost": 0.015,
    "entity set power feedin": "input_number.dao_set_power_feedin",
    "entity set operating mode": "input_select.dao_set_operating_mode",
    "entity stop inverter": "input_datetime.dao_stop_inverter",
    "entity balance switch": "input_boolean.dao_balance_switch",
    "entity from battery": "input_number.dao_from_battery",
    "entity from ac": "input_number.dao_from_ac",
    "entity from pv": "input_number.dao_from_pv",
    "entity calculated soc": "input_number.dao_calculated_soc",

   "solar": [
      {
        "name": "AlphaESS PV",

        "entity pv switch": "input_boolean.alphaess_helper_dispatch_pv_switch",

        "ml_prediction": false,

        "entities sensors": [
          "sensor.alphaess_total_energy_from_pv"
        ],

        "strings": [
          {
            "tilt": 28,
            "orientation": 60,
            "capacity": 3.6,
            "yield": 0.00765
          },
          {
            "tilt": 28,
            "orientation": -120,
            "capacity": 3.15,
            "yield": 0.00669
          }
        ],

        "max_power": 6.75
      }
    ]
  }
],


"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.alphaess_total_energy_consumption_from_grid_meter"      
    ],
    "entities_grid_production": [
      "sensor.alphaess_total_energy_feed_to_grid_meter"      
    ],
    "entities_solar_production_dc": [
      "sensor.alphaess_total_energy_from_pv"
    ],
    "entities_solar_production_ac": [],
    "entities_ev_consumption": [
      "sensor.laadpunt_total_energy"
    ],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.alphaess_total_energy_charge_battery"
    ],
    "entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
    ],
    "entities_machine_consumption": []
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "0235",
        "action": "calc_baseloads"
      },
      {
        "time": "0435",
        "action": "get_meteo_data"
      },
      {
        "time": "1035",
        "action": "get_meteo_data"
      },
      {
        "time": "1635",
        "action": "get_meteo_data"
      },
      {
        "time": "2235",
        "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": "1840",
        "action": "train_ml_predictions"
      },
      {
        "time": "xx00",
        "action": "calc_optimum"
      },
      {
        "time": "xx15",
        "action": "calc_optimum"
      },
      {
        "time": "xx30",
        "action": "calc_optimum"
      },
      {
        "time": "xx45",
        "action": "calc_optimum"
      },
      {
        "time": "2359",
        "action": "clean_data"
      }
    ]
  }
}

Only connect...

Ik zie bij "report" o.a. staan:
JSON:
1
2
3
    "entities_solar_production_dc": [
      "sensor.alphaess_total_energy_from_pv"
    ],
Maar deze doen daar niks en worden ook niet gebruikt voor de berekening van de baseload.
Belangrijk is dat in
JSON:
1
2
"entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
Niet alleen de energie wordt gemeten die uit de cellen van je batterij komen maar alles wat vanuit je Alpa ESS-omvormer naar je meterkast gaat.
Als dat zo is: hoe ziet je balans-rapportage (report/balans) van gisteren eruit (liefst in tabelvorm)?
Ik bedoel deze:
Afbeeldingslocatie: https://tweakers.net/i/hzJPW2coX1BUS2eVQPt5DCbBRq0=/800x/filters:strip_exif()/f/image/zA6azLHpfHuxl0Kp6JOGenuJ.png?f=fotoalbum_large

[ Voor 26% gewijzigd door KC27 op 05-08-2026 11:53 ]

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


  • wmc
  • Registratie: November 2012
  • Laatst online: 09:26

wmc

KC27 schreef op woensdag 5 augustus 2026 @ 11:13:
[...]

Met het mip-algoritme is het niet mogelijk om de vlakke lijn boven 97% SoC te implementeren.
Misschien moet je dat ook niet willen.
Weet je wat de cel-spanning is als de 97% wordt bereikt?
Als de cel-spanning boven de 3,45 V komt is eigenlijk de verzadiging bereikt en ben je alleen maar de cellen aan het opwarmen, de balancering aan het voeden (tenminste als er een top-balancering in je bms zit) en schade aan de cellen aan het toebrengen.
Die wordt inderdaad (volgens de Zendure integratie) hoger dan 3.45V. De beperking op het laden komt ook uit de Zendure omvormer zelf, misschien moet ik de maximale capaciteit dan ook maar op 95% of iets dergelijks zetten. Goede suggestie!

  • Dogooder
  • Registratie: April 2004
  • Laatst online: 19:36

Dogooder

dus...

KC27 schreef op woensdag 5 augustus 2026 @ 11:49:
[...]
JSON:
1
2
"entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
Niet alleen de energie wordt gemeten die uit de cellen van je batterij komen maar alles wat vanuit je Alpa ESS-omvormer naar je meterkast gaat.
Als dat zo is: hoe ziet je balans-rapportage (report/balans) van gisteren eruit (liefst in tabelvorm)?
Dit had ik verkeerd gezet. Ik heb nu
entities_battery_production
en
_consumption
de entiteiten gegeven van mijn kWh meter die aan de AC zijde van het systeem zit. Deze meet dus alles wat in en uit het systeem gaat.

Helaas blijven mijn baseload waardes in de reports negatief, maar bij de baseload berekening zie ik geen negatieve waardes meer.

  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 19:45
KC27 schreef op woensdag 5 augustus 2026 @ 11:49:
[...]

Ik zie bij "report" o.a. staan:
JSON:
1
2
3
    "entities_solar_production_dc": [
      "sensor.alphaess_total_energy_from_pv"
    ],
Maar deze doen daar niks en worden ook niet gebruikt voor de berekening van de baseload.
Belangrijk is dat in
JSON:
1
2
"entities_battery_production": [
      "sensor.alphaess_total_energy_discharge_battery"
Niet alleen de energie wordt gemeten die uit de cellen van je batterij komen maar alles wat vanuit je Alpa ESS-omvormer naar je meterkast gaat.
Als dat zo is: hoe ziet je balans-rapportage (report/balans) van gisteren eruit (liefst in tabelvorm)?
Ik bedoel deze:
[Afbeelding]
Bij deze een screenshot van mijn balans-rapportage van gisteren:

Afbeeldingslocatie: https://tweakers.net/i/229ZOUgoVQB-0AE8QhkmphVk-CA=/800x/filters:strip_exif()/f/image/GOZOfGiTnx47oMU8pivQHaSB.png?f=fotoalbum_large

Ik gok dat "sensor.alphaess_total_energy_discharge_battery" precies weergeeft wat je van de naam zou verwachten: de totale energie geleverd door de accu en niks anders.

Ik weet niet of ik een sensor heb die precies doet wat jij vraagt. Overzicht van vergelijkbare sensors in mijn systeem:

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

Moet ik voor entities_battery_production dan sensor.alphaess_total_energy_feed_to_grid_meter gebruiken? Dat is dan alle energie die uit mijn omvormer komt, exclusief eigen verbruik. Of moet ik twee waardes combineren? Of moet ik simpelweg hiervoor óók sensor.alphaess_total_energy_from_pv gebruiken? Dat is alle door de PV opgewekte energie, inclusief energie die in eerste instantie in de accu wordt geduwd en dus pas later geconsumeerd wordt via de meterkast.

Only connect...

Dogooder schreef op woensdag 5 augustus 2026 @ 16:44:
[...]


Dit had ik verkeerd gezet. Ik heb nu
entities_battery_production
en
_consumption
de entiteiten gegeven van mijn kWh meter die aan de AC zijde van het systeem zit. Deze meet dus alles wat in en uit het systeem gaat.

Helaas blijven mijn baseload waardes in de reports negatief, maar bij de baseload berekening zie ik geen negatieve waardes meer.
Kun je je report/balans van gisteren 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

vlix schreef op woensdag 5 augustus 2026 @ 17:50:
[...]

Bij deze een screenshot van mijn balans-rapportage van gisteren:

~[Afbeelding]

Ik gok dat "sensor.alphaess_total_energy_discharge_battery" precies weergeeft wat je van de naam zou verwachten: de totale energie geleverd door de accu en niks anders.

Ik weet niet of ik een sensor heb die precies doet wat jij vraagt. Overzicht van vergelijkbare sensors in mijn systeem:

~[Afbeelding]

Moet ik voor entities_battery_production dan sensor.alphaess_total_energy_feed_to_grid_meter gebruiken? Dat is dan alle energie die uit mijn omvormer komt, exclusief eigen verbruik. Of moet ik twee waardes combineren? Of moet ik simpelweg hiervoor óók sensor.alphaess_total_energy_from_pv gebruiken? Dat is alle door de PV opgewekte energie, inclusief energie die in eerste instantie in de accu wordt geduwd en dus pas later geconsumeerd wordt via de meterkast.
Ik durf het niet met zekerheid te zeggen, maar ik vermoed dat je "sensor.alphaess_total_energy_feed_to_grid_meter" moet hebben.
Je kunt het eenvoudig uitproberen door deze sensor in te vullen en dan het balans-rapport van gisteren oproepen.
Je ziet nu dat er bijvoorbeeld om 13.00 door je P1-meter energie wordt teruggeleverd, maar waar komt die vandaan?

Oh misschien mijn fout:
Er staat
JSON:
1
2
3
4
5
6
7
 "report": {
    "entities_grid_consumption": [
      "sensor.alphaess_total_energy_consumption_from_grid_meter"      
    ],
    "entities_grid_production": [
      "sensor.alphaess_total_energy_feed_to_grid_meter"      
    ],
Zijn dat data van jouw slimme meter?

[ Voor 9% gewijzigd door KC27 op 05-08-2026 20:00 ]

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
  • Laatst online: 19:36

Dogooder

dus...

KC27 schreef op woensdag 5 augustus 2026 @ 19:52:
[...]

Kun je je report/balans van gisteren hier delen?
Bij deze:
Afbeeldingslocatie: https://tweakers.net/i/mUaMG6acnq_xgXsdSqxtmwbJZOg=/800x/filters:strip_exif()/f/image/MSfPxunSquxsWYtgEe8siUl8.png?f=fotoalbum_large

en de baseload berekening die nu zonder negatieve waardes is:
2026-08-05 22:40:46 info: Day Ahead Optimalisatie gestart: 05-08-2026 22:40:46 taak: calc_baseloads
2026-08-05 22:40:48 info: baseload voor weekdag 0 :
2026-08-05 22:40:48 info: 0.627 0.182 0.701 0.183 0.189 0.177 0.321 0.739 1.287 0.205 0.18 0.13 0.192 0.19 0.174 0.202 0.169 0.173 0.175 0.22 0.245 0.172 0.217 0.18 
2026-08-05 22:40:50 info: baseload voor weekdag 1 :
2026-08-05 22:40:50 info: 0.172 0.163 0.17 0.169 0.167 0.245 0.231 0.184 0.187 0.18 0.165 0.299 0.784 0.84 0.301 0.302 0.288 0.266 0.169 0.235 0.229 0.235 0.186 0.164 
2026-08-05 22:40:53 info: baseload voor weekdag 2 :
2026-08-05 22:40:53 info: 0.638 0.249 0.743 0.229 0.192 0.222 0.212 0.282 0.313 0.256 0.228 0.223 1.076 1.534 0.218 0.208 0.197 0.395 1.29 0.476 0.452 0.431 0.358 0.329 
2026-08-05 22:40:55 info: baseload voor weekdag 3 :
2026-08-05 22:40:55 info: 0.622 0.215 0.699 0.194 0.202 0.196 0.198 0.231 0.431 0.284 1.705 0.2 0.193 0.26 0.199 0.226 0.275 0.239 0.665 0.446 0.418 0.51 0.376 0.295 
2026-08-05 22:40:58 info: baseload voor weekdag 4 :
2026-08-05 22:40:58 info: 0.21 0.205 0.246 0.209 0.191 0.188 0.22 0.249 0.347 0.224 0.214 0.184 0.624 1.702 0.191 0.207 0.196 0.271 0.445 0.414 0.314 0.616 0.41 0.279 
2026-08-05 22:41:01 info: baseload voor weekdag 5 :
2026-08-05 22:41:01 info: 0.337 0.68 0.19 0.725 0.181 0.187 0.263 0.184 0.255 0.283 0.472 0.831 0.864 1.02 0.356 0.362 2.011 0.284 0.295 0.223 0.263 0.403 0.301 0.264 
2026-08-05 22:41:03 info: baseload voor weekdag 6 :
2026-08-05 22:41:03 info: 0.772 0.83 0.204 0.192 0.197 0.191 0.208 0.175 0.215 0.857 0.257 6.57 12.337 7.053 0.721 2.241 0.474 4.938 1.721 0.735 0.411 0.377 0.288 0.223
en het stuk config wat ik nu heb:
  "report": {
    "entities_grid_consumption": [
      "sensor.electricity_delivered_1",
      "sensor.electricity_delivered_2"
    ],
    "entities_grid_production": [
      "sensor.electricity_returned_1",
      "sensor.electricity_returned_2"
    ],
    "entities_solar_production_ac": [],
    "entities_solar_production_dc": [
      "sensor.ss_total_pv_energy"
    ],
    "entities_ev_consumption": [],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.battery_kwh_meter_energy_import"
    ],
    "entities_battery_production": [
      "sensor.battery_kwh_meter_energy_export"
    ],
    "entities_machine_consumption": []
  },
Daarbij zijn sensor.battery_kwh_meter_energy_import/export de waardes van een homewizard meter direct aan de grid zijde van de omvormer.
Ik ben nog aan het puzzelen hoe dit mogelijk is cq ontstaat.
Haal jij toevallig consumptie- (inkoop) en productiedata (teruglevering) op bij Tibber?

Morgen ben ik weg, maar ik kom er op terug!

[ Voor 16% gewijzigd door KC27 op 06-08-2026 00:22 ]

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
  • Laatst online: 19:36

Dogooder

dus...

KC27 schreef op donderdag 6 augustus 2026 @ 00:18:
[...]
Ik ben nog aan het puzzelen hoe dit mogelijk is cq ontstaat.
Haal jij toevallig consumptie- (inkoop) en productiedata (teruglevering) op bij Tibber?
Nee, ik haal prijzen op bij Nordpool en lees verder zelf mijn P1 meter uit met home assistant.

Ok oplossing is een restart van DAO 8)7

Ik heb:
  • De formule gecontroleerd: Ik heb de rapportformule controleerd om te kijken of deze overeenkomt met de weergegeven getallen, uur tot uur, voor zowel calc_base() (route: /reports → routes.py → get_energy_balance_data() → calc_balance_columns()) als calc_weekday_baseload(). Formule: cons − prod + bat_out − bat_in [+ pv_ac] − ev − wp − boil − mach. (Hoofdverdachte hier was het niet hebben van pc_dc)
  • Caching / verouderde data uitgesloten: Ik heb vastgesteld dat de values-tabel van dao database 0 rijen bevat voor bat_in/bat_out-codes. Elk rapport wordt dus rechtstreeks opgehaald via de live fallback (get_sensor_data() op de statistics-tabel van HA) en niet uit een cache.
  • Verkeerde database uitgesloten: Op een gegeven moment ga je aan jezelf twijfelen.
  • Directe aanroep van get_sensor_data(): Ik heb get_sensor_data() rechtstreeks aangeroepen voor sensor.battery_kwh_meter_energy_import. Dit leverde kleine, logische waarden op (~1,46 kWh/dag totaal), wat overeenkomt met de ruwe statistieken in HA. Dit kwam echter niet overeen met de opgeblazen getallen uit het rapport (16,6 kWh/dag).
  • Directe aanroep van get_energy_balance_data(): Toen ik get_energy_balance_data() direct aanriep met identieke datum, kon ik de opgeblazen getallen uit het rapport wél exact reproduceren.
  • Live-inspectie: Ik heb r.energy_balance_dict["bat_in"]["sensors"] / ["bat_out"]["sensors"] live geïnspecteerd. Dit verklaarde.

    Oorzaak:
    report.entities_battery_consumption / entities_battery_production zijn niet de sensoren die daadwerkelijk worden gebruikt:


    Volgens configuratie
    sensor.battery_kwh_meter_energy_import
    sensor.battery_kwh_meter_energy_export

    Daadwerkelijk geconfigureerd / gebruikt
    sensor.ss_total_battery_charge
    sensor.ss_total_battery_discharge
Oplossing:
restart dao

[ Voor 74% gewijzigd door Dogooder op 06-08-2026 12:19 ]


  • hemertje
  • Registratie: Juli 2015
  • Laatst online: 12:34
@KC27

Vraagje, nu in de zomer hebben we met de dynamische tarieven 1 dalperiode, overdag.

Over een paar maanden worden er dat 2, ‘s nachts en overdag.
Gaat DOA dat ook met 2 laad en ontlaad periodes rekenen?

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


  • tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 18:55
Ja zeker!. Er is vast mooier bewijs maar hierbij een oud screenshot van begin dit jaar waarbij dit redelijk te zien is: Twee keer batterij laden en twee keer ontladen binnen 24 uur.Afbeeldingslocatie: https://tweakers.net/i/T8szzBCOWuQPzbsMWXciE4SR2kM=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/2JeFI5g9dWPhdC34cP6PfoEa.png?f=user_large
Dogooder schreef op donderdag 6 augustus 2026 @ 09:44:
[...]

Nee, ik haal prijzen op bij Nordpool en lees verder zelf mijn P1 meter uit met home assistant.

Ok oplossing is een restart van DAO 8)7

Ik heb:
  • De formule gecontroleerd: Ik heb de rapportformule controleerd om te kijken of deze overeenkomt met de weergegeven getallen, uur tot uur, voor zowel calc_base() (route: /reports → routes.py → get_energy_balance_data() → calc_balance_columns()) als calc_weekday_baseload(). Formule: cons − prod + bat_out − bat_in [+ pv_ac] − ev − wp − boil − mach. (Hoofdverdachte hier was het niet hebben van pc_dc)
  • Caching / verouderde data uitgesloten: Ik heb vastgesteld dat de values-tabel van dao database 0 rijen bevat voor bat_in/bat_out-codes. Elk rapport wordt dus rechtstreeks opgehaald via de live fallback (get_sensor_data() op de statistics-tabel van HA) en niet uit een cache.
  • Verkeerde database uitgesloten: Op een gegeven moment ga je aan jezelf twijfelen.
  • Directe aanroep van get_sensor_data(): Ik heb get_sensor_data() rechtstreeks aangeroepen voor sensor.battery_kwh_meter_energy_import. Dit leverde kleine, logische waarden op (~1,46 kWh/dag totaal), wat overeenkomt met de ruwe statistieken in HA. Dit kwam echter niet overeen met de opgeblazen getallen uit het rapport (16,6 kWh/dag).
  • Directe aanroep van get_energy_balance_data(): Toen ik get_energy_balance_data() direct aanriep met identieke datum, kon ik de opgeblazen getallen uit het rapport wél exact reproduceren.
  • Live-inspectie: Ik heb r.energy_balance_dict["bat_in"]["sensors"] / ["bat_out"]["sensors"] live geïnspecteerd. Dit verklaarde.

    Oorzaak:
    report.entities_battery_consumption / entities_battery_production zijn niet de sensoren die daadwerkelijk worden gebruikt:


    Volgens configuratie
    sensor.battery_kwh_meter_energy_import
    sensor.battery_kwh_meter_energy_export

    Daadwerkelijk geconfigureerd / gebruikt
    sensor.ss_total_battery_charge
    sensor.ss_total_battery_discharge
Oplossing:
restart dao
Blijkbaar buffert DAO dus ergens data.
Gebruik jij sqlite engine voor de ha database?
Zou het een oplossing kunnen zijn om bij wijziging van de settings de database connectie af te sluiten en opnieuw op te starten?

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


  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 19:45
KC27 schreef op woensdag 5 augustus 2026 @ 19:58:
[...]

Ik durf het niet met zekerheid te zeggen, maar ik vermoed dat je "sensor.alphaess_total_energy_feed_to_grid_meter" moet hebben.
Je kunt het eenvoudig uitproberen door deze sensor in te vullen en dan het balans-rapport van gisteren oproepen.
Geprobeerd maar dan krijg ik nog steeds negatieve waardes in het balans-rapport.
Je ziet nu dat er bijvoorbeeld om 13.00 door je P1-meter energie wordt teruggeleverd, maar waar komt die vandaan?
Nou ja het antwoord is natuurlijk: van de DC-gekoppelde PV panelen, maar in het rapport is er geen kolom voor "PV DC", alleen een voor "PV ac"?
Oh misschien mijn fout:
Er staat
JSON:
1
2
3
4
5
6
7
 "report": {
    "entities_grid_consumption": [
      "sensor.alphaess_total_energy_consumption_from_grid_meter"      
    ],
    "entities_grid_production": [
      "sensor.alphaess_total_energy_feed_to_grid_meter"      
    ],
Zijn dat data van jouw slimme meter?
Het zijn data van mijn AlphaESS omvormer, maar ik denk dat die overeenkomen met data van mijn slimme meter?

Only connect...

vlix schreef op donderdag 6 augustus 2026 @ 16:37:
[...]

Geprobeerd maar dan krijg ik nog steeds negatieve waardes in het balans-rapport.


[...]

Nou ja het antwoord is natuurlijk: van de DC-gekoppelde PV panelen, maar in het rapport is er geen kolom voor "PV DC", alleen een voor "PV ac"?


[...]

Het zijn data van mijn AlphaESS omvormer, maar ik denk dat die overeenkomen met data van mijn slimme meter?
Heb je deze analyse gelezen:
Dogooder in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"
Misschien ook DAO herstarten?

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
  • Laatst online: 19:36

Dogooder

dus...

KC27 schreef op donderdag 6 augustus 2026 @ 14:52:
[...]

Blijkbaar buffert DAO dus ergens data.
Gebruik jij sqlite engine voor de ha database?
Zou het een oplossing kunnen zijn om bij wijziging van de settings de database connectie af te sluiten en opnieuw op te starten?
Ik gebruik sqlite engine voor de ha database ja. Maar hier zit het probleem niet.

gelukkig valt dit probleem te reproduceren. En heel wat testjes later.

run report() vanuit de container, gebruik private browsers, check de json editor save. Maar de hoofdverdachte nu is da_base.py.

Daar staat zelfs in comments:
# "Load config exactly once, even when multiple threads construct a # DaBase subclass concurrently (e.g. gunicorn workers sharing a process)."
Mijn test in de container: nieuw process; DaBase._config start; laad vers en is correct.
Gunicorn workers: Welke als eerste Report() aanroept locked-in de configuratie die gebruikt wordt.

  • memorynl
  • Registratie: Juni 2010
  • Nu online
Eindelijk zomervakantie deze week en begonnen met wat ik langer wilde doen: DAO instellen om mijn PV en accu’s (een Zendure Ac2400 en een HW PiB) te managen 💪.

Ik ben een heel eind gevorderd, alles draait. Maar waar ik mee worstel is de HW PiB. Voor zover ik weet kan ik die niet op een bepaald (ont)laadt vermogen instellen. Vaak bij NOM is dat wel prima te managen met load of unload only (bij de vertaling van HA entities naar HW-acties), maar het volle-bak-ontladen mis is ik toch wel.

Hoe zou ik daarmee om moeten gaan?

De PiB buiten de berekening laten en als baseload mee laten draaien? Iets in het MIP toevoegen zodat hij alleen NOM kan ontladen?

Wat zijn jullie ideeën om daarmee om te gaan (behalve de PiB verkopen 😇)?

  • vlix
  • Registratie: Augustus 2002
  • Laatst online: 19:45
Ja, wel gelezen, maar ik zal eerlijk bekennen dat ik het maar half snap. Het lijkt alsof Dogooder zelf de Python code in is gedoken, en daar heb ik mij niet aan gewaagd vooralsnog.

En ja, ik start DAO altijd opnieuw op nadat ik wat voor wijziging dan ook maak.

Mijn hersens kraken, dus ik ga een partij domme vragen stellen. Bij voorbaat excuses.
  1. DAO verwacht dus voor "entities_battery_production" niet de output van de accu, maar de output van de accu plus output van PV? Maar waarom heet "entities_battery_production" dan zoals hij heet? Mijn hoofd zegt "does not compute"...
  2. Welke waardes in de DAO config worden nou precies gebruikt voor calc_baseloads, en volgens welke formule?
  3. En zijn dat dezelfde waardes die óók voor de reports worden gebruikt of zijn dat weer andere?
  4. Check dubbelcheck: met "baseload" wordt binnen de context van DAO toch het verbruik van de apparaten in mijn huis bedoeld exclusief het laden van de accu? Ergo de baseload kan per definitie niet negatief zijn?
  5. Ik test momenteel maar gewoon door nadat ik iets verander, DAO opnieuw te starten en een handmatige calc_baseloads te doen via het "run" menu. Ik merk dat ik dus nog steeds wél (wat lijkt op) realistische baseloads krijg als ik "sensor.alphaess_total_energy_from_pv" onder "entities_solar_production_ac" plaats en niet onder "entities_solar_production_dc". Hoe zit dat nou? Moet ik het dan maar zo laten staan ook al klopt het strikt gezien niet?
  6. Wat zijn nou eigenlijk de definities van "entities_solar_production_dc" en "entities_solar_production_ac"? Ik dacht dat met "entities_solar_production_ac" de input van PV panelen wordt bedoeld die via een "gewone" omvormer direct aan het net (of aan je huis) leveren, dus zonder hybride omvormer ertussen, en dat ik daarom per definitie geen enkele "entities_solar_production_ac" heb. Heb ik dit verkeerd begrepen?
Hartelijk dank voor je hulp en geduld!

Only connect...

Pagina: 1 ... 45 46 Laatste