Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[KC27]

Ferrox1 schreef op zondag 24 augustus 2025 @ 21:35:
Was het al een tijdje van plan, maar ook nu met DAO begonnen ter voorbereiding op volgend jaar. Ik heb zelf al de nodige Home Assistant helpers, scripts en automations geschreven om zo goedkoop mogelijk dingen te plannen. Dit gaat best goed, maar is wel alleen op basis van alleen de prijzen. Op dit moment is er geen accu systeem aanwezig dus een langere termijn is minder relevant.

Mijn situatie is als volgt:
26 zonnepanelen oost west (die moeten nog in DAO)
plug-in hybride (wordt nu gepland via een HASS plugin, werkt best goed) en SMART EVSE
PAP + SAP op de huisaansluiting, automatisch geschakeld, beide met P1 meter en rekent via Home Assistant dus netto verbruik van de aansluiting uit ter voorkoming van overbelasting van de grondzekering of interne onderdelen van de groepenkast
2 airco's voor verwarming

Komt volgend jaar er nog bij:
Warmtepompboiler voor SWW (zit nu op stadsverwarming en die is echt te duur voor alleen SWW)
Mogelijk 3 fasen Victron systeem met accu's

En nu komt het lastige, op 1 meter (PAP) is DAO prima te gebruiken. Ik heb beide meters inmiddels al wel in in DAO zitten. Ik heb in home assitant een YAML helper geschreven die beide meters samenvoegen tot 1 teruglever tarief en 1 verbruikstarief. De salderingen lopen ook niet gelijk (minder relevant als deze komt te vervallen). Nu gaat de meter met de laatste saldering op TLV vergoeding waardoor de eerst aflopen saldering prio krijgt op teruglevering.

Het mooiste zou zijn als je beide meters los in kunt voeren met hun eigen contracten, prijzen en salderingsdata. En dat DAO bepaald wanneer en waar het beste op verbruikt kan worden danwel terug geleverd kan worden (de eerste meter die gesaldeerd moet worden, heeft dan een hoger belang). Vervolgens kan ik HASS wel laten schakelen. Uiteindelijk doel is zelfs om wanneer dit het beste uitkomt, volledig op eilandbedrijf te gaan zodat onnodig verbruik of teruglevering compleet voorkomen word. Dus alleen wanneer ik (of het systeem) dit nodig acht maken we verbinding met het net. Dit kan ook als het nodig is om hogere vermogen te vragen dan beschikbaar van het Victron systeem voor bijvoorbeeld bij lage prijzen, volladen accu's en auto / koelen / verwarmen huis.

Een andere oplossing dat ik in plaats van de nordpool prijzen te laten ophalen door DAO, mijn berekende verbruik en terugleveringsprijzen in DAO kan laden. Dit scheelt ook dubbel opvragen vanuit hetzelfde adres.

Ik ben vooral benieuwd of er anderen zijn met een dergelijke opstelling en hoe zij dit gedaan hebben. Ik kom maar 1 iemand in dit topic vinden met een SAP en dat was @sjampeter . @KC27 , hoe denk jij hier over, hoe zou jij dit opzetten? Ik heb een vermoeden dat dit te complex is en een dergelijke opstelling komt niet vaak voor. Omdat dit ook redelijk schud aan de basis hoe DAO is opgebouwd om dit vrijer op te kunnen zetten.

Interessant.
Op korte termijn (eerste twee maanden) geeft DAO geen oplossing.
Er zit een aanpassing in de pijplijn waarmee gebruikers formules voor hun eigen tarieven (levering en teruglevering) kunnen configureren. Dat zou voor jou een oplossing kunnen zijn: als je het goed configureert rekent DAO dan met het goedkoopste inkooptarief en het "duurste" (=hoogste) teruglevertarief. Je kunt zelf in HA deze tarieven opvragen (met een api) en op basis daarvan je ap selecteren.
DAO gaat je niet helpen met je saldering berekenen. Dat zul je zelf moeten bijhouden en vertalen naar de formules voor de prijzen (maar dat is maar voor 1 jaar, vanaf 1 januari 2027 is er niks meer te salderen).

[KC27]

konehead schreef op zondag 24 augustus 2025 @ 22:40:
[...]


Dank voor je check!!

Check, dan heb ik je implementatie verkeerd begrepen. Ik dacht dat je AC en DC beide moest configureren. AC voor het gedeelte wat van de zonnepanelen en het net op gaat en DC voor panelen naar de batterij.

Mijn systeem: Ik heb een growatt inverter voor de panelen en batterij. Ik heb dus geen aparte inverter voor zon en geen aparte inverter voor de batterij. Als ik je reactie goed begrijp: ik moet dit dus als DC configureren?

Ja en dan die list bij "entities solar production ac" leeg houden: dus alleen [ ]

[mistral2]

De nieuwe meteodata grafieken zijn stukken beter nu! Alleen is het terugvinden ervan wat lastig. Is het mogelijk om onder de home tab een subtabje voor de meteo grafieken te maken zodat je daar makkleijk doorheen kan scrollen (en/of een optie onder reports om ze te bekijken...)?

[diamanten]

Vraagje over de baseload berekening:

code:

"use_calc_baseload": "False",

Ik heb nu de waarden in de tabel aangepast.
Kan ik ergens achterhalen of er voldoende data is om bijv. de baseload berekening te starten voor 56 dagen?

[Torch1969]

diamanten schreef op maandag 25 augustus 2025 @ 12:29:
Vraagje over de baseload berekening:

code:

"use_calc_baseload": "False",

Ik heb nu de waarden in de tabel aangepast.
Kan ik ergens achterhalen of er voldoende data is om bijv. de baseload berekening te starten voor 56 dagen?

Ten eerste moet je 56 dagen DAO goed en stabiel gedraaid hebben om genoeg bruikbare data beschikbaar te hebben. Daarna kun je handmatig een baseload berekening opstarten via het menu “Run”. Controleer de uitkomsten daarvan zelf. Zijn de waarden logisch en verklaarbaar? Grote uitschieters en negatieve waarden zijn verdacht en vergen specifieke analyse van de beschikbare data.
Je kunt die 56 dagen in de configuratie ook instellen op een andere periode.

[sMoKeFiSh]

KC27 schreef op woensdag 30 juli 2025 @ 10:39:
[...]

Ik heb de fout in de code gevonden en gefixed. Hopelijk worden daarmee je problemen opgelost.
In de volgende (test)versie zit de fix.

Het lijkt erop dat deze fout (nog) aanwezig is. DAO wil input_number.dao_from_battery, vullen met -26769, terwijl max van m'n config 18000 is. Ik heb op dit moment versie 2025.8.1.

code:

Logging van bewerking "Optimaliseringsberekening zonder debug":
2025-08-25 13:03:58 info: Day Ahead Optimalisering versie: 2025.8.1
2025-08-25 13:03:58 info: Day Ahead Optimalisering gestart op: 25-08-2025 13:03:58
2025-08-25 13:03:58 info: Day Ahead Optimalisatie gestart: 25-08-2025 13:03:58 taak: calc_optimum
2025-08-25 13:03:58 info: Debug = False
2025-08-25 13:03:58 info: Baseload uit instellingen
2025-08-25 13:03:58 info: Start waarden: 
    uur                tijd       p_l       p_t  base  pv_ac      pv_dc
0    13 2025-08-25 13:00:00  0.150040  0.150040  0.62      0  11.962734
1    14 2025-08-25 14:00:00  0.151068  0.151068  0.62      0  12.853658
2    15 2025-08-25 15:00:00  0.173357  0.173357  0.62      0  12.070340
3    16 2025-08-25 16:00:00  0.211097  0.211097  0.62      0   9.943457
4    17 2025-08-25 17:00:00  0.245594  0.245594  1.20      0   5.229467
5    18 2025-08-25 18:00:00  0.273170  0.273170  0.82      0   5.269557
6    19 2025-08-25 19:00:00  0.318133  0.318133  0.82      0   2.594402
7    20 2025-08-25 20:00:00  0.372607  0.372607  0.82      0   0.303783
8    21 2025-08-25 21:00:00  0.307509  0.307509  0.82      0   0.000000
9    22 2025-08-25 22:00:00  0.282063  0.282063  0.62      0   0.000000
10   23 2025-08-25 23:00:00  0.270096  0.270096  0.62      0   0.000000
2025-08-25 13:03:58 info: No reduced hours applied for Accu
2025-08-25 13:03:58 info: Startwaarde SoC Accu: 15.0%
2025-08-25 13:03:58 info: 

2025-08-25 13:03:58 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-08-25 13:03:58 info: Instellingen voor laden van EV: Tesla Model 3
2025-08-25 13:03:58 info: Direct laden is uit
2025-08-25 13:03:58 info:  Ampere  Effic. Grid kW Accu kW
2025-08-25 13:03:58 info:    0.00    1.00    0.00    0.00
2025-08-25 13:03:58 info:   10.00    1.00    6.90    6.90
2025-08-25 13:03:58 info:   12.00    1.00    8.28    8.28
2025-08-25 13:03:58 info:   14.00    1.00    9.66    9.66
2025-08-25 13:03:58 info:   16.00    0.99   11.04   10.93
2025-08-25 13:03:58 info: Capaciteit accu: 75 kWh
2025-08-25 13:03:58 info: Maximaal laadvermogen: 11.04 kW
2025-08-25 13:03:58 info: Klaar met laden op: 23-08-2025 19:30:00
2025-08-25 13:03:58 info: Huidig laadniveau: 70.0 %
2025-08-25 13:03:58 info: Gewenst laadniveau:80.0 %
2025-08-25 13:03:58 info: Marge voor het laden: 0 %
2025-08-25 13:03:58 info: Locatie: Work Gaby
2025-08-25 13:03:58 info: Ingeplugged:False
2025-08-25 13:03:58 info: Benodigde energie: 0 kWh
2025-08-25 13:03:58 info: Tijd nodig om te laden: 0.00 uur
2025-08-25 13:03:58 info: Afgerond naar hele uren: 0
2025-08-25 13:03:58 info: Stand laden schakelaar: off
2025-08-25 13:03:58 info: Stand aantal ampere laden: 0.0 A
2025-08-25 13:03:58 info: Opladen wordt niet ingepland, omdat auto is niet huis, auto is niet ingeplugd, opgegeven tijdstip (2025-08-23 19:30:00) is verouderd.

2025-08-25 13:03:58 info: Instellingen voor laden van EV: Kia EV6
2025-08-25 13:03:58 info: Direct laden is uit
2025-08-25 13:03:58 info:  Ampere  Effic. Grid kW Accu kW
2025-08-25 13:03:58 info:    0.00    1.00    0.00    0.00
2025-08-25 13:03:58 info:   10.00    1.00    6.90    6.90
2025-08-25 13:03:58 info:   12.00    1.00    8.28    8.28
2025-08-25 13:03:58 info:   14.00    1.00    9.66    9.66
2025-08-25 13:03:58 info:   16.00    0.99   11.04   10.93
2025-08-25 13:03:58 info: Capaciteit accu: 77 kWh
2025-08-25 13:03:58 info: Maximaal laadvermogen: 11.04 kW
2025-08-25 13:03:58 info: Klaar met laden op: 24-08-2025 18:00:25
2025-08-25 13:03:58 info: Huidig laadniveau: 89.0 %
2025-08-25 13:03:58 info: Gewenst laadniveau:100.0 %
2025-08-25 13:03:58 info: Marge voor het laden: 0 %
2025-08-25 13:03:58 info: Locatie: Work Geoffrey
2025-08-25 13:03:58 info: Ingeplugged:True
2025-08-25 13:03:58 info: Benodigde energie: 0 kWh
2025-08-25 13:03:58 info: Tijd nodig om te laden: 0.00 uur
2025-08-25 13:03:58 info: Afgerond naar hele uren: 0
2025-08-25 13:03:58 info: Stand laden schakelaar: off
2025-08-25 13:03:58 info: Stand aantal ampere laden: 0.0 A
2025-08-25 13:03:58 info: Opladen wordt niet ingepland, omdat auto is niet huis, opgegeven tijdstip (2025-08-24 18:00:25) is verouderd.

2025-08-25 13:03:58 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

2025-08-25 13:03:58 info: Strategie: minimale kosten
2025-08-25 13:03:58 info: Het programma heeft een optimale oplossing gevonden.
2025-08-25 13:03:58 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -8.87 
2025-08-25 13:03:58 info: Geoptimaliseerd, kosten met day ahead tarieven: -16.72
2025-08-25 13:03:58 info: Levering: 42.93  (kWh)
2025-08-25 13:03:58 info: cannot handle a non-unique multi-index!
2025-08-25 13:03:58 info: Totals of accu Accu cannot be calculated
2025-08-25 13:03:58 info: In- en uitgaande energie per uur batterij Accu
uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
       kWh      %    kWh    kWh    kWh      %    kWh      %      %
 13  16.23  85.20  13.83  11.17  25.00  98.38  24.60 151.53  42.33
 14  17.38  85.20  14.81  12.85  27.66  98.38  27.21 156.57  72.56
 15   7.50  89.80   6.74  12.07  18.81  98.38  18.50 246.68  93.12
 16  -3.95  95.20  -4.15   9.94   5.79  98.38   5.70     --  99.45
 17  -4.50  95.20  -4.73   5.23   0.50  98.38   0.49     -- 100.00
 18  -7.50  93.40  -8.03   5.27  -2.76  98.38  -2.81 267.30  96.88
 19 -15.36  88.60 -17.34   2.59 -14.74  98.38 -14.98 102.50  80.23
 20 -15.36  88.60 -17.34   0.30 -17.03  98.38 -17.31  88.72  61.00
 21 -15.36  88.60 -17.34   0.00 -17.34  98.38 -17.62  87.16  41.42
 22 -10.50  91.50 -11.48   0.00 -11.48  98.38 -11.66  90.02  28.46
 23  -6.99  93.40  -7.49   0.00  -7.49  98.38  -7.61  91.89  20.00
2025-08-25 13:03:58 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 13.00   16.23     0.00  16.81   0.00   0.62   0.00   0.00   0.00   0.00   2.52   -0.00  20.00
 14.00   17.38     0.00  18.00   0.00   0.62   0.00   0.00   0.00   0.00   2.72   -0.00  20.00
 15.00    7.50     0.00   8.12   0.00   0.62   0.00   0.00   0.00   0.00   1.41   -0.00  20.00
 16.00    0.00     3.95   0.00   3.33   0.62   0.00   0.00   0.00   0.00   0.00   -0.70  20.00
 17.00    0.00     4.50   0.00   3.30   1.20   0.00   0.00   0.00   0.00   0.00   -0.81  20.00
 18.00    0.00     7.50   0.00   6.68   0.82   0.00   0.00   0.00   0.00   0.00   -1.82  20.00
 19.00    0.00    15.36   0.00  14.54   0.82   0.00   0.00   0.00   0.00   0.00   -4.63  20.00
 20.00    0.00    15.36   0.00  14.54   0.82   0.00   0.00   0.00   0.00   0.00   -5.42  20.00
 21.00    0.00    15.36   0.00  14.54   0.82   0.00   0.00   0.00   0.00   0.00   -4.47  20.00
 22.00    0.00    10.50   0.00   9.88   0.62   0.00   0.00   0.00   0.00   0.00   -2.79  20.00
 23.00    0.00     6.99   0.00   6.37   0.62   0.00   0.00   0.00   0.00   0.00   -1.72  20.00
Totaal   41.11    79.53  42.93  73.19   8.20   0.00   0.00   0.00   0.00   6.65  -22.36       
2025-08-25 13:03:58 info: Winst: € 7.85
2025-08-25 13:03:58 info: Doorzetten van alle settings naar HA
2025-08-25 13:03:58 info: Berekeningsuitkomst voor opladen van Tesla Model 3:
2025-08-25 13:03:58 info: - aantal ampere 0A (was 0.0A)
2025-08-25 13:03:58 info: - stand schakelaar 'off' (was 'off')
2025-08-25 13:03:58 info: - positie: Work Gaby
2025-08-25 13:03:58 info: - ingeplugd: False
2025-08-25 13:03:58 info: Tesla Model 3 is niet thuis of niet ingeplugd
2025-08-25 13:03:58 info: Evaluatie status laden Tesla Model 3 op 2025-08-25 13:03
2025-08-25 13:03:58 info: - schakelaar laden: off
2025-08-25 13:03:58 info: - aantal ampere: 0.0
2025-08-25 13:03:58 info: Berekeningsuitkomst voor opladen van Kia EV6:
2025-08-25 13:03:58 info: - aantal ampere 0A (was 0.0A)
2025-08-25 13:03:58 info: - stand schakelaar 'off' (was 'off')
2025-08-25 13:03:58 info: - positie: Work Geoffrey
2025-08-25 13:03:58 info: - ingeplugd: True
2025-08-25 13:03:58 info: Kia EV6 is niet thuis of niet ingeplugd
2025-08-25 13:03:58 info: Evaluatie status laden Kia EV6 op 2025-08-25 13:03
2025-08-25 13:03:58 info: - schakelaar laden: off
2025-08-25 13:03:58 info: - aantal ampere: 0.0
2025-08-25 13:03:58 info: Grid set point: 18000.0 W
2025-08-25 13:03:58 info: Cycle cost Accu: 0.00 euro
2025-08-25 13:03:59 info: Netto vermogen naar(+)/uit(-) omvormer Accu: 17380 W
2025-08-25 13:03:59 info: Balanceren: False
2025-08-25 13:03:59 fout: Fout bij schrijven naar input_number.dao_from_battery, waarde -26769
2025-08-25 13:03:59 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3487, in <module>
2025-08-25 13:03:59 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3463, in main
2025-08-25 13:03:59 fout: File: /root/dao/prog/da_base.py, line 573, in run_task_function
2025-08-25 13:03:59 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2854, in calc_optimum
2025-08-25 13:03:59 fout: File: /root/dao/prog/da_base.py, line 455, in set_entity_value
2025-08-25 13:03:59 fout: File: /root/dao/prog/da_base.py, line 217, in set_value

[Lasoul]

Net als nieuwe gebruiker de addon geinstallaleerd in Home Assistant.
Ik heb een MariaDB setup maar krijg bij het opstarten van de Day Ahead add-on de foutmelding dat hij niet op de "day_ahead" database kan inloggen:

code:

2025-08-25 13:39:18 373 [Warning] Access denied for user 'day_ahead'@'172.30.33.9' (using password: YES)

Ik heb ook al geprobeerd de database met het handje aan te maken en de day_ahead gebruiker alle rechten te geven lokaal en globaal maar dat werkt niet. Ik kan via HeidiSQL wel op de database inloggen met de gegevens dus het account werkt wel.

Ik heb de onderstaande config geprobeerd maar ook een config waarbij ik alle velden expliciet heb ingevuld:

code:

"database ha": {
    "password": "!secret db_ha_password"
  },
  "database da": {
    "password": "!secret db_ha_password"
  },

Iemand enig idee?

[DaBit]

Ik heb meerdere PV-AC installaties in het "solar": [] deel van de configuratie staan en het wordt weer eens tijd om de yieldgetalletjes bij te stellen (omdat de voorspellende modellen geen weet hebben van schaduw-werpende bomen en huizen, het snoeigedrag van de buren, enzovoorts)

Kan ik op een makkelijke manier achterhalen wat de prognoses van DAO per installatie waren?

[diamanten]

Lasoul schreef op maandag 25 augustus 2025 @ 14:04:
Net als nieuwe gebruiker de addon geinstallaleerd in Home Assistant.
Ik heb een MariaDB setup maar krijg bij het opstarten van de Day Ahead add-on de foutmelding dat hij niet op de "day_ahead" database kan inloggen:

code:

2025-08-25 13:39:18 373 [Warning] Access denied for user 'day_ahead'@'172.30.33.9' (using password: YES)

Ik heb ook al geprobeerd de database met het handje aan te maken en de day_ahead gebruiker alle rechten te geven lokaal en globaal maar dat werkt niet. Ik kan via HeidiSQL wel op de database inloggen met de gegevens dus het account werkt wel.

Ik heb de onderstaande config geprobeerd maar ook een config waarbij ik alle velden expliciet heb ingevuld:

code:

"database ha": {
    "password": "!secret db_ha_password"
  },
  "database da": {
    "password": "!secret db_ha_password"
  },

Iemand enig idee?

Deze config gebruiken:

