Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[konehead]

konehead schreef op vrijdag 30 mei 2025 @ 20:10:
Vandaag ging het laden helemaal goed, en om 19h/20h had ik verwacht dat hij zou gaan ontladen.. helaas. Vanaf drie uur werd het terug te laden volume steeds kleiner. Zie plaatje 1, 2 en 3. Terwijl de batterij om 17h helemaal vol zat.

Wat doe ik nu verkeerd? Voor de simulatie heb ik de efficiency netjes aangepast. Hij zou nu alles toch op het net moeten zetten vanaf 19h/20h?

[Afbeelding]

[Afbeelding]

[Afbeelding]

code:

2025-05-30 20:15:26 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.00   0.26   0.00   0.35   0.00   0.00   0.00   0.00   0.08   -0.00  20.00
 21.00    0.00     0.42   0.00   0.12   0.30   0.00   0.00   0.00   0.00   0.00   -0.04  20.00
 22.00    0.00     0.00   0.27   0.00   0.27   0.00   0.00   0.00   0.00   0.08   -0.00  20.00
 23.00    0.00     0.00   0.24   0.00   0.24   0.00   0.00   0.00   0.00   0.07   -0.00  20.00
  0.00    0.00     0.00   1.58   0.00   1.58   0.00   0.00   0.00   0.00   0.44   -0.00  20.00
  1.00    0.00     0.00   0.98   0.00   0.98   0.00   0.00   0.00   0.00   0.26   -0.00  20.00
  2.00    0.00     0.00   0.25   0.00   0.25   0.00   0.00   0.00   0.00   0.07   -0.00  20.00
  3.00    0.00     0.00   0.25   0.00   0.25   0.00   0.00   0.00   0.00   0.07   -0.00  20.00
  4.00    0.00     0.00   0.24   0.00   0.24   0.00   0.00   0.00   0.00   0.06   -0.00  20.00
  5.00    0.00     0.01   0.24   0.00   0.25   0.00   0.00   0.00   0.00   0.06   -0.00  20.00
  6.00    0.00     0.07   0.25   0.00   0.33   0.00   0.00   0.00   0.00   0.07   -0.00  20.00
  7.00    0.00     0.17   0.43   0.00   0.60   0.00   0.00   0.00   0.00   0.11   -0.00  20.00
  8.00    0.00     0.37   0.00   0.02   0.35   0.00   0.00   0.00   0.00   0.00   -0.00  20.00
  9.00    0.00     0.43   0.00   0.04   0.39   0.00   0.00   0.00   0.00   0.00   -0.01  20.00
 10.00    0.00     0.94   0.00   0.46   0.48   0.00   0.00   0.00   0.00   0.00   -0.07  20.00
 11.00    0.00     0.00   0.51   0.00   0.51   0.00   0.00   0.00   0.00   0.08    0.00  20.00
 12.00    0.00     0.00   1.07   0.00   1.07   0.00   0.00   0.00   0.00   0.16    0.00  20.00
 13.00    0.00     0.00   2.08   0.00   2.08   0.00   0.00   0.00   0.00   0.28    0.00  20.00
 14.00    0.00     0.00   2.04   0.00   2.04   0.00   0.00   0.00   0.00   0.29    0.00  20.00
 15.00    0.00     0.00   2.40   0.00   2.40   0.00   0.00   0.00   0.00   0.36    0.00  20.00
 16.00    0.00     0.45   1.69   0.00   2.14   0.00   0.00   0.00   0.00   0.26    0.00  20.00
 17.00    0.00     1.13   0.00   0.72   0.41   0.00   0.00   0.00   0.00   0.00   -0.14  20.00
 18.00    0.00     0.77   0.00   0.01   0.76   0.00   0.00   0.00   0.00   0.00   -0.00  20.00
 19.00    0.00     2.42   0.00   2.10   0.32   0.00   0.00   0.00   0.00   0.00   -0.65  20.00
 20.00    0.00     2.76   0.00   2.50   0.26   0.00   0.00   0.00   0.00   0.00   -0.96  20.00
 21.00    0.00     2.76   0.00   2.47   0.29   0.00   0.00   0.00   0.00   0.00   -0.95  20.00
 22.00    0.00     2.76   0.00   2.52   0.24   0.00   0.00   0.00   0.00   0.00   -0.80  20.00
 23.00    0.00     0.00   0.21   0.00   0.21   0.00   0.00   0.00   0.00   0.06   -0.00  20.00
Totaal    0.00    15.47  15.00  10.97  19.59   0.00   0.00   0.00   0.00   2.86   -3.63       
2025-05-30 20:15:26 info: Winst: € 2.12
2025-05-30 20:15:26 info: Doorzetten van alle settings naar HA
2025-05-30 20:15:26 info: Grid set point: 346.0 W
2025-05-30 20:15:26 info: Cycle cost Simulatie: 0.00 euro
2025-05-30 20:15:26 info: Netto vermogen naar(+)/uit(-) omvormer Simulatie: 0 W
2025-05-30 20:15:26 info: Balanceren: False
2025-05-30 20:15:26 info: Vermogen uit batterij: -125W
2025-05-30 20:15:26 info: Vermogen dat binnenkomt van pv: 125W
2025-05-30 20:15:26 info: Vermogen dat binnenkomt van ac: 0W
2025-05-30 20:15:26 info: Waarde SoC na eerste uur: 13.3%
2025-05-30 20:15:26 info: Waarde SoC na eerste uur: 13.3%

code:

    "battery": [
        {
            "name": "Simulatie",
            "entity actual level": "sensor.battery_sim_growatt_test",
            "capacity": 12.6,
            "upper limit": 100,
            "lower limit": 10,
            "minimum power": 500,
            "dc_to_bat efficiency": 0.98,
            "bat_to_dc efficiency": 0.99,
            "cycle cost": 0.00,
            "entity set power feedin": "input_number.dao_set_power_feedin",
            "entity set operating mode": "input_select.dao_bat_sim_operating_mode",
            "entity stop inverter": "input_datetime.dao_stop_inverter",
            "entity balance switch": "input_boolean.dao_balance_switch",
            "entity calculated soc": "input_number.dao_entity_calculated_soc",
            "entity from pv": "input_number.dao_from_pv",
            "entity from ac": "input_number.dao_from_ac",
            "entity from battery": "input_number.dao_from_battery",
            "solar": [
             {
              "name": "Solar",
              "tilt": 35,
              "orientation": 0,
              "capacity": 3.12,
              "yield": 0.00663,
              "entity pv switch": "input_boolean.dao_pv_enabled"
              }
            ],
            "charge stages": [
                {
                    "power": 0,
                    "efficiency": 1
                },
                {
                    "power": 1000,
                    "efficiency": 0.95
                },
                {
                    "power": 2000,
                    "efficiency": 0.94
                },
                {
                    "power": 3000,
                    "efficiency": 0.93
                }
            ],
            "discharge stages": [
                {
                    "power": 0,
                    "efficiency": 1
                },
                {
                    "power": 1000,
                    "efficiency": 0.94
                },
                {
                    "power": 2000,
                    "efficiency": 0.93
                },
                {
                    "power": 3000,
                    "efficiency": 0.92
                }
            ]
        }
    ],

Sinds 21h is het model aan het ontladen met 500 watt. @KC27 de avond piek qua prijs startte om 19h/20h. Wat had ik moeten instellen zodat hij deze uren volledig zou ontladen? Of heb ik nog steeds iets verkeerd geconfigureerd?

[KC27]

Voor de testers van nieuwe versies:
Er staat een nieuwe testversie op github in de addon-branche: versie 2025.6.0.rc2
Zie de topic start hoe je deze moet installeren.
Belangrijkste wijzigingen:

• aftopping van het vermogen van pv
• verlenging van de prognose van pv (zowel ac en dc) tot 96 uur vooruit
• salderen moet je nu zelf instellen (met "tax refund") en wordt nu goed berekend

Verder bug-fixes en voorbereiding voor de toekomst, zie de uitgebreide changelog.
Graag jullie bevindingen!

[remc1979]

KC27 schreef op vrijdag 30 mei 2025 @ 22:01:
[...]

Als je je warmtepomp niet alleen kunt uitlezen maar ook kunt aansturen vanuit HA. Dan kun je de berekening van de aansturing door DAO laten doen.
Je kunt hiervoor het beste de handleiding (DOCS.md) raadplegen ipv dat ik (of iemand anders ) dat hier ga herhalen.
Als je concrete vragen hebt bij de implementatie dan helpen we je graag.

Dank! Ik heb het document proberen te vinden, maar helaas niet gelukt.

[RudolfR]

@remc1979

Hierzo:
https://github.com/corneel27/day-ahead/blob/main/dao/DOCS.md

[KC27]

konehead schreef op vrijdag 30 mei 2025 @ 22:52:
[...]


Sinds 21h is het model aan het ontladen met 500 watt. @KC27 de avond piek qua prijs startte om 19h/20h. Wat had ik moeten instellen zodat hij deze uren volledig zou ontladen? Of heb ik nog steeds iets verkeerd geconfigureerd?

Om te beginnen zou ik de grafiek met de tarieven aan zetten. Dan krijg je zoiets:

Dan zie je dat hij meer of minder gaat laden en of ontladen bij extremere prijzen en het laden en ontladen juist concentreert naar die uren.
Als je er een logging onderzet neem dan de logging van hetzelfde tijdstip waar ook de grafiek is berekend zodat ze beide aan elkaar kunnen worden gerelateerd.
Als je nog vragen hebt: graag met een nieuwe grafiek en logging. Dan is het voor ons geen zoekplaatje.

[konehead]

KC27 schreef op zaterdag 31 mei 2025 @ 13:39:
[...]

Om te beginnen zou ik de grafiek met de tarieven aan zetten. Dan krijg je zoiets:
[Afbeelding]
Dan zie je dat hij meer of minder gaat laden en of ontladen bij extremere prijzen en het laden en ontladen juist concentreert naar die uren.
Als je er een logging onderzet neem dan de logging van hetzelfde tijdstip waar ook de grafiek is berekend zodat ze beide aan elkaar kunnen worden gerelateerd.
Als je nog vragen hebt: graag met een nieuwe grafiek en logging. Dan is het voor ons geen zoekplaatje.

Fair point qua grafiek en logging. Ik heb de grafieken ook aangepast én nog iets gevonden 'entity actual level' is dus in percentage en niet in kWh. Ik heb een batterij-simulatie draaien en die geeft de SOC weer in KWh en niet %. Met een accu van 12.6 KWh en lower limit van 10 valt er vrij weinig te ontladen Toen ik hier achterkwam was het vrij eenvoudig: ik heb een template sensor aangemaakt welke de SOC uitrekent in %. Nu werkt het model veel beter. @KC27 ik vind je manual al helemaal geweldig, wellicht kan je dit voor de duidelijkheid aangeven dat deze entiteit in % moet weergegeven worden. . Laat dit een dagje dragen en dan ga ik mij weer in de schalen verdiepen obv de accu die ik krijg.

En hierbij het resultaat:

code:

2025-05-31 21:00:00 info: Day Ahead Optimalisering versie: 2025.5.0
2025-05-31 21:00:00 info: Day Ahead Optimalisering gestart op: 31-05-2025 21:00:00
2025-05-31 21:00:00 info: Day Ahead Optimalisatie gestart: 31-05-2025 21:00:00 taak: calc_optimum
2025-05-31 21:00:00 info: Debug = False
2025-05-31 21:00:00 info: Zelf berekende baseload
2025-05-31 21:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    21 2025-05-31 21:00:00   0.38   0.38   0.29   0.02      0
1    22 2025-05-31 22:00:00   0.32   0.32   0.24   0.00      0
2    23 2025-05-31 23:00:00   0.27   0.27   0.21   0.00      0
3     0 2025-06-01 00:00:00   0.27   0.27  -0.58   0.00      0
4     1 2025-06-01 01:00:00   0.26   0.26   0.21   0.00      0
5     2 2025-06-01 02:00:00   0.26   0.26   0.22   0.00      0
6     3 2025-06-01 03:00:00   0.25   0.25   0.21   0.00      0
7     4 2025-06-01 04:00:00   0.25   0.25   0.22   0.00      0
8     5 2025-06-01 05:00:00   0.24   0.24   0.21   0.01      0
9     6 2025-06-01 06:00:00   0.20   0.20   0.30   0.07      0
10    7 2025-06-01 07:00:00   0.17   0.17   0.26   0.16      0
11    8 2025-06-01 08:00:00   0.15   0.15   1.67   0.33      0
12    9 2025-06-01 09:00:00   0.15   0.15   1.97   0.40      0
13   10 2025-06-01 10:00:00   0.15   0.15   1.94   0.41      0
14   11 2025-06-01 11:00:00   0.15   0.15   1.14   1.19      0
15   12 2025-06-01 12:00:00   0.15   0.15   4.76   1.31      0
16   13 2025-06-01 13:00:00   0.14   0.14   5.40   1.13      0
17   14 2025-06-01 14:00:00   0.13   0.13   5.89   1.41      0
18   15 2025-06-01 15:00:00   0.13   0.13   3.07   1.18      0
19   16 2025-06-01 16:00:00   0.14   0.14   1.80   1.17      0
20   17 2025-06-01 17:00:00   0.15   0.15   0.99   1.04      0
21   18 2025-06-01 18:00:00   0.17   0.17   0.86   0.75      0
22   19 2025-06-01 19:00:00   0.24   0.24   0.40   0.40      0
23   20 2025-06-01 20:00:00   0.26   0.26   0.30   0.12      0
24   21 2025-06-01 21:00:00   0.29   0.29   0.28   0.02      0
25   22 2025-06-01 22:00:00   0.28   0.28   0.26   0.00      0
26   23 2025-06-01 23:00:00   0.25   0.25   0.23   0.00      0
2025-05-31 21:00:27 info: Verbruik dit contractjaar: 4521.171 kWh
2025-05-31 21:00:27 info: Productie dit contractjaar: 1705.123 kWh
2025-05-31 21:00:27 info: All taxes refund (alles wordt gesaldeerd)
2025-05-31 21:00:27 info: No reduced hours applied for Simulatie
2025-05-31 21:00:27 info: Startwaarde SoC Simulatie: 58.0%
2025-05-31 21:00:27 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-05-31 21:00:27 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-05-31 21:00:27 info: Strategie: minimale kosten
2025-05-31 21:00:27 info: Het programma heeft een optimale oplossing gevonden.
2025-05-31 21:00:27 info: Geen saldeer correctie
2025-05-31 21:00:27 info: Niet geoptimaliseerd, kosten met reguliere tarieven: 9.40  
2025-05-31 21:00:27 info: Niet geoptimaliseerd, kosten met day ahead tarieven: 3.34  
2025-05-31 21:00:27 info: Geoptimaliseerd, kosten met day ahead tarieven: 1.48  
2025-05-31 21:00:27 info: Levering: 33.29  (kWh)
2025-05-31 21:00:27 info: In- en uitgaande energie per uur batterij Simulatie
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
    21  -2.76  92.00  -3.00   0.00  -3.00  99.00  -3.03  91.08  33.95
    22  -2.75  92.00  -2.99   0.00  -2.99  99.00  -3.02  91.08  10.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     0   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     1   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     2   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     3   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     4   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     5   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     6   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     7   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     8   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     9   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    10   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    11   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    12   1.40  94.43   1.32   0.00   1.32  98.00   1.29  92.54  20.28
    13   3.00  93.00   2.79   0.00   2.79  98.00   2.73  91.14  41.98
    14   3.00  93.00   2.79   0.00   2.79  98.00   2.73  91.14  63.68
    15   3.00  93.00   2.79   0.00   2.79  98.00   2.73  91.14  85.38
    16   2.00  94.00   1.88   0.00   1.88  98.00   1.84  92.12 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    19  -0.07  94.00  -0.08   0.00  -0.08  99.00  -0.08  93.06  99.39
    20  -2.76  92.00  -3.00   0.00  -3.00  99.00  -3.03  91.08  75.34
    21  -2.76  92.00  -3.00   0.00  -3.00  99.00  -3.03  91.08  51.29
    22  -2.76  92.00  -3.00   0.00  -3.00  99.00  -3.03  91.08  27.24
    23  -2.00  93.00  -2.15   0.00  -2.15  99.00  -2.17  92.07  10.00
Totaal  -3.46     --  -5.64   0.00  -5.64     --  -6.05     --       
2025-05-31 21:00:27 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 21.00    0.00     2.76   0.00   2.49   0.29   0.00   0.00   0.00   0.02   0.00   -0.96  20.00
 22.00    0.00     2.75   0.00   2.51   0.24   0.00   0.00   0.00   0.00   0.00   -0.79  20.00
 23.00    0.00     0.00   0.21   0.00   0.21   0.00   0.00   0.00   0.00   0.06   -0.00  20.00
  0.00    0.00     0.00   0.00   0.58  -0.58   0.00   0.00   0.00   0.00   0.00   -0.16  20.00
  1.00    0.00     0.00   0.21   0.00   0.21   0.00   0.00   0.00   0.00   0.05   -0.00  20.00
  2.00    0.00     0.00   0.22   0.00   0.22   0.00   0.00   0.00   0.00   0.06   -0.00  20.00
  3.00    0.00     0.00   0.21   0.00   0.21   0.00   0.00   0.00   0.00   0.05   -0.00  20.00
  4.00    0.00     0.00   0.22   0.00   0.22   0.00   0.00   0.00   0.00   0.06   -0.00  20.00
  5.00    0.00     0.00   0.20   0.00   0.21   0.00   0.00   0.00   0.01   0.05   -0.00  20.00
  6.00    0.00     0.00   0.23   0.00   0.30   0.00   0.00   0.00   0.07   0.05   -0.00  20.00
  7.00    0.00     0.00   0.10   0.00   0.26   0.00   0.00   0.00   0.16   0.02   -0.00  20.00
  8.00    0.00     0.00   1.35   0.00   1.67   0.00   0.00   0.00   0.33   0.21   -0.00  20.00
  9.00    0.00     0.00   1.57   0.00   1.97   0.00   0.00   0.00   0.40   0.24    0.00  20.00
 10.00    0.00     0.00   1.53   0.00   1.94   0.00   0.00   0.00   0.41   0.23    0.00  20.00
 11.00    0.00     0.00   0.00   0.05   1.14   0.00   0.00   0.00   1.19   0.00   -0.01  20.00
 12.00    1.40     0.00   4.85   0.00   4.76   0.00   0.00   0.00   1.31   0.71    0.00  20.00
 13.00    3.00     0.00   7.27   0.00   5.40   0.00   0.00   0.00   1.13   0.99    0.00  20.00
 14.00    3.00     0.00   7.48   0.00   5.89   0.00   0.00   0.00   1.41   0.95    0.00  20.00
 15.00    3.00     0.00   4.90   0.00   3.07   0.00   0.00   0.00   1.18   0.65    0.00  20.00
 16.00    2.00     0.00   2.63   0.00   1.80   0.00   0.00   0.00   1.17   0.38    0.00  20.00
 17.00    0.00     0.00   0.00   0.05   0.99   0.00   0.00   0.00   1.04   0.00   -0.01  20.00
 18.00    0.00     0.00   0.11   0.00   0.86   0.00   0.00   0.00   0.75   0.02   -0.00  20.00
 19.00    0.00     0.07   0.00   0.08   0.40   0.00   0.00   0.00   0.40   0.00   -0.02  20.00
 20.00    0.00     2.76   0.00   2.57   0.30   0.00   0.00   0.00   0.12   0.00   -0.67  20.00
 21.00    0.00     2.76   0.00   2.50   0.28   0.00   0.00   0.00   0.02   0.00   -0.73  20.00
 22.00    0.00     2.76   0.00   2.51   0.26   0.00   0.00   0.00   0.00   0.00   -0.69  20.00
 23.00    0.00     2.00   0.00   1.77   0.23   0.00   0.00   0.00   0.00   0.00   -0.45  20.00
Totaal   12.40    15.86  33.29  15.11  32.75   0.00   0.00   0.00  11.12   4.77   -4.48       
2025-05-31 21:00:27 info: Winst: € 1.86
2025-05-31 21:00:27 info: Doorzetten van alle settings naar HA
2025-05-31 21:00:28 info: Grid set point: -2491.0 W
2025-05-31 21:00:28 info: Cycle cost Simulatie: 0.00 euro
2025-05-31 21:00:28 info: Netto vermogen naar(+)/uit(-) omvormer Simulatie: -2760 W
2025-05-31 21:00:28 info: Balanceren: False
2025-05-31 21:00:28 info: Vermogen uit batterij: 3000W
2025-05-31 21:00:28 info: Vermogen dat binnenkomt van pv: 0W
2025-05-31 21:00:28 info: Vermogen dat binnenkomt van ac: -3000W
2025-05-31 21:00:28 info: Waarde SoC na eerste uur: 33.9%

[ Voor 87% gewijzigd door konehead op 31-05-2025 21:45 ]

[KC27]

RudolfR schreef op zaterdag 31 mei 2025 @ 11:55:
@remc1979

Hierzo:
https://github.com/corneel27/day-ahead/blob/main/dao/DOCS.md

@remc1979
Je kunt de handleiding ook lezen in HA via Instellingen\Add-ons Je kiest DAO en dan "Documentatie". Deze route heeft wel een groot nadeel: alle verwijzingen werken niet en de plaatjes (grafieken) worden niet getoond:

[sjampeter]

KC27 schreef op donderdag 29 mei 2025 @ 22:53:
[...]

Je kunt eerst (in een rustig uurtje) proberen de backup van HA en DAO op de nieuwe server te zetten en kijken of alles goed werkt (zet daarbij tijdelijk de oude HA-machine en DAO uit).
Als dat niet werkt kun je ook alleen HA terugzetten en DAO opnieuw installeren. Je kunt een sql-export van de DAO-database maken en deze importeren in een nieuw opgezette database. Ook de DAO settings en secrets kun je eenvoudig kopiëren.
Dan hou je wel je DAO-historie en dat gaat ook snel.
Denk je dat dit kan werken?

Ik heb zelf enkele maanden terug HA en DAO overgezet van een Pi4 naar een Pi5. Die Pi5 opzetten (met ssd) was meer werk dan HA en DAO overzetten via een backup (was binnen een uur gebeurd).

rustig uurtje gehad.
ben gewoon volledig gemigreerd op basis van backup.
afgezien van wat kleine issues, draait het prima.
heb ip-adres van nieuwe server hass omgezet naar oude adres hass et voila.
wel komt er 1 foutmelding in log van db-maria welke mij eerder nog niet was opgevallen.
zie onderstaand screenshot.
@KC27 kun jij hier nog iets mee?



