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.