code:

   "database ha": {
    "engine": "mysql",
    "database": "homeassistant",
    "username": "homeassistant",
    "password": "!secret db_ha_password"
  },
  "database da": {
    "engine" : "mysql",
    "database": "day_ahead",
    "port": 3306,
    "username": "day_ahead",
    "password": "!secret db_da_password"

[Bravo]

DaBit schreef op maandag 25 augustus 2025 @ 14:36:
Ik heb meerdere PV-AC installaties in het "solar": [] deel van de configuratie staan en het wordt weer eens tijd om de yieldgetalletjes bij te stellen (omdat de voorspellende modellen geen weet hebben van schaduw-werpende bomen en huizen, het snoeigedrag van de buren, enzovoorts)

Kan ik op een makkelijke manier achterhalen wat de prognoses van DAO per installatie waren?

Ik kan mij geen manier bedenken om nu terug te halen wat de prognoses per installatie waren.

Misschien dat je per installatie (de rest even uit de config halen) een meteorun kunt doen en dat met de opbrengst van vandaag/morgen kunt vergelijken?

[Lasoul]

diamanten schreef op maandag 25 augustus 2025 @ 16:08:
[...]

Deze config gebruiken:

code:

   "database ha": {
    "engine": "mysql",
    "database": "homeassistant",
    "username": "homeassistant",
    "password": "!secret db_ha_password"
  },
  "database da": {
    "engine" : "mysql",
    "database": "day_ahead",
    "port": 3306,
    "username": "day_ahead",
    "password": "!secret db_da_password"

Dat lijkt te helpen, thx!
Krijg nu het onderstaande in de logfile te zien:

code:

Setting up watches.
Watches established.
=> directory dao_data exist
=> /root/dao/data doesn't exist, made
=> /root/dao/webserver/app/static/data exist
Table "variabel" met inhoud gecreeerd.
Table "values" gecreeerd.
Table "prognoses" gecreeerd.
Table "variabel" geupdated.
Table "variabel" geupdated.
Setting up watches.
Watches established.
[2025-08-25 17:30:50 +0200] [12] [INFO] Starting gunicorn 23.0.0
[2025-08-25 17:30:50 +0200] [12] [INFO] Listening at: http://0.0.0.0:5000 (12)
[2025-08-25 17:30:50 +0200] [12] [INFO] Using worker: sync
[2025-08-25 17:30:50 +0200] [22] [INFO] Booting worker with pid: 22
[2025-08-25 17:30:50 +0200] [23] [INFO] Booting worker with pid: 23

Op de MariaDB addon nog wel de onderstaande melding gezien maar geen access denied meer:

code:

2025-08-25 17:30:44 402 [Warning] Aborted connection 402 to db: 'day_ahead' user: 'day_ahead' host: '172.30.33.9' (Got an error reading communication packets)

[DaBit]

Bravo schreef op maandag 25 augustus 2025 @ 16:26:
Misschien dat je per installatie (de rest even uit de config halen) een meteorun kunt doen en dat met de opbrengst van vandaag/morgen kunt vergelijken?

Jawel, zo kan ik een momentopname krijgen. Maar dat is niet zo heel nuttig. Het ene etmaal loopt de produktie voor op de voorspellling, het andere etmaal achter. Je wil dus eigenlijk de yield zodanig instellen dat de afwijking over een periode van zeg een paar weken zo klein mogelijk is want DAO heeft toch wel degelijk baat bij een redelijk accurate voorspelling.
Dat bijstellen van de yield automatiseren is het beste en KC27 heb ik daar wel eens wat over horen zeggen, maar voorlopig staan er zaken hoger op de prioriteitenlijst schat ik.

[KC27]

sMoKeFiSh schreef op maandag 25 augustus 2025 @ 13:09:
[...]


Het lijkt erop dat deze fout (nog) aanwezig is. DAO wil input_number.dao_from_battery, vullen met -26769, terwijl max van m'n config 18000 is. Ik heb op dit moment versie 2025.8.1.

code:

Logging van bewerking "Optimaliseringsberekening zonder debug":
2025-08-25 13:03:58 info: Day Ahead Optimalisering versie: 2025.8.1
2025-08-25 13:03:58 info: Day Ahead Optimalisering gestart op: 25-08-2025 13:03:58
2025-08-25 13:03:58 info: Day Ahead Optimalisatie gestart: 25-08-2025 13:03:58 taak: calc_optimum
2025-08-25 13:03:58 info: Debug = False
2025-08-25 13:03:58 info: Baseload uit instellingen
2025-08-25 13:03:58 info: Start waarden: 
    uur                tijd       p_l       p_t  base  pv_ac      pv_dc
0    13 2025-08-25 13:00:00  0.150040  0.150040  0.62      0  11.962734
1    14 2025-08-25 14:00:00  0.151068  0.151068  0.62      0  12.853658
2    15 2025-08-25 15:00:00  0.173357  0.173357  0.62      0  12.070340
3    16 2025-08-25 16:00:00  0.211097  0.211097  0.62      0   9.943457
4    17 2025-08-25 17:00:00  0.245594  0.245594  1.20      0   5.229467
5    18 2025-08-25 18:00:00  0.273170  0.273170  0.82      0   5.269557
6    19 2025-08-25 19:00:00  0.318133  0.318133  0.82      0   2.594402
7    20 2025-08-25 20:00:00  0.372607  0.372607  0.82      0   0.303783
8    21 2025-08-25 21:00:00  0.307509  0.307509  0.82      0   0.000000
9    22 2025-08-25 22:00:00  0.282063  0.282063  0.62      0   0.000000
10   23 2025-08-25 23:00:00  0.270096  0.270096  0.62      0   0.000000
2025-08-25 13:03:58 info: No reduced hours applied for Accu
2025-08-25 13:03:58 info: Startwaarde SoC Accu: 15.0%
2025-08-25 13:03:58 info: 

2025-08-25 13:03:58 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-08-25 13:03:58 info: Instellingen voor laden van EV: Tesla Model 3
2025-08-25 13:03:58 info: Direct laden is uit
2025-08-25 13:03:58 info:  Ampere  Effic. Grid kW Accu kW
2025-08-25 13:03:58 info:    0.00    1.00    0.00    0.00
2025-08-25 13:03:58 info:   10.00    1.00    6.90    6.90
2025-08-25 13:03:58 info:   12.00    1.00    8.28    8.28
2025-08-25 13:03:58 info:   14.00    1.00    9.66    9.66
2025-08-25 13:03:58 info:   16.00    0.99   11.04   10.93
2025-08-25 13:03:58 info: Capaciteit accu: 75 kWh
2025-08-25 13:03:58 info: Maximaal laadvermogen: 11.04 kW
2025-08-25 13:03:58 info: Klaar met laden op: 23-08-2025 19:30:00
2025-08-25 13:03:58 info: Huidig laadniveau: 70.0 %
2025-08-25 13:03:58 info: Gewenst laadniveau:80.0 %
2025-08-25 13:03:58 info: Marge voor het laden: 0 %
2025-08-25 13:03:58 info: Locatie: Work Gaby
2025-08-25 13:03:58 info: Ingeplugged:False
2025-08-25 13:03:58 info: Benodigde energie: 0 kWh
2025-08-25 13:03:58 info: Tijd nodig om te laden: 0.00 uur
2025-08-25 13:03:58 info: Afgerond naar hele uren: 0
2025-08-25 13:03:58 info: Stand laden schakelaar: off
2025-08-25 13:03:58 info: Stand aantal ampere laden: 0.0 A
2025-08-25 13:03:58 info: Opladen wordt niet ingepland, omdat auto is niet huis, auto is niet ingeplugd, opgegeven tijdstip (2025-08-23 19:30:00) is verouderd.

2025-08-25 13:03:58 info: Instellingen voor laden van EV: Kia EV6
2025-08-25 13:03:58 info: Direct laden is uit
2025-08-25 13:03:58 info:  Ampere  Effic. Grid kW Accu kW
2025-08-25 13:03:58 info:    0.00    1.00    0.00    0.00
2025-08-25 13:03:58 info:   10.00    1.00    6.90    6.90
2025-08-25 13:03:58 info:   12.00    1.00    8.28    8.28
2025-08-25 13:03:58 info:   14.00    1.00    9.66    9.66
2025-08-25 13:03:58 info:   16.00    0.99   11.04   10.93
2025-08-25 13:03:58 info: Capaciteit accu: 77 kWh
2025-08-25 13:03:58 info: Maximaal laadvermogen: 11.04 kW
2025-08-25 13:03:58 info: Klaar met laden op: 24-08-2025 18:00:25
2025-08-25 13:03:58 info: Huidig laadniveau: 89.0 %
2025-08-25 13:03:58 info: Gewenst laadniveau:100.0 %
2025-08-25 13:03:58 info: Marge voor het laden: 0 %
2025-08-25 13:03:58 info: Locatie: Work Geoffrey
2025-08-25 13:03:58 info: Ingeplugged:True
2025-08-25 13:03:58 info: Benodigde energie: 0 kWh
2025-08-25 13:03:58 info: Tijd nodig om te laden: 0.00 uur
2025-08-25 13:03:58 info: Afgerond naar hele uren: 0
2025-08-25 13:03:58 info: Stand laden schakelaar: off
2025-08-25 13:03:58 info: Stand aantal ampere laden: 0.0 A
2025-08-25 13:03:58 info: Opladen wordt niet ingepland, omdat auto is niet huis, opgegeven tijdstip (2025-08-24 18:00:25) is verouderd.

2025-08-25 13:03:58 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

2025-08-25 13:03:58 info: Strategie: minimale kosten
2025-08-25 13:03:58 info: Het programma heeft een optimale oplossing gevonden.
2025-08-25 13:03:58 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -8.87 
2025-08-25 13:03:58 info: Geoptimaliseerd, kosten met day ahead tarieven: -16.72
2025-08-25 13:03:58 info: Levering: 42.93  (kWh)
2025-08-25 13:03:58 info: cannot handle a non-unique multi-index!
2025-08-25 13:03:58 info: Totals of accu Accu cannot be calculated
2025-08-25 13:03:58 info: In- en uitgaande energie per uur batterij Accu
uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
       kWh      %    kWh    kWh    kWh      %    kWh      %      %
 13  16.23  85.20  13.83  11.17  25.00  98.38  24.60 151.53  42.33
 14  17.38  85.20  14.81  12.85  27.66  98.38  27.21 156.57  72.56
 15   7.50  89.80   6.74  12.07  18.81  98.38  18.50 246.68  93.12
 16  -3.95  95.20  -4.15   9.94   5.79  98.38   5.70     --  99.45
 17  -4.50  95.20  -4.73   5.23   0.50  98.38   0.49     -- 100.00
 18  -7.50  93.40  -8.03   5.27  -2.76  98.38  -2.81 267.30  96.88
 19 -15.36  88.60 -17.34   2.59 -14.74  98.38 -14.98 102.50  80.23
 20 -15.36  88.60 -17.34   0.30 -17.03  98.38 -17.31  88.72  61.00
 21 -15.36  88.60 -17.34   0.00 -17.34  98.38 -17.62  87.16  41.42
 22 -10.50  91.50 -11.48   0.00 -11.48  98.38 -11.66  90.02  28.46
 23  -6.99  93.40  -7.49   0.00  -7.49  98.38  -7.61  91.89  20.00
2025-08-25 13:03:58 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 13.00   16.23     0.00  16.81   0.00   0.62   0.00   0.00   0.00   0.00   2.52   -0.00  20.00
 14.00   17.38     0.00  18.00   0.00   0.62   0.00   0.00   0.00   0.00   2.72   -0.00  20.00
 15.00    7.50     0.00   8.12   0.00   0.62   0.00   0.00   0.00   0.00   1.41   -0.00  20.00
 16.00    0.00     3.95   0.00   3.33   0.62   0.00   0.00   0.00   0.00   0.00   -0.70  20.00
 17.00    0.00     4.50   0.00   3.30   1.20   0.00   0.00   0.00   0.00   0.00   -0.81  20.00
 18.00    0.00     7.50   0.00   6.68   0.82   0.00   0.00   0.00   0.00   0.00   -1.82  20.00
 19.00    0.00    15.36   0.00  14.54   0.82   0.00   0.00   0.00   0.00   0.00   -4.63  20.00
 20.00    0.00    15.36   0.00  14.54   0.82   0.00   0.00   0.00   0.00   0.00   -5.42  20.00
 21.00    0.00    15.36   0.00  14.54   0.82   0.00   0.00   0.00   0.00   0.00   -4.47  20.00
 22.00    0.00    10.50   0.00   9.88   0.62   0.00   0.00   0.00   0.00   0.00   -2.79  20.00
 23.00    0.00     6.99   0.00   6.37   0.62   0.00   0.00   0.00   0.00   0.00   -1.72  20.00
Totaal   41.11    79.53  42.93  73.19   8.20   0.00   0.00   0.00   0.00   6.65  -22.36       
2025-08-25 13:03:58 info: Winst: € 7.85
2025-08-25 13:03:58 info: Doorzetten van alle settings naar HA
2025-08-25 13:03:58 info: Berekeningsuitkomst voor opladen van Tesla Model 3:
2025-08-25 13:03:58 info: - aantal ampere 0A (was 0.0A)
2025-08-25 13:03:58 info: - stand schakelaar 'off' (was 'off')
2025-08-25 13:03:58 info: - positie: Work Gaby
2025-08-25 13:03:58 info: - ingeplugd: False
2025-08-25 13:03:58 info: Tesla Model 3 is niet thuis of niet ingeplugd
2025-08-25 13:03:58 info: Evaluatie status laden Tesla Model 3 op 2025-08-25 13:03
2025-08-25 13:03:58 info: - schakelaar laden: off
2025-08-25 13:03:58 info: - aantal ampere: 0.0
2025-08-25 13:03:58 info: Berekeningsuitkomst voor opladen van Kia EV6:
2025-08-25 13:03:58 info: - aantal ampere 0A (was 0.0A)
2025-08-25 13:03:58 info: - stand schakelaar 'off' (was 'off')
2025-08-25 13:03:58 info: - positie: Work Geoffrey
2025-08-25 13:03:58 info: - ingeplugd: True
2025-08-25 13:03:58 info: Kia EV6 is niet thuis of niet ingeplugd
2025-08-25 13:03:58 info: Evaluatie status laden Kia EV6 op 2025-08-25 13:03
2025-08-25 13:03:58 info: - schakelaar laden: off
2025-08-25 13:03:58 info: - aantal ampere: 0.0
2025-08-25 13:03:58 info: Grid set point: 18000.0 W
2025-08-25 13:03:58 info: Cycle cost Accu: 0.00 euro
2025-08-25 13:03:59 info: Netto vermogen naar(+)/uit(-) omvormer Accu: 17380 W
2025-08-25 13:03:59 info: Balanceren: False
2025-08-25 13:03:59 fout: Fout bij schrijven naar input_number.dao_from_battery, waarde -26769
2025-08-25 13:03:59 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3487, in <module>
2025-08-25 13:03:59 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3463, in main
2025-08-25 13:03:59 fout: File: /root/dao/prog/da_base.py, line 573, in run_task_function
2025-08-25 13:03:59 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 2854, in calc_optimum
2025-08-25 13:03:59 fout: File: /root/dao/prog/da_base.py, line 455, in set_entity_value
2025-08-25 13:03:59 fout: File: /root/dao/prog/da_base.py, line 217, in set_value

DAO schrijft 17380 W naar de entity die regelt hoeveel vermogen (in Watt) vanaf je meterkast in de Deye gaat
(en blijft daarmee binnen de doorjou opgegeven grenzen).
DAO schrijft -26769 W naar de "entity from battery" (die heet bij jou waarschijnlijk "input_number.dao_from_battery". De naamgeving daarvan is mogelijk verwarrend, zou eigenlijk moeten zijn:
"entity from bat to dc". Heb je in je settings dat vermogen gemaximeerd met "dc_to_bat max power" en "bat_to_dc max power". De grenzen die je hebt opgegeven in je settings van DAO moeten overeenkomen met de grenzen van de input_number.

Heb je voor mij de DAO-settings van je batterij?
Dan kunnen we daar samen naar kijken.

[KC27]

DaBit schreef op maandag 25 augustus 2025 @ 20:01:
[...]


Jawel, zo kan ik een momentopname krijgen. Maar dat is niet zo heel nuttig. Het ene etmaal loopt de produktie voor op de voorspellling, het andere etmaal achter. Je wil dus eigenlijk de yield zodanig instellen dat de afwijking over een periode van zeg een paar weken zo klein mogelijk is want DAO heeft toch wel degelijk baat bij een redelijk accurate voorspelling.
Dat bijstellen van de yield automatiseren is het beste en KC27 heb ik daar wel eens wat over horen zeggen, maar voorlopig staan er zaken hoger op de prioriteitenlijst schat ik.

Ik was er ook mee bezig, maar momenteel ligt het inderdaad stil door mijn werk voor het 15min interval.
Het idee is om per omvormer (niet per string want daar zijn geen meetdata van) de prognose )door DAO berekend) te vergelijken met de werkelijke meetdata (een entity uit HA). Voorlopig eerst d.m.v. een op te roepen rapportage. Later zou dit kunnen worden geautomatiseerd met een te berekenen correctiefactor per uur.
Ik pak het in de loop van oktober weer op, sorry ik kan je nu helaas niet uit de brand helpen.

[sMoKeFiSh]

KC27 schreef op maandag 25 augustus 2025 @ 22:53:
[...]


DAO schrijft 17380 W naar de entity die regelt hoeveel vermogen (in Watt) vanaf je meterkast in de Deye gaat
(en blijft daarmee binnen de doorjou opgegeven grenzen).
DAO schrijft -26769 W naar de "entity from battery" (die heet bij jou waarschijnlijk "input_number.dao_from_battery". De naamgeving daarvan is mogelijk verwarrend, zou eigenlijk moeten zijn:
"entity from bat to dc". Heb je in je settings dat vermogen gemaximeerd met "dc_to_bat max power" en "bat_to_dc max power". De grenzen die je hebt opgegeven in je settings van DAO moeten overeenkomen met de grenzen van de input_number.

Heb je voor mij de DAO-settings van je batterij?
Dan kunnen we daar samen naar kijken.

Hieronder mijn config. Mijn helper voor "entity from battery" - "input_number.dao_from_battery" heeft een min/max value van -20.000 tot 20.000. Klopt mijn redenering dat DAO input van grid (max 18.000 in mijn geval) en berekende PV opbrengst in deze helper wil opslaan? In dat geval moet ik de min/max value voor de helper aanpassen naar 18.000 + 23.000 aan PV?

code:

{
  "homeassistant": {
    "protocol api": "http",
    "host": "192.168.2.4",
    "ip port": 8123,
    "token": "!secret ha_api_token"},
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2024-08-01": 0.01653
    },
    "cost supplier production": {
      "2024-08-01": 0.01653
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2025-04-03",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.72,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    1.2,
    0.82,
    0.82,
    0.82,
    0.82,
    0.62,
    0.62
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "prices consumption": "True",
    "prices production": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 18
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
  {
      "name": "Accu",
      "entity actual level": "sensor.deye_12k_3_phase_x_2_battery_state_of_charge",
      "capacity": 90,
      "upper limit": 100,
      "lower limit": 15,
      "optimal lower level": 15,
      "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
        },
        {
          "power": 1500,
          "efficiency": 0.785
        },
        {
          "power": 3000,
          "efficiency": 0.872
        },
        {
          "power": 4500,
          "efficiency": 0.897
        },
        {
          "power": 6000,
          "efficiency": 0.899
        },
        {
          "power": 7500,
          "efficiency": 0.898
        },
        {
          "power": 9000,
          "efficiency": 0.892
        },
        {
          "power": 10500,
          "efficiency": 0.882
        },
        {
          "power": 12000,
          "efficiency": 0.871
        },
        {
          "power": 13050,
          "efficiency": 0.865
        },
        {
          "power": 15360,
          "efficiency": 0.860
        },
        {
          "power": 16500,
          "efficiency": 0.855
        },
        {
          "power": 18000,
          "efficiency": 0.850
        }
      ],
      "discharge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 600,
          "efficiency": 0.891
        },
        {
          "power": 1500,
          "efficiency": 0.935
        },
        {
          "power": 3000,
          "efficiency": 0.952
        },
        {
          "power": 4500,
          "efficiency": 0.952
        },
        {
          "power": 7500,
          "efficiency": 0.934
        },
        {
          "power": 9000,
          "efficiency": 0.925
        },
        {
          "power": 10500,
          "efficiency": 0.915
        },
        {
          "power": 12000,
          "efficiency": 0.9
        },
        {
          "power": 13050,
          "efficiency": 0.893
        },
        {
          "power": 15360,
          "efficiency": 0.886
        },
        {
          "power": 16500,
          "efficiency": 0.863
        },
        {
          "power": 18000,
          "efficiency": 0.850
        }
      ],
      "minimum power": 1000,
      "dc_to_bat efficiency": 0.9838,
      "bat_to_dc efficiency": 0.9838,
      "cycle cost": 0,
      "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 pv": "input_number.dao_from_pv",
      "entity from ac": "input_number.dao_from_grid",
      "entity calculated soc": "input_number.dao_calculated_soc",
      "solar": [
  {"name": "PV Tempelier Achterzijde",
    "tilt": 43,
    "orientation": -90,
    "capacity": 6.8,
    "yield": 0.016,
    "entity pv switch": ""
  },
  {"name": "PV Tempelier Overkapping",
    "tilt": 13,
    "orientation": 0,
    "capacity": 5.2,
    "yield": 0.014,
    "entity pv switch": ""
  },
  {"name": "PV Tempelier Uitbouw",
    "tilt": 10,
    "orientation": -90,
    "capacity": 3.5,
    "yield": 0.012,
    "entity pv switch": ""
  },
  {"name": "PV Tempelier Voorzijde",
    "tilt": 43,
    "orientation": 90,
    "capacity": 7.8,
    "yield": 0.019,
    "entity pv switch": ""
  }]
    } ],
  "solar": [ ],
  "electric vehicle": [
    {
      "name": "Tesla Model 3",
      "capacity": 75,
      "entity position": "device_tracker.chimobiel_location",
      "entity max amperage": "input_number.dao_tesla_max_amperage",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  1},
        {"ampere": 10, "efficiency" :  1},
        {"ampere": 12, "efficiency" :  1},
        {"ampere": 14, "efficiency" :  1},
        {"ampere": 16, "efficiency" :  0.99}
      ],
      "entity actual level": "sensor.chimobiel_battery_level",
      "entity plugged in": "binary_sensor.chimobiel_charge_cable",
      "charge scheduler": {
        "entity set level": "input_number.dao_tesla_max_battery_percentage",
        "entity ready datetime": "input_datetime.dao_tesla_charging_ready"
      },
      "charge switch": "input_boolean.dao_tesla_charging",
      "entity set charging ampere" : "input_number.dao_tesla_amperage",
      "entity instant start" : "input_boolean.tesla_charge_override"
    },
{
      "name": "Kia EV6",
      "capacity": 77,
      "entity position": "device_tracker.oneplus_11_pro_geoffrey",
      "entity max amperage": "input_number.dao_kia_max_amperage",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  1},
        {"ampere": 10, "efficiency" :  1},
        {"ampere": 12, "efficiency" :  1},
        {"ampere": 14, "efficiency" :  1},
        {"ampere": 16, "efficiency" :  0.99}
      ],
      "entity actual level": "sensor.ev6_ev_battery_level",
      "entity plugged in": "input_boolean.dao_kia_ev6_plugged_in",
      "charge scheduler": {
        "entity set level": "input_number.dao_kia_max_battery_percentage",
        "entity ready datetime": "input_datetime.dao_kia_charging_ready"
      },
      "charge switch": "input_boolean.dao_kia_charging",
      "entity set charging ampere" : "input_number.dao_kia_amperage",
      "entity instant start" : "input_boolean.kia_charge_override"
    }
  ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "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"]
  },
  "scheduler": {
    "active": "true",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "xx15": "calc_optimum",
    "xx30": "calc_optimum",
    "xx45": "calc_optimum",
    "2359": "clean_data"
  }
}