edit : deze foutmelding krijg ik enkel bij een "handmatige" run. bij een run volgens schedule (op bijvoorbeeld 13:00, krijg ik geen foutmelding.

[ Voor 4% gewijzigd door sjampeter op 01-06-2025 13:01 ]

[diamanten]

Mooie addon! Ik had problemen met Emhass en ben daarom overgegaan naar DAO.
Ik heb de documentatie gelezen en de boel werkend gekregen, maar heb wat meer guidance nodig bij:

entity set power feedin: entiteit waar je het te laden / ontladen vermogen inzet

Deze sensor moet ik dus zelf aanmaken in HA (neem ik aan), stel:
"entity set power feedin": "input_number.dao_feedin_grid"


Vraag: kunnen daar positieve of negatieve waarden in komen? En zo ja, wat betekent een negatieve waarde? Is dat laden voor de batterij met vermogen X? Zo nee, hoe geef je aan dat de batterij moet laden of ontladen?

[ Voor 11% gewijzigd door diamanten op 01-06-2025 20:38 ]

[konehead]

diamanten schreef op zondag 1 juni 2025 @ 20:37:
Mooie addon! Ik had problemen met Emhass en ben daarom overgegaan naar DAO.
Ik heb de documentatie gelezen en de boel werkend gekregen, maar heb wat meer guidance nodig bij:

entity set power feedin: entiteit waar je het te laden / ontladen vermogen inzet

Deze sensor moet ik dus zelf aanmaken in HA (neem ik aan), stel:
"entity set power feedin": "input_number.dao_feedin_grid"


Vraag: kunnen daar positieve of negatieve waarden in komen? En zo ja, wat betekent een negatieve waarde? Is dat laden voor de batterij met vermogen X? Zo nee, hoe geef je aan dat de batterij moet laden of ontladen?

Welkom. Ik heb het ook draaiend gekregen met de documentatie en hulp van hier. De sensor (helper) input_number.dao_set_power_feedin moet je zelf aanmaken en DAO schrijft daar in met welk vermogen de batterij moet laden (positieve waarden) of juist ontladen (negatieve waarden). Ik heb een automation die deze sensor uitleest obv dao_operating_mode én dao_balance_switch. Zie plaatje hieronder

[KC27]

sjampeter schreef op zondag 1 juni 2025 @ 12:51:
[...]


rustig uurtje gehad.
ben gewoon volledig gemigreerd op basis van backup.
afgezien van wat kleine issues, draait het prima.
heb ip-adres van nieuwe server hass omgezet naar oude adres hass et voila.
wel komt er 1 foutmelding in log van db-maria welke mij eerder nog niet was opgevallen.
zie onderstaand screenshot.
@KC27 kun jij hier nog iets mee?

[Afbeelding]

edit : deze foutmelding krijg ik enkel bij een "handmatige" run. bij een run volgens schedule (op bijvoorbeeld 13:00, krijg ik geen foutmelding.

Goed dat je het rapporteert.
Ik krijg ook dit soort foutmeldingen, ik heb er nooit naar gekeken omdat het liep als een trein.
Ik zal er eens induiken, kijken of ik er iets mee kan en/of moet.

[diamanten]

konehead schreef op zondag 1 juni 2025 @ 20:44:
[...]


Welkom. Ik heb het ook draaiend gekregen met de documentatie en hulp van hier. De sensor (helper) input_number.dao_set_power_feedin moet je zelf aanmaken en DAO schrijft daar in met welk vermogen de batterij moet laden (positieve waarden) of juist ontladen (negatieve waarden). Ik heb een automation die deze sensor uitleest obv dao_operating_mode én dao_balance_switch. Zie plaatje hieronder


[Afbeelding]

OK, dank helder.
Even een check: Nu heb ik 2 accu's van verschillende typen met andere laad/ontlaad commando's. Dus 2 van deze helpers aanmaken?

[KC27]

diamanten schreef op zondag 1 juni 2025 @ 22:11:
[...]

OK, dank helder.
Even een check: Nu heb ik 2 accu's van verschillende typen met andere laad/ontlaad commando's. Dus 2 van deze helpers aanmaken?

Ja moet in jouw geval bij battery ook twee thuisbaterijen definiëren.
Voorbeeld:

code:

"battery": [
    {"name" : "Accu1",
      .......
      alle settings van Accu1
      .....
   },
  {"name" : "Accu2",
      .......
      alle settings van Accu2
      .....
   }
],

De vierkante halen betekenen: een lijst met 0, 1 of meer items
Ieder item begint met een "{" en eindigt met "}"
Je krijgt dan ook voor iedere accu een helper waarin komt te staan met hoeveel W deze moet worden geladen/ontladen.

[sjampeter]

KC27 schreef op zondag 1 juni 2025 @ 21:19:
[...]

Goed dat je het rapporteert.
Ik krijg ook dit soort foutmeldingen, ik heb er nooit naar gekeken omdat het liep als een trein.
Ik zal er eens induiken, kijken of ik er iets mee kan en/of moet.

loopt verder ook als een trein hoor. dus geen probleem voor mij.
zag het voorbij komen bij alle checks dus dacht, ik meld het even

[diamanten]

KC27 schreef op zondag 1 juni 2025 @ 23:53:
[...]

Ja moet in jouw geval bij battery ook twee thuisbaterijen definiëren.
Voorbeeld:

code:

"battery": [
    {"name" : "Accu1",
      .......
      alle settings van Accu1
      .....
   },
  {"name" : "Accu2",
      .......
      alle settings van Accu2
      .....
   }
],

De vierkante halen betekenen: een lijst met 0, 1 of meer items
Ieder item begint met een "{" en eindigt met "}"
Je krijgt dan ook voor iedere accu een helper waarin komt te staan met hoeveel W deze moet worden geladen/ontladen.

Beide staan erin.
Edit:

code:

Logging van bewerking "Optimaliseringsberekening met debug":
2025-06-02 19:53:38 info: Day Ahead Optimalisering versie: 2025.5.0
2025-06-02 19:53:38 info: Day Ahead Optimalisering gestart op: 02-06-2025 19:53:38
2025-06-02 19:53:38 info: Day Ahead Optimalisatie gestart: 02-06-2025 19:53:38 taak: calc_optimum_met_debug
2025-06-02 19:53:39 info: Debug = True
2025-06-02 19:53:39 info: Baseload uit instellingen
2025-06-02 19:53:39 info: Start waarden: 
    uur                tijd      p_l      p_t  base     pv_ac  pv_dc
0    19 2025-06-02 19:00:00  0.28035  0.28035  0.26  0.047172      0
1    20 2025-06-02 20:00:00  0.37679  0.37679  0.22  0.247031      0
2    21 2025-06-02 21:00:00  0.43717  0.43717  0.19  0.067906      0
3    22 2025-06-02 22:00:00  0.32083  0.32083  0.18  0.000000      0
4    23 2025-06-02 23:00:00  0.27636  0.27636  0.16  0.000000      0
5     0 2025-06-03 00:00:00  0.26955  0.26955  0.14  0.000000      0
6     1 2025-06-03 01:00:00  0.26382  0.26382  0.38  0.000000      0
7     2 2025-06-03 02:00:00  0.26144  0.26144  0.26  0.000000      0
8     3 2025-06-03 03:00:00  0.25105  0.25105  0.42  0.000000      0
9     4 2025-06-03 04:00:00  0.24638  0.24638  0.15  0.000000      0
10    5 2025-06-03 05:00:00  0.25878  0.25878  0.12  0.028000      0
11    6 2025-06-03 06:00:00  0.28358  0.28358  0.13  0.398699      0
12    7 2025-06-03 07:00:00  0.27013  0.27013  0.15  0.942148      0
13    8 2025-06-03 08:00:00  0.24132  0.24132  0.23  1.152596      0
14    9 2025-06-03 09:00:00  0.18663  0.18663  0.26  1.446583      0
15   10 2025-06-03 10:00:00  0.14766  0.14766  0.31  1.546069      0
16   11 2025-06-03 11:00:00  0.14524  0.14524  0.32  1.564250      0
17   12 2025-06-03 12:00:00  0.14524  0.14524  0.31  1.467863      0
18   13 2025-06-03 13:00:00  0.14403  0.14403  0.23  1.412215      0
19   14 2025-06-03 14:00:00  0.13556  0.13556  0.26  1.327177      0
20   15 2025-06-03 15:00:00  0.14161  0.14161  0.21  1.025958      0
21   16 2025-06-03 16:00:00  0.14524  0.14524  0.21  0.723219      0
22   17 2025-06-03 17:00:00  0.14778  0.14778  0.54  0.502398      0
23   18 2025-06-03 18:00:00  0.23224  0.23224  0.26  0.476943      0
24   19 2025-06-03 19:00:00  0.26250  0.26250  0.26  0.263652      0
25   20 2025-06-03 20:00:00  0.29745  0.29745  0.22  0.051572      0
26   21 2025-06-03 21:00:00  0.27545  0.27545  0.19  0.007000      0
27   22 2025-06-03 22:00:00  0.27348  0.27348  0.18  0.000000      0
28   23 2025-06-03 23:00:00  0.26064  0.26064  0.16  0.000000      0
2025-06-02 19:53:54 info: Verbruik dit contractjaar: 505.961 kWh
2025-06-02 19:53:54 info: Productie dit contractjaar: 2063.996 kWh
2025-06-02 19:53:54 info: consumption today: 1.7190000000027794 kWh
2025-06-02 19:53:54 info: production today: 43.357999999998356 kWh
2025-06-02 19:53:54 info: verschil: -41.638999999995576 kWh
2025-06-02 19:53:57 info: No reduced hours applied for EvaPower
2025-06-02 19:53:57 info: Startwaarde SoC EvaPower: 100.0%
2025-06-02 19:53:57 info: No reduced hours applied for Delta2Max
2025-06-02 19:53:57 info: Startwaarde SoC Delta2Max: 96.0%
2025-06-02 19:53:58 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-06-02 19:53:58 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-02 19:53:58 waarschuwing: Geen oplossing  voor: minimize cost

Vraag: geen oplossing voor: minimize cost? Ik heb de optie 'salderen' uitgezet. Is hier nog wat aan te configureren want ik lever meer terug dan ik verbruik. Overigens geeft DAO ook geen oplossing voor: minimize consumption.

[ Voor 63% gewijzigd door diamanten op 02-06-2025 20:06 ]

[Mirabis]

Hmm ik loop een beetje vast op "DAO installeren in een aparte container (geen addon)".

Ik heb DAO als losse container op dezelfde host als mijn homeassistant container gedeployed middels een nieuwe portainer stack. homeassistant draait in host network mode. dao heb ik zowel in bridge als host geprobeerd. Ik kan wel bij de instellingen om options/secrets in te vullen en heb dat gedaan. Als ik docker-exec kan ik ook zien dat de volume's goed gemount zijn en het bij de ha database kan.

Echter werkt onderstaande config niet:

code:

  "homeassistant": {
    "protocol api": "http",
    "ip address": "10.0.20.8",
    "ip port": 8123,
    "token": "!secret ha-api-token"
  },

ik krijg onderstaande melding na het klikken op: "Run > Verbruiksgegevens bij Tibber ophalen"

code:

Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3528, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3491, in main
    da_calc = DaCalc("../data/options.json")
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 29, in __init__
    super().__init__(file_name=file_name)
  File "/root/dao/prog/da_base.py", line 93, in __init__
    super().__init__(hassurl=self.hassurl, token=self.hasstoken)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 36, in __init__
    self._assert_api_running()
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 41, in _assert_api_running
    raise ClientError("Home Assistant API is not running.")
hassapi.exceptions.ClientError: Home Assistant API is not running.

Heb al een nieuwe token gemaakt, ander gebruikt adres ingevuld (127.0.0.1) etc. Het reports gedeelte werkt wel en ik kan zien dat het mijn Tibber verbruiksgegevens ophaalt en ook de waarden van mijn Ha entities heeft.

Ik krijg dezelfde error na het klikken op "Optimaliseringsberekening met debug" en andere opties.

[ Voor 8% gewijzigd door Mirabis op 02-06-2025 23:53 ]

[KC27]

Mirabis schreef op maandag 2 juni 2025 @ 23:48:
Hmm ik loop een beetje vast op "DAO installeren in een aparte container (geen addon)".

Ik heb DAO als losse container op dezelfde host als mijn homeassistant container gedeployed middels een nieuwe portainer stack. homeassistant draait in host network mode. dao heb ik zowel in bridge als host geprobeerd. Ik kan wel bij de instellingen om options/secrets in te vullen en heb dat gedaan. Als ik docker-exec kan ik ook zien dat de volume's goed gemount zijn en het bij de ha database kan.

Echter werkt onderstaande config niet:

code:

  "homeassistant": {
    "protocol api": "http",
    "ip address": "10.0.20.8",
    "ip port": 8123,
    "token": "!secret ha-api-token"
  },

ik krijg onderstaande melding na het klikken op: "Run > Verbruiksgegevens bij Tibber ophalen"

code:

Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3528, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3491, in main
    da_calc = DaCalc("../data/options.json")
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 29, in __init__
    super().__init__(file_name=file_name)
  File "/root/dao/prog/da_base.py", line 93, in __init__
    super().__init__(hassurl=self.hassurl, token=self.hasstoken)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 36, in __init__
    self._assert_api_running()
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 41, in _assert_api_running
    raise ClientError("Home Assistant API is not running.")
hassapi.exceptions.ClientError: Home Assistant API is not running.

Heb al een nieuwe token gemaakt, ander gebruikt adres ingevuld (127.0.0.1) etc. Het reports gedeelte werkt wel en ik kan zien dat het mijn Tibber verbruiksgegevens ophaalt en ook de waarden van mijn Ha entities heeft.

Ik krijg dezelfde error na het klikken op "Optimaliseringsberekening met debug" en andere opties.

Misschien het IP-adres gebruiken dat je ook gebruikt in je browser om de gui van Home Assistant te benaderen.

[Mirabis]

KC27 schreef op maandag 2 juni 2025 @ 23:59:
[...]

Misschien het IP-adres gebruiken dat je ook gebruikt in je browser om de gui van Home Assistant te benaderen.

Heb denk ik iets soortgelijks als https://github.com/corneel27/day-ahead/issues/199 . Draai "Home Assistant Container vanuit een Proxmox LXC".

Ik kan homeassistant benaderen via:

• 10.0.20.8 (netwerk beheerd door mijn opnsense host)
• 20.0.20.108 (proxmox internal netwerk tussen lxcs)
• homeassistant.internal. (resolved naar 10.0.20.8
• homeassistant.lab.x.nl (https url via opnsense en haproxy met valid cert).

Geen van alle werken.

Draai ik vanuit mijn HA LXC (dus zelfde host, niet binnen container) een curl dan krijg ik wel resultaat:

code:

curl   -H "Authorization: Bearer eyJhbGciOiJI..."   -H "Content-Type: application/json" http://10.0.20.8:8123/api/states/sun.sun
{"entity_id":"sun.sun","state":"below_horizon","attributes":{"next_dawn":"2025-06-03T02:32:34.439174+00:00","next_dusk":"2025-06-03T20:42:14.395947+00:00","next_midnight":"2025-06-02T23:37:00+00:00","next_noon":"2025-06-03T11:36:54+00:00","next_rising":"2025-06-03T03:21:15.420734+00:00","next_setting":"2025-06-03T19:53:19.296098+00:00","elevation":-12.62,"azimuth":338.31,"rising":false,"friendly_name":"Sun"},"last_changed":"2025-06-02T21:57:08.082793+00:00","last_reported":"2025-06-02T22:05:23.574029+00:00","last_updated":"2025-06-02T22:05:08.083799+00:00","context":{"id":"01JWSATKKK7C6N15XECHSG4SBM","parent_id":null,"user_id":null}}root@homeassistant:~/dao_config#

Doe ik dat vanuit binnen in de DAO container krijg ik ook gewoon valide resultaten:

code:

root@homeassistant:~/dao/prog# curl   -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9....."   -H "Content-Type: application/json" http://10.0.20.8:8123/api/states/sun.sun
{"entity_id":"sun.sun","state":"below_horizon","attributes":{"next_dawn":"2025-06-03T02:32:34.439174+00:00","next_dusk":"2025-06-03T20:42:14.395947+00:00","next_midnight":"2025-06-02T23:37:00+00:00","next_noon":"2025-06-03T11:36:54+00:00","next_rising":"2025-06-03T03:21:15.420734+00:00","next_setting":"2025-06-03T19:53:19.296098+00:00","elevation":-12.62,"azimuth":338.31,"rising":false,"friendly_name":"Sun"},"last_changed":"2025-06-02T21:57:08.082793+00:00","last_reported":"2025-06-02T22:05:23.574029+00:00","last_updated":"2025-06-02T22:05:08.083799+00:00","context":{"id":"01JWSATKKK7C6N15XECHSG4SBM","parent_id":null,"user_id":null}}root@homeassistant:~/dao/prog#

Lijkt dus elders iets niet goed te gaan. Zelfde commando werkt ook voor 20.0.20.108 binnen DAO container.

Volledige config (indien liever op GitHub dan hoor ik dat graag).

code:

{
  "homeassistant": {
    "protocol api": "http",
    "ip address": "10.0.20.8",
    "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": "tibber",
    "entsoe-api-key": "!secret entsoe-api-key",
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23,
    "energy taxes delivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154
    },
    "energy taxes redelivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154
    },
    "cost supplier delivery": {
      "2024-10-25": 0.1255,
      "2025-01-01": 0.12044
    },
    "cost supplier redelivery": {
      "2024-10-25": 0.1255,
      "2025-01-01": 0.12044
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2024-10-25",
    "tax refund": "True"
  },
  "logging level": "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.14, 0.38, 0.26, 0.42, 0.15, 0.12, 0.13, 0.15, 0.23, 0.26, 0.31, 0.32,
    0.31, 0.23, 0.26, 0.21, 0.21, 0.54, 0.26, 0.26, 0.22, 0.19, 0.18, 0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show": "true",
    "prices delivery": "True",
    "prices redelivery": "True",
    "average delivery": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
    "notification entity": "input_text.dao_notificatie",
    "opstarten": "True",
    "berekening": "True",
    "last activity entity": "input_datetime.dao_laatste_activiteit"
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "Marstek Venus-E",
      "entity actual level": "sensor.lilygo_rs485_marstek_battery_state_of_charge",
      "capacity": 5.12,
      "lower limit": 11,
      "upper limit": 100,
      "optimal lower level": 11,
      "charge stages": [
        { "power": 0.0, "efficiency": 1 },
        { "power": 100, "efficiency": 0.5 },
        { "power": 800, "efficiency": 0.89 },
        { "power": 1250, "efficiency": 0.85 },
        { "power": 2500, "efficiency": 0.86 }
      ],
      "discharge stages": [
        { "power": 0.0, "efficiency": 1 },
        { "power": 100, "efficiency": 0.5 },
        { "power": 800, "efficiency": 0.92 },
        { "power": 1250, "efficiency": 0.85 },
        { "power": 2500, "efficiency": 0.88 }
      ],
      "dc_to_bat efficiency:": 0.9,
      "bat_to_dc efficiency": 0.9,
      "cycle cost": 0.054,
      "minimum power": 4,
      "entity set power feedin": "",
      "entity set operating mode": "",
      "entity balance switch": "",
      "entity from ac ": "sensor.energy_socket_power"
    }
  ],
  "boiler": {
    "boiler present": "False"
  },
  "heating": {
    "heater present": "False"
  },
  "solar": [
    {
      "name": "GoodWe Oud",
      "tilt": 40,
      "orientation": 135,
      "capacity": 1,
      "yield": 0.0023375,
      "entity pv switch": "switch.inverter_91000ssn184w0237_switch"
    },
    {
      "name": "Growatt Zuid/West vanaf 11/06/25",
      "tilt": 40,
      "orientation": 135,
      "capacity": 0,
      "yield": 0.01071,
      "entity pv switch": ""
    },
    {
      "name": "pv Noord/Oost vanaf 11/06/25",
      "tilt": 40,
      "orientation": -45,
      "capacity": 0,
      "yield": 0.008925,
      "entity pv switch": ""
    }
  ],
  "electric vehicle": [
    {
      "name":"XPENG G9",
      "capacity": 93.1,
      "entity position":"",
      "entity max amperage":"",
      "charge three phase": "True",
      "charge stages" : [
        {"ampere": 0, "efficiency": 0.00},
        {"ampere": 16, "efficiency": 0.90}
      ],      
      "entity actual level":"",
      "entity plugged in":"",
      "charge states":""
    }


  ],
  "machines": [],
  "tibber": {
    "api_token": "!secret tibber-api-token"
  },
  "report": {
    "entity co2-intensity": ["sensor.co2_signal_co2_intensity"],
    "entities grid consumption": [
      "sensor.p1_meter_energy_import_tariff_1",
      "sensor.p1_meter_energy_import_tariff_2"
    ],
    "entities grid production": [
      "sensor.p1_meter_energy_export_tariff_1",
      "sensor.p1_meter_energy_export_tariff_2"
    ],
    "entities solar production ac": ["sensor.inverter_goodwe_gw1000_ns_energy"],
    "entities solar production dc": [],
    "entities ev consumption": ["sensor.kwh_meter_3_phase_energy_import"],
    "entities battery consumption": [
      "sensor.energy_socket_marstek_energy_import"
    ],
    "entities battery production": [
      "sensor.energy_socket_marstek_energy_export"
    ]
  },
  "scheduler": {
    "0445": "get_meteo_data",
    "0930": "calc_baseloads",
    "1045": "get_meteo_data",
    "0952": "get_tibber_data",
    "1052": "get_tibber_data",
    "1152": "get_tibber_data",
    "1252": "get_tibber_data",
    "1258": "get_day_ahead_prices",
    "1313": "get_day_ahead_prices",
    "1315": "calc_optimum",
    "1328": "get_day_ahead_prices",
    "1330": "calc_optimum",
    "1350": "get_tibber_data",
    "1358": "get_day_ahead_prices",
    "1452": "get_tibber_data",
    "1458": "get_day_ahead_prices",
    "1445": "get_meteo_data",
    "1558": "get_day_ahead_prices",
    "2245": "get_meteo_data",
    "2355": "clean_data",
    "xx00": "calc_optimum"
  }
}

[ Voor 52% gewijzigd door Mirabis op 03-06-2025 00:17 ]

[KC27]

Er staat een typo in je settings, my bad.
Je schrijft (zoals het hoort): ip address, maar dat moet zijn: ip adress (slecht Engels)
Dat verandert met ingang van versie 2025.6.0 (is onderweg) naar host

[Mirabis]

Ah dat was de oplossing. Zal wel MacOS autocorrect zijn die er tussendoor is geglipt. Nu dat de HA connectie werkt kan ik me focussen op de andere fouten (o.a. TypeError: 'NoneType' object is not iterable) ... Voor dat morgen weer een dag. Fijne avond : )

[timenator]

Mirabis schreef op dinsdag 3 juni 2025 @ 00:08:
[...]

code:

  "solar": [
    {
      "name": "GoodWe Oud",
      "tilt": 40,
      "orientation": 135,
      "capacity": 1,
      "yield": 0.0023375,
      "entity pv switch": "switch.inverter_91000ssn184w0237_switch"
    },
    {
      "name": "Growatt Zuid/West vanaf 11/06/25",
      "tilt": 40,
      "orientation": 135,
      "capacity": 0,
      "yield": 0.01071,
      "entity pv switch": ""
    },
    {
      "name": "pv Noord/Oost vanaf 11/06/25",
      "tilt": 40,
      "orientation": -45,
      "capacity": 0,
      "yield": 0.008925,
      "entity pv switch": ""
    }
  ]

Volgens mij kloppen je orientaties van de zonnepanelen ook niet. Als de omschrijvingen kloppen.

Volgens de documentatie in het zuiden 0 graden:
-180(N) ..-90(O)..0(Z) ..90(W)..180(N)

[Mirabis]

Ah zal het straks weer nalopen. De oude set gaat er volgende week af (en nieuwe erop) dus zal dan alles incl. SolCast updaten. Na halve dag debuggen ben ik erachter waarom de batterij niet laadde . de charge en discharge rate volgorde moet van 0 tot x lopen. Wel erg gevoelig qua configuratie zo : )

[sjampeter]

KC27 schreef op donderdag 22 mei 2025 @ 12:09:
@sjampeter @Bravo
Bij het maken van reports wordt de volgende volgorde afgewerkt:

1. Eerst wordt gekeken in de day_ahead database, tabel "values" of er gerealiseerde waarden zijn opgeslagen (bijv opgehaald bij tibber)
2. Voor de uren/dagen dat daar geen waarden zijn gevonden worden data opgehaald uit de HA-database via de gedefinieerde sensoren op "report"
3. Als daar geen sensoren zijn gedefinieerd of er ontbreken waarden dan worden data opgehaald uit de day_ahead database tabel "prognoses".

verder bordurend op deze materie.
ik heb enkele dagen nu alles draaien, echter met geen mogelijkheid krijg ik het rapport kloppend.
onderstaand wat "report" aangeeft van bijvoorbeeld gisteren 2-6-2025