[DaBit]

KC27 schreef op maandag 25 augustus 2025 @ 23:02:
Ik pak het in de loop van oktober weer op, sorry ik kan je nu helaas niet uit de brand helpen.

Wist ik. Geen probleem.

Kan ik ergens een debug-printje in de code neerzetten die de prognosedata per PV-AC installatie laat zien? Ik had al wat door da_meteo.py en da_base.py zitten bladeren maar ik kwam er zo 1-2-3 niet uit waar nu precies over alle installaties geitereerd wordt en de resultaten samengevoegd.

Overigens: jouw aanname dat er per string geen meetdata is, is incorrect. Omvormers zoals de Growatt op mijn dak rapporteren naast het totaal ook de productie per string.
(maar zolang er van veelvuldig aftoppen geen sprake is zie ik niet goed in wat de voordelen zouden zijn om strings te definieren)

[ Voor 22% gewijzigd door DaBit op 26-08-2025 08:51 ]

[Mirabis]

sMoKeFiSh schreef op dinsdag 26 augustus 2025 @ 07:40:
[...]


Hieronder mijn config. Mijn helper voor "entity from battery" - "input_number.dao_from_battery" heeft een min/max value van -20.000 tot 20.000. Klopt mijn redenering dat DAO input van grid (max 18.000 in mijn geval) en berekende PV opbrengst in deze helper wil opslaan? In dat geval moet ik de min/max value voor de helper aanpassen naar 18.000 + 23.000 aan PV?

code:

{
  "homeassistant": {
    "protocol api": "http",
    "host": "192.168.2.4",
    "ip port": 8123,
    "token": "!secret ha_api_token"},
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2024-08-01": 0.01653
    },
    "cost supplier production": {
      "2024-08-01": 0.01653
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2025-04-03",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.72,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    0.62,
    1.2,
    0.82,
    0.82,
    0.82,
    0.82,
    0.62,
    0.62
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "prices consumption": "True",
    "prices production": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 18
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
  {
      "name": "Accu",
      "entity actual level": "sensor.deye_12k_3_phase_x_2_battery_state_of_charge",
      "capacity": 90,
      "upper limit": 100,
      "lower limit": 15,
      "optimal lower level": 15,
      "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
        },
        {
          "power": 1500,
          "efficiency": 0.785
        },
        {
          "power": 3000,
          "efficiency": 0.872
        },
        {
          "power": 4500,
          "efficiency": 0.897
        },
        {
          "power": 6000,
          "efficiency": 0.899
        },
        {
          "power": 7500,
          "efficiency": 0.898
        },
        {
          "power": 9000,
          "efficiency": 0.892
        },
        {
          "power": 10500,
          "efficiency": 0.882
        },
        {
          "power": 12000,
          "efficiency": 0.871
        },
        {
          "power": 13050,
          "efficiency": 0.865
        },
        {
          "power": 15360,
          "efficiency": 0.860
        },
        {
          "power": 16500,
          "efficiency": 0.855
        },
        {
          "power": 18000,
          "efficiency": 0.850
        }
      ],
      "discharge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 600,
          "efficiency": 0.891
        },
        {
          "power": 1500,
          "efficiency": 0.935
        },
        {
          "power": 3000,
          "efficiency": 0.952
        },
        {
          "power": 4500,
          "efficiency": 0.952
        },
        {
          "power": 7500,
          "efficiency": 0.934
        },
        {
          "power": 9000,
          "efficiency": 0.925
        },
        {
          "power": 10500,
          "efficiency": 0.915
        },
        {
          "power": 12000,
          "efficiency": 0.9
        },
        {
          "power": 13050,
          "efficiency": 0.893
        },
        {
          "power": 15360,
          "efficiency": 0.886
        },
        {
          "power": 16500,
          "efficiency": 0.863
        },
        {
          "power": 18000,
          "efficiency": 0.850
        }
      ],
      "minimum power": 1000,
      "dc_to_bat efficiency": 0.9838,
      "bat_to_dc efficiency": 0.9838,
      "cycle cost": 0,
      "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 pv": "input_number.dao_from_pv",
      "entity from ac": "input_number.dao_from_grid",
      "entity calculated soc": "input_number.dao_calculated_soc",
      "solar": [
  {"name": "PV Tempelier Achterzijde",
    "tilt": 43,
    "orientation": -90,
    "capacity": 6.8,
    "yield": 0.016,
    "entity pv switch": ""
  },
  {"name": "PV Tempelier Overkapping",
    "tilt": 13,
    "orientation": 0,
    "capacity": 5.2,
    "yield": 0.014,
    "entity pv switch": ""
  },
  {"name": "PV Tempelier Uitbouw",
    "tilt": 10,
    "orientation": -90,
    "capacity": 3.5,
    "yield": 0.012,
    "entity pv switch": ""
  },
  {"name": "PV Tempelier Voorzijde",
    "tilt": 43,
    "orientation": 90,
    "capacity": 7.8,
    "yield": 0.019,
    "entity pv switch": ""
  }]
    } ],
  "solar": [ ],
  "electric vehicle": [
    {
      "name": "Tesla Model 3",
      "capacity": 75,
      "entity position": "device_tracker.chimobiel_location",
      "entity max amperage": "input_number.dao_tesla_max_amperage",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  1},
        {"ampere": 10, "efficiency" :  1},
        {"ampere": 12, "efficiency" :  1},
        {"ampere": 14, "efficiency" :  1},
        {"ampere": 16, "efficiency" :  0.99}
      ],
      "entity actual level": "sensor.chimobiel_battery_level",
      "entity plugged in": "binary_sensor.chimobiel_charge_cable",
      "charge scheduler": {
        "entity set level": "input_number.dao_tesla_max_battery_percentage",
        "entity ready datetime": "input_datetime.dao_tesla_charging_ready"
      },
      "charge switch": "input_boolean.dao_tesla_charging",
      "entity set charging ampere" : "input_number.dao_tesla_amperage",
      "entity instant start" : "input_boolean.tesla_charge_override"
    },
{
      "name": "Kia EV6",
      "capacity": 77,
      "entity position": "device_tracker.oneplus_11_pro_geoffrey",
      "entity max amperage": "input_number.dao_kia_max_amperage",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  1},
        {"ampere": 10, "efficiency" :  1},
        {"ampere": 12, "efficiency" :  1},
        {"ampere": 14, "efficiency" :  1},
        {"ampere": 16, "efficiency" :  0.99}
      ],
      "entity actual level": "sensor.ev6_ev_battery_level",
      "entity plugged in": "input_boolean.dao_kia_ev6_plugged_in",
      "charge scheduler": {
        "entity set level": "input_number.dao_kia_max_battery_percentage",
        "entity ready datetime": "input_datetime.dao_kia_charging_ready"
      },
      "charge switch": "input_boolean.dao_kia_charging",
      "entity set charging ampere" : "input_number.dao_kia_amperage",
      "entity instant start" : "input_boolean.kia_charge_override"
    }
  ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "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"]
  },
  "scheduler": {
    "active": "true",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "xx15": "calc_optimum",
    "xx30": "calc_optimum",
    "xx45": "calc_optimum",
    "2359": "clean_data"
  }
}

Hmm ook wel benieuwd. Zelf heb ik "input_number.dao_from_battery" gelijk gesteld aan "dc_to_bat max power" en " bat_to_dc max power" (2500W in mijn Marstek situatie).

[diamanten]

Torch1969 schreef op vrijdag 22 augustus 2025 @ 20:16:
[...]

Op totaal is mooi, maar per uur is belangrijker…

Het is toch wat genuanceerder: ik heb de verwachting per uur van DAO, Open-meteo en Solcast in onderstaande grafiek gezet inclusief de daadwerkelijke PV opbrengst (PV Real).

In mijn situatie:
1. De DAO uur forecast voor PV AC (oranje lijn) is structureel lager dan die van Open-meteo en Solcast.
2. Open-meteo en Solcast uurverwachtingen zijn ongeveer gelijk.
3. De PV Real opbrengst (rode lijn) is iets lager dan die van Open-meteo / Solcast (blauwe lijn): de uurverwachtingen van beide providers zijn voor mijn situatie realistisch.
4. De DAO PV 'tot nu toe' AC opbrengst (dus zonder de forecast - groene lijn) volgt achteraf exact de daadwerkelijke PV opbrengst. Dus zonder de prognose klopt de DAO PV AC opbrengst altijd.

Voor punt 1: Wat betekent dit voor de potentiële opbrengsten en andere berekeningen?
En: is het niet handiger/efficienter om (ook) gebruik te maken van Open-meteo/Solcast?

[ Voor 12% gewijzigd door diamanten op 26-08-2025 16:42 ]

[Torch1969]

diamanten schreef op dinsdag 26 augustus 2025 @ 14:15:
[...]

Het is toch wat genuanceerder: ik heb de verwachting per uur van DAO, Open-meteo en Solcast in onderstaande grafiek gezet inclusief de daadwerkelijke PV opbrengst (PV Real).
[Afbeelding]
In mijn situatie:
1. De DAO uur forecast voor PV AC (oranje lijn) is structureel lager dan die van Open-meteo en Solcast.
2. Open-meteo en Solcast uurverwachtingen zijn ongeveer gelijk.
3. De PV Real opbrengst (rode lijn) is iets lager dan die van Open-meteo / Solcast (blauwe lijn): de uurverwachtingen van beide providers zijn voor mijn situatie realistisch.
4. De DAO PV 'tot nu toe' AC opbrengst (dus zonder de forecast - groene lijn) volgt achteraf exact de daadwerkelijke PV opbrengst. Dus zonder de prognose klopt de DAO PV AC opbrengst altijd.

Voor punt 1: Wat betekent dit voor de potentiële opbrengsten en andere berekeningen?
En: is het niet handiger/efficienter om (ook) gebruik te maken van Open-meteo/Solcast?

Die nuancering bedoelde ik ook precies. De voorspelling op uurniveau is belangrijk voor de strategie van DAO.
Hieronder mijn grafiek.

Daarin is te zien dat de voorspelling van DAO (grijs voor historie) redelijk overeenkomt met de daadwerkelijke opwek.
Ik gebruik ook solcast en zou die ook graag aan DAO willen kunnen koppelen. Laten we rustig afwachten wanneer KC27 daar tijd voor wil maken.

[KC27]

diamanten schreef op dinsdag 26 augustus 2025 @ 14:15:
[...]

Het is toch wat genuanceerder: ik heb de verwachting per uur van DAO, Open-meteo en Solcast in onderstaande grafiek gezet inclusief de daadwerkelijke PV opbrengst (PV Real).
[Afbeelding]
In mijn situatie:
1. De DAO uur forecast voor PV AC (oranje lijn) is structureel lager dan die van Open-meteo en Solcast.
2. Open-meteo en Solcast uurverwachtingen zijn ongeveer gelijk.
3. De PV Real opbrengst (rode lijn) is iets lager dan die van Open-meteo / Solcast (blauwe lijn): de uurverwachtingen van beide providers zijn voor mijn situatie realistisch.
4. De DAO PV 'tot nu toe' AC opbrengst (dus zonder de forecast - groene lijn) volgt achteraf exact de daadwerkelijke PV opbrengst. Dus zonder de prognose klopt de DAO PV AC opbrengst altijd.

Voor punt 1: Wat betekent dit voor de potentiële opbrengsten en andere berekeningen?
En: is het niet handiger/efficienter om (ook) gebruik te maken van Open-meteo/Solcast?

De DAO haalt met de gedefinieerde entitiy de daadwerkelijke opbrengst uit HA.Logisch dat die klopt met jouw PV-real.
Als de DAO- prognoses structureel lager zijn de werkelijke opbengsten dan zou je wellicht je yield-instelling(en) wat moeten verhogen.

[Guido Aerts]

Ben gehuisvest in Belgie.
Heb sinds een aantal dagen DAO als addon geinstalleerd.
Heb voor batterij en PV de effektieve gegevens toegekend.
Voor prices voorlopig default waarden gebruikt.
De optimalisaties komen erdoor maar doe nog geen aktieve aansturing.
Wil nu dynamische prijzen van Leverancier Energy Knights erin plaatsen maar krijg dit precies niet in instellingen verwerkt.
Consumption: (c€/kWh) (Uurprijs * 1,07) + 7
Production: (c€/kWh) (Uurprijs * 0,86) - 3

En wat is de bedoeling van "regular high" en "regular low"

[KC27]

Guido Aerts schreef op woensdag 27 augustus 2025 @ 01:04:
Ben gehuisvest in Belgie.
Heb sinds een aantal dagen DAO als addon geinstalleerd.
Heb voor batterij en PV de effektieve gegevens toegekend.
Voor prices voorlopig default waarden gebruikt.
De optimalisaties komen erdoor maar doe nog geen aktieve aansturing.
Wil nu dynamische prijzen van Leverancier Energy Knights erin plaatsen maar krijg dit precies niet in instellingen verwerkt.
Consumption: (c€/kWh) (Uurprijs * 1,07) + 7
Production: (c€/kWh) (Uurprijs * 0,86) - 3

En wat is de bedoeling van "regular high" en "regular low"

Helaas is er nog geen ondersteuning voor de Belgische tarievenopbouw.
Ik ben nu bezig DAO voor te bereiden op de overgang naar kwartierwaarden (gaat in op 1 oktober a.s.)
In loop van oktober komt er een aanpassing met "vrije" formules en het ophalen van landspecifieke day-ahead prijzen. Tot die tijd zul je het met de Nederlands mogelijkheden moeten doen.

[susscorfa]

Ik ben gisteravond bezig geweest de addon te installeren (als docker). Nu heb ik een basis setup en wil ik gaan kijken of ik zonnepanelen en de auto kan toevoegen. Mijn laadpaal heeft echter de mogelijkheid zowel 1 als 3 fase te laden. Begrijp ik het goed dat hier voorlopig nog niet in voorzien is?

[Bravo]

Torch1969 schreef op dinsdag 26 augustus 2025 @ 18:52:
[...]

Die nuancering bedoelde ik ook precies. De voorspelling op uurniveau is belangrijk voor de strategie van DAO.
Hieronder mijn grafiek.
[Afbeelding]
Daarin is te zien dat de voorspelling van DAO (grijs voor historie) redelijk overeenkomt met de daadwerkelijke opwek.
Ik gebruik ook solcast en zou die ook graag aan DAO willen kunnen koppelen. Laten we rustig afwachten wanneer KC27 daar tijd voor wil maken.

Hoe krijg jij het voor elkaar om de historie van de voorspelling weer te geven? Erg interessant!

[Dogooder]

Dat houdt home assistant voor je bij.

[Bravo]

Bij mij niet? Met de template voor de PV data in de API wordt de 'expected' vervangen door 'recorded' als het uur in de geschiedenis ligt.

[Guido Aerts]

KC27 schreef op woensdag 27 augustus 2025 @ 09:40:
[...]

Helaas is er nog geen ondersteuning voor de Belgische tarievenopbouw.
Ik ben nu bezig DAO voor te bereiden op de overgang naar kwartierwaarden (gaat in op 1 oktober a.s.)
In loop van oktober komt er een aanpassing met "vrije" formules en het ophalen van landspecifieke day-ahead prijzen. Tot die tijd zul je het met de Nederlands mogelijkheden moeten doen.

Wil je nog zeggen dat dit een fantatisch initatief is.
Heb eerst geprobeerd met EOS van de accudocter.
Zal wel aan de duitsers liggen maar installeren was al hopeloos ingewikkeld.
Hier kan je tenminste nog relatief gemakkelijk resultaat bekomen.

[Dogooder]

Bravo schreef op woensdag 27 augustus 2025 @ 13:07:
Bij mij niet? Met de template voor de PV data in de API wordt de 'expected' vervangen door 'recorded' als het uur in de geschiedenis ligt.

In de attributes van de entity wordt inderdaad expected vervangen door recorded.
Maar de state van de entity zelf geeft de expected waarde voor het huidige uur.
Homeassistant heeft een history van die state.

[Bravo]

Dogooder schreef op woensdag 27 augustus 2025 @ 16:49:
[...]

In de attributes van de entity wordt inderdaad expected vervangen door recorded.
Maar de state van de entity zelf geeft de expected waarde voor het huidige uur.
Homeassistant heeft een history van die state.

Hmz, dan ga ik nog een keer nakijken of ik het goed heb overgenomen. Bij mij is de status namelijk 'unknown'
rest-sensor:

code:

  - resource: http://192.168.1.x:5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: DAO PV AC
        unique_id: pv_ac
        unit_of_measurement: 'kW'
        value_template: "{{ (value_json.data[now().hour].pv_ac) | round(5) }}"
        json_attributes:
          - data

Output:

data:
- time_ts: 1756245600000
time: 2025-08-27 00:00
value: 0
datatype: recorded
- time_ts: 1756249200000
time: 2025-08-27 01:00
value: 0
datatype: recorded
- time_ts: 1756252800000
time: 2025-08-27 02:00
value: 0
datatype: recorded
- time_ts: 1756256400000
time: 2025-08-27 03:00
value: 0
datatype: recorded
- time_ts: 1756260000000
time: 2025-08-27 04:00
value: 0
datatype: recorded
- time_ts: 1756263600000
time: 2025-08-27 05:00
value: 0
datatype: recorded
- time_ts: 1756267200000
time: 2025-08-27 06:00
value: 0
datatype: recorded
- time_ts: 1756270800000
time: 2025-08-27 07:00
value: 0.02
datatype: recorded
- time_ts: 1756274400000
time: 2025-08-27 08:00
value: 0.18
datatype: recorded
- time_ts: 1756278000000
time: 2025-08-27 09:00
value: 0.464
datatype: recorded
- time_ts: 1756281600000
time: 2025-08-27 10:00
value: 0.756
datatype: recorded
- time_ts: 1756285200000
time: 2025-08-27 11:00
value: 1.35
datatype: recorded
- time_ts: 1756288800000
time: 2025-08-27 12:00
value: 1.926
datatype: recorded
- time_ts: 1756292400000
time: 2025-08-27 13:00
value: 2.124
datatype: recorded
- time_ts: 1756296000000
time: 2025-08-27 14:00
value: 2.08
datatype: recorded
- time_ts: 1756299600000
time: 2025-08-27 15:00
value: 2.6
datatype: recorded
- time_ts: 1756303200000
time: 2025-08-27 16:00
value: 2.01
datatype: recorded
- time_ts: 1756306800000
time: 2025-08-27 17:00
value: 1.5862765701
datatype: expected
- time_ts: 1756310400000
time: 2025-08-27 18:00
value: 1.3088858953
datatype: expected
- time_ts: 1756314000000
time: 2025-08-27 19:00
value: 0.4004260161
datatype: expected
- time_ts: 1756317600000
time: 2025-08-27 20:00
value: 0
datatype: expected
- time_ts: 1756321200000
time: 2025-08-27 21:00
value: 0
datatype: expected
- time_ts: 1756324800000
time: 2025-08-27 22:00
value: 0
datatype: expected
- time_ts: 1756328400000
time: 2025-08-27 23:00
value: 0
datatype: expected
- time_ts: 1756332000000
time: 2025-08-28 00:00
value: 0
datatype: expected
- time_ts: 1756335600000
time: 2025-08-28 01:00
value: 0
datatype: expected
- time_ts: 1756339200000
time: 2025-08-28 02:00
value: 0
datatype: expected
- time_ts: 1756342800000
time: 2025-08-28 03:00
value: 0
datatype: expected
- time_ts: 1756346400000
time: 2025-08-28 04:00
value: 0
datatype: expected
- time_ts: 1756350000000
time: 2025-08-28 05:00
value: 0
datatype: expected
- time_ts: 1756353600000
time: 2025-08-28 06:00
value: 0
datatype: expected
- time_ts: 1756357200000
time: 2025-08-28 07:00
value: 0.0569751491
datatype: expected
- time_ts: 1756360800000
time: 2025-08-28 08:00
value: 0.04925
datatype: expected
- time_ts: 1756364400000
time: 2025-08-28 09:00
value: 0.0394
datatype: expected
- time_ts: 1756368000000
time: 2025-08-28 10:00
value: 0.4393121271
datatype: expected
- time_ts: 1756371600000
time: 2025-08-28 11:00
value: 0.6296567416
datatype: expected
- time_ts: 1756375200000
time: 2025-08-28 12:00
value: 0.8497961267
datatype: expected
- time_ts: 1756378800000
time: 2025-08-28 13:00
value: 1.2331310765
datatype: expected
- time_ts: 1756382400000
time: 2025-08-28 14:00
value: 0.1810689953
datatype: expected
- time_ts: 1756386000000
time: 2025-08-28 15:00
value: 0.1184369902
datatype: expected
- time_ts: 1756389600000
time: 2025-08-28 16:00
value: 1.0419361668
datatype: expected
- time_ts: 1756393200000
time: 2025-08-28 17:00
value: 1.1214627309
datatype: expected
- time_ts: 1756396800000
time: 2025-08-28 18:00
value: 0.220963647
datatype: expected
- time_ts: 1756400400000
time: 2025-08-28 19:00
value: 0.4926028653
datatype: expected
- time_ts: 1756404000000
time: 2025-08-28 20:00
value: 0.02955
datatype: expected
- time_ts: 1756407600000
time: 2025-08-28 21:00
value: 0
datatype: expected
- time_ts: 1756411200000
time: 2025-08-28 22:00
value: 0
datatype: expected
- time_ts: 1756414800000
time: 2025-08-28 23:00
value: 0
datatype: expected
- time_ts: 1756418400000
time: 2025-08-29 00:00
value: 0
datatype: expected
unit_of_measurement: kW
friendly_name: DAO PV AC

[ Voor 3% gewijzigd door Bravo op 27-08-2025 17:21 ]

[Dogooder]

Bij value_template moet het .hour].value zijn. Jij hebt .pv_ac

Verder is volgens mij de eenheid 'kWh'.

[ Voor 25% gewijzigd door Dogooder op 27-08-2025 17:27 ]

[KC27]

susscorfa schreef op woensdag 27 augustus 2025 @ 09:52:
Ik ben gisteravond bezig geweest de addon te installeren (als docker). Nu heb ik een basis setup en wil ik gaan kijken of ik zonnepanelen en de auto kan toevoegen. Mijn laadpaal heeft echter de mogelijkheid zowel 1 als 3 fase te laden. Begrijp ik het goed dat hier voorlopig nog niet in voorzien is?

Nee hierin is nog niet voorzien. Maar....
je kunt de amperes van 3 fasen vertalen naar amperes met 1 fase (een factor 3 gok ik )
Als je DAO dan een van die 3 fase-amperes aangeeft als 'laad-vermogen', dan kun je dat met een automation in HA vertalen naar 3-fasen, de overigen zijn dan 1-fase.
Ik heb ergens in dit topic gelezen dat iemand het zo doet. Misschien even zoeken op 3-fasen?

[Torch1969]

Bravo schreef op woensdag 27 augustus 2025 @ 17:20:
[...]


Hmz, dan ga ik nog een keer nakijken of ik het goed heb overgenomen. Bij mij is de status namelijk 'unknown'
rest-sensor:

code:

  - resource: http://192.168.1.x:5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: DAO PV AC
        unique_id: pv_ac
        unit_of_measurement: 'kW'
        value_template: "{{ (value_json.data[now().hour].pv_ac) | round(5) }}"
        json_attributes:
          - data

Output:

[...]

Kijk anders nog even naar mijn voorbeeld in een eerdere post: Torch1969 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

[konehead]

Vraag: Ik trek de voorspelling uit DAO, alleen die krijg ik voor vandaag cumulatief in de sensor. Wat doe ik fout?

code:

  - resource: http://192.168.1.82:5000/api/report/pv_dc/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: DAO solar production dc
        unique_id: dao_solar_production_dc
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

[diamanten]

KC27 schreef op dinsdag 26 augustus 2025 @ 19:16:
[...]

De DAO haalt met de gedefinieerde entitiy de daadwerkelijke opbrengst uit HA.Logisch dat die klopt met jouw PV-real.
Als de DAO- prognoses structureel lager zijn de werkelijke opbengsten dan zou je wellicht je yield-instelling(en) wat moeten verhogen.

Dank, yield behoorlijk verhoogd (van 0,007 naar 0,039) geeft een prognose in lijn met Open-meteo en Solcast:


Hmm, de accu's worden nu niet meer ingezet (winst =0.00 Euro). Dat lijkt mij niet te bedoeling of is dat nu puur toeval vanwege de tarieven?!.

[ Voor 27% gewijzigd door diamanten op 28-08-2025 11:13 ]

[DaBit]

KC27 schreef op woensdag 27 augustus 2025 @ 19:37:
Ik heb ergens in dit topic gelezen dat iemand het zo doet. Misschien even zoeken op 3-fasen?

Ik doe dat. DAO is geconfigureerd voor 1 fase tot 48 Ampere:

code:

..
..
"electric vehicle": [ 
    {
      "name": "Corsa-E",
      "capacity": 47.0,
      "entity max amperage": "input_number.ev_max_charge_amps",
      "entity position": "input_select.corsae_location",
      "entity instant start": "input_boolean.dao_nu_laden",
      "entity instant level": "input_number.dao_nu_laden_soc",
      "charge three phase": "False",
      "charge stages" : [
      {"ampere":  0, "efficiency" :  1},
            {"ampere":  6, "efficiency": 0.95},
            {"ampere":  7, "efficiency": 0.95},
            {"ampere":  8, "efficiency": 0.95},
            {"ampere":  9, "efficiency": 0.95},
            {"ampere": 10, "efficiency": 0.95},
            {"ampere": 11, "efficiency": 0.95},
      {"ampere": 12, "efficiency": 0.95},
            {"ampere": 13, "efficiency": 0.95},
            {"ampere": 14, "efficiency": 0.95},
            {"ampere": 15, "efficiency": 0.95},
            {"ampere": 16, "efficiency": 0.95},
            {"ampere": 18, "efficiency": 0.95},
            {"ampere": 21, "efficiency": 0.95},
            {"ampere": 24, "efficiency": 0.95},
            {"ampere": 27, "efficiency": 0.95},
      {"ampere": 30, "efficiency": 0.95},
            {"ampere": 33, "efficiency": 0.94},
            {"ampere": 36, "efficiency": 0.93},
            {"ampere": 39, "efficiency": 0.92},
            {"ampere": 42, "efficiency": 0.91},
            {"ampere": 45, "efficiency": 0.85},
            {"ampere": 48, "efficiency": 0.80}
      ],
      "entity actual level": "sensor.corsa_e_battery_percent",
      "entity plugged in": "binary_sensor.charger_pluggedin",
      "charge scheduler": {
        "entity set level": "input_number.ev_desired_chargelevel",
        "level margin": 1,
        "entity ready datetime": "input_datetime.charge_ready_datetime"
      },
      "charge switch": "input_boolean.corsae_charge_switch",
      "entity set charging ampere": "input_number.dao_laadpaal_amp"
    },
..
..

De door DAO gestuurde entiteiten worden vervolgens een NodeRED flow in geleid die het eigenlijke sturen van de (Alfen met Modbus/TCP optie) laadpaal voor de kiezen neemt:



Inhoud van de current2modbus functie:

code:

// Send desired current to modbus charger. Take switching
// between 1/3 phases into account

let currentNrPhases = context.get('currentNrPhases');
let lastPhaseChangeTime = context.get('lastPhaseChangeTime');

const d = new Date();
const ms_curr = d.getTime();

// Minimum time between phase changes in milliseconds. Try one minute to start
const phasechange_mintime = (1.0*60.0*1000.0);
const doWarn = false;

// Build modbus payload string for the current
function build_currentpayload(value) {
    var buf = Buffer.alloc(4);
    buf.writeFloatBE(value);
    var values = [(buf[0] * 256 + buf[1]), (buf[2] * 256) + buf[3]]
    var payload = { "value": values, 'fc': 16, 'unitid': 1, 'address': 1210, 'quantity': 2 };
    return payload;
}

// Build modbus payload string for the phases
function build_phasespayload(value) {
    var payload = { value: value, 'fc': 6, 'unitid': 1, 'address': 1215, 'quantity': 1 };
    return payload;
}

// Clamp range. 
function clamprange(value,min,max) {
    if (value < min) {
        return min;
    }
    if (value > max) {
        return max;
    }
    return value;
}

if (msg.topic != "current") {
    return;
}
let desiredCurrent = parseFloat(msg.payload);
// if the desire for current is low, just return 0 current and do not consider or switch nrphases
if (desiredCurrent < 2.0) {
    desiredCurrent = 0.0;
    msg.payload = build_currentpayload(desiredCurrent);
    return msg;
}

// Single phase goes to 16 amps. Anything above is 3-phase territory
let desiredPhases = 1;
if (desiredCurrent > 16.0) { 
    desiredPhases = 3;
}

// Do we need to change the number of phases, and can we already do so?
if (currentNrPhases != desiredPhases && (ms_curr - lastPhaseChangeTime) > phasechange_mintime) {
    if (doWarn) node.warn("Initiating phase switch to " + desiredPhases + " phases from " + currentNrPhases);
    currentNrPhases = desiredPhases;
    context.set('currentNrPhases', currentNrPhases);
    context.set('lastPhaseChangeTime', ms_curr);
}

// If the current number of phases is 3, split the current
if (currentNrPhases == 3) {
    desiredCurrent /= 3.0;
}

// Clamp current to minimum and maximum
desiredCurrent = clamprange(desiredCurrent, 6.0, 16.0);

if (doWarn) node.warn("Current: " + desiredCurrent);

// Construct return message
var msg1 = { topic: "current", payload: build_currentpayload(desiredCurrent) };
var msg2 = { topic: "phases", payload: build_phasespayload(currentNrPhases) };

return [[msg1, msg2]];

[Mirabis]

diamanten schreef op donderdag 28 augustus 2025 @ 08:28:
[...]

Dank, yield behoorlijk verhoogd (van 0,007 naar 0,039) geeft een prognose in lijn met Open-meteo en Solcast:
[Afbeelding]

Hmm, de accu's worden nu niet meer ingezet (winst =0.00 Euro). Dat lijkt mij niet te bedoeling of is dat nu puur toeval vanwege de tarieven?!.
[Afbeelding]

Toeval (omdat de spread vandaag erg laag is).

[sjampeter]

En nu komt het lastige, op 1 meter (PAP) is DAO prima te gebruiken. Ik heb beide meters inmiddels al wel in in DAO zitten. Ik heb in home assitant een YAML helper geschreven die beide meters samenvoegen tot 1 teruglever tarief en 1 verbruikstarief. De salderingen lopen ook niet gelijk (minder relevant als deze komt te vervallen). Nu gaat de meter met de laatste saldering op TLV vergoeding waardoor de eerst aflopen saldering prio krijgt op teruglevering.

Het mooiste zou zijn als je beide meters los in kunt voeren met hun eigen contracten, prijzen en salderingsdata. En dat DAO bepaald wanneer en waar het beste op verbruikt kan worden danwel terug geleverd kan worden (de eerste meter die gesaldeerd moet worden, heeft dan een hoger belang). Vervolgens kan ik HASS wel laten schakelen. Uiteindelijk doel is zelfs om wanneer dit het beste uitkomt, volledig op eilandbedrijf te gaan zodat onnodig verbruik of teruglevering compleet voorkomen word. Dus alleen wanneer ik (of het systeem) dit nodig acht maken we verbinding met het net. Dit kan ook als het nodig is om hogere vermogen te vragen dan beschikbaar van het Victron systeem voor bijvoorbeeld bij lage prijzen, volladen accu's en auto / koelen / verwarmen huis.

Een andere oplossing dat ik in plaats van de nordpool prijzen te laten ophalen door DAO, mijn berekende verbruik en terugleveringsprijzen in DAO kan laden. Dit scheelt ook dubbel opvragen vanuit hetzelfde adres.

Ik ben vooral benieuwd of er anderen zijn met een dergelijke opstelling en hoe zij dit gedaan hebben. Ik kom maar 1 iemand in dit topic vinden met een SAP en dat was @sjampeter . @KC27 , hoe denk jij hier over, hoe zou jij dit opzetten? Ik heb een vermoeden dat dit te complex is en een dergelijke opstelling komt niet vaak voor. Omdat dit ook redelijk schud aan de basis hoe DAO is opgebouwd om dit vrijer op te kunnen zetten.

klopt, dit zou voor ons PAP/SAP bezitters helemaal fantastisch zijn, echter niet echt haalbaar denk ik.
jouw andere oplossing , de nordpoolprijzen kunnen aanpassen, heb ik ook al eens aan gedacht. dan zou de DAO gewoon standaard blijven maar kunnen wij desgewenst nog wat sturen/tweaken.
ik weet nog een gebruiker met PAP/SAP welke deze oplossing ook zou kunnen gebruiken.

@KC27 is zoiets te implementeren?

[KC27]

sjampeter schreef op donderdag 28 augustus 2025 @ 19:11:
[...]


klopt, dit zou voor ons PAP/SAP bezitters helemaal fantastisch zijn, echter niet echt haalbaar denk ik.
jouw andere oplossing , de nordpoolprijzen kunnen aanpassen, heb ik ook al eens aan gedacht. dan zou de DAO gewoon standaard blijven maar kunnen wij desgewenst nog wat sturen/tweaken.
ik weet nog een gebruiker met PAP/SAP welke deze oplossing ook zou kunnen gebruiken.

@KC27 is zoiets te implementeren?

Ik heb als reactie op de inbreng van @Ferrox1 het volgende geschreven:
KC27 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"
Dat geldt nog steeds, maar daar kom ik pas na 1 oktober (=de overgang naar 15min-tarieven) aan toe.

[Batavia]

Ik zit te kijken in de documentatie maar ik kom er nog niet uit.

Is het mogelijk om een (rest) sensor te maken die zegt wanneer dao gaat beginnen met het opladen van min auto?

[Torch1969]

Batavia schreef op donderdag 28 augustus 2025 @ 19:46:
Ik zit te kijken in de documentatie maar ik kom er nog niet uit.

Is het mogelijk om een (rest) sensor te maken die zegt wanneer dao gaat beginnen met het opladen van min auto?

Ja, zie documentatie: https://github.com/cornee...bleperiodparamparam_value
Of pak mijn voorbeeld van pv voorspelling en vervang “pv_ac” door “ev”.
Dit is mijn planning voor vannacht (phev tot 50% laden):

[ Voor 27% gewijzigd door Torch1969 op 28-08-2025 20:57 ]

[Torch1969]

konehead schreef op donderdag 28 augustus 2025 @ 08:14:
Vraag: Ik trek de voorspelling uit DAO, alleen die krijg ik voor vandaag cumulatief in de sensor. Wat doe ik fout?

code:

  - resource: http://192.168.1.82:5000/api/report/pv_dc/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: DAO solar production dc
        unique_id: dao_solar_production_dc
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

[Afbeelding]

[Afbeelding]

Ik denk dat de fout in de apex chart zit. In het deel voor vandaag, dat van morgen gaat namelijk wel goed. Vergelijk de code nog eens goed met die van mij? Of deel die van jou hier eens?

[Mirabis]

diamanten schreef op donderdag 28 augustus 2025 @ 08:28:
[...]

Dank, yield behoorlijk verhoogd (van 0,007 naar 0,039) geeft een prognose in lijn met Open-meteo en Solcast:
[Afbeelding]

Hmm, de accu's worden nu niet meer ingezet (winst =0.00 Euro). Dat lijkt mij niet te bedoeling of is dat nu puur toeval vanwege de tarieven?!.
[Afbeelding]

Zou je misschien de yaml code van deze diagrammen willen delen? Ben zelf ook aan het kijken of mijn yield klopt en dan is dit wel handig.

[diamanten]

Mirabis schreef op vrijdag 29 augustus 2025 @ 09:57:
[...]

Zou je misschien de yaml code van deze diagrammen willen delen? Ben zelf ook aan het kijken of mijn yield klopt en dan is dit wel handig.

Hierbij de yaml code (tips voor verbetering welkom!):

code:

type: custom:apexcharts-card
graph_span: 24h
span:
  start: day
header:
  show: true
  title: PV Real vs Forecasts (24h)
now:
  show: true
  label: Nu
apex_config:
  chart:
    type: line
  stroke:
    width: 3
  legend:
    show: true
yaxis:
  - decimals: 2
    min: 0
    max: 9
    apex_config:
      title:
        text: kWh/uur
series:
  - entity: sensor.envoy_productie_per_uur
    name: PV Real
    type: column
    color: "#FF6666"
    group_by:
      func: max
      duration: 1h
  - entity: sensor.dao_pv_ac_vandaag_en_morgen
    group_by:
      func: last
      duration: 1h
    type: column
    stroke_width: 0
    name: DAO tot nu toe
    color: grey
    float_precision: 3
  - entity: sensor.dao_pv_ac_vandaag
    name: DAO PV Prognose
    type: line
    color: "#ff7f0e"
    data_generator: |
      const arr = entity.attributes?.data ?? [];
      return arr
        .filter(d => d.datatype === 'expected')
        .map(d => [new Date(d.time_ts), d.value]);
  - entity: sensor.energy_production_today_2
    name: Open-Meteo
    type: line
    color: "#1f77b4"
    opacity: 0.45
    data_generator: |
      const wh = entity.attributes?.wh_period ?? {};
      return Object.entries(wh).map(([iso, val]) => {
        const kwh = (Number(val) || 0) / 1000; // Wh → kWh
        return [new Date(iso), kwh];
      });
  - entity: sensor.solcast_pv_forecast_forecast_today
    name: Solcast
    type: line
    color: "#3b82f6"
    data_generator: |
      const items = (entity?.attributes?.detailedHourly ?? [])
        .map(p => ({ t: new Date(p.period_start).getTime(), v: Number(p.pv_estimate) || 0 }))
        .sort((a,b) => a.t - b.t);
      return items.map(p => [p.t, p.v]);

[Mirabis]

Thanks, @diamanten welk API endpoint (/api/report/XXXX/YYY) gebruik je voor sensor.energy_production_today_2?

Ik heb namelijk het volgende aangemaakt:

code:

# --- DA Price --------------------------------------------------------------
- platform: rest
  name: DA Price
  unique_id: dao_price
  resource: http://172.31.20.108:5000/api/report/da/vandaag_en_morgen
  verify_ssl: false
  scan_interval: 600
  unit_of_measurement: "euro/kWh"
  value_template: "{{ (value_json.data[now().hour].da_ex | float) | round(5) }}"
  json_attributes:
    - data

# --- Grid consumption (hourly, today+tomorrow) ----------------------------
- platform: rest
  name: DAO Grid consumption
  unique_id: dao_grid_consumption
  resource: http://172.31.20.108:5000/api/report/consumption/vandaag_en_morgen
  verify_ssl: false
  scan_interval: 600
  unit_of_measurement: "kWh"
  value_template: "{{ (value_json.data[now().hour].value | float) | round(3) }}"
  json_attributes:
    - data

# --- Grid consumption (cumulative today) ----------------------------------
- platform: rest
  name: DAO Grid consumption cumulatief
  unique_id: dao_grid_consumption_cumulate
  resource: "http://172.31.20.108:5000/api/report/consumption/vandaag?cumulate=1"
  verify_ssl: false
  scan_interval: 600
  unit_of_measurement: "kWh"
  value_template: "{{ (value_json.data[now().hour].value | float) | round(3) }}"
  json_attributes:
    - data

# --- Grid production (hourly, today+tomorrow) -----------------------------
- platform: rest
  name: DAO Grid production
  unique_id: dao_grid_production
  resource: http://172.31.20.108:5000/api/report/production/vandaag_en_morgen
  verify_ssl: false
  scan_interval: 600
  unit_of_measurement: "kWh"
  value_template: "{{ (value_json.data[now().hour].value | float) | round(3) }}"
  json_attributes:
    - data
# --- PV AC Production (hourly, today+tomorrow) ----------------------------
- platform: rest
  name: DAO PV-AC production (vandaag en morgen)
  unique_id: dao_pv_ac_vandaag_en_morgen
  resource: http://172.31.20.108:5000/api/report/pv_ac/vandaag_en_morgen
  verify_ssl: false
  scan_interval: 600
  unit_of_measurement: "kWh"
  value_template: "{{ (value_json.data[now().hour].value | float) | round(3) }}"
  json_attributes:
    - data
# --- PV AC Production (hourly, today)----------------------------------
- platform: rest
  name: DAO PV-AC production (vandaag)
  unique_id: dao_pv_ac_vandaag
  resource: "http://172.31.20.108:5000/api/report/pv_ac/vandaag?cumulate=1"
  verify_ssl: false
  scan_interval: 600
  unit_of_measurement: "kWh"
  value_template: "{{ (value_json.data[now().hour].value | float) | round(3) }}"
  json_attributes:
    - data

[ Voor 98% gewijzigd door Mirabis op 29-08-2025 12:20 ]

[diamanten]

Mirabis schreef op vrijdag 29 augustus 2025 @ 12:10:
Thanks, @diamanten welk API endpoint (/api/report/XXXX/YYY) gebruik je voor sensor.energy_production_today_2?

Ik heb namelijk het volgende aangemaakt:


[...]

Het is geen API endpoint, maar dat is een Solcast entiteit en bevat de PV voorspellingen voor vandaag - per kwartier (watts) en per uur (Wh):

code:

watts:
  "2025-08-29T00:00:00+02:00": 0
  "2025-08-29T00:15:00+02:00": 0
  "2025-08-29T00:30:00+02:00": 0
  "2025-08-29T00:45:00+02:00": 0
  "2025-08-29T01:00:00+02:00": 0
  "2025-08-29T01:15:00+02:00": 0
  "2025-08-29T01:30:00+02:00": 0
  "2025-08-29T01:45:00+02:00": 0
  "2025-08-29T02:00:00+02:00": 0
  "2025-08-29T02:15:00+02:00": 0
  "2025-08-29T02:30:00+02:00": 0
  "2025-08-29T02:45:00+02:00": 0
  "2025-08-29T03:00:00+02:00": 0
  "2025-08-29T03:15:00+02:00": 0
  "2025-08-29T03:30:00+02:00": 0
  "2025-08-29T03:45:00+02:00": 0
  "2025-08-29T04:00:00+02:00": 0
  "2025-08-29T04:15:00+02:00": 0
  "2025-08-29T04:30:00+02:00": 0
  "2025-08-29T04:45:00+02:00": 0
  "2025-08-29T05:00:00+02:00": 0
  "2025-08-29T05:15:00+02:00": 0
  "2025-08-29T05:30:00+02:00": 0
  "2025-08-29T05:45:00+02:00": 0
  "2025-08-29T06:00:00+02:00": 0
  "2025-08-29T06:15:00+02:00": 0
  "2025-08-29T06:30:00+02:00": 0
  "2025-08-29T06:45:00+02:00": 25
  "2025-08-29T07:00:00+02:00": 190
  "2025-08-29T07:15:00+02:00": 461
  "2025-08-29T07:30:00+02:00": 641
  "2025-08-29T07:45:00+02:00": 793
  "2025-08-29T08:00:00+02:00": 929
  "2025-08-29T08:15:00+02:00": 1055
  "2025-08-29T08:30:00+02:00": 1174
  "2025-08-29T08:45:00+02:00": 1408
  "2025-08-29T09:00:00+02:00": 1756
  "2025-08-29T09:15:00+02:00": 2145
  "2025-08-29T09:30:00+02:00": 2555
  "2025-08-29T09:45:00+02:00": 2957
  "2025-08-29T10:00:00+02:00": 3349
  "2025-08-29T10:15:00+02:00": 3732
  "2025-08-29T10:30:00+02:00": 4119
  "2025-08-29T10:45:00+02:00": 4498
  "2025-08-29T11:00:00+02:00": 4860
  "2025-08-29T11:15:00+02:00": 5184
  "2025-08-29T11:30:00+02:00": 5460
  "2025-08-29T11:45:00+02:00": 5692
  "2025-08-29T12:00:00+02:00": 5869
  "2025-08-29T12:15:00+02:00": 6007
  "2025-08-29T12:30:00+02:00": 6102
  "2025-08-29T12:45:00+02:00": 6148
  "2025-08-29T13:00:00+02:00": 6147
  "2025-08-29T13:15:00+02:00": 6096
  "2025-08-29T13:30:00+02:00": 6031
  "2025-08-29T13:45:00+02:00": 6042
  "2025-08-29T14:00:00+02:00": 5990
  "2025-08-29T14:15:00+02:00": 5701
  "2025-08-29T14:30:00+02:00": 4985
  "2025-08-29T14:45:00+02:00": 3736
  "2025-08-29T15:00:00+02:00": 2394
  "2025-08-29T15:15:00+02:00": 1395
  "2025-08-29T15:30:00+02:00": 964
  "2025-08-29T15:45:00+02:00": 1006
  "2025-08-29T16:00:00+02:00": 1236
  "2025-08-29T16:15:00+02:00": 1395
  "2025-08-29T16:30:00+02:00": 1271
  "2025-08-29T16:45:00+02:00": 932
  "2025-08-29T17:00:00+02:00": 580
  "2025-08-29T17:15:00+02:00": 350
  "2025-08-29T17:30:00+02:00": 341
  "2025-08-29T17:45:00+02:00": 504
  "2025-08-29T18:00:00+02:00": 722
  "2025-08-29T18:15:00+02:00": 856
  "2025-08-29T18:30:00+02:00": 816
  "2025-08-29T18:45:00+02:00": 690
  "2025-08-29T19:00:00+02:00": 522
  "2025-08-29T19:15:00+02:00": 355
  "2025-08-29T19:30:00+02:00": 202
  "2025-08-29T19:45:00+02:00": 91
  "2025-08-29T20:00:00+02:00": 13
  "2025-08-29T20:15:00+02:00": 0
  "2025-08-29T20:30:00+02:00": 0
  "2025-08-29T20:45:00+02:00": 0
  "2025-08-29T21:00:00+02:00": 0
  "2025-08-29T21:15:00+02:00": 0
  "2025-08-29T21:30:00+02:00": 0
  "2025-08-29T21:45:00+02:00": 0
  "2025-08-29T22:00:00+02:00": 0
  "2025-08-29T22:15:00+02:00": 0
  "2025-08-29T22:30:00+02:00": 0
  "2025-08-29T22:45:00+02:00": 0
  "2025-08-29T23:00:00+02:00": 0
  "2025-08-29T23:15:00+02:00": 0
  "2025-08-29T23:30:00+02:00": 0
  "2025-08-29T23:45:00+02:00": 0
wh_period:
  "2025-08-29T00:00:00+02:00": 0
  "2025-08-29T01:00:00+02:00": 0
  "2025-08-29T02:00:00+02:00": 0
  "2025-08-29T03:00:00+02:00": 0
  "2025-08-29T04:00:00+02:00": 0
  "2025-08-29T05:00:00+02:00": 0
  "2025-08-29T06:00:00+02:00": 10
  "2025-08-29T07:00:00+02:00": 460.25
  "2025-08-29T08:00:00+02:00": 1065.75
  "2025-08-29T09:00:00+02:00": 2261
  "2025-08-29T10:00:00+02:00": 3826.75
  "2025-08-29T11:00:00+02:00": 5216.5
  "2025-08-29T12:00:00+02:00": 5986.25
  "2025-08-29T13:00:00+02:00": 6074.75
  "2025-08-29T14:00:00+02:00": 5133
  "2025-08-29T15:00:00+02:00": 1460.75
  "2025-08-29T16:00:00+02:00": 1238.25
  "2025-08-29T17:00:00+02:00": 461.75
  "2025-08-29T18:00:00+02:00": 825.5
  "2025-08-29T19:00:00+02:00": 338
  "2025-08-29T20:00:00+02:00": 10
  "2025-08-29T21:00:00+02:00": 0
  "2025-08-29T22:00:00+02:00": 0
  "2025-08-29T23:00:00+02:00": 0
unit_of_measurement: kWh
device_class: energy
friendly_name: Solar production forecast Geschatte energieproductie - vandaag

Nb. Ik vergelijk de DAO-prognoses met die van Solcast en Open-Meteo, beide integraties moet je dus wel hebben in HA.

[sjampeter]

KC27 schreef op donderdag 28 augustus 2025 @ 19:35:
[...]

Ik heb als reactie op de inbreng van @Ferrox1 het volgende geschreven:
KC27 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"
Dat geldt nog steeds, maar daar kom ik pas na 1 oktober (=de overgang naar 15min-tarieven) aan toe.

aha, die had ik gemist. inderdaad alles op zijn tijd. kwartierprijzen komen eraan .

[Impossibl3]

@diamanten Hoe heb je die DAO entiteiten in HA gekregen? Ik zie alleen de entiteit: update.dao_day_ahead_optimizer_update.

Alle andere kan ik niet uit HA halen. Mis ik in mijn configuration.yaml misschien de verwijzing naar de DOA database?

[Mirabis]

@Impossibl3 dat dacht ik eerst ook. Maar ergens onderaan de DOCS staat de uitleg daarvoor: https://github.com/corneel27/day-ahead/blob/main/dao/DOCS.md en CNTRL+F op "Gebruik van deze api voor presentatie in Home Assistant"

[konehead]

Torch1969 schreef op donderdag 28 augustus 2025 @ 20:56:
[...]

Ik denk dat de fout in de apex chart zit. In het deel voor vandaag, dat van morgen gaat namelijk wel goed. Vergelijk de code nog eens goed met die van mij? Of deel die van jou hier eens?

thx, ben nog even met de helpers aan het klooien. post dit van het weekend. Heb jouw code gebruikt, maar ook nog een fout gevonden in de helper.

[Impossibl3]

Vraagje aan de kenners. Hoe zouden jullie de volgende PV-situatie in DAO zetten? Het gaat om 1 string plat op het dak waarbij 5 panelen op het "oosten" liggen (-70) en 4 op het "zuiden" (-20). Maar door de schaduw heb ik een typische piek wanneer ze allemaal zon pakken en de rest worden ze gedempt doordat de bypas niet aan springt per paneel.

Voor nu heb ik het er als volgt in zitten maar dat is niet correct wegens de schaduw vorming op de panelen.

code:

    {
      "name": "pv garage",
      "tilt": 0,
      "orientation": -45,
      "capacity": 2.745,
      "max power": 2.5,
      "yield": 0.002667975,
      "entity pv switch": ""
    }

Situatie:


Homewizzard meter PV (vandaar negatief, ik "exporteer" vanuit de meter gezien) met daar onder de zonnestraling van het weerstation dat op het dak staat. Dan zie je dat als er nog zat zon is (rond 15 uur) de opbrengst minimaal is wegens het niet in werking zijnde van de bypass.


Ter info dit waren de panelen die op het schuinedak lagen, toen we nieuwe kregen heb ik deze maar op de garage gelegd. Tzt gaan deze op een DC aansluiting op de accu met 2 of 3 strings, even kijken wat schaduw en kosten technisch het handigste is.

[Impossibl3]

diamanten schreef op vrijdag 29 augustus 2025 @ 11:03:
[...]

Hierbij de yaml code (tips voor verbetering welkom!):

code:

type: custom:apexcharts-card
graph_span: 24h
span:
  start: day
header:
  show: true
  title: PV Real vs Forecasts (24h)
now:
  show: true
  label: Nu
apex_config:
  chart:
    type: line
  stroke:
    width: 3
  legend:
    show: true
yaxis:
  - decimals: 2
    min: 0
    max: 9
    apex_config:
      title:
        text: kWh/uur
series:
  - entity: sensor.envoy_productie_per_uur
    name: PV Real
    type: column
    color: "#FF6666"
    group_by:
      func: max
      duration: 1h
  - entity: sensor.dao_pv_ac_vandaag_en_morgen
    group_by:
      func: last
      duration: 1h
    type: column
    stroke_width: 0
    name: DAO tot nu toe
    color: grey
    float_precision: 3
  - entity: sensor.dao_pv_ac_vandaag
    name: DAO PV Prognose
    type: line
    color: "#ff7f0e"
    data_generator: |
      const arr = entity.attributes?.data ?? [];
      return arr
        .filter(d => d.datatype === 'expected')
        .map(d => [new Date(d.time_ts), d.value]);
  - entity: sensor.energy_production_today_2
    name: Open-Meteo
    type: line
    color: "#1f77b4"
    opacity: 0.45
    data_generator: |
      const wh = entity.attributes?.wh_period ?? {};
      return Object.entries(wh).map(([iso, val]) => {
        const kwh = (Number(val) || 0) / 1000; // Wh → kWh
        return [new Date(iso), kwh];
      });
  - entity: sensor.solcast_pv_forecast_forecast_today
    name: Solcast
    type: line
    color: "#3b82f6"
    data_generator: |
      const items = (entity?.attributes?.detailedHourly ?? [])
        .map(p => ({ t: new Date(p.period_start).getTime(), v: Number(p.pv_estimate) || 0 }))
        .sort((a,b) => a.t - b.t);
      return items.map(p => [p.t, p.v]);

Ik heb net je kaart in HA gezet maar waarom heb je een extra sensor "sensor.dao_pv_ac_vandaag" gemaakt? De data zit toch ook al in "sensor.dao_pv_ac_vandaag_en_morgen" (althans bij mij wel)

code:

  - resource: http://192.168.XXX.XXX:5000/api/report/pv_ac/vandaag_en_morgen
    scan_interval: 600
    verify_ssl: false
    sensor:
      - name: DAO PV AC Vandaag en Morgen
        unique_id: dao_pv_ac_vandaag_en_morgen
        unit_of_measurement: "kWh"
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

[Torch1969]

Impossibl3 schreef op vrijdag 29 augustus 2025 @ 23:08:
[...]


Ik heb net je kaart in HA gezet maar waarom heb je een extra sensor "sensor.dao_pv_ac_vandaag" gemaakt? De data zit toch ook al in "sensor.dao_pv_ac_vandaag_en_morgen" (althans bij mij wel)

code:

  - resource: http://192.168.XXX.XXX:5000/api/report/pv_ac/vandaag_en_morgen
    scan_interval: 600
    verify_ssl: false
    sensor:
      - name: DAO PV AC Vandaag en Morgen
        unique_id: dao_pv_ac_vandaag_en_morgen
        unit_of_measurement: "kWh"
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

Ik denk om te voorkomen dat de voorspelling voor morgen ook in de grafiek komt. En als dat zo is dan kun je de vraag andersom stellen, waarom de extra sensor voor “vandaag en morgen” (in deze grafiek) gebruiken.

[Impossibl3]

Torch1969 schreef op zaterdag 30 augustus 2025 @ 09:28:
[...]


Ik denk om te voorkomen dat de voorspelling voor morgen ook in de grafiek komt. En als dat zo is dan kun je de vraag andersom stellen, waarom de extra sensor voor “vandaag en morgen” (in deze grafiek) gebruiken.

Eens. De morgen data voorkom je door de spawn op 24h te zetten en day. Dan pakt de grafiek de data van 00 tot 23:59 volgens mij.

Edit: ah ik zie het al. Die extra sensor heb je nodig om de historische voorspelling weer terug geven. Zo kan je vergelijken wat de voorspelling was tov de productie. Die sensor moet je dan ook maar 1x per etmaal actualiseren denk ik want anders ben je de historische voorspelling kwijt. De sensor "vandaag en morgen" "verliest" zijn voorspelling zodra de daadwerkelijke productie bekend is.

[ Voor 29% gewijzigd door Impossibl3 op 30-08-2025 09:54 ]

[konehead]

Torch1969 schreef op donderdag 28 augustus 2025 @ 20:56:
[...]

Ik denk dat de fout in de apex chart zit. In het deel voor vandaag, dat van morgen gaat namelijk wel goed. Vergelijk de code nog eens goed met die van mij? Of deel die van jou hier eens?

@Torch1969
De helper werkt nu ook correct, echter blijft de voorspelling cumulatief. Ik trek de voorspelling en productie uit DAO, echter ik zie in de entiteit dat de waardes cumulatief zijn. Die komen hierdoor ook cumulatief in de APX kart. Wat doe ik fout in mijn request waardoor ik de waardes cumulatief naar binnen trek?

code:

  - resource: http://192.168.1.82:5000/api/report/pv_dc/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: DAO solar production dc
        unique_id: dao_solar_production_dc
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

code:

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

[diamanten]

Impossibl3 schreef op zaterdag 30 augustus 2025 @ 09:49:
[...]


Eens. De morgen data voorkom je door de spawn op 24h te zetten en day. Dan pakt de grafiek de data van 00 tot 23:59 volgens mij.

Edit: ah ik zie het al. Die extra sensor heb je nodig om de historische voorspelling weer terug geven. Zo kan je vergelijken wat de voorspelling was tov de productie. Die sensor moet je dan ook maar 1x per etmaal actualiseren denk ik want anders ben je de historische voorspelling kwijt. De sensor "vandaag en morgen" "verliest" zijn voorspelling zodra de daadwerkelijke productie bekend is.

Toch mooi, zo'n gemeenschappelijke code review

[Torch1969]

konehead schreef op zaterdag 30 augustus 2025 @ 10:09:
[...]


@Torch1969
De helper werkt nu ook correct, echter blijft de voorspelling cumulatief. Ik trek de voorspelling en productie uit DAO, echter ik zie in de entiteit dat de waardes cumulatief zijn. Die komen hierdoor ook cumulatief in de APX kart. Wat doe ik fout in mijn request waardoor ik de waardes cumulatief naar binnen trek?


[Afbeelding]

[Afbeelding]

code:

  - resource: http://192.168.1.82:5000/api/report/pv_dc/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: DAO solar production dc
        unique_id: dao_solar_production_dc
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

code:

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

Je hebt gelijk, de api geeft het al cumulatief. Ik zie dat jij de dc voorspelling binnenhaalt, ik gebruik de ac voorspelling, misschien zit daar nog een verschil of bug in @KC27 ?

[Impossibl3]

Torch1969 schreef op zaterdag 30 augustus 2025 @ 11:53:
[...]

Je hebt gelijk, de api geeft het al cumulatief. Ik zie dat jij de dc voorspelling binnenhaalt, ik gebruik de ac voorspelling, misschien zit daar nog een verschil of bug in @KC27 ?

Nope. Ik trek de AC binnen en die is ook cumulatief zie ik in mijn grafiek. Ik wek nu namelijk geen 6,5 kWh op maar over de hele dag wel.

@diamanten Hoe heb jij je voorspelling historisch er in gekregen? Ik kan de methodiek voor die sensor even niet bedenken.

[diamanten]

Impossibl3 schreef op zaterdag 30 augustus 2025 @ 12:38:
[...]


Nope. Ik trek de AC binnen en die is ook cumulatief zie ik in mijn grafiek. Ik wek nu namelijk geen 6,5 kWh op maar over de hele dag wel.

@diamanten Hoe heb jij je voorspelling historisch er in gekregen? Ik kan de methodiek voor die sensor even niet bedenken.

Merkwaardig, ik gebruik dezelfde code die hier ook al gedeeld is:

code:

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

De sensor:

code:

- resource: http://192.168.xxx.yyy:5001/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 600
    sensor:
      - name: DAO PV AC vandaag en morgen
        unique_id: dao_pv_production_vandaag_morgen
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

[Impossibl3]

@diamanten Suf. Ik keek naar de production real... Die telt bij elkaar op de AC geeft inderdaad netjes per uur weer.

Vraag blijft nog wel staan over de historische weergaven van de voorspelling.

[Torch1969]

Impossibl3 schreef op zaterdag 30 augustus 2025 @ 12:38:
[...]


Nope. Ik trek de AC binnen en die is ook cumulatief zie ik in mijn grafiek. Ik wek nu namelijk geen 6,5 kWh op maar over de hele dag wel.

@diamanten Hoe heb jij je voorspelling historisch er in gekregen? Ik kan de methodiek voor die sensor even niet bedenken.

Je gebruikt dit api endpoint: resource: http://192.168.1.82:5000/api/report/pv_dc/vandaag_en_morgen
Daar staat toch pv_dc?

[Torch1969]

Impossibl3 schreef op zaterdag 30 augustus 2025 @ 14:09:
@diamanten Suf. Ik keek naar de production real... Die telt bij elkaar op de AC geeft inderdaad netjes per uur weer.

Vraag blijft nog wel staan over de historische weergaven van de voorspelling.

De State van die rest sensor is steeds de voorspelling van het huidige uur. Home assistant houdt daar netjes de historie van bij…..

[Impossibl3]

Torch1969 schreef op zaterdag 30 augustus 2025 @ 15:12:
[...]

Je gebruikt dit api endpoint: resource: http://192.168.1.82:5000/api/report/pv_dc/vandaag_en_morgen
Daar staat toch pv_dc?

Ik gebeuik pd_ac. De cumulatieve was verkeerd gekeken. Dat was mijn werkelijke opwek vanuit mijn pv paneel.

[KC27]

Torch1969 schreef op zaterdag 30 augustus 2025 @ 11:53:
[...]

Je hebt gelijk, de api geeft het al cumulatief. Ik zie dat jij de dc voorspelling binnenhaalt, ik gebruik de ac voorspelling, misschien zit daar nog een verschil of bug in @KC27 ?

Ik zie geen fout in mijn code en ook niet als ik het rest-commando in de browser uitvoer:

code:

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

geeft:

code:

{
   "message":"Success",
   "data":[
      {
         "time_ts":1756504800000,
         "time":"2025-08-30 00:00",
         "value":0.0,
         "datatype":"recorded"
      },
      {
         "time_ts":1756508400000,
         "time":"2025-08-30 01:00",
         "value":0.0,
         "datatype":"recorded"
      },
      {
         "time_ts":1756512000000,
         "time":"2025-08-30 02:00",
         "value":0.0,
         "datatype":"recorded"
      },
      {
         "time_ts":1756515600000,
         "time":"2025-08-30 03:00",
         "value":0.0,
         "datatype":"recorded"
      },
      {
         "time_ts":1756519200000,
         "time":"2025-08-30 04:00",
         "value":0.0,
         "datatype":"recorded"
      },
      {
         "time_ts":1756522800000,
         "time":"2025-08-30 05:00",
         "value":0.0,
         "datatype":"recorded"
      },
      {
         "time_ts":1756526400000,
         "time":"2025-08-30 06:00",
         "value":0.0,
         "datatype":"recorded"
      },
      {
         "time_ts":1756530000000,
         "time":"2025-08-30 07:00",
         "value":0.047,
         "datatype":"recorded"
      },
      {
         "time_ts":1756533600000,
         "time":"2025-08-30 08:00",
         "value":0.296,
         "datatype":"recorded"
      },
      {
         "time_ts":1756537200000,
         "time":"2025-08-30 09:00",
         "value":0.688,
         "datatype":"recorded"
      },
      {
         "time_ts":1756540800000,
         "time":"2025-08-30 10:00",
         "value":0.853,
         "datatype":"recorded"
      },
      {
         "time_ts":1756544400000,
         "time":"2025-08-30 11:00",
         "value":1.977,
         "datatype":"recorded"
      },
      {
         "time_ts":1756548000000,
         "time":"2025-08-30 12:00",
         "value":3.342,
         "datatype":"recorded"
      },
      {
         "time_ts":1756551600000,
         "time":"2025-08-30 13:00",
         "value":3.443,
         "datatype":"recorded"
      },
      {
         "time_ts":1756555200000,
         "time":"2025-08-30 14:00",
         "value":4.623,
         "datatype":"recorded"
      },
      {
         "time_ts":1756558800000,
         "time":"2025-08-30 15:00",
         "value":3.846,
         "datatype":"recorded"
      },
      {
         "time_ts":1756562400000,
         "time":"2025-08-30 16:00",
         "value":3.08,
         "datatype":"recorded"
      },
      {
         "time_ts":1756566000000,
         "time":"2025-08-30 17:00",
         "value":1.084,
         "datatype":"recorded"
      },
      {
         "time_ts":1756569600000,
         "time":"2025-08-30 18:00",
         "value":0.79,
         "datatype":"recorded"
      },
      {
         "time_ts":1756573200000,
         "time":"2025-08-30 19:00",
         "value":0.420576,
         "datatype":"expected"
      },
      {
         "time_ts":1756576800000,
         "time":"2025-08-30 20:00",
         "value":0.026,
         "datatype":"expected"
      },
      {
         "time_ts":1756580400000,
         "time":"2025-08-30 21:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756584000000,
         "time":"2025-08-30 22:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756587600000,
         "time":"2025-08-30 23:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756591200000,
         "time":"2025-08-31 00:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756594800000,
         "time":"2025-08-31 01:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756598400000,
         "time":"2025-08-31 02:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756602000000,
         "time":"2025-08-31 03:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756605600000,
         "time":"2025-08-31 04:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756609200000,
         "time":"2025-08-31 05:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756612800000,
         "time":"2025-08-31 06:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756616400000,
         "time":"2025-08-31 07:00",
         "value":0.013,
         "datatype":"expected"
      },
      {
         "time_ts":1756620000000,
         "time":"2025-08-31 08:00",
         "value":0.137766,
         "datatype":"expected"
      },
      {
         "time_ts":1756623600000,
         "time":"2025-08-31 09:00",
         "value":0.277314,
         "datatype":"expected"
      },
      {
         "time_ts":1756627200000,
         "time":"2025-08-31 10:00",
         "value":0.163568,
         "datatype":"expected"
      },
      {
         "time_ts":1756630800000,
         "time":"2025-08-31 11:00",
         "value":0.128478,
         "datatype":"expected"
      },
      {
         "time_ts":1756634400000,
         "time":"2025-08-31 12:00",
         "value":0.0780206,
         "datatype":"expected"
      },
      {
         "time_ts":1756638000000,
         "time":"2025-08-31 13:00",
         "value":0.117901,
         "datatype":"expected"
      },
      {
         "time_ts":1756641600000,
         "time":"2025-08-31 14:00",
         "value":0.144738,
         "datatype":"expected"
      },
      {
         "time_ts":1756645200000,
         "time":"2025-08-31 15:00",
         "value":0.171397,
         "datatype":"expected"
      },
      {
         "time_ts":1756648800000,
         "time":"2025-08-31 16:00",
         "value":0.15812,
         "datatype":"expected"
      },
      {
         "time_ts":1756652400000,
         "time":"2025-08-31 17:00",
         "value":1.33677,
         "datatype":"expected"
      },
      {
         "time_ts":1756656000000,
         "time":"2025-08-31 18:00",
         "value":0.831857,
         "datatype":"expected"
      },
      {
         "time_ts":1756659600000,
         "time":"2025-08-31 19:00",
         "value":0.162153,
         "datatype":"expected"
      },
      {
         "time_ts":1756663200000,
         "time":"2025-08-31 20:00",
         "value":0.013,
         "datatype":"expected"
      },
      {
         "time_ts":1756666800000,
         "time":"2025-08-31 21:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756670400000,
         "time":"2025-08-31 22:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756674000000,
         "time":"2025-08-31 23:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756677600000,
         "time":"2025-09-01 00:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756681200000,
         "time":"2025-09-01 01:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756684800000,
         "time":"2025-09-01 02:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756688400000,
         "time":"2025-09-01 03:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756692000000,
         "time":"2025-09-01 04:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756695600000,
         "time":"2025-09-01 05:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756699200000,
         "time":"2025-09-01 06:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756702800000,
         "time":"2025-09-01 07:00",
         "value":0.2055263681,
         "datatype":"expected"
      },
      {
         "time_ts":1756706400000,
         "time":"2025-09-01 08:00",
         "value":0.3404634717,
         "datatype":"expected"
      },
      {
         "time_ts":1756710000000,
         "time":"2025-09-01 09:00",
         "value":0.8814566331,
         "datatype":"expected"
      },
      {
         "time_ts":1756713600000,
         "time":"2025-09-01 10:00",
         "value":1.3090734624,
         "datatype":"expected"
      },
      {
         "time_ts":1756717200000,
         "time":"2025-09-01 11:00",
         "value":1.6603744161,
         "datatype":"expected"
      },
      {
         "time_ts":1756720800000,
         "time":"2025-09-01 12:00",
         "value":1.994778666,
         "datatype":"expected"
      },
      {
         "time_ts":1756724400000,
         "time":"2025-09-01 13:00",
         "value":4.2197941071,
         "datatype":"expected"
      },
      {
         "time_ts":1756728000000,
         "time":"2025-09-01 14:00",
         "value":4.0105446219,
         "datatype":"expected"
      },
      {
         "time_ts":1756731600000,
         "time":"2025-09-01 15:00",
         "value":3.6897778257,
         "datatype":"expected"
      },
      {
         "time_ts":1756735200000,
         "time":"2025-09-01 16:00",
         "value":3.0834885023,
         "datatype":"expected"
      },
      {
         "time_ts":1756738800000,
         "time":"2025-09-01 17:00",
         "value":2.3522238746,
         "datatype":"expected"
      },
      {
         "time_ts":1756742400000,
         "time":"2025-09-01 18:00",
         "value":1.6406836875,
         "datatype":"expected"
      },
      {
         "time_ts":1756746000000,
         "time":"2025-09-01 19:00",
         "value":0.013,
         "datatype":"expected"
      },
      {
         "time_ts":1756749600000,
         "time":"2025-09-01 20:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756753200000,
         "time":"2025-09-01 21:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756756800000,
         "time":"2025-09-01 22:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756760400000,
         "time":"2025-09-01 23:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756771200000,
         "time":"2025-09-02 02:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756782000000,
         "time":"2025-09-02 05:00",
         "value":0.039,
         "datatype":"expected"
      },
      {
         "time_ts":1756792800000,
         "time":"2025-09-02 08:00",
         "value":1.6802477583,
         "datatype":"expected"
      },
      {
         "time_ts":1756803600000,
         "time":"2025-09-02 11:00",
         "value":2.7334819755,
         "datatype":"expected"
      },
      {
         "time_ts":1756814400000,
         "time":"2025-09-02 14:00",
         "value":3.6340185531,
         "datatype":"expected"
      },
      {
         "time_ts":1756825200000,
         "time":"2025-09-02 17:00",
         "value":1.6845102442,
         "datatype":"expected"
      },
      {
         "time_ts":1756836000000,
         "time":"2025-09-02 20:00",
         "value":0.0,
         "datatype":"expected"
      },
      {
         "time_ts":1756846800000,
         "time":"2025-09-02 23:00",
         "value":0.0,
         "datatype":"expected"
      }
   ]
}

[Hedzie]

Ik heb inmiddels de EV geconfigureerd in DAO.

Wat ik niet helemaal begrijp is waarom DAO nu elk uur een beetje wil laden.
Is het niet voordeliger om vanaf bijv. 03.00u vannacht te gaan laden?

En zet je in je automatisering dat de batterijen naar 0 moeten tijdens het laden van de EV?

code:

  "electric vehicle": [
    {
      "name": "Tesla",
      "capacity": 72.6,
      "entity position": "device_tracker.tesla_hedz_location_tracker",
      "entity instant start": "input_boolean.tesla_direct_laden",
      "entity instant level": "input_number.tesla_direct_laden_soc",
      "entity max amperage": "input_number.stel_tesla_max_ampere_in",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere": 0, "efficiency": 0.00},
        {"ampere": 6, "efficiency": 0.85},
        {"ampere": 7, "efficiency": 0.87},
        {"ampere": 8, "efficiency": 0.89},
        {"ampere": 9, "efficiency": 0.90},
        {"ampere": 10, "efficiency": 0.91},
        {"ampere": 11, "efficiency": 0.915},
        {"ampere": 12, "efficiency": 0.92},
        {"ampere": 13, "efficiency": 0.925},
        {"ampere": 14, "efficiency": 0.93},
        {"ampere": 15, "efficiency": 0.935},
        {"ampere": 16, "efficiency": 0.94}
      ],      
      "entity actual level": "sensor.tesla_hedz_battery",
      "entity plugged in": "binary_sensor.tesla_hedz_charger",
      "entity stop charging": "input_datetime.dao_stop_laden_ev",
      "charge scheduler": {
        "entity set level": "input_number.stel_tesla_gewenst_laadniveau",
        "level margin": 4,
        "entity ready datetime": "input_datetime.tijdstip_klaar_met_laden"
      },
      "charge switch": "input_boolean.tesla_laden",
      "entity set charging ampere" : "input_number.stel_tesla_laad_ampere"
    }
  ],