zoals je ziet zou ik totaal 49 kWh geleverd hebben, right?

deze data komt uit onderstaande input

zoals je kunt zien heb ik 4 x input voor verbruik en 4 x input voor levering. ik heb 2 meters welke registreren.

so far so good zou je zeggen.
nu heb ik meerdere bronnen en meters lopen welke aangeven dat dit gewoon niet correct weergegeven wordt in "report"

onderstaand de energiebalans volgens Hass , gevoed met exact dezelfde sensoren


deze data klopt gewoon als een bus.
waarom lukt dit niet in DAO.
zoals je kunt zien is Tibber ook niet ingevuld (geen lid van die club ook overigens)
wat mis ik, wat kan ik nog proberen.
voor nu nog geen drama, maar wil straks met 0 op de meter willen draaien en dan lijkt mij dit wel van belang dat het correct is toch?

[KC27]

sjampeter schreef op dinsdag 3 juni 2025 @ 18:28:
[...]


verder bordurend op deze materie.
ik heb enkele dagen nu alles draaien, echter met geen mogelijkheid krijg ik het rapport kloppend.
onderstaand wat "report" aangeeft van bijvoorbeeld gisteren 2-6-2025
[Afbeelding]
zoals je ziet zou ik totaal 49 kWh geleverd hebben, right?

deze data komt uit onderstaande input
[Afbeelding]
zoals je kunt zien heb ik 4 x input voor verbruik en 4 x input voor levering. ik heb 2 meters welke registreren.

so far so good zou je zeggen.
nu heb ik meerdere bronnen en meters lopen welke aangeven dat dit gewoon niet correct weergegeven wordt in "report"

onderstaand de energiebalans volgens Hass , gevoed met exact dezelfde sensoren
[Afbeelding]

deze data klopt gewoon als een bus.
waarom lukt dit niet in DAO.
zoals je kunt zien is Tibber ook niet ingevuld (geen lid van die club ook overigens)
wat mis ik, wat kan ik nog proberen.
voor nu nog geen drama, maar wil straks met 0 op de meter willen draaien en dan lijkt mij dit wel van belang dat het correct is toch?

Dit zou natuurlijk gewoon goed moeten gaan.
Je kunt kijken waar het fout gaat door bij productie eerst drie meters weg te halen en dan kijken wat er gerapporteerd wordt. En zo verder.
Je kunt ook een van de meters kopiëren naar een niet gebruikte categorie bijv ev.
Vier meters is meer dan standaard en heb ik nog niet getest, zou best nog een bug in kunnen zitten.
Ik hoor het graag wat je vindt.

[KC27]

Wat ook een mogelijkheid is (in ieder geval de moeite waard om te checken): beide P!-meters rapporteren niet alle twee in kWh, maar een van de twee rapporteert in Wh. Ik weet dat HASS daar automatisch voor corrigeert in zijn rapportages, maar DAO doet dat (nog?) niet.

[KC27]

Nieuwe versie is vrijgegeven

Vandaag is versie 2025.6.0 van DAO vrijgegeven.
Dit staat er in de Changelog:

Breaking changes

1. The calculation of the cost and profit with a "regular" energy-supplier is removed.
So you can remove the corresponding settings:

code:

    "regular high" : 0.40,
    "regular low" : 0.35,
    "switch to low": 23,

2. The terms "delivery" and "redelivery" will be exchanged for the more commonly used terms **consumption** and **production**.
This will be done with backwards compatibilty, so you can use the old names, but you get a warning in the logging.
These are the new settings with the new names:

code:

    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },

The **cost supplier** above are for Tibber so please adjust if you have another supplier.

3. The calculation of the consumption and the production (and the tax refund) in the current contractperiod with your provider is removed.
You must set by yourself with the setting : **"tax refund" : "True"** whether the energy tax will be refund or not.

4. The graphics of the prices are adjusted. You can now set the following graphs on (True) or off (False):

code:

    "prices consumption": "True",
    "prices production": "True",
    "prices spot": "True",
    "average consumption": "True"

The "prices production" are only relevant if they differ from "prices consumption".
When you set both "True" and the values are equal, they will be plotted over each other.

5. The VAT (BTW) is now divided in two categories "vat consumption" and "vat production" and so are the settings:
This is done for the Belgian users of DAO wich have a different vat for redelivery but also for the future when tax refund and possible also vat refund
will stop
To keep it backwards compatible the following logic is implemented:
- when "vat consumption" is not found: "vat" will be used
- when "vat production" is not found: "vat consumption" will be used and when that is not found "vat" will be used. <br>

It is recommended for the future to change your settings now.<br>
For instance:

code:

    "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
    },

6. The term **ip adress** in the settings for connecting your Home Assistant machine is deprecated.
Use the term generic term **host** for it in the future (feature request of ebbz)

New features

- Introduction of a new optional setting for your solar strings (ac and dc):
**max power**. With this setting (in kW) you can cap the power of your pv-string with the max power of your inverter(s) (feature request)
- Extend the result of the api-call for pv_ac and pv_dc (this one is new) when invoked with the period "vandaag_en_morgen".
Therefor the period of getting meteo-data is enlarged until 96 hour from "now" (feature request Torch1969 e.a)

Other changes

- Fixed calculation error when boiler set temperature is lower then boiler actual temperature (reported by timenator)

[Mirabis]

Thanks voor de update.

• Zou je voor **max power** ook een parent property willen maken? Ik heb bijv. twee strings op 1 omvormer en zou de oriëntaties gezamenlijk dus willen beperken op max van de omvormer.
• Aangezien je ook Tibber gebruikt, hoe ga je dan om met "Grid rewards"? Mijn EV laadt af en toe op voor gereduceerde tarieven i.v.m. grid rewards maar dat zal de berekeningen wellicht wel scheef trekken.

[konehead]

Thanks voor de update @KC27! Heb je het model ook (extreem) sneller gemaakt? Is enorm merkbaar.. toeval? Het is nu: run, boem: output.. duurde eerst 20 sec

One minor note:
Ik krijg in de logging odnerstaande, terwijl ik wel de aanpassingen heb doorgevoerd. Als dit is voor better safe than sorry.. prima natuurlijk

code:

2025-06-04 09:14:45 waarschuwing: Gebruik 'prices consumption' ipv `prices delivery'
2025-06-04 09:14:45 waarschuwing: Gebruik 'prices production' ipv `prices redelivery'
2025-06-04 09:14:45 waarschuwing: Gebruik 'average consumption' ipv `average delivery'

code:

        "energy taxes consumption": {
            "2023-01-01": 0.12599,
            "2024-01-01": 0.1088,
            "2025-01-01": 0.10154
        },
        "energy taxes production": {
            "2022-01-01": 0.06729,
            "2023-01-01": 0.12599,
            "2024-01-01": 0.1088,
            "2025-01-01": 0.10154
        },
        "cost supplier consumption": {
            "2024-04-01": 0.02415
        },
        "cost supplier production": {
            "2024-04-01": 0.02415
        },
        "vat": {
            "2024-01-01": 21

[simnet]

konehead schreef op woensdag 4 juni 2025 @ 09:16:
Thanks voor de update @KC27! Heb je het model ook (extreem) sneller gemaakt? Is enorm merkbaar.. toeval? Het is nu: run, boem: output.. duurde eerst 20 sec

Dit zie ik ook, maar ik vermoed dat dit komt omdat je verbruik niet meer hoeft worden opgehaald uit home-assistant om de tax refund te kunnen bepalen.

[Mirabis]

konehead schreef op woensdag 4 juni 2025 @ 09:16:
Thanks voor de update @KC27! Heb je het model ook (extreem) sneller gemaakt? Is enorm merkbaar.. toeval? Het is nu: run, boem: output.. duurde eerst 20 sec

One minor note:
Ik krijg in de logging odnerstaande, terwijl ik wel de aanpassingen heb doorgevoerd. Als dit is voor better safe than sorry.. prima natuurlijk

code:

2025-06-04 09:14:45 waarschuwing: Gebruik 'prices consumption' ipv `prices delivery'
2025-06-04 09:14:45 waarschuwing: Gebruik 'prices production' ipv `prices redelivery'
2025-06-04 09:14:45 waarschuwing: Gebruik 'average consumption' ipv `average delivery'

Bovenstaande meldingen gaan over het rapportage gedeelte. https://github.com/cornee.../dao/DOCS.md#instellingen

graphics	style	string	"default"	kies uit lijst
battery balance	boolean	"True"
prices consumption	boolean	"True"
prices production	boolean	"True"
average consumption	boolean	"True"
show	boolean	"False"

[sjampeter]

KC27 schreef op dinsdag 3 juni 2025 @ 22:41:
Wat ook een mogelijkheid is (in ieder geval de moeite waard om te checken): beide P!-meters rapporteren niet alle twee in kWh, maar een van de twee rapporteert in Wh. Ik weet dat HASS daar automatisch voor corrigeert in zijn rapportages, maar DAO doet dat (nog?) niet.

hier ben ik even niet mee.
het zijn 2 exact dezelfde meters welke uitgelezen worden via de p1 poort doormiddel van 2 homewizard p1 uitleesmeters.


een enkele entiteit invullen heb ik al vaker geprobeerd. zonder resultaat.
ik ben hier toch al jaartje mee bezig ( met tussenpozen uiteraard) om dit aan de gang te krijgen.

overigens zie ik in bovenstaande foto nu ook een totale meter staan. dus tarief 1+2, en dat voor verbruik en voor productie.
ik zal deze ook even proberen .
op deze manier zouden we het aantal sensoren halveren.

thanks voor het meedenken.

[konehead]

Mirabis schreef op woensdag 4 juni 2025 @ 09:35:
[...]


Bovenstaande meldingen gaan over het rapportage gedeelte. https://github.com/cornee.../dao/DOCS.md#instellingen

graphics	style	string	"default"	kies uit lijst
battery balance	boolean	"True"
prices consumption	boolean	"True"
prices production	boolean	"True"
average consumption	boolean	"True"
show	boolean	"False"

check, dank!

[KC27]

Mirabis schreef op woensdag 4 juni 2025 @ 08:58:
Thanks voor de update.

• Zou je voor **max power** ook een parent property willen maken? Ik heb bijv. twee strings op 1 omvormer en zou de oriëntaties gezamenlijk dus willen beperken op max van de omvormer.
• Aangezien je ook Tibber gebruikt, hoe ga je dan om met "Grid rewards"? Mijn EV laadt af en toe op voor gereduceerde tarieven i.v.m. grid rewards maar dat zal de berekeningen wellicht wel scheef trekken.

Dat eerste is nog niet zo simpel. Dan zal ik het model moeten aanpassen:

• pv_ac met nul, een of meer inverters
• per inverter een of meer strings met ieder hun eigen helling, oriëntatie, vermogen en yield
• per inverter een max power en een reductie of aan/uit van het vermogen

Ik zet hem op de lijst met feature requests.

Ik heb zelf een hybride auto (6 kWh accu). Ik laad niet met Grid Rewards.
Als je Grid Rewards wil incasseren dan zul je de planning van je EV door Tibber moeten laten verzorgen en niet door DAO.

[KC27]

konehead schreef op woensdag 4 juni 2025 @ 09:16:
Thanks voor de update @KC27! Heb je het model ook (extreem) sneller gemaakt? Is enorm merkbaar.. toeval? Het is nu: run, boem: output.. duurde eerst 20 sec

One minor note:
Ik krijg in de logging odnerstaande, terwijl ik wel de aanpassingen heb doorgevoerd. Als dit is voor better safe than sorry.. prima natuurlijk

code:

2025-06-04 09:14:45 waarschuwing: Gebruik 'prices consumption' ipv `prices delivery'
2025-06-04 09:14:45 waarschuwing: Gebruik 'prices production' ipv `prices redelivery'
2025-06-04 09:14:45 waarschuwing: Gebruik 'average consumption' ipv `average delivery'

code:

        "energy taxes consumption": {
            "2023-01-01": 0.12599,
            "2024-01-01": 0.1088,
            "2025-01-01": 0.10154
        },
        "energy taxes production": {
            "2022-01-01": 0.06729,
            "2023-01-01": 0.12599,
            "2024-01-01": 0.1088,
            "2025-01-01": 0.10154
        },
        "cost supplier consumption": {
            "2024-04-01": 0.02415
        },
        "cost supplier production": {
            "2024-04-01": 0.02415
        },
        "vat": {
            "2024-01-01": 21

Inderdaad zoals @Mirabis ook al zei: bij een aantal gebruikers duurde de berekening van de "tax refund" lang (waarschijnlijk door de database van HA). Dat is er nu (na een mini-poll hier) uitgehaald.

Sorry waarschijnlijk was ik in de changelog niet duidelijk genoeg.
Ook dit lijstje moet worden aangepast:

code:

  "graphics": {
    ...
    "prices delivery": "True",
    "prices redelivery": "True",
    "average delivery": "True"
  },

naar:

code:

  "graphics": {
    .....
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "True",
    "average consumption": "True"
  },

Zet op True en False zoals jij het wil hebben.

[Mirabis]

KC27 schreef op woensdag 4 juni 2025 @ 10:25:
[...]

Dat eerste is nog niet zo simpel. Dan zal ik het model moeten aanpassen:

• pv_ac met nul, een of meer inverters
• per inverter een of meer strings met ieder hun eigen helling, oriëntatie, vermogen en yield
• per inverter een max power en een reductie of aan/uit van het vermogen

Ik zet hem op de lijst met feature requests.

Ik heb zelf een hybride auto (6 kWh accu). Ik laad niet met Grid Rewards.
Als je Grid Rewards wil incasseren dan zul je de planning van je EV door Tibber moeten laten verzorgen en niet door DAO.

Ah ok. Ja met ~98kWh accu laad ik wel met Grid rewards omdat het uitkomt op 10 cent per kWh of soms zelf minder. Moet ik dan "electric vehicle" array weglaten en "entities ev consumption" vanuit HA wel gewoon opgeven of dat ook weglaten? In principe wil ik niet dat de EV meetelt voor mijn baseload.

[KC27]

Mirabis schreef op woensdag 4 juni 2025 @ 10:37:
[...]


Ah ok. Ja met ~98kWh accu laad ik wel met Grid rewards omdat het uitkomt op 10 cent per kWh of soms zelf minder. Moet ik dan "electric vehicle" array weglaten en "entities ev consumption" vanuit HA wel gewoon opgeven of dat ook weglaten? In principe wil ik niet dat de EV meetelt voor mijn baseload.

Je kunt voorlopig de auto gewoon laten staan en je zet bijvoorbeeld de positie op een input_text met de tekst "away". Dan rekent ie er niet mee en kun je hem later evt alsnog weer snel "aan" zetten.

Ik zou wel de "entities ev consumption" laten staan zodat je een zuiverder beeld houdt van je baseload.

[konehead]

@KC27 Ik weet niet zeker of het volgende 2.6 gerelateerd is. Als ik vanuit home op op de knop tabel (naast grafiek) druk krijg ik de volgende foutmelding:
De run van het model gaat gewoon goed, als ik met de pijltjes van links naar rechts ga, staat er een scherm tussen met onderstaande.. Wat zou dit kunnen zijn?

code:

2025-06-05 09:33:38,056 fout dao.webserver.app MainThread : Exception on /api/report/consumption/vandaag [GET]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 882, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 585, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2972, in get_api_data
    df[field] = df_balance[field].cumsum()
                ^^^^^^^^^^
UnboundLocalError: cannot access local variable 'df_balance' where it is not associated with a value
2025-06-05 09:53:37,670 fout dao.webserver.app MainThread : Exception on /api/report/soc/vandaag_en_morgen [GET]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 882, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 585, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2972, in get_api_data
    df[field] = df_balance[field].cumsum()
                ^^^^^^^^^^
UnboundLocalError: cannot access local variable 'df_balance' where it is not associated with a value
2025-06-05 09:53:37,897 fout dao.webserver.app MainThread : Exception on /api/report/bat_out/vandaag_en_morgen [GET]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/base.py", line 3805, in get_loc
    return self._engine.get_loc(casted_key)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "index.pyx", line 167, in pandas._libs.index.IndexEngine.get_loc
  File "index.pyx", line 196, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 7081, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 7089, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'time'

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

Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 882, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 585, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2975, in get_api_data
    df["time"] = pd.to_datetime(df["time"])
                                ~~^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4102, in __getitem__
    indexer = self.columns.get_loc(key)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/base.py", line 3812, in get_loc
    raise KeyError(key) from err
KeyError: 'time'
2025-06-05 09:53:38,074 fout dao.webserver.app MainThread : Exception on /api/report/consumption/vandaag [GET]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 882, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 585, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2972, in get_api_data
    df[field] = df_balance[field].cumsum()
                ^^^^^^^^^^
UnboundLocalError: cannot access local variable 'df_balance' where it is not associated with a value

[simnet]

Deze foutmelding heb ik ook sinds 2025.6.0.

[arro3038]

Met de nieuwe versie valt me op dat de lijnen voor de prijs van consumptie en productie op elkaar liggen. In mijn geval klopt dat niet omdat mijn leverancier ook een kleine vergoeding in rekening brengt voor productie. Oftewel de cost supplier consumption en cost supplier production zijn even groot. Maar waarom liggen die lijnen dan op elkaar?

Vervang ik dat bedrag nu in de config onder cost supplier production door 0, dan krijg ik wel 2 aparte lijnen te zien, waarbij productie lager ligt dan consumptie.

Ik zou verwachten dat als ik bij cost supplier production een positief getal invul, de lijn voor productie dus nog lager komt te liggen, echter hij verschuift omhoog. Moet ik hier dan een negatief getal invullen?

Hier met plaatje met cost supplier production = 0




PS en ja ik weet dat er leveranciers zijn die wel netjes salderen. In dit geval was het voor mij echter iets voordeliger ivm een cashback

[KC27]

arro3038 schreef op donderdag 5 juni 2025 @ 15:02:
Met de nieuwe versie valt me op dat de lijnen voor de prijs van consumptie en productie op elkaar liggen. In mijn geval klopt dat niet omdat mijn leverancier ook een kleine vergoeding in rekening brengt voor productie. Oftewel de cost supplier consumption en cost supplier production zijn even groot. Maar waarom liggen die lijnen dan op elkaar?

Vervang ik dat bedrag nu in de config onder cost supplier production door 0, dan krijg ik wel 2 aparte lijnen te zien, waarbij productie lager ligt dan consumptie.

Ik zou verwachten dat als ik bij cost supplier production een positief getal invul, de lijn voor productie dus nog lager komt te liggen, echter hij verschuift omhoog. Moet ik hier dan een negatief getal invullen?

Hier met plaatje met cost supplier production = 0

[Afbeelding]


PS en ja ik weet dat er leveranciers zijn die wel netjes salderen. In dit geval was het voor mij echter iets voordeliger ivm een cashback

Als bijvoorbeeld Frank jouw leverancier is dan worden kosten voor teruglevering in rekening gebracht. In dat geval moet je bij "cost supplier production" een negatief bedrag invullen. Namelijk het bedrag (excl btw) wat hij aftrekt van jouw vergoeding bij teruglevering.
Het is wel belangrijk om een goed bedrag in te voelen, omdat het van invloed kan zijn op de uitkomsten van de berekeningen van DAO.

[arro3038]

KC27 schreef op donderdag 5 juni 2025 @ 15:07:
[...]

Als bijvoorbeeld Frank jouw leverancier is dan worden kosten voor teruglevering in rekening gebracht. In dat geval moet je bij "cost supplier production" een negatief bedrag invullen. Namelijk het bedrag (excl btw) wat hij aftrekt van jouw vergoeding bij teruglevering.
Het is wel belangrijk om een goed bedrag in te voelen, omdat het van invloed kan zijn op de uitkomsten van de berekeningen van DAO.

Heb ik inmiddels gedaan. Bedankt!

[KC27]

@simnet @konehead
Ik wil graag jullie foutmeldingen oplossen, maar ik heb iets meer info nodig.
Welke repons krijgen jullie als je in het dashboard \Report\Balans opvraagt.
Als je een "interne fout" krijgt: kun je dan de logging van DAO sturen, die je vindt via \Instellingen\Add-on\DAO en dan "logboek".
Ik wacht het af.

[simnet]

@KC27 Ik krijg geen foutmelding als ik de report/balans opvraag (voor welke dag dan ook).

Edit: de originele error is bij mij nu ook weg...
Edit2: na wat heel en weer scrollen door logs met< en > heb ik de error weer terug...

Ik krijg nu een error 500 als ik via curl deze api url opvraag (is een ha sensor):
http://127.0.0.1:5001/api...mption/vandaag?cumulate=1

In de console logging van docker is niets te zien.
In de dashboard.log komt dan het volgende te staan:

code:

==> dashboard.log <==
2025-06-05 16:03:58,696 fout dao.webserver.app MainThread : Exception on /api/report/consumption/vandaag [GET]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 882, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 585, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2972, in get_api_data
    df[field] = df_balance[field].cumsum()
                ^^^^^^^^^^
UnboundLocalError: cannot access local variable 'df_balance' where it is not associated with a value

Hopelijk helpt dit.

Edit3: zonder de 'cumulate=1' querystring krijg ik geen error

Edit4: ik zit de commits van 2025.6.0 door te lezen, maar aan dat report is helemaal niets gewijzigd. dus ik snap niet waar het ineens vandaag komt. Echter kan ik in de history van home-assistant zien dat die sensor is gestopt met werken op het moment dat ik naar de laatste versie ben overgegaan...
Edit5: lijkt er op dat na deze commit de df_balance variabele niet meer wordt gezet: 6c5d2140bc7c53db95c1c1665861bbdcaace1e93
Ik kan hem helaas niet verder uitpluizen. Ik mis de relevante historie

[ Voor 118% gewijzigd door simnet op 05-06-2025 16:41 ]

[KC27]

simnet schreef op donderdag 5 juni 2025 @ 15:56:
@KC27 Ik krijg geen foutmelding als ik de report/balans opvraag (voor welke dag dan ook).

Edit: de originele error is bij mij nu ook weg...
Edit2: na wat heel en weer scrollen door logs met< en > heb ik de error weer terug...

Ik krijg nu een error 500 als ik via curl deze api url opvraag (is een ha sensor):
http://127.0.0.1:5001/api...mption/vandaag?cumulate=1

In de console logging van docker is niets te zien.
In de dashboard.log komt dan het volgende te staan:

code:

==> dashboard.log <==
2025-06-05 16:03:58,696 fout dao.webserver.app MainThread : Exception on /api/report/consumption/vandaag [GET]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 882, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 585, in api_report
    result = report.get_api_data(fld, periode, cumulate=cumulate)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2972, in get_api_data
    df[field] = df_balance[field].cumsum()
                ^^^^^^^^^^
UnboundLocalError: cannot access local variable 'df_balance' where it is not associated with a value

Hopelijk helpt dit.

Edit3: zonder de 'cumulate=1' querystring krijg ik geen error

Edit4: ik zit de commits van 2025.6.0 door te lezen, maar aan dat report is helemaal niets gewijzigd. dus ik snap niet waar het ineens vandaag komt. Echter kan ik in de history van home-assistant zien dat die sensor is gestopt met werken op het moment dat ik naar de laatste versie ben overgegaan...
Edit5: lijkt er op dat na deze commit de df_balance variabele niet meer wordt gezet: 6c5d2140bc7c53db95c1c1665861bbdcaace1e93
Ik kan hem helaas niet verder uitpluizen. Ik mis de relevante historie

Ik kom hier een stuk verder mee.
Ik ga ermee aan de slag.

[KC27]

Ik heb de fout gevonden. Er staat een test-versie met een fix 2025.6.1.rc1 in de addon branche.
Graag testen!

[bladebla]

Wat een fantastisch project, @KC27 – dank daarvoor. Het is duidelijk dat hier veel denkwerk en uitwerking in zit. Sinds ik je oplossing toepas, zijn mijn Multiplussen ook merkbaar stiller geworden. Ze draaien nu efficiënter bij een bepaald vermogen, in plaats van continu op vol vermogen zoals bij DESS.

Ik ben me de afgelopen dagen aan het verdiepen in de werking, maar loop nog tegen een punt aan:
Wat doe je in een Victron-systeem precies met de entity set power feedin (battery setpoint)? Deze bepaalt het laad-/ontlaadvermogen van de accu’s, terwijl Victron je toelaat om het grid setpoint van Victron ESS in te stellen.

In dit topic zag ik dat @tonvanboven, @thys en @georgeboot hier ook mee bezig zijn, maar ik kon nergens terugvinden hoe ze dit precies aanpakken.

Wat ik nu gebouwd heb:
Ik gebruik de set power feedin uit DAO als basis en corrigeer de grid setpoint continu zodat er een kloppende energiebalans ontstaat:

code:

Grid setpoint = (DAO power feedin + house load) – PV production

Mijn pv installatie bestaat uit een DC Victron MPPT charger en een AC Fronius inverter. Ik heb mijn gehele huis achter AC-out1 hangen.

Ik doe het volgende via Node-RED naar MQTT-server van de Cerbo en HA:



DAO power feedin = homeassistant/dao/set_power_feedin

House load L1 = N/#####/system/0/Ac/Consumption/L1/Power
House load L2 = N/#####/system/0/Ac/Consumption/L2/Power
House load L3 = N/#####/system/0/Ac/Consumption/L3/Power

Fronius inverter = N/#####/pvinverter/20/Ac/Power
Victron charger = N/#####/solarcharger/279/Yield/Power

De resulterende Grit setpoint schrijf ik dan naar:
Grid setpoint = W/#####/settings/0/Settings/CGwacs/AcPowerSetPoint

De berekening wordt continu herhaald bij elke nieuwe input van een van de componenten.

Mijn volledige woning hangt achter AC-out1. 's Nachts, wanneer er geen PV is en de accu’s in rust zijn, zie ik dat het verschil tussen house load en grid zichtbaar wordt: bijvoorbeeld 400W load tegenover 433W uit het net. Dus ~33W eigen verbruik door de drie Multiplussen.

Is deze aanpak logisch volgens jullie?
En is het zinvol (en haalbaar) om die ~33W eigen verbruik van de Multiplussen ook mee te nemen in de berekening?

[Mirabis]

Hmm ik dacht dat ik alles al goed had ingesteld maar ga nu toch weer twijfelen. Vanavond is het 30.4 cent tussen 21:00-22:00 en 30.2 cent tussen 22:00-23:00. Hij lijkt echter enkel 21:00-22:00 te willen ontladen en dan te wachten tot zaterdag 21:00 wanneer het 30,1 cent is.

code:

...
{
      "name": "Marstek Venus-E",
      "capacity": 5.12,
      "lower limit": 11,
      "upper limit": 100,
      "optimal lower level": 12,
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 100.0,
          "efficiency": 0.6364
        },
        {
          "power": 200.0,
          "efficiency": 0.8221
        },
        {
          "power": 400.0,
          "efficiency": 0.8673
        },
        {
          "power": 500.0,
          "efficiency": 0.91
        },
        {
          "power": 600.0,
          "efficiency": 0.8861
        },
        {
          "power": 800.0,
          "efficiency": 0.8933
        },
        {
          "power": 1000.0,
          "efficiency": 0.8975
        },
        {
          "power": 1500.0,
          "efficiency": 0.9015
        },
        {
          "power": 2000.0,
          "efficiency": 0.9010
        },
        {
          "power": 2500.0,
          "efficiency": 0.9017
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 100.0,
          "efficiency": 0.7907
        },
        {
          "power": 200.0,
          "efficiency": 0.8957
        },
        {
          "power": 400.0,
          "efficiency": 0.9581
        },
        {
          "power": 500.0,
          "efficiency": 0.9587
        },
        {
          "power": 600.0,
          "efficiency": 0.9767
        },
        {
          "power": 800.0,
          "efficiency": 0.9812
        },
        {
          "power": 1000.0,
          "efficiency": 0.9890
        },
        {
          "power": 1500.0,
          "efficiency": 0.9907
        },
        {
          "power": 2000.0,
          "efficiency": 0.9841
        },
        {
          "power": 2500.0,
          "efficiency": 0.9928
        }
      ],
      "reduced hours": {},
      "dc_to_bat max power": 2500.0,
      "bat_to_dc max power": 2500.0,
      "dc_to_bat efficiency": 0.935,
      "bat_to_dc efficiency": 0.935,
      "cycle cost": 0.054,
      "minimum power": 200,

code:

 "prices": {
    "source day ahead": "entsoe",
    "entsoe-api-key": "!secret entsoe-api-key",
    "energy taxes consumption": {
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2024-08-01": 0.020496
    },
    "vat consumption": {
      "2023-01-01": 21
    },
    "vat production": {
      "2023-01-01": 21
    },
    "last invoice": "2024-10-25",
    "tax refund": "True"
  },

[KC27]

bladebla schreef op vrijdag 6 juni 2025 @ 17:35:
Wat een fantastisch project, @KC27 – dank daarvoor. Het is duidelijk dat hier veel denkwerk en uitwerking in zit. Sinds ik je oplossing toepas, zijn mijn Multiplussen ook merkbaar stiller geworden. Ze draaien nu efficiënter bij een bepaald vermogen, in plaats van continu op vol vermogen zoals bij DESS.

Ik ben me de afgelopen dagen aan het verdiepen in de werking, maar loop nog tegen een punt aan:
Wat doe je in een Victron-systeem precies met de entity set power feedin (battery setpoint)? Deze bepaalt het laad-/ontlaadvermogen van de accu’s, terwijl Victron je toelaat om het grid setpoint van Victron ESS in te stellen.

In dit topic zag ik dat @tonvanboven, @thys en @georgeboot hier ook mee bezig zijn, maar ik kon nergens terugvinden hoe ze dit precies aanpakken.

Wat ik nu gebouwd heb:
Ik gebruik de set power feedin uit DAO als basis en corrigeer de grid setpoint continu zodat er een kloppende energiebalans ontstaat:

code:

Grid setpoint = (DAO power feedin + house load) – PV production

Mijn pv installatie bestaat uit een DC Victron MPPT charger en een AC Fronius inverter. Ik heb mijn gehele huis achter AC-out1 hangen.

Ik doe het volgende via Node-RED naar MQTT-server van de Cerbo en HA:

[Afbeelding]

DAO power feedin = homeassistant/dao/set_power_feedin

House load L1 = N/#####/system/0/Ac/Consumption/L1/Power
House load L2 = N/#####/system/0/Ac/Consumption/L2/Power
House load L3 = N/#####/system/0/Ac/Consumption/L3/Power

Fronius inverter = N/#####/pvinverter/20/Ac/Power
Victron charger = N/#####/solarcharger/279/Yield/Power

De resulterende Grit setpoint schrijf ik dan naar:
Grid setpoint = W/#####/settings/0/Settings/CGwacs/AcPowerSetPoint

De berekening wordt continu herhaald bij elke nieuwe input van een van de componenten.

Mijn volledige woning hangt achter AC-out1. 's Nachts, wanneer er geen PV is en de accu’s in rust zijn, zie ik dat het verschil tussen house load en grid zichtbaar wordt: bijvoorbeeld 400W load tegenover 433W uit het net. Dus ~33W eigen verbruik door de drie Multiplussen.

Is deze aanpak logisch volgens jullie?
En is het zinvol (en haalbaar) om die ~33W eigen verbruik van de Multiplussen ook mee te nemen in de berekening?

Als ik het zo lees heb je het perfect onder controle en heel goed geconfigureerd.
Fijn te lezen dat je tevreden bent over DAO.
Misschien leuk om jouw ervaringen met DAO te delen in het Het grote Victron aansturing topic
Overigens is er een DAO een optionele in te stellen entiteit waarin het door DAO berekende grid-setpoint wordt weggeschreven: entity ess grid setpoint. Die waarde staat ook in de logging en die zou bij jou hetzelfde moeten opleveren, alleen niks is zo veranderlijk dan de werkelijkheid (even wat zon erbij, stofzuiger aan/uit enz). Dus als je het doet op jouw manier is het (denk ik) beter.
Die 33W eigen verbruik is iets dat er in jouw situatie altijd zal zijn, Ook in een standby-situatie.
Dat heb je ook met het verbruik van je HA-machine en andere apparaten (koelkast, vrieskast enz), die je niet kunt beïnvloeden en worden toegerekend aan de basislast. Daar kan DAO niet mee schuiven of aan/uit zetten.

[ Voor 5% gewijzigd door KC27 op 06-06-2025 23:06 ]

[KC27]

Mirabis schreef op vrijdag 6 juni 2025 @ 17:43:
Hmm ik dacht dat ik alles al goed had ingesteld maar ga nu toch weer twijfelen. Vanavond is het 30.4 cent tussen 21:00-22:00 en 30.2 cent tussen 22:00-23:00. Hij lijkt echter enkel 21:00-22:00 te willen ontladen en dan te wachten tot zaterdag 21:00 wanneer het 30,1 cent is.

[Afbeelding]

code:

...
{
      "name": "Marstek Venus-E",
      "capacity": 5.12,
      "lower limit": 11,
      "upper limit": 100,
      "optimal lower level": 12,
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 100.0,
          "efficiency": 0.6364
        },
        {
          "power": 200.0,
          "efficiency": 0.8221
        },
        {
          "power": 400.0,
          "efficiency": 0.8673
        },
        {
          "power": 500.0,
          "efficiency": 0.91
        },
        {
          "power": 600.0,
          "efficiency": 0.8861
        },
        {
          "power": 800.0,
          "efficiency": 0.8933
        },
        {
          "power": 1000.0,
          "efficiency": 0.8975
        },
        {
          "power": 1500.0,
          "efficiency": 0.9015
        },
        {
          "power": 2000.0,
          "efficiency": 0.9010
        },
        {
          "power": 2500.0,
          "efficiency": 0.9017
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 100.0,
          "efficiency": 0.7907
        },
        {
          "power": 200.0,
          "efficiency": 0.8957
        },
        {
          "power": 400.0,
          "efficiency": 0.9581
        },
        {
          "power": 500.0,
          "efficiency": 0.9587
        },
        {
          "power": 600.0,
          "efficiency": 0.9767
        },
        {
          "power": 800.0,
          "efficiency": 0.9812
        },
        {
          "power": 1000.0,
          "efficiency": 0.9890
        },
        {
          "power": 1500.0,
          "efficiency": 0.9907
        },
        {
          "power": 2000.0,
          "efficiency": 0.9841
        },
        {
          "power": 2500.0,
          "efficiency": 0.9928
        }
      ],
      "reduced hours": {},
      "dc_to_bat max power": 2500.0,
      "bat_to_dc max power": 2500.0,
      "dc_to_bat efficiency": 0.935,
      "bat_to_dc efficiency": 0.935,
      "cycle cost": 0.054,
      "minimum power": 200,

code:

 "prices": {
    "source day ahead": "entsoe",
    "entsoe-api-key": "!secret entsoe-api-key",
    "energy taxes consumption": {
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2024-08-01": 0.020496
    },
    "vat consumption": {
      "2023-01-01": 21
    },
    "vat production": {
      "2023-01-01": 21
    },
    "last invoice": "2024-10-25",
    "tax refund": "True"
  },

Jammer dat je het prijzen grafiekje er niet onder hebt bijstaan. Dat leest altijd net iets makkelijker.
Als ik je instellingen goed lees dan is jouw "Marstek Venus-E" het meest efficiënt bij het hoogste vermogen.
Ook is de batterij-inhoud (5,12 kWh) beperkte t.o.v. het maximale vermogen (2,5 kW).
Dus je batterij is in ca. twee uur leeg of vol.
Door de combinatie van die twee eigenschappen (meest eff. hoge vermogen, beperkte inhoud) zal hij selectief de duurste 2 uren zoeken om te ontladen en de goedkoopste 2 uren om te laden, maar omdat je ook nog 0,05 euro/kWh als cycle cost hebt gedefinieerd zal het prijsverschil tussen laden en ontladen ook minimaal 0,12 euro/kWh moeten zijn.
Dus misschien moet je toch nog een beetje finetunen met je instellingen.
Ik heb het hier al meer gezegd: de batterij-degradatie gaat waarschijnlijk sneller door leeftijd (levensjaren) dan door laad/ontlaad cycles. Je hebt "het ding" gekocht. Je schrijft sowieso dat ding in ca 10 jaar af (dan is ie echt verouderd en achterhaald door nieuwe technieken). Als je nu 400 cycles per jaar haalt (dat is veel, ik zit nu in drie jaar op 650 cycles) dan ben je over 10 jaar op 4000 cycles en dat is een stuk onder de garantie (meestal 6000 cycles). Dus ik zou zeggen: zet die cycle cost lager (staat bij mij op 1 ct) en gaan met die banaan!

[Mirabis]

KC27 schreef op vrijdag 6 juni 2025 @ 23:25:
[...]


Jammer dat je het prijzen grafiekje er niet onder hebt bijstaan. Dat leest altijd net iets makkelijker.
Als ik je instellingen goed lees dan is jouw "Marstek Venus-E" het meest efficiënt bij het hoogste vermogen.
Ook is de batterij-inhoud (5,12 kWh) beperkte t.o.v. het maximale vermogen (2,5 kW).
Dus je batterij is in ca. twee uur leeg of vol.
Door de combinatie van die twee eigenschappen (meest eff. hoge vermogen, beperkte inhoud) zal hij selectief de duurste 2 uren zoeken om te ontladen en de goedkoopste 2 uren om te laden, maar omdat je ook nog 0,05 euro/kWh als cycle cost hebt gedefinieerd zal het prijsverschil tussen laden en ontladen ook minimaal 0,12 euro/kWh moeten zijn.
Dus misschien moet je toch nog een beetje finetunen met je instellingen.
Ik heb het hier al meer gezegd: de batterij-degradatie gaat waarschijnlijk sneller door leeftijd (levensjaren) dan door laad/ontlaad cycles. Je hebt "het ding" gekocht. Je schrijft sowieso dat ding in ca 10 jaar af (dan is ie echt verouderd en achterhaald door nieuwe technieken). Als je nu 400 cycles per jaar haalt (dat is veel, ik zit nu in drie jaar op 650 cycles) dan ben je over 10 jaar op 4000 cycles en dat is een stuk onder de garantie (meestal 6000 cycles). Dus ik zou zeggen: zet die cycle cost lager (staat bij mij op 1 ct) en gaan met die banaan!

In theorie wil ik ook dat het 2 uur (ont)laadt maar het koos ervoor om slechts 1u te pakken. Dat vond ik het vreemde. Ik zal de cycle cost verlagen en even aankijken hoe het gaat. Onderstaand nog ff screenshot van dat tijdstip voor prijsgrafiek.

[KC27]

Inmiddels is versie 2025.6.1 gepubliceerd.
Dit staat in de changelog:

Fixed error with api-call for data with parameter "cumulate=1" (reported by @konehead and @simnet )

[simnet]

Hoi @KC27
Volgens mij gaat er eea niet goed in je git repo. De laatste release bevat 13 commits, waaronder changes die terug gaan tot ergens in februari.
Het lijkt op een squashed commit die je niet hebt in je ontwikkel branch.
Het maakt de historie / releasenotes ook erg lastig om te lezen of om als buitenstaander na te gaan wat er is gewijzigd.

Edit: het lijkt er op dat je branch een rebase nodig heeft, maar ik moet je eerlijk zeggen dat ik er geen wijs uit wordt wat er nou precies is gebeurd. Er zit ergens iets waardoor de historie uit sync loopt en sommige branches lopen voor en anderen achter op main.

[ Voor 27% gewijzigd door simnet op 07-06-2025 18:46 ]

[KC27]

simnet schreef op zaterdag 7 juni 2025 @ 18:39:
Hoi @KC27
Volgens mij gaat er eea niet goed in je git repo. De laatste release bevat 13 commits, waaronder changes die terug gaan tot ergens in februari.
Het lijkt op een squashed commit die je niet hebt in je ontwikkel branch.
Het maakt de historie / releasenotes ook erg lastig om te lezen of om als buitenstaander na te gaan wat er is gewijzigd.

Edit: het lijkt er op dat je branch een rebase nodig heeft, maar ik moet je eerlijk zeggen dat ik er geen wijs uit wordt wat er nou precies is gebeurd. Er zit ergens iets waardoor de historie uit sync loopt en sommige branches lopen voor en anderen achter op main.

Ik heb het ook gezien en ga ermee aan de slag.
Ik stuur je een dm.

[ErnstH]

Klopt het dat (wellicht ivm bovenstaande) de DAO updates teruggetrokken zijn op HA? Ik zie ze niet meer in mijn lijst met updates iig.

[KC27]

ErnstH schreef op maandag 9 juni 2025 @ 16:23:
Klopt het dat (wellicht ivm bovenstaande) de DAO updates teruggetrokken zijn op HA? Ik zie ze niet meer in mijn lijst met updates iig.

@simnet en ik zijn er inderdaad druk mee.
Maar de laatste versie (2025.6.1) zou gewoon beschikbaar moeten zijn op github.
Wat is jouw laatste versie?

[balk]

KC27 schreef op maandag 9 juni 2025 @ 16:41:
[...]

@simnet en ik zijn er inderdaad druk mee.
Maar de laatste versie (2025.6.1) zou gewoon beschikbaar moeten zijn op github.
Wat is jouw laatste versie?

Er is inderdaad ergens een fout ingeslopen waardoor de addon niet beschikbaar is in de store. PR 277 voegt een " toe waardoor het weer zou moeten werken. Bedankt @KC27 en @simnet !

[ErnstH]

KC27 schreef op maandag 9 juni 2025 @ 16:41:
[...]

@simnet en ik zijn er inderdaad druk mee.
Maar de laatste versie (2025.6.1) zou gewoon beschikbaar moeten zijn op github.
Wat is jouw laatste versie?

Ik zit nog op 2025.4.2. Overigens update ik DAO altijd vanuit HA, niet via Github.

[ Voor 9% gewijzigd door ErnstH op 09-06-2025 17:41 ]

[KC27]

balk schreef op maandag 9 juni 2025 @ 17:34:
[...]

Er is inderdaad ergens een fout ingeslopen waardoor de addon niet beschikbaar is in de store. PR 277 voegt een " toe waardoor het weer zou moeten werken. Bedankt @KC27 en @simnet !

Dank voor je oplettendheid en je PR.
Deze is inmiddels gereviewed en approved.

[KC27]

ErnstH schreef op maandag 9 juni 2025 @ 17:40:
[...]

Ik zit nog op 2025.4.2. Overigens update ik DAO altijd vanuit HA, niet via Github.

Er zat inderdaad een typo in config.yaml, mijn fout, sorry.
Dit is inmiddels hersteld.
Als je nu bij Instellingen\Add-ons in de "shop" klikt op "Naar updates zoeken", dan moet de update van DAO naar versie 2025.6.1 erbij staan.
Zo niet dan hoor ik het graag.

[ErnstH]

KC27 schreef op maandag 9 juni 2025 @ 19:10:
[...]

Er zat inderdaad een typo in config.yaml, mijn fout, sorry.
Dit is inmiddels hersteld.
Als je nu bij Instellingen\Add-ons in de "shop" klikt op "Naar updates zoeken", dan moet de update van DAO naar versie 2025.6.1 erbij staan.
Zo niet dan hoor ik het graag.

Geweldig, ik heb de laatste versie nu draaien. Zonder de DB lookup gaat het nu ook een stuk sneller! Heel mooie en nuttige software, dank!

[konehead]

@KC27 Vandaag is er iets niet goed gegaan met mijn HA installatie. De batterij is nu fysiek geïnstalleerd, alleen hierdoor is HA een paar keer hard afgesloten en weer opgestart. DAO leek dan niet helemaal fijn te vinden: De addon lijkt niet meer geinstaleerd en kan hem ook niet meer toevoegen. Waar kan ik de DAO directory vinden? Ik denk dat ik de files moet verwijderen en daarna opnieuw DAO installeren..

[konehead]

konehead schreef op maandag 9 juni 2025 @ 21:16:
@KC27 Vandaag is er iets niet goed gegaan met mijn HA installatie. De batterij is nu fysiek geïnstalleerd, alleen hierdoor is HA een paar keer hard afgesloten en weer opgestart. DAO leek dan niet helemaal fijn te vinden: De addon lijkt niet meer geinstaleerd en kan hem ook niet meer toevoegen. Waar kan ik de DAO directory vinden? Ik denk dat ik de files moet verwijderen en daarna opnieuw DAO installeren..

Opgelost!

[DaBit]

KC27 schreef op donderdag 5 juni 2025 @ 15:07:
..
In dat geval moet je bij "cost supplier production" een negatief bedrag invullen.
..
Het is wel belangrijk om een goed bedrag in te voelen, omdat het van invloed kan zijn op de uitkomsten van de berekeningen van DAO.

Dat was een goede tip want NextEnergy saldeert de in/verkoop vergoedingen ook niet.

Riedeltje in de config:

code:

"cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": 0.0181
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": -0.0181
    },

(moet ik die oudere bedragen eigenlijk bewaren? Zo ja, waarom?)

Grafiekje van tarief levering en tarief teruglevering klopt nu wel; zo op het oog een 4 cent verschil.

Wat me nu opvalt is dat DAO erg vaak en volgens mijn onderbuikgevoel ook onterecht voor balanceren kiest (met strategie 'kostprijs').

Vandaag met de optimalisatierun om 14:46 koos DAO voor balanceren, ondanks de beursprijs van -2ct en een accu SoC van 58%. Lijkt me een vrij ideale tijd om de accu vol te laden gezien de lage stroomprijs.
Een kwartier eerder, om 14:31 koos DAO nog wel voor laden met 6kW. Een kwartier later, om 15:01, met een hogere stroomprijs, ook weer 6kW laden en niet balanceren.

Binnen het tijdsblok 14.00-15.00 waren de uitgangscondities voor DAO vandaag toch niet echt anders, dus ik snap niet helemaal goed waarom-ie een kwartier lang voor balanceren koos.

[KC27]

Heb je voor mij de logging en de grafieken van die drie berekeningen (mag ook per pm)?
Verder ben ik wel benieuwd waarom je die berekening ieder kwartier doet of is het gewoon met de hand uitproberen?

[ Voor 40% gewijzigd door KC27 op 14-06-2025 21:52 ]

[DaBit]

Zie PB.
Ik had ze inderdaad expres niet gepost hier; het wordt zo'n bende met die lange lappen tekst hier in de berichten.

Kwa elk kwartier draaien: bedrijfsomstandigheden veranderen en DAO krijgt regelmatig niet wat-ie vraagt.
Veranderende bedrijfsomstandigheden (zoals een EV die ingeplugd wordt) is nog wel te doen door met een automatie de berekening te starten via REST. Maar als dat gemiddeld 7,5 minuut en max 15 minuten later opgepikt wordt is het ook wel prima. KISS.

DAO die niet krijgt wat-ie vraagt is vooral overbelasting van de netaansluiting. Als dat de 25A nadert wordt er geschaald en tegenwoordig varieer ik ook afname van de 3 Victrons op de fases (dus de zwaarst belaste fase doet minder mee met acculaden). Dat elk uur her-evalueren is te langzaam.

Elk kwartier her-evalueren kan (kon?) geen kwaad. Soms helpt het, meestal doet het niet zoveel, maar het vreet ook geen brood.

[ Voor 75% gewijzigd door DaBit op 15-06-2025 21:05 ]

[KC27]

@DaBit
Als er veel verandert dan is frequenter berekenen inderdaad slim.

(moet ik die oudere bedragen eigenlijk bewaren? Zo ja, waarom?)

De oudere bedragen kunnen weg zolang DAO maar kan rekenen met "vorig jaar" (dus 2024).
Misschien komt er ooit nog een rapportage periode "vorig contractjaar" dan moet je misschien (een deel van) 2023 ook nog aanhouden.

[sMoKeFiSh]

Klopt het dat DAO geen rekening houdt met de maximale capaciteit van de hoofdaansluiting tijdens het laden van thuisaccu + EV?

Ik loop vaak tegen issues aan tijdens de gustige tarieven waarbij zowel de thuisaccu als een van de EV's geladen wordt. Een van de EV's wordt met 3x16A geladen, ik zie daarnaast dat DAO dan ook de thuisaccu vaak met 10+ kW wil laden. Hierdoor stopt de laadpaal telkens met laden vanwege de loadbalancing.

In mijn config heb ik het volgende staan voor de hoofdaansluiting en EV's:

code:

"grid": {"max_power": 18},

code:

"charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  1},
        {"ampere": 16, "efficiency" :  1}

Ik had stiekem verwacht dat DAO het load-balancen ook zou meenemen. Aangezien er maar 1 charging stage van 16A is voor het laden van de EV, zou DAO voor het laden van de thuisaccu maar max 7 kW mogen pakken. Klopt het dat DAO het verbruik van de EV niet meetelt?

Ik heb zojuist ook van release 2025.5 naar 2025.6.1 geupgrade zonder problemen. Netjes alle nieuwe namen in config aangepast en alle warnings zijn weg. Bedankt voor de update van deze prachtige addon

[KC27]

sMoKeFiSh schreef op maandag 16 juni 2025 @ 11:51:
Klopt het dat DAO geen rekening houdt met de maximale capaciteit van de hoofdaansluiting tijdens het laden van thuisaccu + EV?

Ik loop vaak tegen issues aan tijdens de gustige tarieven waarbij zowel de thuisaccu als een van de EV's geladen wordt. Een van de EV's wordt met 3x16A geladen, ik zie daarnaast dat DAO dan ook de thuisaccu vaak met 10+ kW wil laden. Hierdoor stopt de laadpaal telkens met laden vanwege de loadbalancing.

In mijn config heb ik het volgende staan voor de hoofdaansluiting en EV's:

code:

"grid": {"max_power": 18},

code:

"charge three phase": "True",
      "charge stages" : [
        {"ampere":  0, "efficiency" :  1},
        {"ampere": 16, "efficiency" :  1}

Ik had stiekem verwacht dat DAO het load-balancen ook zou meenemen. Aangezien er maar 1 charging stage van 16A is voor het laden van de EV, zou DAO voor het laden van de thuisaccu maar max 7 kW mogen pakken. Klopt het dat DAO het verbruik van de EV niet meetelt?

Ik heb zojuist ook van release 2025.5 naar 2025.6.1 geupgrade zonder problemen. Netjes alle nieuwe namen in config aangepast en alle warnings zijn weg. Bedankt voor de update van deze prachtige addon

Als je 18 kW als max vermogen opgeeft zal DAO dat respecteren.
Kun je berekende grafieken en logging van de berekening in een uur dat het "misgaat" hier delen.
DAO zelf kan niet balanceren, maar kan wel aangeven dat er gebalanceerd moet worden. Dat zou dan door een automation in HA gedaan moeten worden.
Ik weet vrijwel zeker dat dat onderdeel in DAO nog veel verbetering behoeft. Dus ik ben benieuwd naar je use-case en wil er graag naar kijken.

[sMoKeFiSh]

EV's zijn nu vol, dus zal als ik ga laden nog eens nieuwe screenshots fixen inclusief de logging.

Hieronder screenshots van zaterdag 15:00. De balk in de grafiek lijkt inderdaad netjes 18kW. De laadpaal zal iets boven de 11kW trekken op dit tijdstip. DAO wil dan nog 9634W laden, wat boven de 18kW uitkomt. De feedin gaat zelfs nog hoger (12+ kW om 15:15) later terwijl de auto nog aan het laden is. Ik laat DAO ook elke 15 minuten een run doen.

[Undertilted]

hoe regelen jullie de EV's? Ik ben wat aan het proberen met OCPP, maxCurrent, maar met mijn lader, als je die te veel wijzigt gaat die in error.

[DaBit]

sMoKeFiSh schreef op maandag 16 juni 2025 @ 16:01:
EV's zijn nu vol, dus zal als ik ga laden nog eens nieuwe screenshots fixen inclusief de logging.

Hieronder screenshots van zaterdag 15:00. De balk in de grafiek lijkt inderdaad netjes 18kW. De laadpaal zal iets boven de 11kW trekken op dit tijdstip. DAO wil dan nog 9634W laden, wat boven de 18kW uitkomt.

Maar op dat moment heb je ook nog aardig wat zonnestroom ter beschikking, en dat komt bovenop die 18kW.

(overigens vind ik dat persoonlijk gevaarlijk veel. Als DAO de 3-fasen accu en 3-fasen auto inschaalt op 18kW afname van het net en er zet iemand nog de oven aan voor broodjes dan zit je op 40+A door een zekering. Zeker porcelein traag kun je vrij fors overbelasten, maar dat vinden die dingen toch niet oneindig lang goed.

Ik laat DAO z'n ding doen, hou in HomeAssistant/NodeRed de stroom door de hoofdzekeringen in de gaten, en als die boven de 25A uit dreigt te komen schaal ik de vermogens naar de grootverbruikers. Auto, accu en boiler kan ik binnen grenzen traploos regelen. Beetje erg specifiek voor mijn situatie denk ik, maar ik zou de flows wel eens kunnen delen als inspiratie)

Undertilted schreef op maandag 16 juni 2025 @ 16:26:
hoe regelen jullie de EV's? Ik ben wat aan het proberen met OCPP, maxCurrent, maar met mijn lader, als je die te veel wijzigt gaat die in error.

Ik heb een Alfen met modbus-TCP optie (duur geintje overigens, maar techniek waar de rondborstige directie interactie mee heeft moet feilloos werken zonder enige zweem van gerommel van mijn kant. Zal wel niet helemaal onbekend klinken).

Aantal fasen en stroom instellen doe ik dan ook via het Ethernet-draadje.
Stroom bijstellen gaat vrij vlekkeloos; ik stuur maximaal 1 message/seconde en dat gaat prima. Aantal fases moet ik inderdaad niet te vaak omschakelen, dat vind-ie niet leuk.

[ Voor 10% gewijzigd door DaBit op 16-06-2025 22:59 ]

[KC27]

sMoKeFiSh schreef op maandag 16 juni 2025 @ 16:01:
EV's zijn nu vol, dus zal als ik ga laden nog eens nieuwe screenshots fixen inclusief de logging.

Hieronder screenshots van zaterdag 15:00. De balk in de grafiek lijkt inderdaad netjes 18kW. De laadpaal zal iets boven de 11kW trekken op dit tijdstip. DAO wil dan nog 9634W laden, wat boven de 18kW uitkomt. De feedin gaat zelfs nog hoger (12+ kW om 15:15) later terwijl de auto nog aan het laden is. Ik laat DAO ook elke 15 minuten een run doen.

DAO berekent om 15:00 uur ongeveer 8 kWh laden in het uur. Maar dat wordt in een kortere periode gezet omdat je alleen maar met 11 kW kunt laden.
Ik denk dat dat nog een foutje van DAO is.
Hij blijft binnen een uur binnen 18 kWh en kijkt (nog) niet naar de instantane vermogens.
Ik ga ernaar kijken of ik dit binnen DAO kan oplossen anders moet je een automation en/of flow toepassen zoals @DaBit.

[sMoKeFiSh]

KC27 schreef op maandag 16 juni 2025 @ 23:37:
[...]

DAO berekent om 15:00 uur ongeveer 8 kWh laden in het uur. Maar dat wordt in een kortere periode gezet omdat je alleen maar met 11 kW kunt laden.
Ik denk dat dat nog een foutje van DAO is.
Hij blijft binnen een uur binnen 18 kWh en kijkt (nog) niet naar de instantane vermogens.
Ik ga ernaar kijken of ik dit binnen DAO kan oplossen anders moet je een automation en/of flow toepassen zoals @DaBit.

Bedankt voor de toelichting. Voor mijn gevoel zou het mooier zijn als DAO rekening houdt met het vermogen van de geselecteerde EV charging stage en daarmee inclusief accu laden van grid nooit boven het geconfigureerde max vermogen van de aansluiting komt.

Als eventuele andere oplossing kan ik natuurlijk ook meer charging stages toevoegen aan mijn config. Als DAO via een entity de geselecteerde charging stage kan doorgeven aan HA, kan ik die weer aan m'n Alfen laadpaal doorgeven.

DaBit schreef op maandag 16 juni 2025 @ 22:56:
[...]


(overigens vind ik dat persoonlijk gevaarlijk veel. Als DAO de 3-fasen accu en 3-fasen auto inschaalt op 18kW afname van het net en er zet iemand nog de oven aan voor broodjes dan zit je op 40+A door een zekering. Zeker porcelein traag kun je vrij fors overbelasten, maar dat vinden die dingen toch niet oneindig lang goed.

Ik laat DAO z'n ding doen, hou in HomeAssistant/NodeRed de stroom door de hoofdzekeringen in de gaten, en als die boven de 25A uit dreigt te komen schaal ik de vermogens naar de grootverbruikers. Auto, accu en boiler kan ik binnen grenzen traploos regelen. Beetje erg specifiek voor mijn situatie denk ik, maar ik zou de flows wel eens kunnen delen als inspiratie)

Ik heb hier 2x een Eve Single Pro-line laadpaal. Deze zitten als enige (samen met de accu) direct op grid. Elk ander verbruik (complete woning) zit achter de 2 Deye hybride omvormers en worden altijd uit accu en/of PV gevoed (tenzij accu leeg is, maar dat komt nooit voor). Op beide laadpalen is loadbalancing enabled en ze zijn verbonden met de P1 poort van de slimme meter. Ik ben dus niet zo bang dat er een automaat uitgaat door overbelasting.

Het enige probleem dat ik nu heb komt waarschijnlijk ook door de manier waarmee ik het laden van de Alfen laadpaal start. Ik kijk of de helper dao_ev_charging op enabled staat, dan zet ik de "Power Connector Max Current Socket 1" van de betreffende laadpaal op 16A. Zodra helper dao_ev_charging op disabled staat, zet ik de max current weer op 5 en stopt de laadpaal met laden.

Omdat ik de current van de Alfen laadpaal op 16A forceer, kan de laadpaal zelf zijn vermogen niet dynamisch aanpassen dmv de loadbalancing data van de P1 poort en stopt de laadpaal tijdelijk met laden als het max vermogen uit grid te hoog wordt. Dit zorgt weer voor extreem veel notificaties van de Kia en Tesla app's met de melding dat het laden onderbroken is. Weet jij een betere manier om het laden te starten/pauzeren van de Alfen laadpaal?

[Bravo]

sMoKeFiSh schreef op dinsdag 17 juni 2025 @ 07:55:
[...]


Bedankt voor de toelichting. Voor mijn gevoel zou het mooier zijn als DAO rekening houdt met het vermogen van de geselecteerde EV charging stage en daarmee inclusief accu laden van grid nooit boven het geconfigureerde max vermogen van de aansluiting komt.

Als eventuele andere oplossing kan ik natuurlijk ook meer charging stages toevoegen aan mijn config. Als DAO via een entity de geselecteerde charging stage kan doorgeven aan HA, kan ik die weer aan m'n Alfen laadpaal doorgeven.


[...]


Ik heb hier 2x een Eve Single Pro-line laadpaal. Deze zitten als enige (samen met de accu) direct op grid. Elk ander verbruik (complete woning) zit achter de 2 Deye hybride omvormers en worden altijd uit accu en/of PV gevoed (tenzij accu leeg is, maar dat komt nooit voor). Op beide laadpalen is loadbalancing enabled en ze zijn verbonden met de P1 poort van de slimme meter. Ik ben dus niet zo bang dat er een automaat uitgaat door overbelasting.

Het enige probleem dat ik nu heb komt waarschijnlijk ook door de manier waarmee ik het laden van de Alfen laadpaal start. Ik kijk of de helper dao_ev_charging op enabled staat, dan zet ik de "Power Connector Max Current Socket 1" van de betreffende laadpaal op 16A. Zodra helper dao_ev_charging op disabled staat, zet ik de max current weer op 5 en stopt de laadpaal met laden.

Omdat ik de current van de Alfen laadpaal op 16A forceer, kan de laadpaal zelf zijn vermogen niet dynamisch aanpassen dmv de loadbalancing data van de P1 poort en stopt de laadpaal tijdelijk met laden als het max vermogen uit grid te hoog wordt. Dit zorgt weer voor extreem veel notificaties van de Kia en Tesla app's met de melding dat het laden onderbroken is. Weet jij een betere manier om het laden te starten/pauzeren van de Alfen laadpaal?

Als je meerdere punten aangeeft voor de EV om te laden, dan geeft DAO netjes het amperage aan wat bedoelt is voor de EV in de output. Dat kun je doorgeven aan de Alfen als current, zoals je nu ook de 16A doorgeeft via een automation. Het wordt door DAO doorgegeven als set_car_charge_ampere.
Je zou de Alfen op Fast Charging (oid) kunnen instellen als je wil laden, dan heeft de paal zelf nog de ruimte om te schalen binnen de load balancing en schakelt hij niet de hele tijd aan en uit.

En met dat vele in- en uitschakelen zou ik een beetje terughoudend zijn. Dat is niet leuk voor de paal, niet leuk voor de auto en zal zorgen voor verhoogde slijtage door telkens de relais aan te trekken en weer los te laten om het laden te starten en te stoppen.

[KC27]

sMoKeFiSh schreef op dinsdag 17 juni 2025 @ 07:55:
[...]


Bedankt voor de toelichting. Voor mijn gevoel zou het mooier zijn als DAO rekening houdt met het vermogen van de geselecteerde EV charging stage en daarmee inclusief accu laden van grid nooit boven het geconfigureerde max vermogen van de aansluiting komt.

Als eventuele andere oplossing kan ik natuurlijk ook meer charging stages toevoegen aan mijn config. Als DAO via een entity de geselecteerde charging stage kan doorgeven aan HA, kan ik die weer aan m'n Alfen laadpaal doorgeven.


[...]


Ik heb hier 2x een Eve Single Pro-line laadpaal. Deze zitten als enige (samen met de accu) direct op grid. Elk ander verbruik (complete woning) zit achter de 2 Deye hybride omvormers en worden altijd uit accu en/of PV gevoed (tenzij accu leeg is, maar dat komt nooit voor). Op beide laadpalen is loadbalancing enabled en ze zijn verbonden met de P1 poort van de slimme meter. Ik ben dus niet zo bang dat er een automaat uitgaat door overbelasting.

Het enige probleem dat ik nu heb komt waarschijnlijk ook door de manier waarmee ik het laden van de Alfen laadpaal start. Ik kijk of de helper dao_ev_charging op enabled staat, dan zet ik de "Power Connector Max Current Socket 1" van de betreffende laadpaal op 16A. Zodra helper dao_ev_charging op disabled staat, zet ik de max current weer op 5 en stopt de laadpaal met laden.

Omdat ik de current van de Alfen laadpaal op 16A forceer, kan de laadpaal zelf zijn vermogen niet dynamisch aanpassen dmv de loadbalancing data van de P1 poort en stopt de laadpaal tijdelijk met laden als het max vermogen uit grid te hoog wordt. Dit zorgt weer voor extreem veel notificaties van de Kia en Tesla app's met de melding dat het laden onderbroken is. Weet jij een betere manier om het laden te starten/pauzeren van de Alfen laadpaal?

Het is precies zoals @Bravo aangeeft: als je meer stages toevoegt aan je DAO-ev-settings dan zal DAO berekenen wat het beste uitkomt. Als je dan de "lagere" stages met een iets hogere efficiency waardeert bijvoorbeeld 1 (=100%) tov 0.99 (=99%) zullen deze de voorkeur krijgen als het kwa prijs niet uitmaakt.
Wat je ook kunt doen:
DAO communiceert twee zaken:
- het aantal ampere waarmee geladen moet worden in "entity_charging_ampere"
- het tijdstip waarop het laden moet worden gestopt in "entity_stop_laden"
Als die laatste is gezet (heeft een waarde in het lopende uur) en de eerste is groter dan 0 dat je dat dan omrekent naar een gemiddeld amperage over een heel uur en die waarde dan communiceert naar de laadpaal.
Bijvoorbeeld (eenvoudig voorbeeld):
DAO communiceert om 10:00 uur 16 A
en wil stoppen om 10:40 uur
dan is het uurgemiddelde: 16 x 40/60 = 10,6 A
Je communiceert dan 10,6 A naar de laadpaal.
Dat kan redelijk eenvoudig met een automation, die je triggert bij verandering van een van de genoemde entities.

[Impossibl3]

Ik neem aan dat je laadpaal als die al slim is toch wel iedere seconden een ander ampèrage kan hebben? (of het wenselijk is voor de elektronica daar gelaten). Mijn Easee paal kan ik op hele ampère instellen op ieder moment. Zo draai ik nom op mijn PV. Wel heb ik, wegens EU wetgeving, een start ampèrage van 6 Amp. Maar zo doende kan je wel goed kijken wat het meest efficiënts is. Bijvoorbeeld de vaatwasser starten na de auto laden zodat de opwarm piek (1200 watt ~ 5 Amp) van de vaatwasser na de auto komt.

Ik snap dus niet helemaal waarom je het maximale ampèrage wil spreiden over het hele uur.

[ Voor 8% gewijzigd door Impossibl3 op 17-06-2025 10:13 ]

[Bravo]

KC27 schreef op dinsdag 17 juni 2025 @ 09:58:
[...]

Het is precies zoals @Bravo aangeeft: als je meer stages toevoegt aan je DAO-ev-settings dan zal DAO berekenen wat het beste uitkomt. Als je dan de "lagere" stages met een iets hogere efficiency waardeert bijvoorbeeld 1 (=100%) tov 0.99 (=99%) zullen deze de voorkeur krijgen als het kwa prijs niet uitmaakt.
Wat je ook kunt doen:
DAO communiceert twee zaken:
- het aantal ampere waarmee geladen moet worden in "entity_charging_ampere"
- het tijdstip waarop het laden moet worden gestopt in "entity_stop_laden"
Als die laatste is gezet (heeft een waarde in het lopende uur) en de eerste is groter dan 0 dat je dat dan omrekent naar een gemiddeld amperage over een heel uur en die waarde dan communiceert naar de laadpaal.
Bijvoorbeeld (eenvoudig voorbeeld):
DAO communiceert om 10:00 uur 16 A
en wil stoppen om 10:40 uur
dan is het uurgemiddelde: 16 x 40/60 = 10,6 A
Je communiceert dan 10,6 A naar de laadpaal.
Dat kan redelijk eenvoudig met een automation, die je triggert bij verandering van een van de genoemde entities.

De praktische uitwerking vind ik omslachtig van het voorbeeld wat je geeft met het laden op een deel van het uur. De functionaliteit van de efficiency wordt omzeilt als het gaat om het bereiken van de laagste kosten. Daarnaast wil ik helemaal niet dat ik meerdere starts/stops heb, omdat het slijtage oplevert aan de apparatuur (lader, EV). Geen idee wat die kosten zijn en of je die in het mdoel kunt verwerken, maar dat lijkt mij ook niet nodig.

DAO is een heel mooi platform wat veel inzicht levert en ook de batterijen optimaal kan benutten.
Zelf simuleer ik al 2027 qua instellingen en gebruik ik de uitkomsten van DAO niet als directe waarden voor de batterij of EV, maar zet ze om in een mode/strategie. De EV-lader en batterij hebben allebei zelf ook intelligentie en kunnen NOM behalen, wat in het post salderen tijdperk nuttig is om PV overschot in huis te houden en import uit het grid te minimaliseren. De modi zijn: NOM met zowel overschot laden (zowel EV als batterij) en ontladen (huisondersteuning batterij), force charge (batterij en EV, loadbalancing regelt de grid limiet) en force discharge (batterij) als er nog wat te verdienen valt aan het opgeslagen PV overschot/Day Ahead handel.
Hiermee vang je ook op dat er 'onverwacht' gedrag is doordat je een keer meer/minder energie verbruikt of opwek hebt.

Geen idee of anderen dit ook zo zien en gebruiken, of dat ik DAO nu enorm aan het misbruiken ben

[f.welvering]

Ik ben ondertussen al even aan het stoeien met DAO ondanks ik nog geen accu of dynamisch contract heb.
Ik zie veel mooie grafiekjes voorbij komen, maar de mijne ziet er niet echt mooi uit. wat doe ik verkeerd?

[Bravo]

f.welvering schreef op dinsdag 17 juni 2025 @ 11:48:
Ik ben ondertussen al even aan het stoeien met DAO ondanks ik nog geen accu of dynamisch contract heb.
Ik zie veel mooie grafiekjes voorbij komen, maar de mijne ziet er niet echt mooi uit. wat doe ik verkeerd?

[Afbeelding]

Dat is de grafiek na het ophalen van de meteo informatie, met de verwachte PV-opwek in de komende 8 dagen (eerst per uur, daarna grovere blokken). Als je het in tekst bekijkt kun je het vast beter begrijpen.

[sMoKeFiSh]

KC27 schreef op dinsdag 17 juni 2025 @ 09:58:
[...]

Het is precies zoals @Bravo aangeeft: als je meer stages toevoegt aan je DAO-ev-settings dan zal DAO berekenen wat het beste uitkomt. Als je dan de "lagere" stages met een iets hogere efficiency waardeert bijvoorbeeld 1 (=100%) tov 0.99 (=99%) zullen deze de voorkeur krijgen als het kwa prijs niet uitmaakt.
Wat je ook kunt doen:
DAO communiceert twee zaken:
- het aantal ampere waarmee geladen moet worden in "entity_charging_ampere"
- het tijdstip waarop het laden moet worden gestopt in "entity_stop_laden"
Als die laatste is gezet (heeft een waarde in het lopende uur) en de eerste is groter dan 0 dat je dat dan omrekent naar een gemiddeld amperage over een heel uur en die waarde dan communiceert naar de laadpaal.
Bijvoorbeeld (eenvoudig voorbeeld):
DAO communiceert om 10:00 uur 16 A
en wil stoppen om 10:40 uur
dan is het uurgemiddelde: 16 x 40/60 = 10,6 A
Je communiceert dan 10,6 A naar de laadpaal.
Dat kan redelijk eenvoudig met een automation, die je triggert bij verandering van een van de genoemde entities.

Bedankt voor de extra info. Ik heb wat extra charging stages toegevoegd (8 tm 15A). Eens kijken of het hier ook beter mee gaat.

[f.welvering]

Bravo schreef op dinsdag 17 juni 2025 @ 11:53:
[...]

Dat is de grafiek na het ophalen van de meteo informatie, met de verwachte PV-opwek in de komende 8 dagen (eerst per uur, daarna grovere blokken). Als je het in tekst bekijkt kun je het vast beter begrijpen.

Ah duidelijk!
Maar als ik door alle grafieken klik krijg ik enkel deze, er zal dan vermoed ik ergens iets niet werken wat de andere grafiek zou moeten maken denk ik?

code:

31   22 2025-06-18 22:00:00       NaN       NaN  0.386  0.000000      0
32   23 2025-06-18 23:00:00       NaN       NaN  0.308  0.000000      0
2025-06-17 15:45:56 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-06-17 15:45:56 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-17 15:45:56 waarschuwing: Geen oplossing  voor: minimize cost

Wellicht dat bovenstaande dit veroorzaakt.

[ Voor 32% gewijzigd door f.welvering op 17-06-2025 15:46 ]

[KC27]

f.welvering schreef op dinsdag 17 juni 2025 @ 15:44:
[...]


Ah duidelijk!
Maar als ik door alle grafieken klik krijg ik enkel deze, er zal dan vermoed ik ergens iets niet werken wat de andere grafiek zou moeten maken denk ik?

code:

31   22 2025-06-18 22:00:00       NaN       NaN  0.386  0.000000      0
32   23 2025-06-18 23:00:00       NaN       NaN  0.308  0.000000      0
2025-06-17 15:45:56 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-06-17 15:45:56 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-17 15:45:56 waarschuwing: Geen oplossing  voor: minimize cost

Wellicht dat bovenstaande dit veroorzaakt.

Misschien kun je je instellingen delen?
En een volledige logging van de laatste berekening.

[ Voor 3% gewijzigd door KC27 op 17-06-2025 16:05 ]

[f.welvering]

KC27 schreef op dinsdag 17 juni 2025 @ 16:04:
[...]

Misschien kun je je instellingen delen?
En een volledige logging van de laatste berekening.

Zeker:
Config:

code:

{
{
  "homeassistant": {
    "host": "192.168.60.3",
    "ip port": 8123,
    "token": "!secret ha_api_token"
  },
  "database ha": {
    "engine": "mysql",
    "server": "192.168.60.3",
    "port": 3306,
    "database": "homeassistant",
    "username": "dao",
    "password": "!secret db_da_password"
  },
  "database da": {
    "engine": "mysql",
    "server": "192.168.60.3",
    "port": 3306,
    "database": "dao",
    "username": "dao",
    "password": "!secret db_da_password"
  },
  "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": {
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2024-08-01": 0.020496
    },
    "vat": {
      "2023-01-01": 21
    },
    "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": "2024-09-01",
    "tax refund": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "False",
    "average consumption": "False"
  },
  "logging level" : "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "false",
    "average consumption": "false"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False"
  },
  "heating": {
    "heater present": "False"
  },
  "battery": [ ],
  "solar": [
    { "name" : "main",
      "tilt": 50,
      "orientation": 160,
      "capacity": 9.0,
      "yield": 0.0180625,
      "entity pv switch": "input_boolean.pv_main_aan_uit"
  }],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.p1_meter_energie_import_tarief_1",
      "sensor.p1_meter_energie_import_tarief_2"
    ],
    "entities grid production": [
      "sensor.p1_meter_energie_export_tarief_1",
      "sensor.p1_meter_energie_export_tarief_2"
    ],
    "entities solar production ac": [
      "sensor.solaredge_panel_production_daily"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : [],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": [],
    "entities battery 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",
    "2359": "clean_data"
  }
}

Log

code:

025-06-17 16:07:29 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-17 16:07:29 info: Day Ahead Optimalisering gestart op: 17-06-2025 16:07:29
2025-06-17 16:07:29 info: Day Ahead Optimalisatie gestart: 17-06-2025 16:07:29 taak: calc_optimum
2025-06-17 16:07:29 info: Debug = False
2025-06-17 16:07:29 info: Zelf berekende baseload
2025-06-17 16:07:29 info: Start waarden: 
    uur                tijd       p_l       p_t   base     pv_ac  pv_dc
0    16 2025-06-17 16:00:00  0.274714  0.274714  0.449  1.731585      0
1    17 2025-06-17 17:00:00  0.302544  0.302544  5.109  1.660790      0
2    18 2025-06-17 18:00:00  0.435160  0.435160  7.476  2.171827      0
3    19 2025-06-17 19:00:00  0.432848  0.432848  4.472  1.675457      0
4    20 2025-06-17 20:00:00  0.317535  0.317535  1.540  0.596896      0
5    21 2025-06-17 21:00:00  0.288725  0.288725  3.710  0.147266      0
6    22 2025-06-17 22:00:00  0.284394  0.284394  1.353  0.000000      0
7    23 2025-06-17 23:00:00  0.277230  0.277230  0.544  0.000000      0
8     0 2025-06-18 00:00:00  0.270612  0.270612  0.284  0.000000      0
9     1 2025-06-18 01:00:00  0.264235  0.264235  0.282  0.000000      0
10    2 2025-06-18 02:00:00  0.265433  0.265433  0.288  0.000000      0
11    3 2025-06-18 03:00:00  0.274024  0.274024  0.453  0.000000      0
12    4 2025-06-18 04:00:00  0.284575  0.284575  0.530  0.000000      0
13    5 2025-06-18 05:00:00  0.287564  0.287564  0.345  0.055634      0
14    6 2025-06-18 06:00:00  0.287177  0.287177  0.261  0.933216      0
15    7 2025-06-18 07:00:00  0.256128  0.256128  0.570  1.082545      0
16    8 2025-06-18 08:00:00  0.174017  0.174017  0.456  1.174981      0
17    9 2025-06-18 09:00:00  0.149079  0.149079  1.306  1.223650      0
18   10 2025-06-18 10:00:00  0.147506  0.147506  0.948  1.297351      0
19   11 2025-06-18 11:00:00  0.147083  0.147083  0.859  1.473755      0
20   12 2025-06-18 12:00:00  0.146405  0.146405  0.866  1.681076      0
21   13 2025-06-18 13:00:00  0.147301  0.147301  1.532  1.864969      0
22   14 2025-06-18 14:00:00  0.150350  0.150350  0.566  2.088593      0
23   15 2025-06-18 15:00:00  0.236139  0.236139  0.532  2.306070      0
24   16 2025-06-18 16:00:00  0.275173  0.275173  1.487  2.440201      0
25   17 2025-06-18 17:00:00  0.289100  0.289100  5.144  2.432890      0
26   18 2025-06-18 18:00:00  0.318745  0.318745  4.630  2.440477      0
27   19 2025-06-18 19:00:00  0.359801  0.359801  4.730  2.120656      0
28   20 2025-06-18 20:00:00  0.312308  0.312308  4.533  1.306222      0
29   21 2025-06-18 21:00:00  0.292864  0.292864  1.213  0.265193      0
30   22 2025-06-18 22:00:00       NaN       NaN  0.386  0.000000      0
31   23 2025-06-18 23:00:00       NaN       NaN  0.308  0.000000      0
2025-06-17 16:07:30 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-06-17 16:07:30 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-17 16:07:30 waarschuwing: Geen oplossing  voor: minimize cost

[Bravo]

f.welvering schreef op dinsdag 17 juni 2025 @ 16:07:
[...]


Zeker:
Config:

code:

{
{
  "homeassistant": {
    "host": "192.168.60.3",
    "ip port": 8123,
    "token": "!secret ha_api_token"
  },
  "database ha": {
    "engine": "mysql",
    "server": "192.168.60.3",
    "port": 3306,
    "database": "homeassistant",
    "username": "dao",
    "password": "!secret db_da_password"
  },
  "database da": {
    "engine": "mysql",
    "server": "192.168.60.3",
    "port": 3306,
    "database": "dao",
    "username": "dao",
    "password": "!secret db_da_password"
  },
  "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": {
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2024-08-01": 0.020496
    },
    "vat": {
      "2023-01-01": 21
    },
    "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": "2024-09-01",
    "tax refund": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "False",
    "average consumption": "False"
  },
  "logging level" : "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "false",
    "average consumption": "false"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False"
  },
  "heating": {
    "heater present": "False"
  },
  "battery": [ ],
  "solar": [
    { "name" : "main",
      "tilt": 50,
      "orientation": 160,
      "capacity": 9.0,
      "yield": 0.0180625,
      "entity pv switch": "input_boolean.pv_main_aan_uit"
  }],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.p1_meter_energie_import_tarief_1",
      "sensor.p1_meter_energie_import_tarief_2"
    ],
    "entities grid production": [
      "sensor.p1_meter_energie_export_tarief_1",
      "sensor.p1_meter_energie_export_tarief_2"
    ],
    "entities solar production ac": [
      "sensor.solaredge_panel_production_daily"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : [],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": [],
    "entities battery 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",
    "2359": "clean_data"
  }
}

Log

code:

025-06-17 16:07:29 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-17 16:07:29 info: Day Ahead Optimalisering gestart op: 17-06-2025 16:07:29
2025-06-17 16:07:29 info: Day Ahead Optimalisatie gestart: 17-06-2025 16:07:29 taak: calc_optimum
2025-06-17 16:07:29 info: Debug = False
2025-06-17 16:07:29 info: Zelf berekende baseload
2025-06-17 16:07:29 info: Start waarden: 
    uur                tijd       p_l       p_t   base     pv_ac  pv_dc
0    16 2025-06-17 16:00:00  0.274714  0.274714  0.449  1.731585      0
1    17 2025-06-17 17:00:00  0.302544  0.302544  5.109  1.660790      0
2    18 2025-06-17 18:00:00  0.435160  0.435160  7.476  2.171827      0
3    19 2025-06-17 19:00:00  0.432848  0.432848  4.472  1.675457      0
4    20 2025-06-17 20:00:00  0.317535  0.317535  1.540  0.596896      0
5    21 2025-06-17 21:00:00  0.288725  0.288725  3.710  0.147266      0
6    22 2025-06-17 22:00:00  0.284394  0.284394  1.353  0.000000      0
7    23 2025-06-17 23:00:00  0.277230  0.277230  0.544  0.000000      0
8     0 2025-06-18 00:00:00  0.270612  0.270612  0.284  0.000000      0
9     1 2025-06-18 01:00:00  0.264235  0.264235  0.282  0.000000      0
10    2 2025-06-18 02:00:00  0.265433  0.265433  0.288  0.000000      0
11    3 2025-06-18 03:00:00  0.274024  0.274024  0.453  0.000000      0
12    4 2025-06-18 04:00:00  0.284575  0.284575  0.530  0.000000      0
13    5 2025-06-18 05:00:00  0.287564  0.287564  0.345  0.055634      0
14    6 2025-06-18 06:00:00  0.287177  0.287177  0.261  0.933216      0
15    7 2025-06-18 07:00:00  0.256128  0.256128  0.570  1.082545      0
16    8 2025-06-18 08:00:00  0.174017  0.174017  0.456  1.174981      0
17    9 2025-06-18 09:00:00  0.149079  0.149079  1.306  1.223650      0
18   10 2025-06-18 10:00:00  0.147506  0.147506  0.948  1.297351      0
19   11 2025-06-18 11:00:00  0.147083  0.147083  0.859  1.473755      0
20   12 2025-06-18 12:00:00  0.146405  0.146405  0.866  1.681076      0
21   13 2025-06-18 13:00:00  0.147301  0.147301  1.532  1.864969      0
22   14 2025-06-18 14:00:00  0.150350  0.150350  0.566  2.088593      0
23   15 2025-06-18 15:00:00  0.236139  0.236139  0.532  2.306070      0
24   16 2025-06-18 16:00:00  0.275173  0.275173  1.487  2.440201      0
25   17 2025-06-18 17:00:00  0.289100  0.289100  5.144  2.432890      0
26   18 2025-06-18 18:00:00  0.318745  0.318745  4.630  2.440477      0
27   19 2025-06-18 19:00:00  0.359801  0.359801  4.730  2.120656      0
28   20 2025-06-18 20:00:00  0.312308  0.312308  4.533  1.306222      0
29   21 2025-06-18 21:00:00  0.292864  0.292864  1.213  0.265193      0
30   22 2025-06-18 22:00:00       NaN       NaN  0.386  0.000000      0
31   23 2025-06-18 23:00:00       NaN       NaN  0.308  0.000000      0
2025-06-17 16:07:30 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-06-17 16:07:30 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-17 16:07:30 waarschuwing: Geen oplossing  voor: minimize cost

Er is voor DAO niets om mee te rekenen, dus wordt er geen resultaat gemaakt.
Je moet minimaal 1 ding toevoegen die geoptimaliseerd kan worden, een machine, batterij, boiler, WP of EV.

@KC27 : featurerequest: Is het mogelijk om wel grafieken te tonen als er geen optimalisatie gedaan kan worden, maar als de basisinformatie (pv, prices, baseload) wel bekend is?

edit: Ik vroeg mij af wat er zou gebeuren als je alleen een EV geconfigureerd hebt, die niet beschikbaar is of geen laaddoel heeft.
Hoewel er niets te rekenen valt, weet DAO toch een winst van 0.02 euro te behalen

edit2: Featurerequest zou dus al kunnen worden ingevuld door standaard een niet beschikbare EV in de config op te nemen

[DaBit]

Weet jij een betere manier om het laden te starten/pauzeren van de Alfen laadpaal?

Ik schrijf dan 0 Ampere naar modbus adres 1210 van de paal. De status van het chargepoint gaat dan naar B1/Connected. Zo gauw ik de stroom weer boven de 6A zet gaat het laden verder. Aantal fases schrijf ik naar adres 1215, en dat doe ik maximaal 1x per minuut anders gebeuren er rare dingen inderdaad.

Zonder modbus-communicatie doet de paal 3x10A overigens. Kun je ergens in dat Alfen-spul instellen. Is alweer te lang geleden om exact te herinneren waar.

DAO laat ik de laadpaal beschouwen als een enkelfasige met stroom tussen 6A en 48A. NodeRED/Javascript logica maakt van 6-16A enkelfasig laden, daarboven driefasig (waarbij het minimum dan 3x6A is).

DAO kan dus vrij nauwkeurig het laadvermogen kiezen wat er nodig is om de auto op het eind van het uur op de gewenste SoC te hebben.

[Hedzie]

@KC27

Gisteren zag ik dit in mijn log:
Sessy1 staat te laden terwijl Sessy2 staat te ontladen.

code:

2025-06-16 22:00:00 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-16 22:00:00 info: Day Ahead Optimalisering gestart op: 16-06-2025 22:00:00
2025-06-16 22:00:00 info: Day Ahead Optimalisatie gestart: 16-06-2025 22:00:00 taak: calc_optimum
2025-06-16 22:00:00 info: Debug = False
2025-06-16 22:00:00 info: Zelf berekende baseload
2025-06-16 22:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    22 2025-06-16 22:00:00   0.31   0.19   0.12   0.00      0
1    23 2025-06-16 23:00:00   0.28   0.16   0.10   0.00      0
2     0 2025-06-17 00:00:00   0.28   0.15   0.51   0.00      0
3     1 2025-06-17 01:00:00   0.27   0.15   1.02   0.00      0
4     2 2025-06-17 02:00:00   0.26   0.14   1.23   0.00      0
5     3 2025-06-17 03:00:00   0.26   0.14   0.87   0.00      0
6     4 2025-06-17 04:00:00   0.26   0.14   0.30   0.00      0
7     5 2025-06-17 05:00:00   0.27   0.15  -0.02   0.17      0
8     6 2025-06-17 06:00:00   0.29   0.17   0.03   1.01      0
9     7 2025-06-17 07:00:00   0.28   0.16  -0.01   1.93      0
10    8 2025-06-17 08:00:00   0.27   0.15   0.04   3.98      0
11    9 2025-06-17 09:00:00   0.25   0.13  -0.11   5.80      0
12   10 2025-06-17 10:00:00   0.15   0.03   0.06   5.88      0
13   11 2025-06-17 11:00:00   0.15   0.02   0.26   6.46      0
14   12 2025-06-17 12:00:00   0.15   0.02   0.24   6.89      0
15   13 2025-06-17 13:00:00   0.14   0.02   0.20   6.86      0
16   14 2025-06-17 14:00:00   0.14   0.02   0.13   6.12      0
17   15 2025-06-17 15:00:00   0.15   0.02   0.12   4.68      0
18   16 2025-06-17 16:00:00   0.16   0.04   0.25   3.45      0
19   17 2025-06-17 17:00:00   0.24   0.12   0.66   4.14      0
20   18 2025-06-17 18:00:00   0.27   0.15   0.24   2.86      0
21   19 2025-06-17 19:00:00   0.30   0.18   0.60   2.00      0
22   20 2025-06-17 20:00:00   0.43   0.31   0.25   1.07      0
23   21 2025-06-17 21:00:00   0.43   0.31   0.28   0.32      0
24   22 2025-06-17 22:00:00   0.32   0.19   0.25   0.00      0
25   23 2025-06-17 23:00:00   0.29   0.17   0.20   0.00      0
2025-06-16 22:00:00 info: No reduced hours applied for Sessy1
2025-06-16 22:00:00 info: Startwaarde SoC Sessy1: 47.0%
2025-06-16 22:00:00 info: No reduced hours applied for Sessy2
2025-06-16 22:00:00 info: Startwaarde SoC Sessy2: 54.0%
2025-06-16 22:00:00 info: Boiler opwarmen wordt ingepland tussen: 16 en 23 uur
2025-06-16 22:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-16 22:00:47 info: Eerste berekening
2025-06-16 22:00:47 info: Kosten (euro): -0.77 
2025-06-16 22:00:47 info: Levering (kWh): 0.05  
2025-06-16 22:01:50 info: Herberekening
2025-06-16 22:01:50 info: Kosten (euro): -5.73 
2025-06-16 22:01:50 info: Levering (kWh): 0.05  
2025-06-16 22:01:50 info: Strategie: minimale levering
2025-06-16 22:01:50 info: Het programma heeft een optimale oplossing gevonden.
2025-06-16 22:01:50 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -2.82 
2025-06-16 22:01:50 info: Geoptimaliseerd, kosten met day ahead tarieven: -5.73 
2025-06-16 22:01:50 info: Levering: 0.05   (kWh)
2025-06-16 22:01:50 info: Waarde boiler om 23 uur: 2.66 kWh
2025-06-16 22:01:50 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      %      %
    22   0.60  92.86   0.55   0.00   0.55 100.00   0.55  92.86  57.08
    23  -0.10  82.90  -0.11   0.00  -0.11 100.00  -0.11  82.90  55.00
     0  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  45.31
     1  -0.17  88.20  -0.20   0.00  -0.20 100.00  -0.20  88.20  41.76
     2  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  32.07
     3  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  15.92
     4  -0.30  92.10  -0.33   0.00  -0.33 100.00  -0.33  92.10  10.00
     5   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     6   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     7   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     8   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     9   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    10   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    11   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    12   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    13   1.81  92.69   1.68   0.00   1.68 100.00   1.68  92.69  40.58
    14   1.98  92.11   1.82   0.00   1.82 100.00   1.82  92.11  73.74
    15   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    19   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    20  -1.53  92.90  -1.65   0.00  -1.65 100.00  -1.65  92.90  70.06
    21  -1.53  92.90  -1.64   0.00  -1.64 100.00  -1.64  92.90  40.16
    22  -1.36  92.90  -1.46   0.00  -1.46 100.00  -1.46  92.90  13.55
    23  -0.17  88.20  -0.20   0.00  -0.20 100.00  -0.20  88.20  10.00
Totaal  -1.09     --  -2.03   0.00  -2.04     --  -2.04     --       
2025-06-16 22:01:50 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      %      %
    22  -0.75  95.70  -0.78   0.00  -0.78 100.00  -0.78  95.70  39.78
    23   0.00     --   0.00   0.00   0.00     --   0.00     --  39.78
     0   0.01  94.90   0.00   0.00   0.00 100.00   0.00  94.90  39.87
     1  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  23.72
     2  -0.72  95.70  -0.75   0.00  -0.75 100.00  -0.75  95.70  10.00
     3   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     4   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     5   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     6   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     7   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     8   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     9   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    10   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    11   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    12   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    13   1.81  92.69   1.68   0.00   1.68 100.00   1.68  92.69  40.58
    14   1.98  92.11   1.82   0.00   1.82 100.00   1.82  92.11  73.74
    15   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    19  -0.09  82.90  -0.10   0.00  -0.10 100.00  -0.10  82.90  98.14
    20  -1.57  92.50  -1.70   0.00  -1.70 100.00  -1.70  92.50  67.23
    21  -1.57  92.50  -1.70   0.00  -1.70 100.00  -1.70  92.50  36.32
    22  -1.35  93.60  -1.45   0.00  -1.45 100.00  -1.45  93.60  10.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
Totaal  -1.57     --  -2.42   0.00  -2.42     --  -2.42     --       
2025-06-16 22:01:53 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 22.00    0.60     0.75   0.00   0.03   0.12   0.00   0.00   0.00   0.00   0.00   -0.01  45.26
 23.00    0.00     0.10   0.00   0.00   0.10   0.00   0.00   0.00   0.00   0.00   -0.00  45.02
  0.00    0.01     0.51   0.00   0.00   0.51   0.00   0.00   0.00   0.00   0.00   -0.00  44.79
  1.00    0.00     1.02   0.00   0.00   1.02   0.00   0.00   0.00   0.00   0.00   -0.00  44.55
  2.00    0.00     1.23   0.00   0.00   1.23   0.00   0.00   0.00   0.00   0.00   -0.00  44.31
  3.00    0.00     0.85   0.02   0.00   0.87   0.00   0.00   0.00   0.00   0.01   -0.00  44.07
  4.00    0.00     0.30   0.00   0.00   0.30   0.00   0.00   0.00   0.00   0.00   -0.00  43.84
  5.00    0.00     0.00   0.00   0.19  -0.02   0.00   0.00   0.00   0.16   0.00   -0.03  43.60
  6.00    0.00     0.00   0.00   0.98   0.03   0.00   0.00   0.00   1.01   0.00   -0.17  43.36
  7.00    0.00     0.00   0.00   1.94  -0.01   0.00   0.00   0.00   1.93   0.00   -0.30  43.12
  8.00    0.00     0.00   0.00   3.94   0.04   0.00   0.00   0.00   3.98   0.00   -0.58  42.89
  9.00    0.00     0.00   0.00   5.92  -0.11   0.00   0.00   0.00   5.80   0.00   -0.76  42.65
 10.00    0.00     0.00   0.00   5.82   0.06   0.00   0.00   0.00   5.88   0.00   -0.17  42.41
 11.00    0.00     0.00   0.00   6.20   0.26   0.00   0.00   0.00   6.46   0.00   -0.15  42.17
 12.00    0.00     0.00   0.00   6.65   0.24   0.00   0.00   0.00   6.89   0.00   -0.16  41.94
 13.00    3.63     0.00   0.00   3.04   0.20   0.00   0.00   0.00   6.86   0.00   -0.06  41.70
 14.00    3.96     0.00   0.00   2.03   0.13   0.00   0.00   0.00   6.12   0.00   -0.04  41.46
 15.00    3.08     0.00   0.00   1.49   0.12   0.00   0.00   0.00   4.68   0.00   -0.03  41.23
 16.00    0.00     0.00   0.00   1.64   0.25   1.56   0.00   0.00   3.45   0.00   -0.06  54.15
 17.00    0.00     0.00   0.00   3.49   0.66   0.00   0.00   0.00   4.14   0.00   -0.42  53.91
 18.00    0.00     0.00   0.00   2.61   0.24   0.00   0.00   0.00   2.86   0.00   -0.40  53.68
 19.00    0.00     0.09   0.00   1.49   0.60   0.00   0.00   0.00   2.00   0.00   -0.27  53.44
 20.00    0.00     3.10   0.00   3.93   0.25   0.00   0.00   0.00   1.07   0.00   -1.22  53.20
 21.00    0.00     3.10   0.00   3.13   0.28   0.00   0.00   0.00   0.32   0.00   -0.97  52.96
 22.00    0.00     2.71   0.00   2.46   0.25   0.00   0.00   0.00   0.00   0.00   -0.48  52.73
 23.00    0.00     0.17   0.02   0.00   0.20   0.00   0.00   0.00   0.00   0.01   -0.00  52.49
Totaal   11.27    13.93   0.05  56.96   7.82   1.56   0.00   0.00  63.63   0.01   -6.27       
2025-06-16 22:01:53 info: Winst: € 2.91
2025-06-16 22:01:53 info: Doorzetten van alle settings naar HA
2025-06-16 22:01:53 info: Boiler opwarmen niet geactiveerd
2025-06-16 22:01:53 info: Grid set point: -27.0 W
2025-06-16 22:01:53 info: Cycle cost Sessy1: 0.00 euro
2025-06-16 22:01:53 info: Netto vermogen naar(+)/uit(-) omvormer Sessy1: 597 W
2025-06-16 22:01:53 info: Balanceren: False
2025-06-16 22:01:53 info: Vermogen uit batterij: -554W
2025-06-16 22:01:53 info: Vermogen dat binnenkomt van pv: 0W
2025-06-16 22:01:53 info: Vermogen dat binnenkomt van ac: 554W
2025-06-16 22:01:53 info: Waarde SoC na eerste uur: 57.1%
2025-06-16 22:01:53 info: Grid set point: -27.0 W
2025-06-16 22:01:53 info: Cycle cost Sessy2: 0.00 euro
2025-06-16 22:01:53 info: Netto vermogen naar(+)/uit(-) omvormer Sessy2: -748 W
2025-06-16 22:01:53 info: Balanceren: False
2025-06-16 22:01:53 info: Vermogen uit batterij: 782W
2025-06-16 22:01:53 info: Vermogen dat binnenkomt van pv: 0W
2025-06-16 22:01:53 info: Vermogen dat binnenkomt van ac: -782W
2025-06-16 22:01:53 info: Waarde SoC na eerste uur: 39.8%

Dat zou eigenlijk niet moeten toch?

Voor de rest werkt het super!

[sjampeter]

iets wat mij opvalt sinds "report" bij mij correct werkt.
de schaal op y-as is niet dynamisch?
stiekem wel een heel groot blauw vlak.

[KC27]

Hedzie schreef op dinsdag 17 juni 2025 @ 19:08:
@KC27

Gisteren zag ik dit in mijn log:
Sessy1 staat te laden terwijl Sessy2 staat te ontladen.

code:

2025-06-16 22:00:00 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-16 22:00:00 info: Day Ahead Optimalisering gestart op: 16-06-2025 22:00:00
2025-06-16 22:00:00 info: Day Ahead Optimalisatie gestart: 16-06-2025 22:00:00 taak: calc_optimum
2025-06-16 22:00:00 info: Debug = False
2025-06-16 22:00:00 info: Zelf berekende baseload
2025-06-16 22:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    22 2025-06-16 22:00:00   0.31   0.19   0.12   0.00      0
1    23 2025-06-16 23:00:00   0.28   0.16   0.10   0.00      0
2     0 2025-06-17 00:00:00   0.28   0.15   0.51   0.00      0
3     1 2025-06-17 01:00:00   0.27   0.15   1.02   0.00      0
4     2 2025-06-17 02:00:00   0.26   0.14   1.23   0.00      0
5     3 2025-06-17 03:00:00   0.26   0.14   0.87   0.00      0
6     4 2025-06-17 04:00:00   0.26   0.14   0.30   0.00      0
7     5 2025-06-17 05:00:00   0.27   0.15  -0.02   0.17      0
8     6 2025-06-17 06:00:00   0.29   0.17   0.03   1.01      0
9     7 2025-06-17 07:00:00   0.28   0.16  -0.01   1.93      0
10    8 2025-06-17 08:00:00   0.27   0.15   0.04   3.98      0
11    9 2025-06-17 09:00:00   0.25   0.13  -0.11   5.80      0
12   10 2025-06-17 10:00:00   0.15   0.03   0.06   5.88      0
13   11 2025-06-17 11:00:00   0.15   0.02   0.26   6.46      0
14   12 2025-06-17 12:00:00   0.15   0.02   0.24   6.89      0
15   13 2025-06-17 13:00:00   0.14   0.02   0.20   6.86      0
16   14 2025-06-17 14:00:00   0.14   0.02   0.13   6.12      0
17   15 2025-06-17 15:00:00   0.15   0.02   0.12   4.68      0
18   16 2025-06-17 16:00:00   0.16   0.04   0.25   3.45      0
19   17 2025-06-17 17:00:00   0.24   0.12   0.66   4.14      0
20   18 2025-06-17 18:00:00   0.27   0.15   0.24   2.86      0
21   19 2025-06-17 19:00:00   0.30   0.18   0.60   2.00      0
22   20 2025-06-17 20:00:00   0.43   0.31   0.25   1.07      0
23   21 2025-06-17 21:00:00   0.43   0.31   0.28   0.32      0
24   22 2025-06-17 22:00:00   0.32   0.19   0.25   0.00      0
25   23 2025-06-17 23:00:00   0.29   0.17   0.20   0.00      0
2025-06-16 22:00:00 info: No reduced hours applied for Sessy1
2025-06-16 22:00:00 info: Startwaarde SoC Sessy1: 47.0%
2025-06-16 22:00:00 info: No reduced hours applied for Sessy2
2025-06-16 22:00:00 info: Startwaarde SoC Sessy2: 54.0%
2025-06-16 22:00:00 info: Boiler opwarmen wordt ingepland tussen: 16 en 23 uur
2025-06-16 22:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-16 22:00:47 info: Eerste berekening
2025-06-16 22:00:47 info: Kosten (euro): -0.77 
2025-06-16 22:00:47 info: Levering (kWh): 0.05  
2025-06-16 22:01:50 info: Herberekening
2025-06-16 22:01:50 info: Kosten (euro): -5.73 
2025-06-16 22:01:50 info: Levering (kWh): 0.05  
2025-06-16 22:01:50 info: Strategie: minimale levering
2025-06-16 22:01:50 info: Het programma heeft een optimale oplossing gevonden.
2025-06-16 22:01:50 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -2.82 
2025-06-16 22:01:50 info: Geoptimaliseerd, kosten met day ahead tarieven: -5.73 
2025-06-16 22:01:50 info: Levering: 0.05   (kWh)
2025-06-16 22:01:50 info: Waarde boiler om 23 uur: 2.66 kWh
2025-06-16 22:01:50 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      %      %
    22   0.60  92.86   0.55   0.00   0.55 100.00   0.55  92.86  57.08
    23  -0.10  82.90  -0.11   0.00  -0.11 100.00  -0.11  82.90  55.00
     0  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  45.31
     1  -0.17  88.20  -0.20   0.00  -0.20 100.00  -0.20  88.20  41.76
     2  -0.51  95.70  -0.53   0.00  -0.53 100.00  -0.53  95.70  32.07
     3  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  15.92
     4  -0.30  92.10  -0.33   0.00  -0.33 100.00  -0.33  92.10  10.00
     5   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     6   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     7   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     8   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     9   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    10   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    11   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    12   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    13   1.81  92.69   1.68   0.00   1.68 100.00   1.68  92.69  40.58
    14   1.98  92.11   1.82   0.00   1.82 100.00   1.82  92.11  73.74
    15   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    19   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    20  -1.53  92.90  -1.65   0.00  -1.65 100.00  -1.65  92.90  70.06
    21  -1.53  92.90  -1.64   0.00  -1.64 100.00  -1.64  92.90  40.16
    22  -1.36  92.90  -1.46   0.00  -1.46 100.00  -1.46  92.90  13.55
    23  -0.17  88.20  -0.20   0.00  -0.20 100.00  -0.20  88.20  10.00
Totaal  -1.09     --  -2.03   0.00  -2.04     --  -2.04     --       
2025-06-16 22:01:50 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      %      %
    22  -0.75  95.70  -0.78   0.00  -0.78 100.00  -0.78  95.70  39.78
    23   0.00     --   0.00   0.00   0.00     --   0.00     --  39.78
     0   0.01  94.90   0.00   0.00   0.00 100.00   0.00  94.90  39.87
     1  -0.85  95.70  -0.89   0.00  -0.89 100.00  -0.89  95.70  23.72
     2  -0.72  95.70  -0.75   0.00  -0.75 100.00  -0.75  95.70  10.00
     3   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     4   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     5   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     6   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     7   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     8   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
     9   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    10   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    11   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    12   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
    13   1.81  92.69   1.68   0.00   1.68 100.00   1.68  92.69  40.58
    14   1.98  92.11   1.82   0.00   1.82 100.00   1.82  92.11  73.74
    15   1.54  93.80   1.44   0.00   1.44 100.00   1.44  93.80 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    19  -0.09  82.90  -0.10   0.00  -0.10 100.00  -0.10  82.90  98.14
    20  -1.57  92.50  -1.70   0.00  -1.70 100.00  -1.70  92.50  67.23
    21  -1.57  92.50  -1.70   0.00  -1.70 100.00  -1.70  92.50  36.32
    22  -1.35  93.60  -1.45   0.00  -1.45 100.00  -1.45  93.60  10.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
Totaal  -1.57     --  -2.42   0.00  -2.42     --  -2.42     --       
2025-06-16 22:01:53 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 22.00    0.60     0.75   0.00   0.03   0.12   0.00   0.00   0.00   0.00   0.00   -0.01  45.26
 23.00    0.00     0.10   0.00   0.00   0.10   0.00   0.00   0.00   0.00   0.00   -0.00  45.02
  0.00    0.01     0.51   0.00   0.00   0.51   0.00   0.00   0.00   0.00   0.00   -0.00  44.79
  1.00    0.00     1.02   0.00   0.00   1.02   0.00   0.00   0.00   0.00   0.00   -0.00  44.55
  2.00    0.00     1.23   0.00   0.00   1.23   0.00   0.00   0.00   0.00   0.00   -0.00  44.31
  3.00    0.00     0.85   0.02   0.00   0.87   0.00   0.00   0.00   0.00   0.01   -0.00  44.07
  4.00    0.00     0.30   0.00   0.00   0.30   0.00   0.00   0.00   0.00   0.00   -0.00  43.84
  5.00    0.00     0.00   0.00   0.19  -0.02   0.00   0.00   0.00   0.16   0.00   -0.03  43.60
  6.00    0.00     0.00   0.00   0.98   0.03   0.00   0.00   0.00   1.01   0.00   -0.17  43.36
  7.00    0.00     0.00   0.00   1.94  -0.01   0.00   0.00   0.00   1.93   0.00   -0.30  43.12
  8.00    0.00     0.00   0.00   3.94   0.04   0.00   0.00   0.00   3.98   0.00   -0.58  42.89
  9.00    0.00     0.00   0.00   5.92  -0.11   0.00   0.00   0.00   5.80   0.00   -0.76  42.65
 10.00    0.00     0.00   0.00   5.82   0.06   0.00   0.00   0.00   5.88   0.00   -0.17  42.41
 11.00    0.00     0.00   0.00   6.20   0.26   0.00   0.00   0.00   6.46   0.00   -0.15  42.17
 12.00    0.00     0.00   0.00   6.65   0.24   0.00   0.00   0.00   6.89   0.00   -0.16  41.94
 13.00    3.63     0.00   0.00   3.04   0.20   0.00   0.00   0.00   6.86   0.00   -0.06  41.70
 14.00    3.96     0.00   0.00   2.03   0.13   0.00   0.00   0.00   6.12   0.00   -0.04  41.46
 15.00    3.08     0.00   0.00   1.49   0.12   0.00   0.00   0.00   4.68   0.00   -0.03  41.23
 16.00    0.00     0.00   0.00   1.64   0.25   1.56   0.00   0.00   3.45   0.00   -0.06  54.15
 17.00    0.00     0.00   0.00   3.49   0.66   0.00   0.00   0.00   4.14   0.00   -0.42  53.91
 18.00    0.00     0.00   0.00   2.61   0.24   0.00   0.00   0.00   2.86   0.00   -0.40  53.68
 19.00    0.00     0.09   0.00   1.49   0.60   0.00   0.00   0.00   2.00   0.00   -0.27  53.44
 20.00    0.00     3.10   0.00   3.93   0.25   0.00   0.00   0.00   1.07   0.00   -1.22  53.20
 21.00    0.00     3.10   0.00   3.13   0.28   0.00   0.00   0.00   0.32   0.00   -0.97  52.96
 22.00    0.00     2.71   0.00   2.46   0.25   0.00   0.00   0.00   0.00   0.00   -0.48  52.73
 23.00    0.00     0.17   0.02   0.00   0.20   0.00   0.00   0.00   0.00   0.01   -0.00  52.49
Totaal   11.27    13.93   0.05  56.96   7.82   1.56   0.00   0.00  63.63   0.01   -6.27       
2025-06-16 22:01:53 info: Winst: € 2.91
2025-06-16 22:01:53 info: Doorzetten van alle settings naar HA
2025-06-16 22:01:53 info: Boiler opwarmen niet geactiveerd
2025-06-16 22:01:53 info: Grid set point: -27.0 W
2025-06-16 22:01:53 info: Cycle cost Sessy1: 0.00 euro
2025-06-16 22:01:53 info: Netto vermogen naar(+)/uit(-) omvormer Sessy1: 597 W
2025-06-16 22:01:53 info: Balanceren: False
2025-06-16 22:01:53 info: Vermogen uit batterij: -554W
2025-06-16 22:01:53 info: Vermogen dat binnenkomt van pv: 0W
2025-06-16 22:01:53 info: Vermogen dat binnenkomt van ac: 554W
2025-06-16 22:01:53 info: Waarde SoC na eerste uur: 57.1%
2025-06-16 22:01:53 info: Grid set point: -27.0 W
2025-06-16 22:01:53 info: Cycle cost Sessy2: 0.00 euro
2025-06-16 22:01:53 info: Netto vermogen naar(+)/uit(-) omvormer Sessy2: -748 W
2025-06-16 22:01:53 info: Balanceren: False
2025-06-16 22:01:53 info: Vermogen uit batterij: 782W
2025-06-16 22:01:53 info: Vermogen dat binnenkomt van pv: 0W
2025-06-16 22:01:53 info: Vermogen dat binnenkomt van ac: -782W
2025-06-16 22:01:53 info: Waarde SoC na eerste uur: 39.8%

Dat zou eigenlijk niet moeten toch?

Voor de rest werkt het super!

Omdat het laden en ontladen gratis is probeert DAO een - ook voor mij nog onbegrijpelijke - ideale situatie te bereiken. Zal waarschijnlijk te maken hebben met de efficiency van het laden en ontladen. Hij rekent waarschijnlijk: beter ontladen bij de een met 782 W en ontladen bij de ander met 554w dan ontladen bij een met 228 W.
Je kunt dit ondervangen door een kleine prijs aan de cycle cost te hangen bijv 0,005 euro/kWh. Het vermindert je berekende winst iets maar je systeem gaat er beter door draaien en de echte winst blijft hetzelfde.

Een andere (en waarschijnlijk betere) optie is door de twee Sessy's als een virtuele batterij te behandelen en dan met een automation het berekende vermogen verdelen over of toerekenen aan een of beide Sessy'a.
Er staan in dit topic voorbeelden van Sessy-gebruikers die dit met succes hebben toegepast.

[KC27]

sjampeter schreef op dinsdag 17 juni 2025 @ 19:57:
iets wat mij opvalt sinds "report" bij mij correct werkt.
de schaal op y-as is niet dynamisch?
stiekem wel een heel groot blauw vlak.


[Afbeelding]

Hier zit echt nog iets fout want een kleur maar eigenlijk maar een kant opgaan.
Heb de logging van de bijbehorende berekening voor mij?

[KC27]

f.welvering schreef op dinsdag 17 juni 2025 @ 16:07:
[...]


Zeker:
Config:

code:

{
{
  "homeassistant": {
    "host": "192.168.60.3",
    "ip port": 8123,
    "token": "!secret ha_api_token"
  },
  "database ha": {
    "engine": "mysql",
    "server": "192.168.60.3",
    "port": 3306,
    "database": "homeassistant",
    "username": "dao",
    "password": "!secret db_da_password"
  },
  "database da": {
    "engine": "mysql",
    "server": "192.168.60.3",
    "port": 3306,
    "database": "dao",
    "username": "dao",
    "password": "!secret db_da_password"
  },
  "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": {
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2024-08-01": 0.020496
    },
    "cost supplier production": {
      "2024-08-01": 0.020496
    },
    "vat": {
      "2023-01-01": 21
    },
    "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": "2024-09-01",
    "tax refund": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "False",
    "average consumption": "False"
  },
  "logging level" : "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "false",
    "average consumption": "false"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False"
  },
  "heating": {
    "heater present": "False"
  },
  "battery": [ ],
  "solar": [
    { "name" : "main",
      "tilt": 50,
      "orientation": 160,
      "capacity": 9.0,
      "yield": 0.0180625,
      "entity pv switch": "input_boolean.pv_main_aan_uit"
  }],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.p1_meter_energie_import_tarief_1",
      "sensor.p1_meter_energie_import_tarief_2"
    ],
    "entities grid production": [
      "sensor.p1_meter_energie_export_tarief_1",
      "sensor.p1_meter_energie_export_tarief_2"
    ],
    "entities solar production ac": [
      "sensor.solaredge_panel_production_daily"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : [],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": [],
    "entities battery 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",
    "2359": "clean_data"
  }
}

Log

code:

025-06-17 16:07:29 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-17 16:07:29 info: Day Ahead Optimalisering gestart op: 17-06-2025 16:07:29
2025-06-17 16:07:29 info: Day Ahead Optimalisatie gestart: 17-06-2025 16:07:29 taak: calc_optimum
2025-06-17 16:07:29 info: Debug = False
2025-06-17 16:07:29 info: Zelf berekende baseload
2025-06-17 16:07:29 info: Start waarden: 
    uur                tijd       p_l       p_t   base     pv_ac  pv_dc
0    16 2025-06-17 16:00:00  0.274714  0.274714  0.449  1.731585      0
1    17 2025-06-17 17:00:00  0.302544  0.302544  5.109  1.660790      0
2    18 2025-06-17 18:00:00  0.435160  0.435160  7.476  2.171827      0
3    19 2025-06-17 19:00:00  0.432848  0.432848  4.472  1.675457      0
4    20 2025-06-17 20:00:00  0.317535  0.317535  1.540  0.596896      0
5    21 2025-06-17 21:00:00  0.288725  0.288725  3.710  0.147266      0
6    22 2025-06-17 22:00:00  0.284394  0.284394  1.353  0.000000      0
7    23 2025-06-17 23:00:00  0.277230  0.277230  0.544  0.000000      0
8     0 2025-06-18 00:00:00  0.270612  0.270612  0.284  0.000000      0
9     1 2025-06-18 01:00:00  0.264235  0.264235  0.282  0.000000      0
10    2 2025-06-18 02:00:00  0.265433  0.265433  0.288  0.000000      0
11    3 2025-06-18 03:00:00  0.274024  0.274024  0.453  0.000000      0
12    4 2025-06-18 04:00:00  0.284575  0.284575  0.530  0.000000      0
13    5 2025-06-18 05:00:00  0.287564  0.287564  0.345  0.055634      0
14    6 2025-06-18 06:00:00  0.287177  0.287177  0.261  0.933216      0
15    7 2025-06-18 07:00:00  0.256128  0.256128  0.570  1.082545      0
16    8 2025-06-18 08:00:00  0.174017  0.174017  0.456  1.174981      0
17    9 2025-06-18 09:00:00  0.149079  0.149079  1.306  1.223650      0
18   10 2025-06-18 10:00:00  0.147506  0.147506  0.948  1.297351      0
19   11 2025-06-18 11:00:00  0.147083  0.147083  0.859  1.473755      0
20   12 2025-06-18 12:00:00  0.146405  0.146405  0.866  1.681076      0
21   13 2025-06-18 13:00:00  0.147301  0.147301  1.532  1.864969      0
22   14 2025-06-18 14:00:00  0.150350  0.150350  0.566  2.088593      0
23   15 2025-06-18 15:00:00  0.236139  0.236139  0.532  2.306070      0
24   16 2025-06-18 16:00:00  0.275173  0.275173  1.487  2.440201      0
25   17 2025-06-18 17:00:00  0.289100  0.289100  5.144  2.432890      0
26   18 2025-06-18 18:00:00  0.318745  0.318745  4.630  2.440477      0
27   19 2025-06-18 19:00:00  0.359801  0.359801  4.730  2.120656      0
28   20 2025-06-18 20:00:00  0.312308  0.312308  4.533  1.306222      0
29   21 2025-06-18 21:00:00  0.292864  0.292864  1.213  0.265193      0
30   22 2025-06-18 22:00:00       NaN       NaN  0.386  0.000000      0
31   23 2025-06-18 23:00:00       NaN       NaN  0.308  0.000000      0
2025-06-17 16:07:30 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-06-17 16:07:30 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-17 16:07:30 waarschuwing: Geen oplossing  voor: minimize cost

Het is wat @Bravo ook zegt: er valt niks met je verbruik te schuiven,
Een andere mogelijkheid om toch een goede berekening en grafiek te krijgen: voeg een vaatwasser of wasmachine toe met een klein eco-programma.
Er staat een voorbeeld voor de instellingen in example_options.json.

[sjampeter]

KC27 schreef op dinsdag 17 juni 2025 @ 20:58:
[...]

Hier zit echt nog iets fout want een kleur maar eigenlijk maar een kant opgaan.
Heb de logging van de bijbehorende berekening voor mij?

hmm. had ik even niet zo door inderdaad. levering kan niet positief en negatief tegelijk zijn.
onderstaand een logging van 08:00

code:

 2025-06-18 08:00:00 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-18 08:00:00 info: Day Ahead Optimalisering gestart op: 18-06-2025 08:00:00
2025-06-18 08:00:00 info: Day Ahead Optimalisatie gestart: 18-06-2025 08:00:00 taak: calc_optimum
2025-06-18 08:00:00 info: Debug = False
2025-06-18 08:00:00 info: Zelf berekende baseload
2025-06-18 08:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0     8 2025-06-18 08:00:00   0.29   0.29  -3.83   1.57   0.00
1     9 2025-06-18 09:00:00   0.26   0.26  -5.60   3.09   0.00
2    10 2025-06-18 10:00:00   0.17   0.17  -7.26   4.56   0.00
3    11 2025-06-18 11:00:00   0.15   0.15  -7.45   5.76   0.00
4    12 2025-06-18 12:00:00   0.15   0.15  -8.69   6.64   0.00
5    13 2025-06-18 13:00:00   0.15   0.15  -9.96   7.05   0.00
6    14 2025-06-18 14:00:00   0.15   0.15  -9.44   6.91   0.00
7    15 2025-06-18 15:00:00   0.15   0.15  -8.12   6.33   0.00
8    16 2025-06-18 16:00:00   0.15   0.15  -6.84   5.30   0.00
9    17 2025-06-18 17:00:00   0.24   0.24  -4.26   4.11   0.00
10   18 2025-06-18 18:00:00   0.27   0.27  -3.08   2.74   0.00
11   19 2025-06-18 19:00:00   0.29   0.29  -1.04   1.42   0.00
12   20 2025-06-18 20:00:00   0.32   0.32   0.16   0.43   0.00
13   21 2025-06-18 21:00:00   0.36   0.36   1.06   0.14   0.00
14   22 2025-06-18 22:00:00   0.31   0.31   1.94   0.00   0.00
15   23 2025-06-18 23:00:00   0.29   0.29   1.68   0.00   0.00
2025-06-18 08:00:00 info: No reduced hours applied for Victron
2025-06-18 08:00:00 info: Startwaarde SoC Victron: 24.5%
2025-06-18 08:00:00 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-06-18 08:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-18 08:00:00 info: Apparaat warmtepomp met programma 'SWW aan' wordt ingepland tussen 2025-06-18 08:00 en 2025-06-18 17:00.
2025-06-18 08:00:00 info: Strategie: minimale kosten
2025-06-18 08:00:00 info: Het programma heeft een optimale oplossing gevonden.
2025-06-18 08:00:00 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -21.23
2025-06-18 08:00:00 info: Geoptimaliseerd, kosten met day ahead tarieven: -23.13
2025-06-18 08:00:00 info: Levering: 0.00   (kWh)
2025-06-18 08:00:00 info: In- en uitgaande energie per uur batterij Victron
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
     8  -1.47  95.90  -1.53   0.00  -1.53  99.00  -1.54  94.94  18.07
     9   0.00     --   0.00   0.00   0.00     --   0.00     --  18.07
    10   0.00     --   0.00   0.00   0.00     --   0.00     --  18.07
    11   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  31.02
    12   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  43.97
    13   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  56.92
    14   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  69.87
    15   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  82.82
    16   3.27  90.24   2.95   0.00   2.95  99.00   2.92  89.34  95.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     --  95.00
    18  -1.81  95.40  -1.90   0.00  -1.90  99.00  -1.92  94.45  87.02
    19  -2.75  93.50  -2.94   0.00  -2.94  99.00  -2.97  92.57  74.66
    20  -3.12  92.70  -3.37   0.00  -3.37  99.00  -3.40  91.77  60.50
    21  -3.12  92.70  -3.37   0.00  -3.37  99.00  -3.40  91.77  46.33
    22  -3.12  92.70  -3.37   0.00  -3.37  99.00  -3.40  91.77  32.17
    23  -3.12  92.70  -3.37   0.00  -3.37  99.00  -3.40  91.77  18.00
Totaal   2.27     --  -1.17   0.00  -1.17     --  -1.56     --       
2025-06-18 08:00:00 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
  8.00    0.00     1.47   0.00   6.87  -3.83   0.00   0.00   0.00   1.57   0.00   -1.97  20.00   0.00
  9.00    0.00     0.00   0.00   8.69  -5.60   0.00   0.00   0.00   3.09   0.00   -2.22  20.00   0.00
 10.00    0.00     0.00   0.00  11.82  -7.26   0.00   0.00   0.00   4.56   0.00   -2.05  20.00   0.00
 11.00    3.50     0.00   0.00   9.72  -7.45   0.00   0.00   0.00   5.76   0.00   -1.44  20.00   0.00
 12.00    3.50     0.00   0.00  11.83  -8.69   0.00   0.00   0.00   6.64   0.00   -1.74  20.00   0.00
 13.00    3.50     0.00   0.00  11.81  -9.96   0.00   0.00   0.00   7.05   0.00   -1.73  20.00   1.70
 14.00    3.50     0.00   0.00  11.15  -9.44   0.00   0.00   0.00   6.91   0.00   -1.63  20.00   1.70
 15.00    3.50     0.00   0.00  10.53  -8.12   0.00   0.00   0.00   6.33   0.00   -1.54  20.00   0.42
 16.00    3.27     0.00   0.00   8.87  -6.84   0.00   0.00   0.00   5.30   0.00   -1.33  20.00   0.00
 17.00    0.00     0.00   0.00   8.37  -4.26   0.00   0.00   0.00   4.11   0.00   -1.97  20.00   0.00
 18.00    0.00     1.81   0.00   7.63  -3.08   0.00   0.00   0.00   2.74   0.00   -2.09  20.00   0.00
 19.00    0.00     2.75   0.00   5.21  -1.04   0.00   0.00   0.00   1.42   0.00   -1.50  20.00   0.00
 20.00    0.00     3.12   0.00   3.39   0.16   0.00   0.00   0.00   0.43   0.00   -1.08  20.00   0.00
 21.00    0.00     3.12   0.00   2.19   1.06   0.00   0.00   0.00   0.14   0.00   -0.79  20.00   0.00
 22.00    0.00     3.12   0.00   1.19   1.94   0.00   0.00   0.00   0.00   0.00   -0.37  20.00   0.00
 23.00    0.00     3.12   0.00   1.44   1.68   0.00   0.00   0.00   0.00   0.00   -0.42  20.00   0.00
Totaal   20.77    18.50   0.00 120.70 -70.73   0.00   0.00   0.00  56.06   0.00  -23.87          3.83
2025-06-18 08:00:00 info: Winst: € 1.90
2025-06-18 08:00:00 info: Doorzetten van alle settings naar HA
2025-06-18 08:00:00 info: Grid set point: -6867.0 W
2025-06-18 08:00:00 info: Cycle cost Victron: 0.46 euro
2025-06-18 08:00:00 info: Netto vermogen naar(+)/uit(-) omvormer Victron: -1466 W
2025-06-18 08:00:00 info: Balanceren: False
2025-06-18 08:00:00 info: Vermogen uit batterij: 1528W
2025-06-18 08:00:00 info: Vermogen dat binnenkomt van pv: 0W
2025-06-18 08:00:00 info: Vermogen dat binnenkomt van ac: -1528W
2025-06-18 08:00:00 info: Waarde SoC na eerste uur: 18.1%
2025-06-18 08:00:00 info: Apparaat: warmtepomp
2025-06-18 08:00:00 info: Programma: SWW aan
2025-06-18 08:00:00 info: Start op 2025-06-18 13:00
2025-06-18 08:00:00 info: Is klaar op 2025-06-18 15:15

als ik naar "report" kijk, kloppen de getallen eigenlijk als een bus. opzich al een overwinning op zich haha

deze is bijvoorbeeld van gisteren. correct me if i'm wrong, maar lijkt toch correct.

kan het zijn dat deze "blauwe vlakken" komen doordat ik sinds report werkt, de baseload automatisch laat rekenen?

[KC27]

sjampeter schreef op woensdag 18 juni 2025 @ 08:08:
[...]


hmm. had ik even niet zo door inderdaad. levering kan niet positief en negatief tegelijk zijn.
onderstaand een logging van 08:00

code:

 2025-06-18 08:00:00 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-18 08:00:00 info: Day Ahead Optimalisering gestart op: 18-06-2025 08:00:00
2025-06-18 08:00:00 info: Day Ahead Optimalisatie gestart: 18-06-2025 08:00:00 taak: calc_optimum
2025-06-18 08:00:00 info: Debug = False
2025-06-18 08:00:00 info: Zelf berekende baseload
2025-06-18 08:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0     8 2025-06-18 08:00:00   0.29   0.29  -3.83   1.57   0.00
1     9 2025-06-18 09:00:00   0.26   0.26  -5.60   3.09   0.00
2    10 2025-06-18 10:00:00   0.17   0.17  -7.26   4.56   0.00
3    11 2025-06-18 11:00:00   0.15   0.15  -7.45   5.76   0.00
4    12 2025-06-18 12:00:00   0.15   0.15  -8.69   6.64   0.00
5    13 2025-06-18 13:00:00   0.15   0.15  -9.96   7.05   0.00
6    14 2025-06-18 14:00:00   0.15   0.15  -9.44   6.91   0.00
7    15 2025-06-18 15:00:00   0.15   0.15  -8.12   6.33   0.00
8    16 2025-06-18 16:00:00   0.15   0.15  -6.84   5.30   0.00
9    17 2025-06-18 17:00:00   0.24   0.24  -4.26   4.11   0.00
10   18 2025-06-18 18:00:00   0.27   0.27  -3.08   2.74   0.00
11   19 2025-06-18 19:00:00   0.29   0.29  -1.04   1.42   0.00
12   20 2025-06-18 20:00:00   0.32   0.32   0.16   0.43   0.00
13   21 2025-06-18 21:00:00   0.36   0.36   1.06   0.14   0.00
14   22 2025-06-18 22:00:00   0.31   0.31   1.94   0.00   0.00
15   23 2025-06-18 23:00:00   0.29   0.29   1.68   0.00   0.00
2025-06-18 08:00:00 info: No reduced hours applied for Victron
2025-06-18 08:00:00 info: Startwaarde SoC Victron: 24.5%
2025-06-18 08:00:00 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-06-18 08:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-06-18 08:00:00 info: Apparaat warmtepomp met programma 'SWW aan' wordt ingepland tussen 2025-06-18 08:00 en 2025-06-18 17:00.
2025-06-18 08:00:00 info: Strategie: minimale kosten
2025-06-18 08:00:00 info: Het programma heeft een optimale oplossing gevonden.
2025-06-18 08:00:00 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -21.23
2025-06-18 08:00:00 info: Geoptimaliseerd, kosten met day ahead tarieven: -23.13
2025-06-18 08:00:00 info: Levering: 0.00   (kWh)
2025-06-18 08:00:00 info: In- en uitgaande energie per uur batterij Victron
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
     8  -1.47  95.90  -1.53   0.00  -1.53  99.00  -1.54  94.94  18.07
     9   0.00     --   0.00   0.00   0.00     --   0.00     --  18.07
    10   0.00     --   0.00   0.00   0.00     --   0.00     --  18.07
    11   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  31.02
    12   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  43.97
    13   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  56.92
    14   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  69.87
    15   3.50  89.70   3.14   0.00   3.14  99.00   3.11  88.80  82.82
    16   3.27  90.24   2.95   0.00   2.95  99.00   2.92  89.34  95.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     --  95.00
    18  -1.81  95.40  -1.90   0.00  -1.90  99.00  -1.92  94.45  87.02
    19  -2.75  93.50  -2.94   0.00  -2.94  99.00  -2.97  92.57  74.66
    20  -3.12  92.70  -3.37   0.00  -3.37  99.00  -3.40  91.77  60.50
    21  -3.12  92.70  -3.37   0.00  -3.37  99.00  -3.40  91.77  46.33
    22  -3.12  92.70  -3.37   0.00  -3.37  99.00  -3.40  91.77  32.17
    23  -3.12  92.70  -3.37   0.00  -3.37  99.00  -3.40  91.77  18.00
Totaal   2.27     --  -1.17   0.00  -1.17     --  -1.56     --       
2025-06-18 08:00:00 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
  8.00    0.00     1.47   0.00   6.87  -3.83   0.00   0.00   0.00   1.57   0.00   -1.97  20.00   0.00
  9.00    0.00     0.00   0.00   8.69  -5.60   0.00   0.00   0.00   3.09   0.00   -2.22  20.00   0.00
 10.00    0.00     0.00   0.00  11.82  -7.26   0.00   0.00   0.00   4.56   0.00   -2.05  20.00   0.00
 11.00    3.50     0.00   0.00   9.72  -7.45   0.00   0.00   0.00   5.76   0.00   -1.44  20.00   0.00
 12.00    3.50     0.00   0.00  11.83  -8.69   0.00   0.00   0.00   6.64   0.00   -1.74  20.00   0.00
 13.00    3.50     0.00   0.00  11.81  -9.96   0.00   0.00   0.00   7.05   0.00   -1.73  20.00   1.70
 14.00    3.50     0.00   0.00  11.15  -9.44   0.00   0.00   0.00   6.91   0.00   -1.63  20.00   1.70
 15.00    3.50     0.00   0.00  10.53  -8.12   0.00   0.00   0.00   6.33   0.00   -1.54  20.00   0.42
 16.00    3.27     0.00   0.00   8.87  -6.84   0.00   0.00   0.00   5.30   0.00   -1.33  20.00   0.00
 17.00    0.00     0.00   0.00   8.37  -4.26   0.00   0.00   0.00   4.11   0.00   -1.97  20.00   0.00
 18.00    0.00     1.81   0.00   7.63  -3.08   0.00   0.00   0.00   2.74   0.00   -2.09  20.00   0.00
 19.00    0.00     2.75   0.00   5.21  -1.04   0.00   0.00   0.00   1.42   0.00   -1.50  20.00   0.00
 20.00    0.00     3.12   0.00   3.39   0.16   0.00   0.00   0.00   0.43   0.00   -1.08  20.00   0.00
 21.00    0.00     3.12   0.00   2.19   1.06   0.00   0.00   0.00   0.14   0.00   -0.79  20.00   0.00
 22.00    0.00     3.12   0.00   1.19   1.94   0.00   0.00   0.00   0.00   0.00   -0.37  20.00   0.00
 23.00    0.00     3.12   0.00   1.44   1.68   0.00   0.00   0.00   0.00   0.00   -0.42  20.00   0.00
Totaal   20.77    18.50   0.00 120.70 -70.73   0.00   0.00   0.00  56.06   0.00  -23.87          3.83
2025-06-18 08:00:00 info: Winst: € 1.90
2025-06-18 08:00:00 info: Doorzetten van alle settings naar HA
2025-06-18 08:00:00 info: Grid set point: -6867.0 W
2025-06-18 08:00:00 info: Cycle cost Victron: 0.46 euro
2025-06-18 08:00:00 info: Netto vermogen naar(+)/uit(-) omvormer Victron: -1466 W
2025-06-18 08:00:00 info: Balanceren: False
2025-06-18 08:00:00 info: Vermogen uit batterij: 1528W
2025-06-18 08:00:00 info: Vermogen dat binnenkomt van pv: 0W
2025-06-18 08:00:00 info: Vermogen dat binnenkomt van ac: -1528W
2025-06-18 08:00:00 info: Waarde SoC na eerste uur: 18.1%
2025-06-18 08:00:00 info: Apparaat: warmtepomp
2025-06-18 08:00:00 info: Programma: SWW aan
2025-06-18 08:00:00 info: Start op 2025-06-18 13:00
2025-06-18 08:00:00 info: Is klaar op 2025-06-18 15:15

als ik naar "report" kijk, kloppen de getallen eigenlijk als een bus. opzich al een overwinning op zich haha
[Afbeelding]
deze is bijvoorbeeld van gisteren. correct me if i'm wrong, maar lijkt toch correct.

kan het zijn dat deze "blauwe vlakken" komen doordat ik sinds report werkt, de baseload automatisch laat rekenen?

Je automatisch berekende baseload klopt nog niet.
De kolom base in de logging is negatief. Dat kan in principe niet. In dat geval zou je "gebruikers" hebben die elektra leveren aan je net.
Misschien de baseload-berekening niet verder terug laten gaan dan dat je betrouwbare verbruik- en terugleverdata in je database hebt zitten.

[Torch1969]

KC27 schreef op woensdag 18 juni 2025 @ 09:38:
[...]

Je automatisch berekende baseload klopt nog niet.
De kolom base in de logging is negatief. Dat kan in principe niet. In dat geval zou je "gebruikers" hebben die elektra leveren aan je net.
Misschien de baseload-berekening niet verder terug laten gaan dan dat je betrouwbare verbruik- en terugleverdata in je database hebt zitten.

Ik heb ook negatieve waarden in mijn automatisch berekende baseload. Kan het nog niet helemaal verklaren, maar deels ligt het aan een verbruiker die niet al zijn verbruik “realtime” rapporteert (mijn airco die ik als wp heb geconfigureerd). Die rapporteert eens in de ongeveer 6 uur 100W verbruik (stand-by verbruik) en bij gebruik in het volgende uur met terugwerkende kracht (en dan ook in stappen van 100W). Het daadwerkelijk verbruik (gemeten op de netaansluiting) komt dus niet overeen met het “geboekte” verbruik.

En terwijl ik dit schrijf en een run doe voor berekening baseload, zitten er geen negatieve getallen meer tussen…

[ Voor 5% gewijzigd door Torch1969 op 18-06-2025 18:59 ]

[sjampeter]

ik heb hem even op 3 dagen gezet. vooralsnog geen verandering, maar ik geef het even 24 uur.

[KC27]

sjampeter schreef op woensdag 18 juni 2025 @ 20:44:
ik heb hem even op 3 dagen gezet. vooralsnog geen verandering, maar ik geef het even 24 uur.

@sjampeter @Torch1969
Het staat niet goed in de documentatie maar de periode moet minimaal 7 dagen zijn en verder liefst een veelvoud van 7.
De berekening rekent voor iedere dag van de week en alle uren van die dag de baseload als gemiddelde van de dagen uit de historie.
Dus voor de baseload van woensdag pakt ie alle woensdagen uit de historie. En als je dan de historie op 3 dagen zet dan rekent ie vandaag alleen een baseload van zondag, maandag en dinsdag en heeft ie niks voor woensdag en donderdag.
Als je de berekende baseload wilt controleren:

• zij staan in de logging van de berekening
• zij staan ook in de map addon_configs/xxxx_day ahead_optxxx/dao_data/baseload. Maandag is baseload_0.json, dinsdag is baseload_1.json en zo verder (svp niet editten)

Mijn advies: reken eerst met een handmatige baseload ( "use_calc_baseload": "False") en als je met report\balans een betrouwbaar stuk geschiedenis kunt berekenen dan kun je switchen:

PS: het verbruik van mijn boiler is opgenomen in het verbruik van de wp (moet ik nog uitsplitsen in HA) .

[sailor_dg]

ik heb inmiddels DAO al een tijdje naar volle tevredenheid draaien - de batterij wordt lekker beziggehouden . Baseload historie heb ik, maar het berekenen blijft NaNs geven op bepaalde uren. Is dit een kwestie van nog meer geduld?

code:

Logging van bewerking "Bereken de baseloads":
2025-06-18 23:04:18 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-18 23:04:18 info: Day Ahead Optimalisering gestart op: 18-06-2025 23:04:18
2025-06-18 23:04:18 info: Day Ahead Optimalisatie gestart: 18-06-2025 23:04:18 taak: calc_baseloads
2025-06-18 23:04:18 info: baseload voor weekdag 0 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.915 0.714 0.388 0.491 0.466 2.674 2.601 2.245 0.321 1.306 0.931 -0.057 1.336 0.457 0.126 0.974 0.734 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 1 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.812 0.823 0.486 0.731 0.774 1.115 1.646 2.578 -19.905 -27.248 0.839 0.522 0.034 1.021 0.401 0.691 0.953 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 2 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 1.004 0.423 0.745 0.254 1.312 0.788 1.121 0.843 1.128 0.656 0.915 0.312 1.475 0.69 0.426 0.763 0.91 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 3 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.793 0.884 0.389 0.285 0.529 0.97 1.871 0.484 1.092 0.37 0.995 0.431 0.806 0.602 0.317 0.693 0.695 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 4 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 1.034 0.933 0.614 0.374 0.459 1.271 1.397 2.048 1.481 0.745 1.189 0.148 0.594 1.331 0.624 0.57 -21.137 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 5 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.977 -21.224 0.584 0.457 1.635 2.295 1.816 1.285 1.216 0.764 0.695 1.932 0.672 1.106 1.313 1.021 0.954 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 6 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.89 0.952 0.988 1.056 1.55 0.934 0.121 -0.458 -0.255 -0.98 -0.863 6.601 -22.476 1.265 0.868 1.473 0.654 nan

[KC27]

sailor_dg schreef op woensdag 18 juni 2025 @ 23:06:
ik heb inmiddels DAO al een tijdje naar volle tevredenheid draaien - de batterij wordt lekker beziggehouden . Baseload historie heb ik, maar het berekenen blijft NaNs geven op bepaalde uren. Is dit een kwestie van nog meer geduld?

code:

Logging van bewerking "Bereken de baseloads":
2025-06-18 23:04:18 info: Day Ahead Optimalisering versie: 2025.6.1
2025-06-18 23:04:18 info: Day Ahead Optimalisering gestart op: 18-06-2025 23:04:18
2025-06-18 23:04:18 info: Day Ahead Optimalisatie gestart: 18-06-2025 23:04:18 taak: calc_baseloads
2025-06-18 23:04:18 info: baseload voor weekdag 0 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.915 0.714 0.388 0.491 0.466 2.674 2.601 2.245 0.321 1.306 0.931 -0.057 1.336 0.457 0.126 0.974 0.734 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 1 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.812 0.823 0.486 0.731 0.774 1.115 1.646 2.578 -19.905 -27.248 0.839 0.522 0.034 1.021 0.401 0.691 0.953 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 2 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 1.004 0.423 0.745 0.254 1.312 0.788 1.121 0.843 1.128 0.656 0.915 0.312 1.475 0.69 0.426 0.763 0.91 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 3 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.793 0.884 0.389 0.285 0.529 0.97 1.871 0.484 1.092 0.37 0.995 0.431 0.806 0.602 0.317 0.693 0.695 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 4 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 1.034 0.933 0.614 0.374 0.459 1.271 1.397 2.048 1.481 0.745 1.189 0.148 0.594 1.331 0.624 0.57 -21.137 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 5 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.977 -21.224 0.584 0.457 1.635 2.295 1.816 1.285 1.216 0.764 0.695 1.932 0.672 1.106 1.313 1.021 0.954 nan 
2025-06-18 23:04:18 info: baseload voor weekdag 6 :
2025-06-18 23:04:18 info: nan nan nan nan nan nan 0.89 0.952 0.988 1.056 1.55 0.934 0.121 -0.458 -0.255 -0.98 -0.863 6.601 -22.476 1.265 0.868 1.473 0.654 nan

Hoe ziet je berekening eruit van Report\Balans met periode "deze maand" en "vorige maand"?
Waarschijnlijk kun je daar zien wat er ontbreekt en/of fout gaat.

[sjampeter]

KC27 schreef op woensdag 18 juni 2025 @ 22:57:
[...]

@sjampeter @Torch1969
Het staat niet goed in de documentatie maar de periode moet minimaal 7 dagen zijn en verder liefst een veelvoud van 7.
De berekening rekent voor iedere dag van de week en alle uren van die dag de baseload als gemiddelde van de dagen uit de historie.
Dus voor de baseload van woensdag pakt ie alle woensdagen uit de historie. En als je dan de historie op 3 dagen zet dan rekent ie vandaag alleen een baseload van zondag, maandag en dinsdag en heeft ie niks voor woensdag en donderdag.
Als je de berekende baseload wilt controleren:

• zij staan in de logging van de berekening
• zij staan ook in de map addon_configs/xxxx_day ahead_optxxx/dao_data/baseload. Maandag is baseload_0.json, dinsdag is baseload_1.json en zo verder (svp niet editten)

Mijn advies: reken eerst met een handmatige baseload ( "use_calc_baseload": "False") en als je met report\balans een betrouwbaar stuk geschiedenis kunt berekenen dan kun je switchen:
[Afbeelding]
PS: het verbruik van mijn boiler is opgenomen in het verbruik van de wp (moet ik nog uitsplitsen in HA) .

je hebt natuurlijk helemaal gelijk. stom van me. ik heb even gekeken daar de baseload per week (vorige week) en inderdaad, allemaal negatieve getallen. toen was ik inderdaad nog aan het prutsen om alle sensoren goed te krijgen. deze week ziet die er al een stuk beter uit.
vooralsnog even handmatig wat getallen er in geknald, et voila.
een grafiek die er best mag zijn haha. laat de zon maar schijnen !!! (met een buitje snachts als het kan).

[KC27]

Er is (met veel dank aan @simnet ) een nieuw buildsysteem gemaakt voor de images van DAO.
Voor de testers: er is met het nieuwe systeem een nieuwe release vrijgegeven: versie 2025.6.2.rc4.
Helaas kan je je oude test-versie niet updaten, maar het installeren is er wel makkelijker op geworden.

Voor testers met HA-OS: ga naar Instellingen\Add-ons en klik op de addon-winkel(shop).
Als het goed is staat daar deze tegel bij:

Als die er niet bij staat kun je via de dao- root toevoegen aan je repositories:

https://github.com/corneel27/day-ahead/

Na installatie kopieer je options.json, secrets.json en eventueel day_ahead.db en de baseload-folder via samba van de oude test-addon naar de nieuwe.

Voor testers met HA-container is dit de nieuwe image: ghcr.io/corneel27/dao-{arch}:2025.6.2.rc4,
waarbij je {arch} vervangt door jouw de architectuurnaam van jouw machine.

We horen graag jullie bevindingen.

[storeman]

@KC27 Ik heb nog een gedachtegang waar je misschien wat aan hebt.

Ik probeer zo goed mogelijk mijn hybride omvormer aan te sturen vanuit de velden die DAO vult. Ik merk soms dat het wat lastig is. Ik zal het proberen te schetsen:

Soms wil je de cap op de laadsnelheid bijvoorbeeld wel respecteren, tijdens goedkope uren wil ik liever bijv 4 uur met 4KW laden, dat kan prima met het efficiency-profiel. Dan zou mijn systeem ook nog 3,5KW invoeden, dat kan ik prima instellen. In dit scenario is de 4KW dus een cap op de laadsnelheid.

Een ander scenario is dat het niet zo zonnig is. Dan zal DAO de laadsnelheid (discharge rate) op een hogere negatieve waarde zetten (dichter bij de nul). Maar in dit scenario is het niet echt een cap. Is hier slim mee om te gaan? Of zie ik iets over het hoofd in de aansturing?