code:

 2025-08-30 20:00:00 info: Day Ahead Optimalisering versie: 2025.8.1
2025-08-30 20:00:00 info: Day Ahead Optimalisering gestart op: 30-08-2025 20:00:00
2025-08-30 20:00:00 info: Day Ahead Optimalisatie gestart: 30-08-2025 20:00:00 taak: calc_optimum
2025-08-30 20:00:00 info: Debug = False
2025-08-30 20:00:00 info: Zelf berekende baseload
2025-08-30 20:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    20 2025-08-30 20:00:00   0.30   0.18   0.03   0.10      0
1    21 2025-08-30 21:00:00   0.27   0.15   0.40   0.00      0
2    22 2025-08-30 22:00:00   0.26   0.14   0.48   0.00      0
3    23 2025-08-30 23:00:00   0.25   0.13   0.19   0.00      0
4     0 2025-08-31 00:00:00   0.25   0.13   0.26   0.00      0
5     1 2025-08-31 01:00:00   0.24   0.11   0.18   0.00      0
6     2 2025-08-31 02:00:00   0.23   0.10   0.22   0.00      0
7     3 2025-08-31 03:00:00   0.22   0.10   0.19   0.00      0
8     4 2025-08-31 04:00:00   0.22   0.09   0.16   0.00      0
9     5 2025-08-31 05:00:00   0.21   0.09   0.20   0.00      0
10    6 2025-08-31 06:00:00   0.21   0.09   0.20   0.00      0
11    7 2025-08-31 07:00:00   0.21   0.09   0.24   0.00      0
12    8 2025-08-31 08:00:00   0.17   0.05   0.43   0.03      0
13    9 2025-08-31 09:00:00   0.15   0.03   0.79   0.17      0
14   10 2025-08-31 10:00:00   0.15   0.02   1.00   0.75      0
15   11 2025-08-31 11:00:00   0.15   0.02   0.71   3.13      0
16   12 2025-08-31 12:00:00   0.15   0.02   0.86   2.00      0
17   13 2025-08-31 13:00:00   0.15   0.02   1.03   0.72      0
18   14 2025-08-31 14:00:00   0.15   0.02   0.25   0.66      0
19   15 2025-08-31 15:00:00   0.15   0.02   1.21   0.87      0
20   16 2025-08-31 16:00:00   0.17   0.05   0.67   0.24      0
21   17 2025-08-31 17:00:00   0.23   0.11   0.39   0.22      0
22   18 2025-08-31 18:00:00   0.27   0.15   0.20   0.69      0
23   19 2025-08-31 19:00:00   0.30   0.18   0.35   0.58      0
24   20 2025-08-31 20:00:00   0.30   0.18   0.23   0.03      0
25   21 2025-08-31 21:00:00   0.28   0.16   0.19   0.00      0
26   22 2025-08-31 22:00:00   0.27   0.15   0.37   0.00      0
27   23 2025-08-31 23:00:00   0.25   0.13   0.20   0.00      0
2025-08-30 20:00:00 info: No reduced hours applied for Sessy1
2025-08-30 20:00:00 info: Startwaarde SoC Sessy1: 97.0%
2025-08-30 20:00:00 info: No reduced hours applied for Sessy2
2025-08-30 20:00:00 info: Startwaarde SoC Sessy2: 100.0%
2025-08-30 20:00:00 info: 

2025-08-30 20:00:00 info: Boiler direct opwarmen staat uit
2025-08-30 20:00:00 info: Boiler opwarmen wordt ingepland tussen: 1 en 23 uur

2025-08-30 20:00:00 info: Instellingen voor laden van EV: Tesla
2025-08-30 20:00:00 info: Direct laden is uit
2025-08-30 20:00:00 info:  Ampere  Effic. Grid kW Accu kW
2025-08-30 20:00:00 info:    0.00    0.00    0.00    0.00
2025-08-30 20:00:00 info:    6.00    0.85    4.14    3.52
2025-08-30 20:00:00 info:    7.00    0.87    4.83    4.20
2025-08-30 20:00:00 info:    8.00    0.89    5.52    4.91
2025-08-30 20:00:00 info:    9.00    0.90    6.21    5.59
2025-08-30 20:00:00 info:   10.00    0.91    6.90    6.28
2025-08-30 20:00:00 info:   11.00    0.92    7.59    6.94
2025-08-30 20:00:00 info:   12.00    0.92    8.28    7.62
2025-08-30 20:00:00 info:   13.00    0.93    8.97    8.30
2025-08-30 20:00:00 info:   14.00    0.93    9.66    8.98
2025-08-30 20:00:00 info:   15.00    0.94   10.35    9.68
2025-08-30 20:00:00 info:   16.00    0.94   11.04   10.38
2025-08-30 20:00:00 info: Capaciteit accu: 72.6 kWh
2025-08-30 20:00:00 info: Maximaal laadvermogen: 11.04 kW
2025-08-30 20:00:00 info: Klaar met laden op: 31-08-2025 07:30:00
2025-08-30 20:00:00 info: Huidig laadniveau: 73.0 %
2025-08-30 20:00:00 info: Gewenst laadniveau:80.0 %
2025-08-30 20:00:00 info: Marge voor het laden: 4 %
2025-08-30 20:00:00 info: Locatie: home
2025-08-30 20:00:00 info: Ingeplugged:True
2025-08-30 20:00:00 info: Benodigde energie: 5.081999999999999 kWh
2025-08-30 20:00:00 info: Tijd nodig om te laden: 0.49 uur
2025-08-30 20:00:00 info: Afgerond naar hele uren: 1
2025-08-30 20:00:00 info: Stand laden schakelaar: off
2025-08-30 20:00:00 info: Stand aantal ampere laden: 16.0 A
2025-08-30 20:00:00 info: Opladen wordt ingepland tussen 2025-08-30 20:00:00 en 2025-08-31 07:30:00

2025-08-30 20:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

2025-08-30 20:00:20 info: Eerste berekening
2025-08-30 20:00:20 info: Kosten (euro): 1.07  
2025-08-30 20:00:20 info: Levering (kWh): 0.24  
2025-08-30 20:00:47 info: Herberekening
2025-08-30 20:00:47 info: Kosten (euro): 1.07  
2025-08-30 20:00:47 info: Levering (kWh): 0.24  
2025-08-30 20:00:47 info: Strategie: minimale levering
2025-08-30 20:00:47 info: Het programma heeft een optimale oplossing gevonden.
2025-08-30 20:00:47 info: Niet geoptimaliseerd, kosten met day ahead tarieven: 2.59  
2025-08-30 20:00:47 info: Geoptimaliseerd, kosten met day ahead tarieven: 1.07  
2025-08-30 20:00:47 info: Levering: 0.24   (kWh)
2025-08-30 20:00:47 info: Waarde boiler om 23 uur: 2.67 kWh
2025-08-30 20:00:47 info: In- en uitgaande energie per uur batterij Sessy1
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
    20  -0.68  95.70  -0.71   0.00  -0.71 100.00  -0.71  95.70  84.08
    21   0.00     --   0.00   0.00   0.00     --   0.00     --  84.08
    22   0.00     --   0.00   0.00   0.00     --   0.00     --  84.08
    23  -0.68  95.70  -0.71   0.00  -0.71 100.00  -0.71  95.70  71.16
     0  -0.68  95.70  -0.71   0.00  -0.71 100.00  -0.71  95.70  58.24
     1  -0.68  95.70  -0.71   0.00  -0.71 100.00  -0.71  95.70  45.32
     2   0.00     --   0.00   0.00   0.00     --   0.00     --  45.32
     3   0.00     --   0.00   0.00   0.00     --   0.00     --  45.32
     4   0.00     --   0.00   0.00   0.00     --   0.00     --  45.32
     5  -0.53  95.70  -0.56   0.00  -0.56 100.00  -0.56  95.70  35.23
     6  -0.68  95.70  -0.71   0.00  -0.71 100.00  -0.71  95.70  22.31
     7   0.00     --   0.00   0.00   0.00     --   0.00     --  22.31
     8   0.00     --   0.00   0.00   0.00     --   0.00     --  22.31
     9  -0.62  95.70  -0.65   0.00  -0.65 100.00  -0.65  95.70  10.48
    10   0.00     --   0.00   0.00   0.00     --   0.00     --  10.48
    11   1.32  94.19   1.25   0.00   1.25 100.00   1.25  94.19  33.12
    12  -0.97  95.30  -1.02   0.00  -1.02 100.00  -1.02  95.30  14.64
    13   0.03  94.90   0.03   0.00   0.03 100.00   0.03  94.90  15.15
    14   0.41  90.69   0.37   0.00   0.37 100.00   0.37  90.69  21.85
    15  -0.35  94.30  -0.37   0.00  -0.37 100.00  -0.37  94.30  15.14
    16  -0.26  92.10  -0.28   0.00  -0.28 100.00  -0.28  92.10  10.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    19   0.01  94.90   0.01   0.00   0.01 100.00   0.01  94.90  10.10
    20   0.22  85.00   0.19   0.00   0.19 100.00   0.19  85.00  13.50
    21   0.00     --   0.00   0.00   0.00     --   0.00     --  13.50
    22   0.00     --   0.00   0.00   0.00     --   0.00     --  13.50
    23  -0.16  82.90  -0.19   0.00  -0.19 100.00  -0.19  82.90  10.00
Totaal  -4.31     --  -4.78   0.00  -4.78     --  -4.78     --       
2025-08-30 20:00:47 info: In- en uitgaande energie per uur batterij Sessy2
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
    20   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    21  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  90.31
    22  -0.68  95.70  -0.71   0.00  -0.71 100.00  -0.71  95.70  77.39
    23  -0.76  95.70  -0.80   0.00  -0.80 100.00  -0.80  95.70  62.91
     0   0.00     --   0.00   0.00   0.00     --   0.00     --  62.91
     1   0.00     --   0.00   0.00   0.00     --   0.00     --  62.91
     2  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  53.22
     3  -0.68  95.70  -0.71   0.00  -0.71 100.00  -0.71  95.70  40.30
     4  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  30.61
     5   0.00     --   0.00   0.00   0.00     --   0.00     --  30.61
     6   0.00     --   0.00   0.00   0.00     --   0.00     --  30.61
     7  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  20.92
     8  -0.38  94.30  -0.41   0.00  -0.41 100.00  -0.41  94.30  13.50
     9   0.00     --   0.00   0.00   0.00     --   0.00     --  13.50
    10  -0.17  88.20  -0.19   0.00  -0.19 100.00  -0.19  88.20  10.00
    11   1.10  94.60   1.04   0.00   1.04 100.00   1.04  94.60  28.92
    12   0.00     --   0.00   0.00   0.00     --   0.00     --  28.92
    13  -0.34  94.30  -0.36   0.00  -0.36 100.00  -0.36  94.30  22.36
    14   0.00     --   0.00   0.00   0.00     --   0.00     --  22.36
    15   0.00     --   0.00   0.00   0.00     --   0.00     --  22.36
    16  -0.17  88.20  -0.19   0.00  -0.19 100.00  -0.19  88.20  18.86
    17  -0.08  82.90  -0.10   0.00  -0.10 100.00  -0.10  82.90  17.00
    18   0.49  91.79   0.45   0.00   0.45 100.00   0.45  91.79  25.10
    19   0.22  85.00   0.19   0.00   0.19 100.00   0.19  85.00  28.50
    20  -0.42  94.30  -0.44   0.00  -0.44 100.00  -0.44  94.30  20.46
    21  -0.19  88.20  -0.21   0.00  -0.21 100.00  -0.21  88.20  16.58
    22  -0.33  92.10  -0.36   0.00  -0.36 100.00  -0.36  92.10  10.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
Totaal  -4.44     --  -4.95   0.00  -4.95     --  -4.95     --       
2025-08-30 20:00:47 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 20.00    0.00     0.68   0.00   0.00   0.03   0.00   0.00   0.75   0.10   0.00   -0.00  44.16
 21.00    0.00     0.51   0.00   0.00   0.40   0.00   0.00   0.11   0.00   0.00   -0.00  43.92
 22.00    0.00     0.68   0.00   0.00   0.48   0.00   0.00   0.20   0.00   0.00   -0.00  43.69
 23.00    0.00     1.44   0.00   0.00   0.19   0.00   0.00   1.25   0.00   0.00   -0.00  43.45
  0.00    0.00     0.68   0.00   0.00   0.26   0.00   0.00   0.42   0.00   0.00   -0.00  43.21
  1.00    0.00     0.68   0.00   0.00   0.18   0.00   0.00   0.50   0.00   0.00   -0.00  42.98
  2.00    0.00     0.51   0.00   0.00   0.22   0.00   0.00   0.29   0.00   0.00   -0.00  42.74
  3.00    0.00     0.68   0.00   0.00   0.19   0.00   0.00   0.49   0.00   0.00   -0.00  42.50
  4.00    0.00     0.51   0.00   0.00   0.16   0.00   0.00   0.35   0.00   0.00   -0.00  42.26
  5.00    0.00     0.53   0.00   0.00   0.20   0.00   0.00   0.33   0.00   0.00   -0.00  42.03
  6.00    0.00     0.68   0.00   0.00   0.20   0.00   0.00   0.48   0.00   0.00   -0.00  41.79
  7.00    0.00     0.51   0.00   0.00   0.24   0.00   0.00   0.27   0.00   0.00   -0.00  41.55
  8.00    0.00     0.38   0.01   0.00   0.43   0.00   0.00   0.00   0.03   0.00   -0.00  41.31
  9.00    0.00     0.62   0.00   0.00   0.79   0.00   0.00   0.00   0.16   0.00   -0.00  41.08
 10.00    0.00     0.17   0.09   0.00   1.00   0.00   0.00   0.00   0.75   0.01   -0.00  40.84
 11.00    2.42     0.00   0.00   0.00   0.71   0.00   0.00   0.00   3.13   0.00   -0.00  40.60
 12.00    0.00     0.97   0.00   0.00   0.86   2.11   0.00   0.00   2.00   0.00   -0.00  58.19
 13.00    0.03     0.34   0.00   0.00   1.03   0.00   0.00   0.00   0.72   0.00   -0.00  57.95
 14.00    0.41     0.00   0.00   0.00   0.25   0.00   0.00   0.00   0.66   0.00   -0.00  57.71
 15.00    0.00     0.35   0.00   0.00   1.21   0.00   0.00   0.00   0.87   0.00   -0.00  57.48
 16.00    0.00     0.43   0.00   0.00   0.67   0.00   0.00   0.00   0.24   0.00   -0.00  57.24
 17.00    0.00     0.08   0.08   0.00   0.39   0.00   0.00   0.00   0.22   0.02   -0.00  57.00
 18.00    0.49     0.00   0.00   0.00   0.20   0.00   0.00   0.00   0.69   0.00   -0.00  56.76
 19.00    0.23     0.00   0.00   0.00   0.35   0.00   0.00   0.00   0.58   0.00   -0.00  56.53
 20.00    0.22     0.42   0.00   0.00   0.23   0.00   0.00   0.00   0.03   0.00   -0.00  56.29
 21.00    0.00     0.19   0.00   0.00   0.19   0.00   0.00   0.00   0.00   0.00   -0.00  56.05
 22.00    0.00     0.33   0.04   0.00   0.37   0.00   0.00   0.00   0.00   0.01   -0.00  55.81
 23.00    0.00     0.16   0.04   0.00   0.20   0.00   0.00   0.00   0.00   0.01   -0.00  55.58
Totaal    3.79    12.54   0.24   0.00  11.62   2.11   0.00   5.44  10.17   0.05    0.00       
2025-08-30 20:00:47 info: Winst: € 1.52
2025-08-30 20:00:47 info: Doorzetten van alle settings naar HA
2025-08-30 20:00:47 info: Boiler opwarmen niet geactiveerd
2025-08-30 20:00:47 info: Inzet-factor laden Tesla per stap
2025-08-30 20:00:47 info: Berekeningsuitkomst voor opladen van Tesla:
2025-08-30 20:00:47 info: - aantal ampere 16A (was 16.0A)
2025-08-30 20:00:47 info: - stand schakelaar 'on' (was 'off')
2025-08-30 20:00:47 info: - stop laden op 2025-08-30 20:04
2025-08-30 20:00:47 info: - positie: home
2025-08-30 20:00:47 info: - ingeplugd: True
2025-08-30 20:00:47 info: Laden van Tesla aangezet met 16 ampere via 'input_number.stel_tesla_laad_ampere'
2025-08-30 20:00:47 info: Evaluatie status laden Tesla op 2025-08-30 20:00
2025-08-30 20:00:47 info: - schakelaar laden: on
2025-08-30 20:00:47 info: - aantal ampere: 16.0
2025-08-30 20:00:47 info: Grid set point: 0.0 W
2025-08-30 20:00:47 info: Cycle cost Sessy1: 0.08 euro
2025-08-30 20:00:47 info: Netto vermogen naar(+)/uit(-) omvormer Sessy1: -680 W
2025-08-30 20:00:47 info: Balanceren: True
2025-08-30 20:00:47 info: Vermogen uit batterij: 710W
2025-08-30 20:00:47 info: Vermogen dat binnenkomt van pv: 0W
2025-08-30 20:00:47 info: Vermogen dat binnenkomt van ac: -710W
2025-08-30 20:00:47 info: Waarde SoC na eerste uur: 84.1%
2025-08-30 20:00:47 info: Grid set point: 0.0 W
2025-08-30 20:00:47 info: Cycle cost Sessy2: 0.08 euro
2025-08-30 20:00:47 info: Netto vermogen naar(+)/uit(-) omvormer Sessy2: 0 W
2025-08-30 20:00:47 info: Balanceren: False
2025-08-30 20:00:47 info: Vermogen uit batterij: 0W
2025-08-30 20:00:47 info: Vermogen dat binnenkomt van pv: 0W
2025-08-30 20:00:47 info: Vermogen dat binnenkomt van ac: 0W
2025-08-30 20:00:47 info: Waarde SoC na eerste uur: 100.0%

[KC27]

Verzoek
Ik heb op github een feature request aangemaakt voor Home Assistant:
https://github.com/orgs/home-assistant/discussions/836
Met als titel: Storage interval longterm statistics to 15minutes.
Tot nu toe slaat HA je verbruiks- en terugleveringsdata, maak ook het verbruik/productie van je auto('s), je wp, je pv enz op als een meterstand met een interval van 1 uur.
Vanaf 1 oktober a.s. gaat bij veel dynamische leveranciers het tarief ieder kwartier wijzigen ipv ieder uur.
Om straks de kosten toch goed te kunnen berekenen heeft DAO verbruiksgegevens per kwartier nodig.
Daarom heb ik deze feature request aangemaakt.
Mijn verzoek aan jullie is om dit verzoek te ondersteunen met een "up-vote" en aanvullend commentaar is uiteraard ook welkom.

[konehead]

KC27 schreef op zaterdag 30 augustus 2025 @ 19:43:
[...]

Ik zie geen fout in mijn code en ook niet als ik het rest-commando in de browser uitvoer:

code:

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

geeft:

[...]

@KC27
en is er een verschil tussen AC en DC? Ik krijg de forecast (expected) cumulatief terug vanuit DOA. Zou je ajb ook naar DC willen kijken?

Edit: ik krijg het niet zo mooi als jij in de post, de data die ik terug krijg wordt nu als 1 string in de post geplaatst.

Als ik dit uitvoer:

code:

http://192.168.1.82:5000/api/report/pv_dc/vandaag

code:

{ "message":"Success", "data": [{"time_ts":1756591200000,"time":"2025-08-31 00:00","value":0.0,"datatype":"recorded"},{"time_ts":1756594800000,"time":"2025-08-31 01:00","value":0.0,"datatype":"recorded"},{"time_ts":1756598400000,"time":"2025-08-31 02:00","value":0.0,"datatype":"recorded"},{"time_ts":1756602000000,"time":"2025-08-31 03:00","value":0.0,"datatype":"recorded"},{"time_ts":1756605600000,"time":"2025-08-31 04:00","value":0.0,"datatype":"recorded"},{"time_ts":1756609200000,"time":"2025-08-31 05:00","value":0.0,"datatype":"recorded"},{"time_ts":1756612800000,"time":"2025-08-31 06:00","value":0.0,"datatype":"recorded"},{"time_ts":1756616400000,"time":"2025-08-31 07:00","value":0.0,"datatype":"recorded"},{"time_ts":1756620000000,"time":"2025-08-31 08:00","value":0.0,"datatype":"recorded"},{"time_ts":1756623600000,"time":"2025-08-31 09:00","value":0.1243892853,"datatype":"expected"},{"time_ts":1756627200000,"time":"2025-08-31 10:00","value":1.3370306951,"datatype":"expected"},{"time_ts":1756630800000,"time":"2025-08-31 11:00","value":2.9750500471,"datatype":"expected"},{"time_ts":1756634400000,"time":"2025-08-31 12:00","value":4.8019537837,"datatype":"expected"},{"time_ts":1756638000000,"time":"2025-08-31 13:00","value":6.5107138825,"datatype":"expected"},{"time_ts":1756641600000,"time":"2025-08-31 14:00","value":6.8602960194,"datatype":"expected"},{"time_ts":1756645200000,"time":"2025-08-31 15:00","value":7.0756172851,"datatype":"expected"},{"time_ts":1756648800000,"time":"2025-08-31 16:00","value":7.2751824921,"datatype":"expected"},{"time_ts":1756652400000,"time":"2025-08-31 17:00","value":7.3337766967,"datatype":"expected"},{"time_ts":1756656000000,"time":"2025-08-31 18:00","value":7.3625766967,"datatype":"expected"},{"time_ts":1756659600000,"time":"2025-08-31 19:00","value":7.4513641633,"datatype":"expected"},{"time_ts":1756663200000,"time":"2025-08-31 20:00","value":7.4585641633,"datatype":"expected"},{"time_ts":1756666800000,"time":"2025-08-31 21:00","value":7.4585641633,"datatype":"expected"},{"time_ts":1756670400000,"time":"2025-08-31 22:00","value":7.4585641633,"datatype":"expected"},{"time_ts":1756674000000,"time":"2025-08-31 23:00","value":7.4585641633,"datatype":"expected"}] }

[KC27]

konehead schreef op zondag 31 augustus 2025 @ 10:00:
[...]


@KC27
en is er een verschil tussen AC en DC? Ik krijg de forecast (expected) cumulatief terug vanuit DOA. Zou je ajb ook naar DC willen kijken?

Edit: ik krijg het niet zo mooi als jij in de post, de data die ik terug krijg wordt nu als 1 string in de post geplaatst.

Als ik dit uitvoer:

code:

http://192.168.1.82:5000/api/report/pv_dc/vandaag

[...]

Ik ben er nog eens ingedoken.
Er zit toch een fout aan mijn kant: bij het opslaan van de prognoses van de uurlijkse waarden van pv_dc worden deze cumulatief opgeslagen, waarna ze dus ook cumulatief worden weergegeven bij de aanroep van de api.
Ik ga een dezer dagen een fix uitbrengen voor deze fout.

[Dogooder]

Ik heb net dit weekend mijn zonnepanelen van ac naar dc gebracht met een nieuwe omvormer.
Ik was daarom ook net bezig om de dao daar op aan te passen. En ik begreep maar niet waarom de grafiek die het eerst prima deed ineens hele hoge waardes gaf.
Fijn dat je het probleem gevonden hebt.

[KC27]

@Dogooder @konehead @Torch1969 en andere testers
Ik heb versie 2025.9.0.rc1 gepubliceerd.
Changelog:
Fix error api prognose pv_dc
Zou een van jullie met problemen met de prognose van pv_dc dit willen testen en mij het resultaat laten weten?
Let op;
De fout zat bij het opslaan van de berekende prognose in de rekenroutine van het programma.
Dus je moet eerst de rekenroutine laten rekenen en niet in debug-mode want dan worden de berekende prognoses ook niet opgeslagen.

[konehead]

KC27 schreef op zondag 31 augustus 2025 @ 23:45:
[...]

Ik ben er nog eens ingedoken.
Er zit toch een fout aan mijn kant: bij het opslaan van de prognoses van de uurlijkse waarden van pv_dc worden deze cumulatief opgeslagen, waarna ze dus ook cumulatief worden weergegeven bij de aanroep van de api.
Ik ga een dezer dagen een fix uitbrengen voor deze fout.

Je bent een held! Dank voor het checken en ook fixen.

[Torch1969]

KC27 schreef op maandag 1 september 2025 @ 08:53:
@Dogooder @konehead @Torch1969 en andere testers
Ik heb versie 2025.9.0.rc1 gepubliceerd.
Changelog:
Fix error api prognose pv_dc
Zou een van jullie met problemen met de prognose van pv_dc dit willen testen en mij het resultaat laten weten?
Let op;
De fout zat bij het opslaan van de berekende prognose in de rekenroutine van het programma.
Dus je moet eerst de rekenroutine laten rekenen en niet in debug-mode want dan worden de berekende prognoses ook niet opgeslagen.

Ik heb deze test-versie geïnstalleerd, maar kan zelf geen dc testen (om dat helemaal te configureren gaat me net wat te ver). De berekening (zonder debug) en de pv_ac api werkt gewoon. Ik hoop dat iemand met pv_dc configuratie die api kan testen.

[Dogooder]

2025.9.0.rc1 lijkt het goed te doen.

[konehead]

Dogooder schreef op maandag 1 september 2025 @ 20:07:
2025.9.0.rc1 lijkt het goed te doen.
[Afbeelding]

Bij mij ook!

[KC27]

@Dogooder @konehead
Dank voor het testen!
Ik zet hem door naar stable.

[KC27]

Op dit moment is de build klaar voor versie 2025.9.0.
Deze versie is exact hetzelfde als de 2025.9.0.rc1, dus er komt geen nieuwe rc.

[KC27]

Dank voor het upvoten van de feature request:

Ik heb op github een feature request aangemaakt voor Home Assistant:
https://github.com/orgs/home-assistant/discussions/836
Met als titel: Storage interval longterm statistics to 15minutes.

Upvoten kan nog steeds!
Op dit moment hebben we 20 votes en staan we bovenaan in het maandklassement.

[simnet]

KC27 schreef op zondag 31 augustus 2025 @ 09:43:
Verzoek
Ik heb op github een feature request aangemaakt voor Home Assistant:
https://github.com/orgs/home-assistant/discussions/836
Met als titel: Storage interval longterm statistics to 15minutes.

Deze discussie is hier misschien ook relevant voor: https://community.home-as...rd-update-interval/424324

[RudolfR]

Via de websocket API kunnen LTS al worden opgevraagd met een resolutie van 5 minuten:
https://github.com/home-a...der/websocket_api.py#L164

Ik heb voor EMHASS ook een verzoek openstaan om daar gebruik van te maken:
https://github.com/davidusb-geek/emhass/discussions/511
Daar zit wat python voorbeeldcode bij.

[KC27]

RudolfR schreef op dinsdag 2 september 2025 @ 15:09:
Via de websocket API kunnen LTS al worden opgevraagd met een resolutie van 5 minuten:
https://github.com/home-a...der/websocket_api.py#L164

Ik heb voor EMHASS ook een verzoek openstaan om daar gebruik van te maken:
https://github.com/davidusb-geek/emhass/discussions/511
Daar zit wat python voorbeeldcode bij.

Ik vrees dat de websocket api niet verder terug gaat dan de standaard 10 dagen opslag van de standaard entities van HA (opslag per 5 minuten in de statistics-short-term tabel).
De sensoren van de long term statistics worden in de statistics tabel eens per uur met hun oplopende meterstand opgeslagen. Misschien dat de websocket api met interpolatie de tussenliggende verbruiken berekent. Maar dan is de meerwaarde gering..
Meer info hierover:
https://data.home-assistant.io/docs/statistics/

Ik heb in DAO een sql-alchemy-query gemaakt die uit die meterstanden direct de historische verbruiken van de sensoren berekent.

[Los Tigros]

Heb deze post even veranderd. Mijn initiele probleem is verholpen. Had een automatisering die de andere ongedaan maakte

Ik heb net mijn database omgezet naar Maria DB via de addon. Home assistant draait prima. De addon ook maar de database_da geeft 2025-09-03 16:35:25 78 [Warning] Access denied for user 'day_ahead'@'fd0c:ac1e:2100::b' (using password: YES)

Is er een wachtwoord wat ik in moet stellen? Heb excact de documentatie gevolgd maar lukt me niet die database ook via Maria DB te laten lopen.

Iemand de gouden tip? Heb al wat configs die eerder zijn geplakt maar geen succes. Dank!

UPDATE: Ik moest blijkbaar zelf nog de database en een user aanmaken via PHP Admin. Dit kon ik niet opmaken uit de documentatie. Waarschijnlijk logisch maar is nu dus gelukt!

[ Voor 100% gewijzigd door Los Tigros op 03-09-2025 17:25 . Reden: Update ]

[Bravo]

Voor een kennis ben ik bezig om te inventariseren wat de resultaten van een batterij zouden kunnen zijn en hiervoor misbruik ik DAO om wat grafiekjes te kunnen maken van een doorsnee dag om de impact van verschillende variabelen (vermogen batterij, vermogen netaansluiting, capaciteit batterij) te kunnen tonen.

Nu valt mij op dat de waarde "Winst" afhankelijk is van de grootte van de batterij, en niet van de import/export totalen.
Even doordenkend is mijn hypothese dat de hoeveelheid energie in de batterij ook een waarde wordt toegekend, wat op mij arbitrair overkomt, want je hebt geen flauw idee wat die waarde zou worden als je het gebruik en de tarieven niet weet. Aan de andere kant moet je vast een waarde voor de in de batterij opgeslagen energie hebben, omdat de optimizer anders er niet mee kan rekenen?

@KC27 Klopt mijn veronderstelling? En wat is de aangenomen waarde voor een kWh in de batterij?
Dit is vast ook de drijfveer dat DAO de batterij iedere run het liefst een keer op 100% SOC wil hebben (mits haalbaar met PV productie)?

[KC27]

Bravo schreef op donderdag 4 september 2025 @ 08:38:
Voor een kennis ben ik bezig om te inventariseren wat de resultaten van een batterij zouden kunnen zijn en hiervoor misbruik ik DAO om wat grafiekjes te kunnen maken van een doorsnee dag om de impact van verschillende variabelen (vermogen batterij, vermogen netaansluiting, capaciteit batterij) te kunnen tonen.

Nu valt mij op dat de waarde "Winst" afhankelijk is van de grootte van de batterij, en niet van de import/export totalen.
Even doordenkend is mijn hypothese dat de hoeveelheid energie in de batterij ook een waarde wordt toegekend, wat op mij arbitrair overkomt, want je hebt geen flauw idee wat die waarde zou worden als je het gebruik en de tarieven niet weet. Aan de andere kant moet je vast een waarde voor de in de batterij opgeslagen energie hebben, omdat de optimizer anders er niet mee kan rekenen?

@KC27 Klopt mijn veronderstelling? En wat is de aangenomen waarde voor een kWh in de batterij?
Dit is vast ook de drijfveer dat DAO de batterij iedere run het liefst een keer op 100% SOC wil hebben (mits haalbaar met PV productie)?

[Afbeelding]

Het klopt dat aan de inhoud van de batterij een waarde wordt toegekend, zou dat niet gebeuren dan wordt deze altijd "leeg getrokken" op het eind.
De waarde wordt bepaald door de inhoud (omgerekend naar kWh) te waarderen op het gemiddelde leveringstarief.

[Bravo]

KC27 schreef op donderdag 4 september 2025 @ 09:43:
[...]

Het klopt dat aan de inhoud van de batterij een waarde wordt toegekend, zou dat niet gebeuren dan wordt deze altijd "leeg getrokken" op het eind.
De waarde wordt bepaald door de inhoud (omgerekend naar kWh) te waarderen op het gemiddelde leveringstarief.

Oeh, dat tikt wel aan aan in de winst. Iedere kWh die je in de batterij stopt ipv aan het net levert bij een markttarief van 0 ct/kWh wordt dan opeens 24 ct/kWh waard in mijn voorbeeld. Terwijl je met levering uit de batterijen op een later moment om je verbruik te dekken alleen het verschil tussen inkoop en verkoopkosten terughaald (in mijn 2027 instellingen 14 ct/kWh).

Goed om te weten, dan gebruik ik die waarde niet bij de vergelijking.

[Torch1969]

Bravo schreef op donderdag 4 september 2025 @ 08:38:
Voor een kennis ben ik bezig om te inventariseren wat de resultaten van een batterij zouden kunnen zijn en hiervoor misbruik ik DAO om wat grafiekjes te kunnen maken van een doorsnee dag om de impact van verschillende variabelen (vermogen batterij, vermogen netaansluiting, capaciteit batterij) te kunnen tonen.

Nu valt mij op dat de waarde "Winst" afhankelijk is van de grootte van de batterij, en niet van de import/export totalen.
Even doordenkend is mijn hypothese dat de hoeveelheid energie in de batterij ook een waarde wordt toegekend, wat op mij arbitrair overkomt, want je hebt geen flauw idee wat die waarde zou worden als je het gebruik en de tarieven niet weet. Aan de andere kant moet je vast een waarde voor de in de batterij opgeslagen energie hebben, omdat de optimizer anders er niet mee kan rekenen?

@KC27 Klopt mijn veronderstelling? En wat is de aangenomen waarde voor een kWh in de batterij?
Dit is vast ook de drijfveer dat DAO de batterij iedere run het liefst een keer op 100% SOC wil hebben (mits haalbaar met PV productie)?

[Afbeelding]

Even uit interesse, waarom zo’n “belachelijk” (sorry, mijn oordeel ;-) ) grote batterij overwegen als je weet dat saldering in 2027 wegvalt en teruglevering pas interessant wordt als de terugleverprijs (zonder energie belasting) hoger is dan de prijs waartegen geladen is en/of zonopwek overschot aanwezig is? Ik kan me best voorstellen dat je die 160kWh in de loop van dagen wel vol krijgt met zon opwek overschot, maar waar laat je het dan daarna?
Welke use cases zie ik hier over het hoofd?

[Torch1969]

Bravo schreef op donderdag 4 september 2025 @ 09:57:
[...]

Oeh, dat tikt wel aan aan in de winst. Iedere kWh die je in de batterij stopt ipv aan het net levert bij een markttarief van 0 ct/kWh wordt dan opeens 24 ct/kWh waard in mijn voorbeeld. Terwijl je met levering uit de batterijen op een later moment om je verbruik te dekken alleen het verschil tussen inkoop en verkoopkosten terughaald (in mijn 2027 instellingen 14 ct/kWh).

Goed om te weten, dan gebruik ik die waarde niet bij de vergelijking.

Tja, aan de andere kant drukte het laten zitten van die kWh in de batterij wel de winst op de dag dat er geladen is. Daarom is het vergelijken van winst per simulatie periode lastig voor een proces dat over dagen heen werkt en wijzigt….. uiteindelijk weet je het pas achteraf als de batterij leeg is en je een report maakt over de afgelopen periode.

[Bravo]

Torch1969 schreef op donderdag 4 september 2025 @ 12:41:
[...]

Even uit interesse, waarom zo’n “belachelijk” (sorry, mijn oordeel ;-) ) grote batterij overwegen als je weet dat saldering in 2027 wegvalt en teruglevering pas interessant wordt als de terugleverprijs (zonder energie belasting) hoger is dan de prijs waartegen geladen is en/of zonopwek overschot aanwezig is? Ik kan me best voorstellen dat je die 160kWh in de loop van dagen wel vol krijgt met zon opwek overschot, maar waar laat je het dan daarna?
Welke use cases zie ik hier over het hoofd?

Het (basis)verbruik van 4-25 kW was nog niet in de grafiek opgenomen
Het gaat niet om een woonhuissituatie, maar een bedrijfssituatie met >30 kWp aan PV en seizoensvariabele belasting (meer in voorjaar/zomer, heel veel minder in de winter). In delen van het jaar is er sprake van enorme overproductie die nu met salderen het verbruik compleet wegstreept. Dat zal na 2027 niet meer het geval zijn, mogelijk kan een investering in batterijen die pijn verzachten.
En peakshaving met de batterijen is ook een kostendrukker als het aansluittarief kan halveren (of meer).

En juist zo'n grafiekje laat zien dat bigger niet altijd better is, al kun je in de zonnige maanden zonder PV-curtailing wel de 0/negatieve uren opvangen om later op de markt te zetten.

[ Voor 3% gewijzigd door Bravo op 04-09-2025 13:30 ]

[Bravo]

Torch1969 schreef op donderdag 4 september 2025 @ 12:53:
[...]

Tja, aan de andere kant drukte het laten zitten van die kWh in de batterij wel de winst op de dag dat er geladen is. Daarom is het vergelijken van winst per simulatie periode lastig voor een proces dat over dagen heen werkt en wijzigt….. uiteindelijk weet je het pas achteraf als de batterij leeg is en je een report maakt over de afgelopen periode.

Klopt, maar als je de minimaliseer consumptie modus gebruikt (die vrijwel hetzelfde resultaat geeft als minimal cost met bij een delta van 14 ct tussen inkoop- en verkooptarief), dan is de waarde 14 ct. Tenzij je het nog als overtollige energie op de markt kunt zetten, dan wordt het weer variabel. Maar het zal nooit de waarde verkrijgen van het gemiddelde levertarief.

edit: ja, ik besef me dat bij de Energiebelasting minder wordt bij >10.001 kWh afname, dus dat die 14 ct dan ook minder wordt.

[ Voor 7% gewijzigd door Bravo op 04-09-2025 13:25 ]

[KC27]

Bravo schreef op donderdag 4 september 2025 @ 09:57:
[...]

Oeh, dat tikt wel aan aan in de winst. Iedere kWh die je in de batterij stopt ipv aan het net levert bij een markttarief van 0 ct/kWh wordt dan opeens 24 ct/kWh waard in mijn voorbeeld. Terwijl je met levering uit de batterijen op een later moment om je verbruik te dekken alleen het verschil tussen inkoop en verkoopkosten terughaald (in mijn 2027 instellingen 14 ct/kWh).

Goed om te weten, dan gebruik ik die waarde niet bij de vergelijking.

Ik moet mijn reactie nog een beetje nuanceren:

• De inhoud wordt berekend door deze te corrigeren met de gemiddelde omzet verliezen vanaf de batterij tot aan AC. Dus netto AC levering.
• Als je salderen op false hebt staan dan wordt gerekend met de gemiddelde teruglevering tarieven

.

[Batavia]

Kan je bij een machine opgeven dat hij over de daggrens heen moet kijken?

Ik heb nu een Shelly schakelaar als machine met een tijdswindow van 13:00-6:00 maar hij maakt er 6:00-13:00 van.

[Hedzie]

@KC27
Had je hier al eens een blik op kunnen werpen?

Hedzie schreef op zaterdag 30 augustus 2025 @ 20:22:
Ik heb inmiddels de EV geconfigureerd in DAO.

Wat ik niet helemaal begrijp is waarom DAO nu elk uur een beetje wil laden.
Is het niet voordeliger om vanaf bijv. 03.00u vannacht te gaan laden?

En zet je in je automatisering dat de batterijen naar 0 moeten tijdens het laden van de EV?


[...]


[...]


[Afbeelding]

[KC27]

Hedzie schreef op donderdag 4 september 2025 @ 18:46:
@KC27
Had je hier al eens een blik op kunnen werpen?


[...]

Sorry, ik dacht dat ik gereageerd had, maar door de drukte helaas vergeten.

Je hebt als strategie:minimize consumption.
Dat betekent dat daar alles voor moet wijken.
Zeker als je dan ook nog eens je auto gaat laden.
Het ontladen van de batterij en het laden van de auto gaat overall net iets efficiënter bij het lage vermogen.

En zet je in je automatisering dat de batterijen naar 0 moeten tijdens het laden van de EV?

Je bedoelt dat DAO dat moet doen of wil je dat in HA regelen.
In DAO is er (nog) geen speciale setting dat het laden van de auto niet vanuit de thuisbatterij mag (wel een goede tip).
Als DAO dat toch moet doen zou ik kiezen voor de strategie: minimize cost.
Dan wordt de auto opgeladen bij het laagste tarief, alleen heb je dan geen "nul op de meter" tijdens de andere uren.
Of je houdt de auto buiten DAO.
Als je het in HA wilt regelen kun je een automation maken die getriggerd wordt door "verbruik op de laadpaal".
Deze laat je het ontlaadvermogen van je Sessy's dan maximeren op 0 (ze mogen nog wel laden).

[KC27]

Batavia schreef op donderdag 4 september 2025 @ 18:26:
Kan je bij een machine opgeven dat hij over de daggrens heen moet kijken?

Ik heb nu een Shelly schakelaar als machine met een tijdswindow van 13:00-6:00 maar hij maakt er 6:00-13:00 van.

Dat zou wel moeten werken.
Ik ga er nog eens naar kijken.

[Ferrox1]

Ik wilde DAO in mijn docker updaten. Alleen loop tegen een probleem aan.

1 probleem is dat libnauty2-dev is veranderd in libnauty-dev. Die was redelijk simpel
Echter de 2e krijg ik niet opgelost en gaat voor mij te diep: libcholmod3 geeft de volgende error:
Unable to locate package libcholmod3

Ik heb gegraven naar een oplossing op het internet om te committen, maar krijg die niet gevonden. Wellicht dat iemand (@KC27 ?) hier een oplossing weet?

Als het nodig is kan ik ook een issue en een commit aanmaken op github.

[Torch1969]

Ferrox1 schreef op donderdag 4 september 2025 @ 21:08:
Ik wilde DAO in mijn docker updaten. Alleen loop tegen een probleem aan.

1 probleem is dat libnauty2-dev is veranderd in libnauty-dev. Die was redelijk simpel
Echter de 2e krijg ik niet opgelost en gaat voor mij te diep: libcholmod3 geeft de volgende error:
Unable to locate package libcholmod3

Ik heb gegraven naar een oplossing op het internet om te committen, maar krijg die niet gevonden. Wellicht dat iemand (@KC27 ?) hier een oplossing weet?

Als het nodig is kan ik ook een issue en een commit aanmaken op github.

Je kunt dao inmiddels met een complete docker image installeren: https://github.com/cornee...iguratie#docker-container

[Ferrox1]

Torch1969 schreef op donderdag 4 september 2025 @ 21:12:
[...]

Je kunt dao inmiddels met een complete docker image installeren: https://github.com/cornee...iguratie#docker-container

Ahhh die staat in de wiki!

Thanks, ga ik morgen even aanpassen.

[KC27]

Batavia schreef op donderdag 4 september 2025 @ 18:26:
Kan je bij een machine opgeven dat hij over de daggrens heen moet kijken?

Ik heb nu een Shelly schakelaar als machine met een tijdswindow van 13:00-6:00 maar hij maakt er 6:00-13:00 van.

Ik krijg het niet nagedaan.
Heb je voor mij (als quotes):
Kopie van je settings
Kopie van de logging van de berekening
Plaatje van je opgave ( zoals dit):

[Ferrox1]

diamanten schreef op zaterdag 5 juli 2025 @ 20:28:
[...]

OK, dank voor je uitleg!

Trouwens ik ben ook geinteresseerd in het toevoegen van een airco-optie in dao.
Ik maak gebruik van de mitsubishi addon:
https://github.com/jeatheak/Mitsubishi-WF-RAC-Integration/
met ondermeer deze sensor.airco_xxxxx_energy_usage_cycle: energie in kWh.
Momenteel heb ik een quick&dirty oplossing gemaakt door een machine aan te maken (zie ook mijn eerdere posts):

code:

  "machines" : [ 
      { "name": "Airco",
        "programs":[
          {"name": "Uit",
           "power": []},
          {"name": "Auto",
           "power": [1000, 1000, 1000, 1000, 1000, 1000, 1000, 800, 600]
           }
        ],
        "entity start window": "input_datetime.start_window_airco",
        "entity end window": "input_datetime.eind_window_airco",
        "entity selected program": "input_select.airco_programma",
        "entity calculated start": "input_datetime.berekende_start_airco",
        "entity calculated end": "input_datetime.berekende_stop_airco"
      }
  ],

Als ik het goed begrijp staat hij altijd bij jou 2 uur en een kwartier aan, of geld die laatste dan voor de rest tot einde stoken?

Ik ben daar nu ook mee aan het stoeien, om de airco's er in te zetten. Maar dat is lastiger dan je in eerste instantie denkt. Het enige metric die ik heb is het verbruik van de airco in kw. Hoeveel dit oplevert in warmte is lastig (theorie 5kW). Ook ligt het verbruik bij koudere temperaturen hoger dan bij 16 graden bijvoorbeeld.

Wat ik wel weet is dat de volgende berekening bestaat om enigsinds een idee te krijgen wat je nodig hebt om op tijd je doel temperatuur te halen: (even geleend van een ander forum)

dT/dt = = (P - UA*(T - To))/W = (P + UA*To)/W - (UA/W)*T

waarin W = warmtecapaciteit van kamerlucht+muren+meubilair in J/K
P is toegevoerd constante vermogen in Watt,
T en To in oC of K,
UA is in W/K,
en t is in seconden.
(alles in SI eenheden dus)

Dit is te berekenen, maar ik heb dit ook aan de hand van data moeten uitvinden. Vooral de constanten bepalen is lastig. Dit is het resultaat voor mijn huis en klopt vrij aardig:
Temperatuurtoename =
(gewenste temperatuur – huidige binnentemperatuur)
gedeeld door
((beschikbaar stookvermogen – 156,9 × (huidige binnentemperatuur – buitentemperatuur)) ÷ 5.435.100)

Volledige Yaml:

YAML:

        {%set tempdifference = states.input_number.wens_temperatuur2.state |float -0.5 - states.sensor.temperatuur_beneden.state | float %}
        {%set tempincreasepersecond = (states.sensor.beschikbaar_stookvermogen.state|float - 156.9 *
        (states.sensor.temperatuur_beneden.state |float
        - states.sensor.buienradar_temperature.state |float ))/ 5435100%}
        {%set prewarmingseconds = tempdifference/tempincreasepersecond %}
        {%if prewarmingseconds < 0 %}
          {%set prewarmingseconds = 0%}
        {%endif%}
        {{ prewarmingseconds|round(0)}}

Let op, die constanten verschillen per huis en installatie!

Daarna heb je alleen het warmte vermogen nodig om de lekverliezen te compenseren en zou de airco in theorie terug gaan regelen. Wat mooi zou zijn is dat er dus een heater is die kijkt naar de doeltemperatuur en probeert dit op de meest efficiente manier te bereiken. Dit kan dus betekenen dat de airco gaat stoken rond 12:00 (lekker goedkoop) om het warm te hebben om 17:00 om daarna op laag verbruik door te pruttelen. Al is dit ook weer relevant aan de temperatuur buiten, want het kan zomaar zijn dat die zo hard keldert dat de airco alsnog hard moet werken (of buitenunit ontdooien) wat de eerdere start mogelijk teniet doet.

Ook ik heb de COP niet beschikbaar als variabele. Ik zat ook te denken, als DAO nou kan "leren" van de curves (Verbruik Airco, Temperatuur in huis, Temperatuur buiten) zou hij na een aantal keer dit zelf moeten kunnen bepalen? (eigenlijk netzoals de baseload berekening)

[ Voor 8% gewijzigd door Ferrox1 op 05-09-2025 15:19 ]

[Hedzie]

KC27 schreef op donderdag 4 september 2025 @ 19:44:
[...]

Sorry, ik dacht dat ik gereageerd had, maar door de drukte helaas vergeten.

Je hebt als strategie:minimize consumption.
Dat betekent dat daar alles voor moet wijken.
Zeker als je dan ook nog eens je auto gaat laden.
Het ontladen van de batterij en het laden van de auto gaat overall net iets efficiënter bij het lage vermogen.


[...]

Je bedoelt dat DAO dat moet doen of wil je dat in HA regelen.
In DAO is er (nog) geen speciale setting dat het laden van de auto niet vanuit de thuisbatterij mag (wel een goede tip).
Als DAO dat toch moet doen zou ik kiezen voor de strategie: minimize cost.
Dan wordt de auto opgeladen bij het laagste tarief, alleen heb je dan geen "nul op de meter" tijdens de andere uren.
Of je houdt de auto buiten DAO.
Als je het in HA wilt regelen kun je een automation maken die getriggerd wordt door "verbruik op de laadpaal".
Deze laat je het ontlaadvermogen van je Sessy's dan maximeren op 0 (ze mogen nog wel laden).

Is er een api waarmee je de strategie kunt wijzigen?

[KC27]

Hedzie schreef op zaterdag 6 september 2025 @ 09:48:
[...]


Is er een api waarmee je de strategie kunt wijzigen?

Nee niet met een api, wel via je settings. Dus dat wordt een handmatige aanpassing.

[diamanten]

Ferrox1 schreef op vrijdag 5 september 2025 @ 15:11:
[...]

Als ik het goed begrijp staat hij altijd bij jou 2 uur en een kwartier aan, of geld die laatste dan voor de rest tot einde stoken?

Ik ben daar nu ook mee aan het stoeien, om de airco's er in te zetten. Maar dat is lastiger dan je in eerste instantie denkt. Het enige metric die ik heb is het verbruik van de airco in kw. Hoeveel dit oplevert in warmte is lastig (theorie 5kW). Ook ligt het verbruik bij koudere temperaturen hoger dan bij 16 graden bijvoorbeeld.

Wat ik wel weet is dat de volgende berekening bestaat om enigsinds een idee te krijgen wat je nodig hebt om op tijd je doel temperatuur te halen: (even geleend van een ander forum)

dT/dt = = (P - UA*(T - To))/W = (P + UA*To)/W - (UA/W)*T

waarin W = warmtecapaciteit van kamerlucht+muren+meubilair in J/K
P is toegevoerd constante vermogen in Watt,
T en To in oC of K,
UA is in W/K,
en t is in seconden.
(alles in SI eenheden dus)

Dit is te berekenen, maar ik heb dit ook aan de hand van data moeten uitvinden. Vooral de constanten bepalen is lastig. Dit is het resultaat voor mijn huis en klopt vrij aardig:
Temperatuurtoename =
(gewenste temperatuur – huidige binnentemperatuur)
gedeeld door
((beschikbaar stookvermogen – 156,9 × (huidige binnentemperatuur – buitentemperatuur)) ÷ 5.435.100)

Volledige Yaml:

YAML:

        {%set tempdifference = states.input_number.wens_temperatuur2.state |float -0.5 - states.sensor.temperatuur_beneden.state | float %}
        {%set tempincreasepersecond = (states.sensor.beschikbaar_stookvermogen.state|float - 156.9 *
        (states.sensor.temperatuur_beneden.state |float
        - states.sensor.buienradar_temperature.state |float ))/ 5435100%}
        {%set prewarmingseconds = tempdifference/tempincreasepersecond %}
        {%if prewarmingseconds < 0 %}
          {%set prewarmingseconds = 0%}
        {%endif%}
        {{ prewarmingseconds|round(0)}}

Let op, die constanten verschillen per huis en installatie!

Daarna heb je alleen het warmte vermogen nodig om de lekverliezen te compenseren en zou de airco in theorie terug gaan regelen. Wat mooi zou zijn is dat er dus een heater is die kijkt naar de doeltemperatuur en probeert dit op de meest efficiente manier te bereiken. Dit kan dus betekenen dat de airco gaat stoken rond 12:00 (lekker goedkoop) om het warm te hebben om 17:00 om daarna op laag verbruik door te pruttelen. Al is dit ook weer relevant aan de temperatuur buiten, want het kan zomaar zijn dat die zo hard keldert dat de airco alsnog hard moet werken (of buitenunit ontdooien) wat de eerdere start mogelijk teniet doet.

Ook ik heb de COP niet beschikbaar als variabele. Ik zat ook te denken, als DAO nou kan "leren" van de curves (Verbruik Airco, Temperatuur in huis, Temperatuur buiten) zou hij na een aantal keer dit zelf moeten kunnen bepalen? (eigenlijk netzoals de baseload berekening)

Ja, mijn oplossing is niet geavanceerd en zet de airco inderdaad 2 uur en 15 minuten aan. Jouw oplossing is veel mooier, Hoe kom je precies aan de waarden van de constanten?