Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[KC27]

Deikke schreef op woensdag 1 juli 2026 @ 16:52:
[...]

Ook nog even de scheduler aanpassen dat ie elke 15 min draait is wel handig.

Zeker, die was ik in de gauwigheid vergeten.

[thesaxofonist]

KC27 schreef op woensdag 1 juli 2026 @ 15:58:
[...]

Je zet interval op "15min", haalt de prijzen van vandaag en morgen opnieuw "met de hand" op en gaan met die banaan.

Dat heb ik gedaan. Ik krijg dit als foutmelding: Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken. Het werkt overigens al langer niet, maar ik heb er geen aandacht aan besteed omdat toen nog niet relevant was. De fout is ontstaan op een dag dat ik veel op en neer geschakeld ben van 15min naar 1hour. Ook andere dingen gewijzigd, maar volgens mij heb ik alles goed teruggezet.

Hier mijn configuratiefile. Wat zou ik nog kunnen proberen?

code:

{
  "config_version": 2,
  "homeassistant": {
    "ip_address": "supervisor",
    "protocol_api": "http"
  },
  "database_ha": {
    "engine": "sqlite",
    "db_path": "/homeassistant",
    "database": "home-assistant_v2.db"
  },
  "database_da": {
    "engine": "sqlite",
    "db_path": "../data",
    "database": "day_ahead.db"
  },
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "entsoe_api_key": "!secret entsoe-api-key",
    "energy_taxes_consumption": {
      "2026-01-01": 0.09161
    },
    "energy_taxes_production": {
      "2026-01-01": 0.09161
    },
    "cost_supplier_consumption": {
      "2024-08-01": 0.0165
    },
    "cost_supplier_production": {
      "2024-08-01": 0.0165
    },
    "vat_consumption": {
      "2023-01-01": 21.0
    },
    "vat_production": {
      "2023-01-01": 21.0
    },
    "multiplier_consumption": {
      "2000-01-01": 1.0
    },
    "multiplier_production": {
      "2000-01-01": 1.0
    },
    "last_invoice": "2025-09-01",
    "tax_refund": false,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },
  "logging_level": "info",
  "use_calc_baseload": false,
  "baseload_calc_periode": 35,
  "baseload": [
    0.1,
    0.1,
    0.1,
    0.1,
    0.1,
    0.1,
    0.1,
    0.2,
    0.2,
    0.2,
    0.1,
    0.1,
    0.2,
    0.1,
    0.2,
    0.1,
    0.1,
    0.5,
    0.5,
    0.2,
    0.2,
    0.2,
    0.1,
    0.1
  ],
  "graphical_backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": false,
    "prices_spot": true,
    "average_consumption": true,
    "show": "true"
  },
  "interval": "15min",
  "strategy": "minimize cost",
  "max_gap": 0.1,
  "notifications": {
    "opstarten": false,
    "berekening": false
  },
  "grid": {
    "max_power": 17.0
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "qcells1",
      "entity_actual_level": "sensor.hansol_batterij_niveau",
      "capacity": 5.0,
      "upper_limit": 92,
      "lower_limit": 15,
      "penalty_low_soc": 0.0025,
      "charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        }
      ],
      "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 2000.0,
          "efficiency": 0.95
        },
        {
          "power": 4600.0,
          "efficiency": 0.95
        }
      ],
      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],
      "minimum_power": 100,
      "dc_to_bat_efficiency": 0.95,
      "dc_to_bat_max_power": 2000,
      "bat_to_dc_efficiency": 0.85,
      "bat_to_dc_max_power": 2000,
      "cycle_cost": 0.015,
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "entity_from_battery": "input_number.dao_from_battery_1",
      "entity_calculated_soc": "input_number.dao_calculated_soc_1",
      "solar": [
        {
          "name": "string1",
          "tilt": 30.0,
          "orientation": 0.0,
          "capacity": 3.3,
          "yield_factor": 0.0059,
          "strings": [],
          "ml_prediction": true,
          "ml_training_start_date": "2000-01-01",
          "entities_sensors": [
            "sensor.saj_sununo_plus_4k_m_total_yield"
          ]
        },
        {
          "name": "string2",
          "tilt": 30.0,
          "orientation": 0.0,
          "capacity": 1.95,
          "yield_factor": 0.004,
          "strings": [],
          "ml_prediction": false,
          "ml_training_start_date": "2000-01-01",
          "entities_sensors": [
            "sensor.sununo_5k_string1_energie_kwh"
          ]
        }
      ],
      "entity balance switch": "input_boolean.dao_balance_switch_1"
    }
  ],
  "solar": [
    {
      "name": "string3",
      "tilt": 30.0,
      "orientation": 0.0,
      "capacity": 1.95,
      "yield_factor": 0.004,
      "strings": [],
      "ml_prediction": false,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": [
        "sensor.sununo_5k_string2_energie_kwh"
      ]
    },
    {
      "name": "string4",
      "entity_pv_switch": "input_boolean.dao_pv_switch_saj_r5",
      "tilt": 30.0,
      "orientation": 0.0,
      "capacity": 1.95,
      "yield_factor": 0.004,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": [
        "sensor.saj_r5_string1_energie_kwh"
      ]
    },
    {
      "name": "Noord",
      "tilt": 45.0,
      "orientation": 180.0,
      "capacity": 4.77,
      "yield_factor": 0.004,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": [
        "sensor.saj_r5_string2_energie_kwh"
      ]
    },
    {
      "name": "Envoy",
      "entity_pv_switch": "input_boolean.dao_pv_switch_envoy",
      "tilt": 15.0,
      "orientation": 0.0,
      "capacity": 5.0,
      "yield_factor": 0.0029,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": [
        "sensor.envoy_121317004432_lifetime_energy_production"
      ]
    }
  ],
  "electric_vehicle": [],
  "machines": [],
  "boiler": {
    "boiler_present": false,
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater_present": false,
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "tibber": {
    "api_token": "!secret tibber_api_token",
    "api_url": "https://api.tibber.com/v1-beta/gql"
  },
  "xgboost": {
    "tune_hyperparameters": true
  },
  "report": {
    "entities_grid_consumption": [
      "sensor.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.saj_r5_3_6k_s2_total_yield_gefilterd",
      "sensor.saj_sununo_plus_4k_m_total_yield",
      "sensor.saj_sununo_plus_5k_m_total_yield",
      "sensor.envoy_121317004432_lifetime_energy_production"
    ],
    "entities_solar_production_dc": [],
    "entities_ev_consumption": [],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [],
    "entities_battery_production": [],
    "entities_machine_consumption": []
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "0435",
        "action": "get_meteo_data"
      },
      {
        "time": "1035",
        "action": "get_meteo_data"
      },
      {
        "time": "1635",
        "action": "get_meteo_data"
      },
      {
        "time": "2235",
        "action": "get_meteo_data"
      },
      {
        "time": "1310",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1735",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1405",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "xx00",
        "action": "calc_optimum"
      },
      {
        "time": "xx15",
        "action": "calc_optimum"
      },
      {
        "time": "xx30",
        "action": "calc_optimum"
      },
      {
        "time": "xx40",
        "action": "calc_optimum"
      },
      {
        "time": "xx45",
        "action": "calc_optimum"
      },
      {
        "time": "xx50",
        "action": "calc_optimum"
      },
      {
        "time": "xx55",
        "action": "calc_optimum"
      },
      {
        "time": "2359",
        "action": "clean_data"
      },
      {
        "time": "0005",
        "action": "train_ml_predictions"
      },
      {
        "time": "0018",
        "action": "calc_baseloads"
      }
    ]
  },
  "meteoserver_attempts": 2
}

[

[ Voor 92% gewijzigd door thesaxofonist op 01-07-2026 18:39 ]

[pimNH]

thesaxofonist schreef op woensdag 1 juli 2026 @ 17:10:
[...]

Dat heb ik gedaan. Ik krijg dit als foutmelding: Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken. Het werkt overigens al langer niet, maar ik heb er geen aandacht aan besteed omdat toen nog niet relevant was. De fout is ontstaan op een dag dat ik veel op en neer geschakeld ben van 15min naar 1hour. Ook andere dingen gewijzigd, maar volgens mij heb ik alles goed teruggezet.

Hier mijn configuratiefile. Wat zou ik nog kunnen proberen?


[...]
[

Had net hetzelfde probleem, day ahead prijzen moet je zo ophalen:

Day ahead prijzen ophalen prijzen_start prijzen_tot 2026-07-02, geen start datum invullen!

[thesaxofonist]

pimNH schreef op woensdag 1 juli 2026 @ 18:48:
[...]

Had net hetzelfde probleem, day ahead prijzen moet je zo ophalen:

Day ahead prijzen ophalen prijzen_start prijzen_tot 2026-07-02, geen start datum invullen!

Dit werkt! Bedankt, ik ben hier inmiddels uren mee bezig geweest. En nu binnen een paar minuten weer kwartierwaarden.

[The Source]

The Source schreef op maandag 29 juni 2026 @ 00:36:
Ik weet dat het voorbij gekomen is, maar ik kan het niet vinden. Mijn solar loopt een uur achter.
Daarbij merk ik dat ik op West ook meer schaduw krijg dan verwacht. Helaas heb ik nog geen genoeg historische data voor deze string. Moet ik dan de yield factor omlaag gooien?

[Afbeelding]


[...]

@KC27 Kun je aub confirmen dat bovenstaande idd correct is.
Ik heb nu terug gevonden dat de straling van KMNI komt en dat een plat vlak betreft, de ML en DAO data berekenen dit naar de helling en orientatie van de panelen. Klopt dat? Visueel is het nog steeds gek.

Daarnaast zie ik dat de prognose in zoawel DAO als ML meer verwachten dan de daadwerkelijke opbrengst. Moet ik dan de yield factor omlaag gooien?

[pimNH]

The Source schreef op woensdag 1 juli 2026 @ 19:04:
[...]

@KC27 Kun je aub confirmen dat bovenstaande idd correct is.
Ik heb nu terug gevonden dat de straling van KMNI komt en dat een plat vlak betreft, de ML en DAO data berekenen dit naar de helling en orientatie van de panelen. Klopt dat? Visueel is het nog steeds gek.

Daarnaast zie ik dat de prognose in zoawel DAO als ML meer verwachten dan de daadwerkelijke opbrengst. Moet ik dan de yield factor omlaag gooien?

Bij mij lijkt de prognose inderdaad ook altijd een uur later dan de realiteit, nu maakt het nog niet zoveel uit maar volgend jaar als de saldering er af is is het wel handig dat t klopt. Ik zat even verkeerd te kijken, volgensmij klopt het gewoon.

[ Voor 21% gewijzigd door pimNH op 01-07-2026 19:15 ]

[simnet]

thesaxofonist schreef op woensdag 1 juli 2026 @ 17:10:
[...]

Dat heb ik gedaan. Ik krijg dit als foutmelding: Er ontbreken kwartierwaarden van de day-ahead tarieven, de berekening wordt afgebroken. Het werkt overigens al langer niet, maar ik heb er geen aandacht aan besteed omdat toen nog niet relevant was. De fout is ontstaan op een dag dat ik veel op en neer geschakeld ben van 15min naar 1hour. Ook andere dingen gewijzigd, maar volgens mij heb ik alles goed teruggezet.

Hier mijn configuratiefile. Wat zou ik nog kunnen proberen?


[...]
[

Het valt me op dat je batterij geen charge stages heeft. Misschien is dat het?

[thesaxofonist]

simnet schreef op woensdag 1 juli 2026 @ 19:32:
[...]

Het valt me op dat je batterij geen charge stages heeft. Misschien is dat het?

Goed gezien! Maar dat was de oorzaak niet. Probleem is inmiddels opgelost, zie een paar berichten hierboven.

Mijn systeem is een AOI (All-In-One), dus geïntegreerde omvormer/accu die alleen kan laden vanuit PV. @KC27 heeft me op weg geholpen om dat ingesteld te krijgen. En dat werkt prima zo.

Nu valt het kwartje: je hebt een hybride pv-omvormer waarop je pv-panelen en een batterij zijn aangesloten. Die omvormer kan alleen terugleveren.

Dat kun je in DAO vrij eenvoudig definiëren door maar 1 charge-stage te definiëren:

code:

"charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        }
 ]

En je configureert je panelen natuurlijk binnen de batterij.

[ Voor 3% gewijzigd door thesaxofonist op 01-07-2026 20:04 ]

[jessedejong1989]

even voor de zonneplan gebruikers onder ons. klopt deze prijs config?

"energy_taxes_consumption": {

"2022-01-01": 0.06729,

"2023-01-01": 0.12599,

"2024-01-01": 0.1088,

"2025-01-01": 0.10154,

"2026-01-01": 0.09161

},

"energy_taxes_production": {

"2022-01-01": 0.06729,

"2023-01-01": 0.12599,

"2024-01-01": 0.1088,

"2025-01-01": 0.10154,

"2026-01-01": 0.0

},

"cost_supplier_consumption": {

"2022-01-01": 0.002,

"2023-03-01": 0.018,

"2024-04-01": 0.0175,

"2024-08-01": 0.020496,

"2026-01-01": 0.02

},

"cost_supplier_production": {

"2022-01-01": 0.002,

"2023-03-01": 0.018,

"2024-04-01": 0.0175,

"2024-08-01": 0.020496,

"2026-01-01": -0.02

},

"vat_consumption": {

"2022-01-01": 21.0,

"2022-07-01": 9.0,

"2023-01-01": 21.0

},

"vat_production": {

"2022-01-01": 21.0,

"2022-07-01": 9.0,

"2023-01-01": 21.0

},

"multiplier_consumption": {

"2000-01-01": 1.0

},

"multiplier_production": {

"2000-01-01": 1.1

[Mirabis]

jessedejong1989 schreef op donderdag 2 juli 2026 @ 00:20:
even voor de zonneplan gebruikers onder ons. klopt deze prijs config?


[...]

Volgens mij heb je de inkoopvergoeding incl. btw (0.02) ingevuld i.p.v. excl. BTW (0.01652893)

[Mirabis]

jessedejong1989 schreef op donderdag 2 juli 2026 @ 00:20:
even voor de zonneplan gebruikers onder ons. klopt deze prijs config?


[...]

Volgens mij heb je de inkoopvergoeding incl. btw (0.02) ingevuld i.p.v. excl. BTW (0.01652893). En onder 'energy taxes production' dien je ook nog 0.09161 mee te nemen dit jaar als je mag salderen.

code:

 "prices": {
    "source_day_ahead": "nordpool",
    "entsoe_api_key": "!secret entsoe-api-key",
    "energy_taxes_consumption": {
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161
    },
    "energy_taxes_production": {
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161,
      "2027-01-01": 0.0
    },
    "cost_supplier_consumption": {
      "2024-08-01": 0.020496,
      "2026-01-01": 0.01652893
    },
    "cost_supplier_production": {
      "2024-08-01": 0.020496,
      "2026-01-01": 0.01818182,
      "2026-01-22": 0.01652893
    },
    "vat_consumption": {
      "2000-01-01": 21.0
    },
    "vat_production": {
      "2000-01-01": 21.0,
      "2027-01-01": 0.0
    },
    "multiplier_consumption": {
      "2000-01-01": 1.0
    },
    "multiplier_production": {
      "2000-01-01": 1.0,
      "2026-01-01": 1.1
    },
    "last_invoice": "2026-01-01",
    "tax_refund": true
  },

[Animal]

Deikke schreef op woensdag 1 juli 2026 @ 16:52:
[...]

Ook nog even de scheduler aanpassen dat ie elke 15 min draait is wel handig.

De interval staat nu zo:

},

"interval": "15min",

"strategy": "minimize cost",

"max_gap": 0.005,

"notifications": {

"opstarten": false,

"berekening": false

},

Begrijp ik dat ik deze scheduler xx00 moet aanpassen? Hoe dan precies?

{

"time": "xx00",

"action": "calc_optimum"

},


Is het deze?

[ Voor 102% gewijzigd door Animal op 02-07-2026 01:30 ]

[thomvh]

Animal schreef op donderdag 2 juli 2026 @ 01:27:
[...]

De interval staat nu zo:


[...]

Begrijp ik dat ik deze scheduler xx00 moet aanpassen? Hoe dan precies?


[...]

code:

"time": "xx00",
"time": "xx15",
"time": "xx30",
"time": "xx45",

Staat ook op de wiki. https://github.com/cornee...ppen-naar-kwartierprijzen

[ Voor 15% gewijzigd door thomvh op 02-07-2026 09:14 ]

[ErnstH]

jessedejong1989 schreef op donderdag 2 juli 2026 @ 00:20:
even voor de zonneplan gebruikers onder ons. klopt deze prijs config?


[...]

Is de multiplier production een flex setting? Want die moet als de zon onder is naar 1 worden gezet idealiter. (Ik ga per 1 januari weer over naar zonneplan denk ik)

Alhoewel, een flex setting is nog steeds niet perfect, aangezien DAO er dan niet mee kan rekenen van tevoren.

[ Voor 13% gewijzigd door ErnstH op 02-07-2026 09:58 ]

[Impossibl3]

Mirabis schreef op donderdag 2 juli 2026 @ 01:21:
[...]

Volgens mij heb je de inkoopvergoeding incl. btw (0.02) ingevuld i.p.v. excl. BTW (0.01652893). En onder 'energy taxes production' dien je ook nog 0.09161 mee te nemen dit jaar als je mag salderen.


[...]

Waarom heb jij bij "multiplier_production" 1.1 ingevoerd vanaf 2026? Is dat om de zonnebonus van 2 cent een beetje na te bootsen?

[jessedejong1989]

Impossibl3 schreef op donderdag 2 juli 2026 @ 10:10:
[...]


Waarom heb jij bij "multiplier_production" 1.1 ingevoerd vanaf 2026? Is dat om de zonnebonus van 2 cent een beetje na te bootsen?

nee, omdat we 10% "zonnebonus" krijgen voor terugleveren bij zonneplan.


ander vraagje. de baseload. ik heb een remeha elga ace 4kw hybride warmtepomp. houd de baseload hier in de winter automatisch rekening mee?

[ Voor 18% gewijzigd door jessedejong1989 op 02-07-2026 10:55 ]

[thomvh]

jessedejong1989 schreef op donderdag 2 juli 2026 @ 10:54:
[...]

nee, omdat we 10% "zonnebonus" krijgen voor terugleveren bij zonneplan.


ander vraagje. de baseload. ik heb een remeha elga ace 4kw hybride warmtepomp. houd de baseload hier in de winter automatisch rekening mee?

Ja, gebaseerd op historische info, om het beter te maken zet je je warmtepomp als losse reporting entiteit erin. Dan weet hij ook specifiek wat de warmtepomp is.

[Bravo]

thomvh schreef op donderdag 2 juli 2026 @ 11:29:
[...]

Ja, gebaseerd op historische info, om het beter te maken zet je je warmtepomp als losse reporting entiteit erin. Dan weet hij ook specifiek wat de warmtepomp is.

Als de de WP als losse entiteit meeneemt, wordt hij niet meer in de baseload meegerekend.
Als je de WP via DAO aanstuurt, dan kan DAO er rekening mee houden. Als de WP 'zijn eigen ding doet' EN als losse entiteit wordt gemeten, dan zit de last van de WP niet in de baseload en wordt er dus geen rekening mee gehouden.

Aanvulling: de baseload berekening kijkt altijd terug (standaard 56 dagen) wat de baseload was. Het houdt op geen enkele manier rekening met wijzigende omstandigheden zoals een koudere periode, wat wel relevant is voor het verbruik van een warmtepomp.

[ Voor 17% gewijzigd door Bravo op 02-07-2026 13:19 ]

[jessedejong1989]

aha.. deze er even uithalen dus:

"entities_wp_consumption": [

"sensor.warmtepomp_energy"

],


deze sensor zit overigens ook in het energiedashboard van HA. maar zit er pas sinds een week op.

[ Voor 31% gewijzigd door jessedejong1989 op 02-07-2026 12:36 ]

[rescla]

Ter info, na het updaten naar Home Assistant 2026.7.0 is bij mij het gedrag van de entity die ik bij entity_position geconfigueerd heb voor mijn elektrische auto. Hierdoor werd laden niet meer ingepland. De oorzaak zat hem in een zone die overlapt met mijn home zone, waardoor de location iets anders dan de home was, en DAO de laadsessie niet meer inplande.

Volgens mij komt het door deze change: https://www.home-assistant.io/blog/2026/07/01/release-20267#content_11

Voor nu heb ik de andere zone verwijderd, maar het zou mooi zijn als dit gefixt wordt

[KC27]

rescla schreef op donderdag 2 juli 2026 @ 13:43:
Ter info, na het updaten naar Home Assistant 2026.7.0 is bij mij het gedrag van de entity die ik bij entity_position geconfigueerd heb voor mijn elektrische auto. Hierdoor werd laden niet meer ingepland. De oorzaak zat hem in een zone die overlapt met mijn home zone, waardoor de location iets anders dan de home was, en DAO de laadsessie niet meer inplande.

Volgens mij komt het door deze change: https://www.home-assistant.io/blog/2026/07/01/release-20267#content_11

Voor nu heb ik de andere zone verwijderd, maar het zou mooi zijn als dit gefixt wordt

Hoe zou jij het dan nu willen: dat zowel "home" als "near_home" worden aangemerkt als "home"?

[rescla]

KC27 schreef op donderdag 2 juli 2026 @ 14:01:
[...]

Hoe zou jij het dan nu willen: dat zowel "home" als "near_home" worden aangemerkt als "home"?

Nee, van mij hoeft het niet configurabel te zijn. Ik weet niet exact wat voorheen het gedrag was, maar ik zie nu het volgende:

code:

state: test
in_zones:
  - zone.test
  - zone.home

De state waarde is nu "test", maar hij zit ook in de home zone, en dat kan je zien aan in_zones attribuut.

Ik zou verwachten dat er niet (alleen) gekeken wordt naar de state, maar ook naar in_zones, of home in de lijst zit.

Als ik het goed begrijp is met deze update de sortering van de zones veranderd. Van het dichtst bij het centrum van het gebied, naar gesorteerd van klein naar groot. Daardoor was de "normale" state waarde niet meer home bij mij.

[KC27]

rescla schreef op donderdag 2 juli 2026 @ 14:19:
[...]

Nee, van mij hoeft het niet configurabel te zijn. Ik weet niet exact wat voorheen het gedrag was, maar ik zie nu het volgende:

code:

state: test
in_zones:
  - zone.test
  - zone.home

De state waarde is nu "test", maar hij zit ook in de home zone, en dat kan je zien aan in_zones attribuut.

Ik zou verwachten dat er niet (alleen) gekeken wordt naar de state, maar ook naar in_zones, of home in de lijst zit.

Als ik het goed begrijp is met deze update de sortering van de zones veranderd. Van het dichtst bij het centrum van het gebied, naar gesorteerd van klein naar groot. Daardoor was de "normale" state waarde niet meer home bij mij.

DAO test nu of een auto in de zone "home" is. Alles wat niet "home" was was "away". Als ik jou goed begrijp moet DAO nu testen op "home" of op "near_home". Zodra een van beide "true" is wordt de auto aangemerkt als "home" en kan het laden worden ingepland.
Klopt het zo?

Of ook kijken of een van de attributen "home" is?

[rescla]

KC27 schreef op donderdag 2 juli 2026 @ 14:35:
[...]

DAO test nu of een auto in de zone "home" is. Alles wat niet "home" was was "away". Als ik jou goed begrijp moet DAO nu testen op "home" of op "near_home". Zodra een van beide "true" is wordt de auto aangemerkt als "home" en kan het laden worden ingepland.
Klopt het zo?

Of ook kijken of een van de attributen "home" is?

https://github.com/cornee...o/prog/day_ahead.py#L1516

code:

position = self.get_state(self.ev_options[e].entity_position).state
ev_position.append(position)
...
and (ev_position[e] == "home")

Er wordt nu alleen naar .state gekeken. Die kan "home" zijn, maar in mijn geval is die dus "test" ipv "home". Wat ik bedoel is dat er in plaats van 1 zones/positions waar de ev in kan zijn, nu een lijst van zones/positions zou moeten zijn (de inhoud van in_zones). En dan vervolgens kijken of deze "home" bevat.

Dus meer zoiets:

code:

positions = self.get_state(self.ev_options[e].entity_position).in_zones
ev_position.append(positions)
...
and ("home" in ev_position[e])

Wat jij voorstelt kan natuurlijk ook, dan zou ik een lijst van zones die overlappen met Home op moeten geven. Maar dat is extra configuratie die iemand dan moet toevoegen, voor raar gedrag waarbij niet meteen duidelijk is wat de oorzaak is.

Geen idee wat de syntax van get_state is, en of je daarmee een state attribute op kan halen. Maar in een template zou je dit doen:

code:

{{ "zone.home" in state_attr("device_tracker.tesla_location", "in_zones")}}

[ Voor 6% gewijzigd door rescla op 02-07-2026 14:55 ]

[KC27]

rescla schreef op donderdag 2 juli 2026 @ 14:49:
[...]

https://github.com/cornee...o/prog/day_ahead.py#L1516

code:

position = self.get_state(self.ev_options[e].entity_position).state
ev_position.append(position)
...
and (ev_position[e] == "home")

Er wordt nu alleen naar .state gekeken. Die kan "home" zijn, maar in mijn geval is die dus "test" ipv "home". Wat ik bedoel is dat er in plaats van 1 zones/positions waar de ev in kan zijn, nu een lijst van zones/positions zou moeten zijn (de inhoud van in_zones). En dan vervolgens kijken of deze "home" bevat.

Dus meer zoiets:

code:

positions = self.get_state(self.ev_options[e].entity_position).in_zones
ev_position.append(positions)
...
and ("home" in ev_position[e])

Wat jij voorstelt kan natuurlijk ook, dan zou ik een lijst van zones die overlappen met Home op moeten geven. Maar dat is extra configuratie die iemand dan moet toevoegen, voor raar gedrag waarbij niet meteen duidelijk is wat de oorzaak is.

Geen idee wat de syntax van get_state is, en of je daarmee een state attribute op kan halen. Maar in een template zou je dit doen:

code:

{{ "zone.home" in state_attr("device_tracker.tesla_location", "in_zones")}}

Ja zoiets is ook in Python mogelijk.
Dank je wel voor het melden en meedenken.

[Bravo]

In verband met de overstap van Zonneplan naar kwartierprijzen had ik DAO alvast overgezet.
Nu zat ik naar de PV verwachting van morgen te kijken en zag ik per kwartier ruim 1 kWh geproduceerd worden, dat is een beetje veel voor 2300W en 1500W max. Als ik DAO weer op een uur zet, dan krijg ik wel waarden die goed lijken.
Zie bovenstaande arceringen in geel uit de berekening. Enig idee waar het mis kan gaan? Machine Learning voor de PV opbrengst staat uit.
DAO versie: 2026.06

[thomvh]

Bravo schreef op donderdag 2 juli 2026 @ 17:05:
[Afbeelding]
In verband met de overstap van Zonneplan naar kwartierprijzen had ik DAO alvast overgezet.
Nu zat ik naar de PV verwachting van morgen te kijken en zag ik per kwartier ruim 1 kWh geproduceerd worden, dat is een beetje veel voor 2300W en 1500W max. Als ik DAO weer op een uur zet, dan krijg ik wel waarden die goed lijken.
Zie bovenstaande arceringen in geel uit de berekening. Enig idee waar het mis kan gaan? Machine Learning voor de PV opbrengst staat uit.
DAO versie: 2026.06

Heb je de nieuwe PV voorspelling opgehaald na het wisselen?

[Bravo]

thomvh schreef op donderdag 2 juli 2026 @ 20:53:
[...]

Heb je de nieuwe PV voorspelling opgehaald na het wisselen?

Ik zou niet weten wat dat zou opleveren? De meteodata is altijd in uren.
Maar een rerun heeft geen effect op de uitkomst van de PV opbrengst.

[thomvh]

Bravo schreef op donderdag 2 juli 2026 @ 21:03:
[...]

Ik zou niet weten wat dat zou opleveren? De meteodata is altijd in uren.
Maar een rerun heeft geen effect op de uitkomst van de PV opbrengst.

Ik zit bij die van mij te kijken. Die is ook best wel heel positief morgen. Heb 7,8kWp liggen. Hij doet gemiddeld tussen 14 en 15 per kwartier 2,3 kWh aangeven. Dat is toch een goeie 117% van mijn vermogen. Een heel uur lang.

[ Voor 4% gewijzigd door thomvh op 02-07-2026 21:21 ]

[LittleKiller]

@KC27

Ik heb inmiddels DAO draaien. Top werk!

Ik ben mijn growatt systeem aan het aanleggen, dat in combinatie met een backupbox. Aangezien daar toch een 500ms wordt gespecificeerd voordat die overschakelt naar eiland bedrijf, heb ik daarbij ook een anker solix batterij gekocht (voor de kritische systemen) om als UPS te fungeren.

Nu viel mijn oog op "noodweer" functie. wat dat eigenlijk doet is de batterij volledig opladen op het moment dat er bijzonder weer aan komt. Zodoende kwam ik op het idee om mijn batterij systeem vol te hebben als er een bepaalde weercode aankomt.

Om DAO niet vol met bloat te krijgen, lijkt het me onlogisch om dat in DAO te bouwen, maar wat natuurlijk wel kan, is om de min_soc_end_opt aan een bepaald tijdsslot te hangen. Dus eigenlijk je horizon af te kappen.

Kortom: een extra entity/variabele in de trend van:

"min_soc_schedule": [
{ "time": "18:00", "soc": 80 },
{ "time": "22:00", "soc": 90 }
]

of eigenlijk mooier een nieuwe functie oid:

"soc_deadlines": [
{ "at": "18:00", "minimum": 80 }
]

Heb ik je zegen om een PR te maken hiervoor? Ik wil geen werk doen wat verloren gaat, en ik heb geen zin om een fork te gaan onderhouden.

[pimNH]

LittleKiller schreef op donderdag 2 juli 2026 @ 22:20:

Kun je die top up charge niet beter doen door hem als een machine programma aan te roepen. Zou wel mooi zijn als het verbruik van een machine programma met entiteiten in te stellen is, maar je kunt ook meerdere programma's aanmaken afhankelijk van hoeveel % soc bijgeladen moet worden.

[LittleKiller]

pimNH schreef op donderdag 2 juli 2026 @ 22:30:
[...]

Kun je die top up charge niet beter doen door hem als een machine programma aan te roepen. Zou wel mooi zijn als het verbruik van een machine programma met entiteiten in te stellen is, maar je kunt ook meerdere programma's aanmaken afhankelijk van hoeveel % soc bijgeladen moet worden.

Ja, maar dan mis je wel de kans om te optimizen TOT die potentiële nood situatie. Alle logica zit al in dao, waarom niet gebruik van maken

[jessedejong1989]

ben ik nou gek? hij doet voor morgen helemaal niks? je zou toch zeggen dat het morgen middag lekker goedkoop laden is, en vanacht en morgenavond 0 op de meter te draaien?

[KC27]

jessedejong1989 schreef op vrijdag 3 juli 2026 @ 20:05:
[Afbeelding] ben ik nou gek? hij doet voor morgen helemaal niks? je zou toch zeggen dat het morgen middag lekker goedkoop laden is, en vanacht en morgenavond 0 op de meter te draaien?

Ik denk dat er iets niet goed staat bij je instellingen (cycle cost, efficiëncy, ??).
Ik heb deze inzet:

[DaBit]

Wat mij opvalt is dat als ik zeg dat EV laden om bijvoorbeeld 18.00 klaar moet zijn (oftewel: gebruik het prijsdal overdag voor het laden) dat het eigenlijke laden pas ver aan het eind van het dal gebeurt omdat de stroom dan bijvoorbeeld 0.127ct/kWh kost ipv 0.13ct/kWh. De reeele besparing van dat wachten is nihil, en het is om diverse redenen niet helemaal gewenst. Soms red DAO het dan niet meer om de opgegeven SoC te bereiken omdat er andere verbruikers actief zijn, omdat je toch nog even weg moest, etcetera.

Ik zou graag zien dat als de kostenimpact minimaal is dat verbruikers eerder in de tijd bediend worden.

Wat misschien zou kunnen werken is een mechanisme vergelijkbaar aan de switch_cost; virtuele extra kosten die oplopen naarmate het ready datetime tijdstip nadert?

[balk]

DaBit schreef op zaterdag 4 juli 2026 @ 10:29:
Wat mij opvalt is dat als ik zeg dat EV laden om bijvoorbeeld 18.00 klaar moet zijn (oftewel: gebruik het prijsdal overdag voor het laden) dat het eigenlijke laden pas ver aan het eind van het dal gebeurt omdat de stroom dan bijvoorbeeld 0.127ct/kWh kost ipv 0.13ct/kWh. De reeele besparing van dat wachten is nihil, en het is om diverse redenen niet helemaal gewenst. Soms red DAO het dan niet meer om de opgegeven SoC te bereiken omdat er andere verbruikers actief zijn, omdat je toch nog even weg moest, etcetera.

Ik zou graag zien dat als de kostenimpact minimaal is dat verbruikers eerder in de tijd bediend worden.

Wat misschien zou kunnen werken is een mechanisme vergelijkbaar aan de switch_cost; virtuele extra kosten die oplopen naarmate het ready datetime tijdstip nadert?

Volgens mij is zoiets ook al eerder langs gekomen, en ge-road-mapped. Iets met het toekennen van waarde aan elke opgeslagen kWh dacht ik, om het rekenkundig mogelijk te maken?

[Dogooder]

Of je voegt een hele kleine penalty toe die toeneemt per kwartier/uur later starten. Dit zal ook het laden naar voren halen.

Oh wacht dat is precies wat Dabit zegt

[ Voor 15% gewijzigd door Dogooder op 04-07-2026 22:20 ]

[storeman]

Ik ben bezig geweest om de frontend op te frissen. Ik heb een stukje van de webserver herschreven en ik hoor graag jullie feedback. Ik heb een discussion geopend op github:

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

[balk]

storeman schreef op zondag 5 juli 2026 @ 00:04:
Ik ben bezig geweest om de frontend op te frissen. Ik heb een stukje van de webserver herschreven en ik hoor graag jullie feedback. Ik heb een discussion geopend op github:

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

Wat goed! @simnet is het mogelijk om de config ui er in te integreren? Dat zou een mooie combi zijn!

[ljsquare]

KC27 schreef op dinsdag 30 juni 2026 @ 21:50:
[...]

Ik bedoelde dat je ze een voor een uitschakelt en dan steeds een extra. Zou je dat eens willen proberen?
Ik ga ondertussen toch nog even naar je loggings kijken.

Het systeem draaide voor een paar dagen wel weer goed, tot vandaag.
Nu heb ik alles uitgeschakeld, maar het probleem bleef. Echter ik denk dat het met de setting te maken heeft.

code:

 "use_calc_baseload": true,

Als ik deze op false zet, werkt het weer.

Wat kan er voor zorgen dat soms deze instelling wel werkt, en soms niet?
Ik heb een baseload berekening laten doen:

2026-07-05 17:53:38 INFO: Loaded 6 secrets from ../data/secrets.json
2026-07-05 17:53:38 INFO: Validating configuration with ConfigurationV2
2026-07-05 17:53:39 info: Day Ahead Optimalisering versie: 2026.6.0
2026-07-05 17:53:39 info: Day Ahead Optimalisering gestart op: 05-07-2026 17:53:39
2026-07-05 17:53:39 info: Day Ahead Optimalisatie gestart: 05-07-2026 17:53:39 taak: calc_baseloads
2026-07-05 17:55:10 info: baseload voor weekdag 0 :
2026-07-05 17:55:10 info: 0.362 0.338 0.396 0.332 0.384 0.315 0.318 0.365 0.39 0.788 0.332 0.549 0.482 0.458 0.494 0.458 573.035 0.337 0.614 0.54 0.556 0.43 0.457 0.504
2026-07-05 17:56:38 info: baseload voor weekdag 1 :
2026-07-05 17:56:38 info: 0.646 0.569 0.674 0.611 0.476 0.372 0.355 0.462 0.358 0.395 0.48 0.527 0.725 0.682 0.771 0.57 1.048 0.557 0.802 0.734 0.628 0.64 0.512 0.475
2026-07-05 17:58:08 info: baseload voor weekdag 2 :
2026-07-05 17:58:08 info: 0.42 0.476 0.636 0.543 0.656 0.424 0.314 0.296 0.401 0.386 0.348 0.44 0.413 0.553 0.464 0.396 0.803 0.536 0.526 0.49 0.418 0.474 0.455 0.432
2026-07-05 17:59:42 info: baseload voor weekdag 3 :
2026-07-05 17:59:42 info: 0.395 0.557 0.751 0.668 0.614 0.345 0.334 0.284 0.293 0.257 0.392 0.532 0.636 0.44 0.581 0.415 0.703 0.437 0.811 0.606 0.461 0.521 0.503 0.438
2026-07-05 18:01:22 info: baseload voor weekdag 4 :
2026-07-05 18:01:22 info: 0.531 0.584 0.576 0.68 0.469 0.394 0.312 0.29 0.259 0.296 0.166 0.602 0.554 0.516 0.504 0.496 0.81 0.403 0.416 0.362 0.388 0.406 0.401 0.404
2026-07-05 18:02:56 info: baseload voor weekdag 5 :
2026-07-05 18:02:56 info: 0.372 0.345 0.385 0.47 0.48 0.375 0.326 0.279 0.266 0.342 0.54 0.507 0.541 0.612 0.517 0.366 0.644 0.333 0.428 0.419 0.403 0.374 0.396 0.405
2026-07-05 18:04:38 info: baseload voor weekdag 6 :
2026-07-05 18:04:38 info: 0.428 0.383 0.465 0.428 0.465 0.427 0.334 0.278 0.285 0.774 621.974 0.547 0.57 0.679 0.554 0.574 0.611 0.424 0.379 0.446 0.411 0.433 0.45 0.434

Wat mijn opvalt is de zeer hoge waarde op het 16e uur van weekdag 0 en de 10e van weekdag 6.
Zou dit een aanwijzing kunnen zijn?

[ Voor 63% gewijzigd door ljsquare op 05-07-2026 18:07 ]

[KC27]

ljsquare schreef op zondag 5 juli 2026 @ 17:52:
[...]

Het systeem draaide voor een paar dagen wel weer goed, tot vandaag.
Nu heb ik alles uitgeschakeld, maar het probleem bleef. Echter ik denk dat het met de setting te maken heeft.

code:

 "use_calc_baseload": true,

Als ik deze op false zet, werkt het weer.

Wat kan er voor zorgen dat soms deze instelling wel werkt, en soms niet?
Ik heb een baseload berekening laten doen:

[...]

Wat mijn opvalt is de zeer hoge waarde op het 16e uur van weekdag 0 en de 10e van weekdag 6.
Zou dit een aanwijzing kunnen zijn?

Goede analyse!
Die waarden zijn niet zo maar verhoogd, maar veel te hoog. Dat is dus op zondag (weekdag 6) en maandag (weekdag 0).
Ik zou proberen te achterhalen waar die fout zit en hoe je dat kunt repareren. Tot die tijd kun je beter rekenen met "use_calc_baseload": true.
Waarschijnlijk is het een uitschieter van een productie sensor (pv?).
Over hoeveel dagen bereken je de baseload?
Wat staat er in de rapportage van de "vorige maand" bij Reports/Balans ?

[simnet]

balk schreef op zondag 5 juli 2026 @ 15:43:
[...]

Wat goed! @simnet is het mogelijk om de config ui er in te integreren? Dat zou een mooie combi zijn!

Dat lijkt me geen probleem. Ik heb alleen de komende maanden geen tijd om aan de config gui te werken. De openstaaNde PR is nog prima bruikbaar.
Misschien kan @storeman deze PR zelfs wel mergen en in zijn frontend opnemen. Zoals gezegd kom ik er de komende maanden niet aan toe en het zou jammer zijn als al het werk door bitrot te ver achter gaat lopen.

[TheMystery]

@KC27 Ik heb nog een vraagje mbt het aansturen van de bepaalde strategie van DAO waar er maar voor een bepaalde tijd iets moet gebeuren, wat me onduidelijk blijft, dit voorbeeld zou nu alle pv opbrengst teruggeleverd moeten worden aan het net:


Doa komt met deze strategie:

code:

2026-07-06 10:00:01 info: Doorzetten van alle settings naar HA
2026-07-06 10:00:01 info: Grid balanceren: off
2026-07-06 10:00:01 info: Grid set point: -1037.0 W
2026-07-06 10:00:01 info: Cycle cost AlphaEss G3 Smile T10: 1.19 euro
2026-07-06 10:00:01 info: Netto vermogen naar(+)/uit(-) omvormer AlphaEss G3 Smile T10: -5000 W  tot: 2026-07-06 10:20
2026-07-06 10:00:01 info: Vermogen uit batterij: 90W
2026-07-06 10:00:01 info: Vermogen dat binnenkomt van pv: 1668W
2026-07-06 10:00:01 info: Vermogen dat binnenkomt van ac: -1758W
2026-07-06 10:00:01 info: Waarde SoC na eerste uur: 15.0%

Dus eigenlijk zet hij voor 20 min de batterij op 90w terugleveren, en dus gaat de pv ook naar het grid.
na deze 20 min stopt mijn aansturing en gaat mijn batterij nom draaien en dus laad de batterij weer op.

wat is nu precies de bedoeling van DAO dat je na 20 min alles uitzet?
ik zou eigenlijk verwachten dat die 20min niet nodig was en dat ie gewoon 1 uur 90w ontlaad, het heeft denk ik te maken met de ontlaad efficientie dat 5000w waar hij op wilt sturen effifienter is, maar is dit er ook uit te halen?

[thomvh]

TheMystery schreef op maandag 6 juli 2026 @ 10:36:
@KC27 Ik heb nog een vraagje mbt het aansturen van de bepaalde strategie van DAO waar er maar voor een bepaalde tijd iets moet gebeuren, wat me onduidelijk blijft, dit voorbeeld zou nu alle pv opbrengst teruggeleverd moeten worden aan het net:
[Afbeelding]

Doa komt met deze strategie:

code:

2026-07-06 10:00:01 info: Doorzetten van alle settings naar HA
2026-07-06 10:00:01 info: Grid balanceren: off
2026-07-06 10:00:01 info: Grid set point: -1037.0 W
2026-07-06 10:00:01 info: Cycle cost AlphaEss G3 Smile T10: 1.19 euro
2026-07-06 10:00:01 info: Netto vermogen naar(+)/uit(-) omvormer AlphaEss G3 Smile T10: -5000 W  tot: 2026-07-06 10:20
2026-07-06 10:00:01 info: Vermogen uit batterij: 90W
2026-07-06 10:00:01 info: Vermogen dat binnenkomt van pv: 1668W
2026-07-06 10:00:01 info: Vermogen dat binnenkomt van ac: -1758W
2026-07-06 10:00:01 info: Waarde SoC na eerste uur: 15.0%

Dus eigenlijk zet hij voor 20 min de batterij op 90w terugleveren, en dus gaat de pv ook naar het grid.
na deze 20 min stopt mijn aansturing en gaat mijn batterij nom draaien en dus laad de batterij weer op.

wat is nu precies de bedoeling van DAO dat je na 20 min alles uitzet?
ik zou eigenlijk verwachten dat die 20min niet nodig was en dat ie gewoon 1 uur 90w ontlaad, het heeft denk ik te maken met de ontlaad efficientie dat 5000w waar hij op wilt sturen effifienter is, maar is dit er ook uit te halen?

Je kunt toch ook die tijd gewoon negeren en de feedin gebruiken om te bepalen hoeveel er terug geleverd moet worden over de gehele tijdslot?

[TheMystery]

thomvh schreef op maandag 6 juli 2026 @ 10:46:
[...]

Je kunt toch ook die tijd gewoon negeren en de feedin gebruiken om te bepalen hoeveel er terug geleverd moet worden over de gehele tijdslot?

Dat zou idd kunnen maar er zijn ook momenten dat er een half uur ingekocht of verkocht moet worden waar je dat dan eigenlijk wel wilt hebben.
Zonneplan gaat volgende maand over op 15min misschien dat dit dan misschien minder gaat gebeuren?

[KC27]

TheMystery schreef op maandag 6 juli 2026 @ 10:36:
@KC27 Ik heb nog een vraagje mbt het aansturen van de bepaalde strategie van DAO waar er maar voor een bepaalde tijd iets moet gebeuren, wat me onduidelijk blijft, dit voorbeeld zou nu alle pv opbrengst teruggeleverd moeten worden aan het net:
[Afbeelding]

Doa komt met deze strategie:

code:

2026-07-06 10:00:01 info: Doorzetten van alle settings naar HA
2026-07-06 10:00:01 info: Grid balanceren: off
2026-07-06 10:00:01 info: Grid set point: -1037.0 W
2026-07-06 10:00:01 info: Cycle cost AlphaEss G3 Smile T10: 1.19 euro
2026-07-06 10:00:01 info: Netto vermogen naar(+)/uit(-) omvormer AlphaEss G3 Smile T10: -5000 W  tot: 2026-07-06 10:20
2026-07-06 10:00:01 info: Vermogen uit batterij: 90W
2026-07-06 10:00:01 info: Vermogen dat binnenkomt van pv: 1668W
2026-07-06 10:00:01 info: Vermogen dat binnenkomt van ac: -1758W
2026-07-06 10:00:01 info: Waarde SoC na eerste uur: 15.0%

Dus eigenlijk zet hij voor 20 min de batterij op 90w terugleveren, en dus gaat de pv ook naar het grid.
na deze 20 min stopt mijn aansturing en gaat mijn batterij nom draaien en dus laad de batterij weer op.

wat is nu precies de bedoeling van DAO dat je na 20 min alles uitzet?
ik zou eigenlijk verwachten dat die 20min niet nodig was en dat ie gewoon 1 uur 90w ontlaad, het heeft denk ik te maken met de ontlaad efficientie dat 5000w waar hij op wilt sturen effifienter is, maar is dit er ook uit te halen?

Eigenlijk wil je dat hij het hele interval (bij jou het hele uur) de pv opbrengst het grid opstuurt. In zo'n situatie wil je dus niet dat hij rekening houdt met het efficiency voordeel.
Wat zijn je batterij instellingen?

[ljsquare]

KC27 schreef op zondag 5 juli 2026 @ 19:34:
[...]

Goede analyse!
Die waarden zijn niet zo maar verhoogd, maar veel te hoog. Dat is dus op zondag (weekdag 6) en maandag (weekdag 0).
Ik zou proberen te achterhalen waar die fout zit en hoe je dat kunt repareren. Tot die tijd kun je beter rekenen met "use_calc_baseload": true.
Waarschijnlijk is het een uitschieter van een productie sensor (pv?).
Over hoeveel dagen bereken je de baseload?
Wat staat er in de rapportage van de "vorige maand" bij Reports/Balans ?

De baseload berekent hij op de standaard waarde van 56 dagen.
In de rapportage van vorige maand staat inderdaad een extreme waarde bij de PV ac (14-06):

Dag Verbruik Productie Accu_uit Accu in PV ac Elec. vehicle WP Boiler Machines Baseload
kWh kWh kWh kWh kWh kWh kWh kWh kWh kWh
2026-06-01 3.484 3.470 4.040 6.380 13.008 0.000 0.000 0.000 0.000 10.682
2026-06-02 6.173 3.012 3.640 0.490 6.952 0.000 0.000 0.000 0.000 13.263
2026-06-03 4.683 3.695 2.930 5.310 11.859 0.000 0.000 0.000 0.000 10.467
2026-06-04 5.095 5.031 4.500 5.930 11.695 0.000 0.000 0.000 0.000 10.329
2026-06-05 6.392 3.761 6.300 6.120 10.595 0.000 0.000 0.000 0.000 13.406
2026-06-06 3.084 4.085 4.680 5.580 12.516 0.000 0.000 0.000 0.000 10.615
2026-06-07 1.938 3.495 4.920 5.360 10.847 0.000 0.000 0.000 0.000 8.850
2026-06-08 1.105 3.748 3.940 3.980 10.006 0.000 0.000 0.000 0.000 7.323
2026-06-09 1.870 9.224 5.620 6.550 15.725 0.000 0.000 0.000 0.000 7.441
2026-06-10 0.928 9.631 5.480 5.770 16.351 0.000 0.000 0.000 0.000 7.358
2026-06-11 1.185 13.771 4.590 1.110 15.367 0.000 0.000 0.000 0.000 6.261
2026-06-12 2.176 5.762 1.660 2.180 10.995 0.000 0.000 0.000 0.000 6.889
2026-06-13 2.917 4.537 3.100 6.440 11.997 0.000 0.000 0.000 0.000 7.037
2026-06-14 3.210 4.993 5.160 4.900 4983.639 0.000 0.000 0.000 0.000 4982.116
2026-06-15 2.144 4.228 4.710 5.220 11.940 0.000 0.000 0.000 0.000 9.346
2026-06-16 2.967 6.145 5.100 4.520 13.941 0.000 0.000 0.000 0.000 11.343
2026-06-17 3.025 7.007 5.540 6.110 14.680 0.000 0.000 0.000 0.000 10.128
2026-06-18 2.171 13.159 8.220 6.620 21.810 0.000 0.000 0.000 0.000 12.422
2026-06-19 5.253 4.913 4.580 4.120 11.416 0.000 0.000 0.000 0.000 12.216
2026-06-20 3.829 5.613 3.540 6.610 16.359 0.000 0.000 0.000 0.000 11.505
2026-06-21 2.743 6.844 6.070 6.560 17.767 0.000 0.000 0.000 0.000 13.176
2026-06-22 4.037 15.506 5.240 4.650 21.884 0.000 0.000 0.000 0.000 11.005
2026-06-23 5.293 8.149 7.940 6.740 20.715 0.000 0.000 0.000 0.000 19.059
2026-06-24 4.722 11.410 6.080 6.620 21.603 0.000 0.000 0.000 0.000 14.375
2026-06-25 5.113 9.687 6.390 7.570 21.702 0.000 0.000 0.000 0.000 15.948
2026-06-26 3.242 10.274 4.570 6.580 20.617 0.000 0.000 0.000 0.000 11.575
2026-06-27 1.864 8.941 6.260 6.360 18.913 0.000 0.000 0.000 0.000 11.736
2026-06-28 1.663 3.813 7.210 7.000 16.232 0.000 0.000 0.000 0.000 14.292
2026-06-29 2.525 10.289 5.970 6.290 20.895 0.000 0.000 0.000 0.000 12.811
2026-06-30 10.891 5.465 3.880 2.350 10.523 0.000 0.000 0.000 0.000 17.479
Totaal 105.722 209.658 151.860 160.020 5422.549 0.000 0.000 0.000 0.000 5310.453

Ik zal in Home Assistant kijken waarom dit is.
Zojuist in Home Assistant gekeken, maar daar zijn geen extreme waardes te zien.

[TheMystery]

KC27 schreef op maandag 6 juli 2026 @ 11:27:
[...]

Eigenlijk wil je dat hij het hele interval (bij jou het hele uur) de pv opbrengst het grid opstuurt. In zo'n situatie wil je dus niet dat hij rekening houdt met het efficiency voordeel.
Wat zijn je batterij instellingen?

Dat dacht ik dus ook al, alleen lastig te bepalen wanneer je wel of niet het voordeel wilt met een automatisering. Of toch niet gebruiken? denk dat het met 15min prijzen wel weer anders berekend gaat worden als nu met uur prijzen.
Dit zijn de batterij instellingen:

JSON:

  "battery": [
    {
      "name": "AlphaEss G3 Smile T10",
      "entity actual level": "sensor.alphaess_soc_battery",
      "capacity": 46.5,
      "upper limit": "input_number.dao_upper_limit",
      "lower limit": "input_number.dao_lower_limit",
      "optimal lower level": "input_number.dao_optimal_lower_level",
      "entity min soc end opt": "input_number.dao_min_soc_einde",
      "entity max soc end opt": "input_number.dao_max_soc_einde",
      "charge stages": [
        {"power": 0,     "efficiency": 1.0},
        {"power": 2500,  "efficiency": 0.955},
        {"power": 5000,  "efficiency": 0.968},
        {"power": 7500,  "efficiency": 0.965},
        {"power": 10000, "efficiency": 0.960}
      ],
      "discharge stages": [
        {"power": 0,     "efficiency": 1.0},
        {"power": 2500,  "efficiency": 0.955},
        {"power": 5000,  "efficiency": 0.968},
        {"power": 7500,  "efficiency": 0.965},
        {"power": 10000, "efficiency": 0.960}
      ],
      "minimum power": 100,
      "dc_to_bat efficiency": 0.968,
        "dc_to_bat max power" : 10000.0,
      "bat_to_dc efficiency": 0.968,
      "bat_to_dc max power" : 10000.0,
      "cycle cost": 0.015,
      "entity set power feedin": "input_number.dao_set_power_feedin",
      "entity set operating mode": "input_select.dao_set_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_inverter",
      "entity from battery": "input_number.dao_from_battery",
      "entity from ac": "input_number.dao_from_ac",
      "entity from pv": "input_number.dao_from_pv",
      "entity calculated soc": "input_number.dao_calculated_soc",
      "solar": [
        {
          "name": "AlphaEss G3 Smile T10 PV",
          "entity_pv_switch": "input_boolean.dao_alphaess_pv_on_off",
          "strings": [
            {
              "tilt": 15.0,
              "orientation": -18.0,
              "capacity": 6.25,
              "yield_factor": 0.01375
            },
            {
              "tilt": 35.0,
              "orientation": 73.0,
              "capacity": 3.0,
              "yield_factor": 0.00625
            }
          ],
          "ml_prediction": true,  
          "entities_sensors": [
            "sensor.alphaess_total_energy_from_pv"
          ],
          "max_power": 10.0
        }
      ]
    }
  ],

[hemertje]

Bravo schreef op donderdag 2 juli 2026 @ 12:17:
[...]

Als de de WP als losse entiteit meeneemt, wordt hij niet meer in de baseload meegerekend.
Als je de WP via DAO aanstuurt, dan kan DAO er rekening mee houden. Als de WP 'zijn eigen ding doet' EN als losse entiteit wordt gemeten, dan zit de last van de WP niet in de baseload en wordt er dus geen rekening mee gehouden.

Aanvulling: de baseload berekening kijkt altijd terug (standaard 56 dagen) wat de baseload was. Het houdt op geen enkele manier rekening met wijzigende omstandigheden zoals een koudere periode, wat wel relevant is voor het verbruik van een warmtepomp.

iemand een idee waar de 56 dagen vandaan komen en wat de reden ervan is?
met bv 7 dagen hou je naar mijn idee meer rekeningen met de actuele weersomstandigheden, wat dan weer gunstig is voor de baseload berekening voor je all-electric woning met warmtepomp?

[storeman]

hemertje schreef op maandag 6 juli 2026 @ 22:02:
[...]


iemand een idee waar de 56 dagen vandaan komen en wat de reden ervan is?
met bv 7 dagen hou je naar mijn idee meer rekeningen met de actuele weersomstandigheden, wat dan weer gunstig is voor de baseload berekening voor je all-electric woning met warmtepomp?

Ik denk dat het een vrij arbitraire waarde is. Een week lijkt mij echter wel erg kort, als je een keer een pan kokend water uit de quooker trekt omdat je net spaghetti gaat eten die week, is je voorspelling de week erop al weer tamelijk ontregelt. Zelfde geldt voor wassen en drogen.

Ik weet niet hoe de voorspelling zich verhoudt tot de aansturing van de WP of de verbruikssensor van de WP.

[KC27]

hemertje schreef op maandag 6 juli 2026 @ 22:02:
[...]


iemand een idee waar de 56 dagen vandaan komen en wat de reden ervan is?
met bv 7 dagen hou je naar mijn idee meer rekeningen met de actuele weersomstandigheden, wat dan weer gunstig is voor de baseload berekening voor je all-electric woning met warmtepomp?

Die 56 dagen zijn een default waarde, die je naar eigen smaak kunt aanpassen.
Als je wp verbruik wordt gemeten en dat verbruik wordt gerapporteerd in een report-sensor dan wordt het wp-verbruik buiten de baseload gehouden.
Je baseload bestaat hoofdzakelijk uit sluipverbruik, huishoudelijk gebruik (koel- en vrieskasten), koken en verlichting. Met name die laatste is seizoen afhankelijk vandaar die 56 dagen.

[tomvandepoel3]

storeman schreef op zondag 5 juli 2026 @ 00:04:
Ik ben bezig geweest om de frontend op te frissen. Ik heb een stukje van de webserver herschreven en ik hoor graag jullie feedback. Ik heb een discussion geopend op github:

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

Dat ziet er strak uit. Ik probeer de /v2 aan de praat te krijgen maar dat lukt me nog niet helemaal:

code:

  File "/home/tom/dao/dao/webserver/app/v2/routes.py", line 14, in inject_data
    "vite_tags": vite_tags("assets/main.js")
                 ~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/home/tom/dao/dao/webserver/app/v2/routes.py", line 30, in vite_tags
    with VITE_MANIFEST.open() as f:
         ~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.13/pathlib/_local.py", line 539, in open
    return io.open(self, mode, buffering, encoding, errors, newline)
           ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'app/static/build/.vite/manifest.json'

In ~/dao/webserver/app/static ontbreekt bij mij de build directory. Enig idee wat ik hier fout doe?

[hemertje]

KC27 schreef op maandag 6 juli 2026 @ 23:04:
[...]

Die 56 dagen zijn een default waarde, die je naar eigen smaak kunt aanpassen.
Als je wp verbruik wordt gemeten en dat verbruik wordt gerapporteerd in een report-sensor dan wordt het wp-verbruik buiten de baseload gehouden.
Je baseload bestaat hoofdzakelijk uit sluipverbruik, huishoudelijk gebruik (koel- en vrieskasten), koken en verlichting. Met name die laatste is seizoen afhankelijk vandaar die 56 dagen.

zoals @Bravo hierboven aangeeft kan ik de WP toch niet apart meten en in de voorspellingen laten opnemen want met apart opnemen dan wordt die niet meegenomen in de baseload en dus verbruiksberekeningen?

tenminste zo heb ik het laatst ook al een keer eerder begrepen van je?

met 56 dagen bereken je het gemiddelde over 2 maanden, met de seizoenswisselingen reken je dan naar mijn idee te krap of te ruim afhankelijk of we richting zomer of winter gaan...

of ik snap de uitgangspunten van de berekeningen nog niet?

[storeman]

tomvandepoel3 schreef op dinsdag 7 juli 2026 @ 10:49:
[...]

Dat ziet er strak uit. Ik probeer de /v2 aan de praat te krijgen maar dat lukt me nog niet helemaal:

code:

  File "/home/tom/dao/dao/webserver/app/v2/routes.py", line 14, in inject_data
    "vite_tags": vite_tags("assets/main.js")
                 ~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/home/tom/dao/dao/webserver/app/v2/routes.py", line 30, in vite_tags
    with VITE_MANIFEST.open() as f:
         ~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.13/pathlib/_local.py", line 539, in open
    return io.open(self, mode, buffering, encoding, errors, newline)
           ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'app/static/build/.vite/manifest.json'

In ~/dao/webserver/app/static ontbreekt bij mij de build directory. Enig idee wat ik hier fout doe?

Ik ben behoorlijk bezig met /v2, ik heb gisteren een en ander gebundeld dmv vite. Wat je moet doen in de webserver directory:

$ npm install
$ npm run build

[Animal]

thomvh schreef op donderdag 2 juli 2026 @ 09:14:
[...]

code:

"time": "xx00",
"time": "xx15",
"time": "xx30",
"time": "xx45",

Staat ook op de wiki. [ur

code:

l="https://github.com/corneel27/day-ahead/wiki/4.-Ondersteuning#overstappen-naar-kwartierprijzen","https://github.com/corneel27/day-ahead/wiki/4.-Ondersteuning#overstappen-naar-kwartierprijzen"]https://github.com/cornee...ppen-naar-kwartierprijzen~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[/url]

De overstap naar kwartierprijzen gaat toch moeilijker dan gedacht. Hoe geweldig DAO is als het werkt blijven dit soort kleine wijzingen toch elke keer lastig.

code:

2026-07-07 09:45:00 info: Day Ahead Optimalisering versie: 2026.6.0.rc1

2026-07-07 09:45:00 info: Day Ahead Optimalisering gestart op: 07-07-2026 09:45:00

2026-07-07 09:45:00 info: Day Ahead Optimalisatie gestart: 07-07-2026 09:45:00 taak: calc_optimum

2026-07-07 09:45:00 info: Debug = False

2026-07-07 09:45:00 info: Baseload uit instellingen

2026-07-07 09:45:00 info: ML prediction Oost_West

                   date_time  prediction

0  2026-07-07 09:00:00+02:00       0.461

1  2026-07-07 10:00:00+02:00       0.466

2  2026-07-07 11:00:00+02:00       0.691

3  2026-07-07 12:00:00+02:00       0.763

4  2026-07-07 13:00:00+02:00       0.756

5  2026-07-07 14:00:00+02:00       0.680

6  2026-07-07 15:00:00+02:00       0.737

7  2026-07-07 16:00:00+02:00       0.680

8  2026-07-07 17:00:00+02:00       0.625

9  2026-07-07 18:00:00+02:00       0.443

10 2026-07-07 19:00:00+02:00       0.289

11 2026-07-07 20:00:00+02:00       0.117

12 2026-07-07 21:00:00+02:00       0.029

13 2026-07-07 22:00:00+02:00       0.000

14 2026-07-07 23:00:00+02:00       0.000

2026-07-07 09:45:00 info: ML prediction Zuid_paneel

                   date_time  prediction

0  2026-07-07 09:00:00+02:00       0.151

1  2026-07-07 10:00:00+02:00       0.132

2  2026-07-07 11:00:00+02:00       0.206

3  2026-07-07 12:00:00+02:00       0.219

4  2026-07-07 13:00:00+02:00       0.219

5  2026-07-07 14:00:00+02:00       0.183

6  2026-07-07 15:00:00+02:00       0.140

7  2026-07-07 16:00:00+02:00       0.138

8  2026-07-07 17:00:00+02:00       0.143

9  2026-07-07 18:00:00+02:00       0.101

10 2026-07-07 19:00:00+02:00       0.045

11 2026-07-07 20:00:00+02:00       0.025

12 2026-07-07 21:00:00+02:00       0.003

13 2026-07-07 22:00:00+02:00       0.000

14 2026-07-07 23:00:00+02:00       0.000

2026-07-07 09:45:00 info: ML prediction Schuine_dak

                   date_time  prediction

0  2026-07-07 09:00:00+02:00       0.053

1  2026-07-07 10:00:00+02:00       0.034

2  2026-07-07 11:00:00+02:00       0.120

3  2026-07-07 12:00:00+02:00       0.192

4  2026-07-07 13:00:00+02:00       0.217

5  2026-07-07 14:00:00+02:00       0.211

6  2026-07-07 15:00:00+02:00       0.235

7  2026-07-07 16:00:00+02:00       0.287

8  2026-07-07 17:00:00+02:00       0.295

9  2026-07-07 18:00:00+02:00       0.259

10 2026-07-07 19:00:00+02:00       0.166

11 2026-07-07 20:00:00+02:00       0.087

12 2026-07-07 21:00:00+02:00       0.021

13 2026-07-07 22:00:00+02:00       0.006

14 2026-07-07 23:00:00+02:00       0.003

2026-07-07 09:45:00 info: Start waarden: 

      uur                tijd   spot   p_l   p_t  base  pv_ac  pv_dc

0   09:45 2026-07-07 09:45:00  0.078 0.242 0.242 0.088  0.163      0

1   10:00 2026-07-07 10:00:00  0.103 0.272 0.272 0.088  0.155      0

2   10:15 2026-07-07 10:15:00  0.073 0.237 0.237 0.088  0.153      0

3   10:30 2026-07-07 10:30:00  0.047 0.204 0.204 0.088  0.151      0

4   10:45 2026-07-07 10:45:00  0.007 0.156 0.156 0.087  0.175      0

5   11:00 2026-07-07 11:00:00  0.028 0.182 0.182 0.084  0.222      0

6   11:15 2026-07-07 11:15:00  0.004 0.152 0.152 0.083  0.246      0

7   11:30 2026-07-07 11:30:00  0.001 0.149 0.149 0.082  0.270      0

8   11:45 2026-07-07 11:45:00  0.001 0.149 0.149 0.081  0.280      0

9   12:00 2026-07-07 12:00:00  0.002 0.150 0.150 0.079  0.281      0

10  12:15 2026-07-07 12:15:00  0.001 0.149 0.149 0.077  0.291      0

11  12:30 2026-07-07 12:30:00  0.001 0.149 0.149 0.076  0.301      0

12  12:45 2026-07-07 12:45:00 -0.000 0.148 0.148 0.077  0.302      0

13  13:00 2026-07-07 13:00:00  0.000 0.148 0.148 0.081  0.298      0

14  13:15 2026-07-07 13:15:00 -0.001 0.146 0.146 0.082  0.299      0

15  13:30 2026-07-07 13:30:00 -0.002 0.146 0.146 0.083  0.301      0

16  13:45 2026-07-07 13:45:00 -0.002 0.145 0.145 0.083  0.293      0

17  14:00 2026-07-07 14:00:00 -0.002 0.145 0.145 0.083  0.277      0

18  14:15 2026-07-07 14:15:00 -0.002 0.145 0.145 0.083  0.270      0

19  14:30 2026-07-07 14:30:00 -0.002 0.145 0.145 0.083  0.262      0

20  14:45 2026-07-07 14:45:00 -0.002 0.145 0.145 0.083  0.265      0

21  15:00 2026-07-07 15:00:00 -0.001 0.146 0.146 0.083  0.275      0

22  15:15 2026-07-07 15:15:00 -0.000 0.148 0.148 0.083  0.277      0

23  15:30 2026-07-07 15:30:00  0.002 0.150 0.150 0.083  0.280      0

24  15:45 2026-07-07 15:45:00  0.005 0.154 0.154 0.083  0.279      0

25  16:00 2026-07-07 16:00:00  0.003 0.151 0.151 0.083  0.277      0

26  16:15 2026-07-07 16:15:00  0.005 0.154 0.154 0.083  0.277      0

27  16:30 2026-07-07 16:30:00  0.008 0.158 0.158 0.083  0.277      0

28  16:45 2026-07-07 16:45:00  0.021 0.173 0.173 0.083  0.274      0

29  17:00 2026-07-07 17:00:00  0.007 0.156 0.156 0.083  0.273      0

30  17:15 2026-07-07 17:15:00  0.017 0.168 0.168 0.083  0.271      0

31  17:30 2026-07-07 17:30:00  0.082 0.246 0.246 0.083  0.268      0

32  17:45 2026-07-07 17:45:00  0.163 0.345 0.345 0.083  0.252      0

33  18:00 2026-07-07 18:00:00  0.078 0.242 0.242 0.083  0.226      0

34  18:15 2026-07-07 18:15:00  0.110 0.281 0.281 0.083  0.210      0

35  18:30 2026-07-07 18:30:00  0.127 0.301 0.301 0.083  0.193      0

36  18:45 2026-07-07 18:45:00  0.151 0.330 0.330 0.083  0.175      0

37  19:00 2026-07-07 19:00:00  0.088 0.254 0.254 0.083  0.153      0

38  19:15 2026-07-07 19:15:00  0.110 0.281 0.281 0.083  0.134      0

39  19:30 2026-07-07 19:30:00  0.135 0.311 0.311 0.083  0.115      0

40  19:45 2026-07-07 19:45:00  0.150 0.330 0.330 0.082  0.098      0

41  20:00 2026-07-07 20:00:00  0.115 0.287 0.287 0.081  0.081      0

42  20:15 2026-07-07 20:15:00  0.126 0.300 0.300 0.080  0.064      0

43  20:30 2026-07-07 20:30:00  0.142 0.319 0.319 0.080  0.047      0

44  20:45 2026-07-07 20:45:00  0.183 0.369 0.369 0.079  0.036      0

45  21:00 2026-07-07 21:00:00  0.128 0.302 0.302 0.078  0.028      0

46  21:15 2026-07-07 21:15:00  0.139 0.316 0.316 0.078  0.017      0

47  21:30 2026-07-07 21:30:00  0.159 0.340 0.340 0.077  0.006      0

48  21:45 2026-07-07 21:45:00  0.174 0.359 0.359 0.077  0.003      0

49  22:00 2026-07-07 22:00:00  0.148 0.327 0.327 0.077  0.005      0

50  22:15 2026-07-07 22:15:00  0.151 0.330 0.330 0.077  0.002      0

51  22:30 2026-07-07 22:30:00  0.150 0.329 0.329 0.077  0.001      0

52  22:45 2026-07-07 22:45:00  0.145 0.323 0.323 0.077  0.001      0

53  23:00 2026-07-07 23:00:00  0.149 0.328 0.328 0.077  0.001      0

54  23:15 2026-07-07 23:15:00  0.140 0.317 0.317 0.077  0.001      0

55  23:30 2026-07-07 23:30:00  0.131 0.306 0.306 0.077  0.001      0

56  23:45 2026-07-07 23:45:00  0.138 0.315 0.315 0.077  0.000      0

2026-07-07 09:45:00 info: No reduced hours applied for Marstek Venus-E 5.12kWh

2026-07-07 09:45:00 info: No reduced power applied during discharging at low soc

2026-07-07 09:45:00 info: No reduced power applied during charging at high soc

2026-07-07 09:45:00 info: Startwaarde SoC Marstek Venus-E 5.12kWh: 11.0%

2026-07-07 09:45:00 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland

2026-07-07 09:45:00 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland

2026-07-07 09:45:00 info: Apparaat wasmachine direct starten staat uit

2026-07-07 09:45:00 info: Apparaat wasmachine met programma 'Stand D 40 graden' wordt ingepland tussen 2026-07-07 09:45 en 2026-07-07 16:00.

2026-07-07 09:45:00 info: Apparaat Droger direct starten staat uit

2026-07-07 09:45:00 info: Machine Droger wordt niet ingepland, want er is gekozen voor off

2026-07-07 09:45:00 info: Apparaat vaatwasser direct starten staat uit

2026-07-07 09:45:00 info: Apparaat vaatwasser met programma 'eco' wordt ingepland tussen 2026-07-07 16:00 en 2026-07-07 17:00.

2026-07-07 09:45:00 info: Strategie: minimale kosten

2026-07-07 09:45:00 info: Maximale fout (maximal gap): 0.005000 euro

2026-07-07 09:45:00 info: Rekentijd: 0.02  sec

2026-07-07 09:45:00 waarschuwing: Geen oplossing voor: minimize cost

code:

{
  "config_version": 2,
  "homeassistant": {
    "ip_address": "supervisor",
    "protocol_api": "http"
  },
  "database_ha": {
    "engine": "sqlite",
    "db_path": "/homeassistant",
    "database": "home-assistant_v2.db"
  },
  "database_da": {
    "engine": "sqlite",
    "db_path": "../data",
    "database": "day_ahead.db"
  },
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "energy_taxes_consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154
    },
    "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": {
      "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
    },
    "vat_consumption": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0,
      "2025-01-01": 21.0
    },
    "vat_production": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0,
      "2025-01-01": 21.0
    },
    "multiplier_consumption": {
      "2000-01-01": 1.0
    },
    "multiplier_production": {
      "2000-01-01": 1.0
    },
    "last_invoice": "2025-09-01",
    "tax_refund": true,
    "regular high": 0.5,
    "regular low": 0.4,
    "switch to low": 23
  },
  "logging_level": "info",
  "use_calc_baseload": false,
  "baseload_calc_periode": 56,
  "baseload": [
    0.33,
    0.33,
    0.32,
    0.32,
    0.31,
    0.33,
    0.33,
    0.34,
    0.33,
    0.35,
    0.35,
    0.33,
    0.31,
    0.33,
    0.33,
    0.33,
    0.33,
    0.33,
    0.33,
    0.33,
    0.32,
    0.31,
    0.31,
    0.31
  ],
  "graphical_backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": true,
    "prices_spot": true,
    "average_consumption": true,
    "show": true
  },
  "interval": "15min",
  "strategy": "minimize cost",
  "max_gap": 0.005,
  "notifications": {
    "opstarten": false,
    "berekening": false
  },
  "grid": {
    "max_power": 5.75,
    "entity_balance_switch": "input_boolean.dao_balance_grid"
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "Marstek Venus-E 5.12kWh",
      "entity_actual_level": "sensor.lilygo_rs485_marstek_battery_state_of_charge",
      "capacity": 5.12,
      "upper_limit": 100,
      "lower_limit": 11,
      "optimal_lower_level": 11,
      "penalty_low_soc": 0.0025,
      "charge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 100.0,
          "efficiency": 0.36
        },
        {
          "power": 200.0,
          "efficiency": 0.8221
        },
        {
          "power": 400.0,
          "efficiency": 0.8673
        },
        {
          "power": 600.0,
          "efficiency": 0.8861
        },
        {
          "power": 800.0,
          "efficiency": 0.8975
        },
        {
          "power": 1000.0,
          "efficiency": 0.8933
        },
        {
          "power": 1500.0,
          "efficiency": 0.9015
        },
        {
          "power": 2000.0,
          "efficiency": 0.901
        },
        {
          "power": 2500.0,
          "efficiency": 0.9017
        }
      ],
      "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 100.0,
          "efficiency": 0.7907
        },
        {
          "power": 200.0,
          "efficiency": 0.8957
        },
        {
          "power": 400.0,
          "efficiency": 0.9581
        },
        {
          "power": 600.0,
          "efficiency": 0.9767
        },
        {
          "power": 800.0,
          "efficiency": 0.9812
        },
        {
          "power": 1000.0,
          "efficiency": 0.989
        },
        {
          "power": 1500.0,
          "efficiency": 0.9907
        },
        {
          "power": 2000.0,
          "efficiency": 0.9841
        },
        {
          "power": 2500.0,
          "efficiency": 0.9928
        }
      ],
      "reduced_hours": {},
      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],
      "minimum_power": 10,
      "dc_to_bat_efficiency": 0.935,
      "dc_to_bat_max_power": 2500.0,
      "bat_to_dc_efficiency": 0.935,
      "bat_to_dc_max_power": 2500.0,
      "cycle_cost": 0.005,
      "entity_set_power_feedin": "input_number.dao_set_power_feedin",
      "entity_set_operating_mode": "input_select.dao_set_operating_mode",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "entity_stop_inverter": "input_datetime.dao_stop_marstek",
      "entity_calculated_soc": "input_number.dao_marstek_calculated_soc",
      "solar": []
    }
  ],
  "solar": [
    {
      "name": "Oost West",
      "entity_pv_switch": "input_boolean.oost_west_turn_inverter_on_off",
      "strings": [
        {
          "tilt": 45.0,
          "orientation": -135.0,
          "capacity": 0.43,
          "yield_factor": 0.00091375,
          "ml_prediction": false,
          "entities_sensors": []
        },
        {
          "tilt": 45.0,
          "orientation": -135.0,
          "capacity": 0.43,
          "yield_factor": 0.00091375,
          "ml_prediction": false,
          "entities_sensors": []
        },
        {
          "tilt": 45.0,
          "orientation": 45.0,
          "capacity": 0.43,
          "yield_factor": 0.00091375,
          "ml_prediction": false,
          "entities_sensors": []
        },
        {
          "tilt": 45.0,
          "orientation": 45.0,
          "capacity": 0.43,
          "yield_factor": 0.00091375,
          "ml_prediction": false,
          "entities_sensors": []
        }
      ],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": [
        "sensor.hms_2000_4t_yieldtotal"
      ]
    },
    {
      "name": "Zuid paneel",
      "entity_pv_switch": "input_boolean.zuid_paneel_on_off",
      "tilt": 60.0,
      "orientation": -45.0,
      "capacity": 0.43,
      "yield_factor": 0.00091375,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": [
        "sensor.zuid_paneel_yieldtotal"
      ]
    },
    {
      "name": "Schuine dak",
      "entity_pv_switch": "input_boolean.schuin_dak_on_off",
      "tilt": 45.0,
      "orientation": 45.0,
      "capacity": 0.5,
      "yield_factor": 0.0010625,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": [
        "sensor.schuine_dak_yieldtotal"
      ]
    }
  ],
  "electric_vehicle": [],
  "machines": [
    {
      "name": "wasmachine",
      "programs": [
        {
          "name": "off",
          "power": []
        },
        {
          "name": "Stand D 40 graden",
          "power": [
            405.0,
            1782.0,
            398.0,
            158.0,
            142.0,
            123.0,
            104.0,
            253.0
          ]
        },
        {
          "name": "Stand A 95 graden",
          "power": [
            405.0,
            1782.0,
            398.0,
            158.0,
            142.0,
            123.0,
            104.0,
            253.0
          ]
        }
      ],
      "entity_start_window": "input_datetime.start_window_wasmachine",
      "entity_end_window": "input_datetime.end_window_wasmachine",
      "entity_selected_program": "input_select.program_wasmachine",
      "entity_calculated_start": "input_datetime.calculated_start_wasmachine",
      "entity_calculated_end": "input_datetime.calculated_stop_wasmachine"
    },
    {
      "name": "Droger",
      "programs": [
        {
          "name": "off",
          "power": []
        },
        {
          "name": "40 min",
          "power": [
            1173.0,
            1910.0,
            948.0
          ]
        },
        {
          "name": "60 min",
          "power": [
            1173.0,
            1910.0,
            1910.0,
            948.0
          ]
        },
        {
          "name": "90 min",
          "power": [
            1173.0,
            1910.0,
            1910.0,
            1910.0,
            1910.0,
            948.0
          ]
        }
      ],
      "entity_start_window": "input_datetime.start_window_droger",
      "entity_end_window": "input_datetime.end_window_droger",
      "entity_selected_program": "input_select.program_droger",
      "entity_calculated_start": "input_datetime.calculated_start_droger",
      "entity_calculated_end": "input_datetime.calculated_stop_droger"
    },
    {
      "name": "vaatwasser",
      "programs": [
        {
          "name": "off",
          "power": []
        },
        {
          "name": "70 graden",
          "power": [
            203.0,
            2000.0,
            62.0,
            49.0,
            0.0,
            0.0,
            0.0,
            0.0,
            1943.0,
            1918.0,
            0.0,
            0.0
          ]
        },
        {
          "name": "eco",
          "power": [
            203.0,
            2000.0,
            62.0,
            49.0,
            0.0,
            0.0,
            0.0,
            0.0,
            0.0,
            1943.0,
            1918.0,
            0.0,
            0.0,
            0.0
          ]
        }
      ],
      "entity_start_window": "input_datetime.start_window_vaatwasser",
      "entity_end_window": "input_datetime.end_window_vaatwasser",
      "entity_selected_program": "input_select.program_vaatwasser",
      "entity_calculated_start": "input_datetime.calculated_start_vaatwasser",
      "entity_calculated_end": "input_datetime.calculated_stop_vaatwasser"
    }
  ],
  "boiler": {
    "boiler_present": false,
    "entity_actual_temp": "sensor.boiler_gemeten",
    "entity_setpoint": "sensor.boiler_ingesteld",
    "entity_hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling_rate": 0.4,
    "volume": 180.0,
    "heating_allowed_below": 44,
    "elec_power": 1500.0,
    "activate_service": "press",
    "activate_entity": "input_button.hw_trigger",
    "boiler_heated_by_heatpump": true
  },
  "heating": {
    "heater_present": false,
    "degree_days_factor": 3.6,
    "adjustment": "power",
    "stages": [
      {
        "max_power": 0.0,
        "cop": 8.0
      },
      {
        "max_power": 225.0,
        "cop": 7.1
      },
      {
        "max_power": 300.0,
        "cop": 7.0
      },
      {
        "max_power": 400.0,
        "cop": 6.5
      },
      {
        "max_power": 500.0,
        "cop": 6.0
      },
      {
        "max_power": 600.0,
        "cop": 5.5
      },
      {
        "max_power": 750.0,
        "cop": 5.0
      },
      {
        "max_power": 1000.0,
        "cop": 4.5
      },
      {
        "max_power": 1250.0,
        "cop": 4.0
      }
    ],
    "entity_adjust_heating_curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment_factor": 0.04,
    "min_run_length": 1
  },
  "tibber": {
    "api_token": "!secret tibber_api_token",
    "api_url": "https://api.tibber.com/v1-beta/gql"
  },
  "xgboost": {
    "tune_hyperparameters": true
  },
  "report": {
    "entities_grid_consumption": [
      "sensor.electricity_meter_energieverbruik_tarief_1",
      "sensor.electricity_meter_energieverbruik_tarief_2"
    ],
    "entities_grid_production": [
      "sensor.electricity_meter_energieproductie_tarief_1",
      "sensor.electricity_meter_energieproductie_tarief_2"
    ],
    "entities_solar_production_ac": [
      "sensor.hms_2000_4t_yieldtotal",
      "sensor.zuid_paneel_yieldtotal",
      "sensor.schuine_dak_yieldtotal"
    ],
    "entities_solar_production_dc": [],
    "entities_ev_consumption": [],
    "entities_wp_consumption": [],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.lilygo_rs485_marstek_total_charging_energy"
    ],
    "entities_battery_production": [
      "sensor.lilygo_rs485_marstek_total_discharging_energy"
    ],
    "entities_machine_consumption": [
      "sensor.0xa4c1382c8e5d5ad5_energy",
      "sensor.0xa4c13863a14fb69f_energy",
      "sensor.0xa4c138ecff011f2e_energy"
    ],
    "entity co2-intensity": [
      "sensor.co2_intensity"
    ]
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "0430",
        "action": "get_meteo_data"
      },
      {
        "time": "1030",
        "action": "get_meteo_data"
      },
      {
        "time": "1630",
        "action": "get_meteo_data"
      },
      {
        "time": "2230",
        "action": "get_meteo_data"
      },
      {
        "time": "2240",
        "action": "train_ml_predictions"
      },
      {
        "time": "1255",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1355",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1455",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1554",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1655",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "xx00",
        "time": "xx15",
        "time": "xx30",
        "time": "xx45",
        "action": "calc_optimum"
      },
      {
        "time": "2359",
        "action": "clean_data"
      }
    ]
  },
  "meteoserver_attempts": 2
}

Edit: Ik had al een paar keer de prijzen zelf binnengehaald maar het werkt ineens vanzelf nu
De run werkt alleen maar elk uur. Dus 7:45, 8:45. De worker per kwartier werkt dus nog niet

In mijn config staat een andere indeling dan in de wiki. Moet ik dit wijzingen? Dan is het niet consistent met de andere runners.

code:

{
        "time": "xx00",
        "time": "xx15",
        "time": "xx30",
        "time": "xx45",
        "action": "calc_optimum"
      },

En wiki:

code:

"xx15": "calc_optimum",
    "xx30": "calc_optimum",
    "xx45": "calc_optimum",

Zelf dan gekozen voor deze wijze

code:

{
        "time": "xx00",
        "action": "calc_optimum"
      },
      {
        "time": "xx15",
        "action": "calc_optimum"
      },
      {
        "time": "xx30",
        "action": "calc_optimum"
      },
      {
        "time": "xx45",
        "action": "calc_optimum"
      },

[ Voor 64% gewijzigd door Animal op 08-07-2026 09:02 ]

[KC27]

ljsquare schreef op maandag 6 juli 2026 @ 12:13:
[...]


De baseload berekent hij op de standaard waarde van 56 dagen.
In de rapportage van vorige maand staat inderdaad een extreme waarde bij de PV ac (14-06):

[...]

Ik zal in Home Assistant kijken waarom dit is.
Zojuist in Home Assistant gekeken, maar daar zijn geen extreme waardes te zien.

Dit wil ik wel proberen op te lossen, maar dan moet een stukje export van je HA database hebben.
Ben je een beetje handig met sql en kun je zo'n gedeeltelijke export maken? Zoja dan stuur ik de details via dm.

[thewhi]

Drie weken geleden heb ik een nieuwe thuisbatterij geplaatst. De oude sensor voor laden en ontladen is daarbij komen te vervallen en in HA heb ik deze gelijk in het Energy Dashboard vervangen door de de Shelly Pro 3EM meter (sensor voor laden en ontladen) die sinds april al meeliep. Ik kwam er vandaag pas achter dat ik de entiteit in DAO nog niet had aangepast. Dit heb ik vanmiddag gecorrigeerd naar de juiste entiteiten.

Maar de accu_uit en accu in blijven maar 0 rapporteren

"report": {
"entities_grid_consumption": [
"sensor.hw_p1meter_428e3e_energie_import"
],
"entities_grid_production": [
"sensor.hw_p1meter_428e3e_energie_export"
],
"entities_solar_production_ac": [
"sensor.zonneplan_one_refurbished_yield_total"
],
"entities_solar_production_dc": [],
"entities_ev_consumption": [
"sensor.peblar_ev_charger_energie"
],
"entities_wp_consumption": [],
"entities_boiler_consumption": [],
"entities_battery_consumption": [
"sensor.garage_batterij_elektra_laden"
],
"entities_battery_production": [
"sensor.garage_batterij_elektra_ontladen"
],
"entities_machine_consumption": []
},

dit komt mijn baseload berekening natuurlijk niet ten goede...


....


Enig idee wat er nu mis gaat?

[KC27]

thewhi schreef op woensdag 8 juli 2026 @ 22:22:
Drie weken geleden heb ik een nieuwe thuisbatterij geplaatst. De oude sensor voor laden en ontladen is daarbij komen te vervallen en in HA heb ik deze gelijk in het Energy Dashboard vervangen door de de Shelly Pro 3EM meter (sensor voor laden en ontladen) die sinds april al meeliep. Ik kwam er vandaag pas achter dat ik de entiteit in DAO nog niet had aangepast. Dit heb ik vanmiddag gecorrigeerd naar de juiste entiteiten.

Maar de accu_uit en accu in blijven maar 0 rapporteren


[...]


dit komt mijn baseload berekening natuurlijk niet ten goede...

[Afbeelding]
....


Enig idee wat er nu mis gaat?

Voor de historie moet je zowel de oude sensor als de nieuwe sensor opnemen in de lijst. O.a. hierom is er een lijst (met [ ]) voorzien.

[thewhi]

KC27 schreef op woensdag 8 juli 2026 @ 22:37:
[...]

Voor de historie moet je zowel de oude sensor als de nieuwe sensor opnemen in de lijst. O.a. hierom is er een lijst (met [ ]) voorzien.

Dat is inderdaad handig. Maar die historie vind ik niet zo spannend. Immers de nieuwe sensor loopt al sinds april mee en zou dus ook al terug moeten komen in reports? En met baseloadbepaling op 56 dagen zit ik dan toch ook nog goed?

[ Voor 3% gewijzigd door thewhi op 08-07-2026 23:08 ]

[ljsquare]

KC27 schreef op dinsdag 7 juli 2026 @ 17:44:
[...]

Dit wil ik wel proberen op te lossen, maar dan moet een stukje export van je HA database hebben.
Ben je een beetje handig met sql en kun je zo'n gedeeltelijke export maken? Zoja dan stuur ik de details via dm.

Prima plan. Dank daarvoor.
Ik ben wel beetje handig met sql.
Stuur mij maar een dm met wat je nodig hebt 👍🏻

[thomvh]

Mhh vandaag lijkt DAO mijn batterij verbruik niet te meten:

De sensor is hetzelfde als dat er in het Energy Dashboard staat. Deze reset 1x per week.

[thewhi]

thomvh schreef op donderdag 9 juli 2026 @ 09:26:
Mhh vandaag lijkt DAO mijn batterij verbruik niet te meten:

[...]


[...]


De sensor is hetzelfde als dat er in het Energy Dashboard staat. Deze reset 1x per week.
[Afbeelding]

Is dat "pas" sinds vandaag? ik zit dus met een vergelijkbaar issue en ik wijt het voorlopig aan het aanpassen van de sensornaam. Maar mogelijk toch wat anders? Zoals bijv update van HA? Ik zag namelijk wel dat daar wat aangepast zou zijn in energy dashboard (maar heb verder niet onder de motorkap gekeken... dus slechts een wilde gok. )

[thomvh]

thewhi schreef op donderdag 9 juli 2026 @ 10:43:
[...]


Is dat "pas" sinds vandaag? ik zit dus met een vergelijkbaar issue en ik wijt het voorlopig aan het aanpassen van de sensornaam. Maar mogelijk toch wat anders? Zoals bijv update van HA? Ik zag namelijk wel dat daar wat aangepast zou zijn in energy dashboard (maar heb verder niet onder de motorkap gekeken... dus slechts een wilde gok. )

Mhh gister is mijn integratie wel geupdate, maar dan zou die alsnog de data van vandaag moeten laten zien. Maar nu gaan de baseloads fout... Maar ik snap niet waarom die het niet meer registreert.

[ Voor 5% gewijzigd door thomvh op 09-07-2026 10:47 ]

[thewhi]

ik heb vanochtend een volledig kale herinstallatie gedaan (rond 9u15). omdat de battery report in balans report leeg bleef) Ik zou dan verwachten dat de reports zich weer gaan vullen vanaf 10 uur. Maar de balans report is nu helemaal leeg (vreemd!) en grid report laat ook wat geks zien en niet te rijmen met de het energydashhoard. dit lijkt op een hick-up tussen HA en DAO.

Baseload bepaling en ML doen het wel gewoon..en prognoses worden ook netjes aangevuld, maar de historische reporting is helemaal kaduuk/padje af.

.

[ Voor 16% gewijzigd door thewhi op 09-07-2026 11:25 ]

[thomvh]

thewhi schreef op donderdag 9 juli 2026 @ 11:25:
ik heb vanochtend een volledig kale herinstallatie gedaan (rond 9u15). omdat de battery report in balans report leeg bleef) Ik zou dan verwachten dat de reports zich weer gaan vullen vanaf 10 uur. Maar de balans report is nu helemaal leeg (vreemd!) en grid report laat ook wat geks zien en niet te rijmen met de het energydashhoard. dit lijkt op een hick-up tussen HA en DAO.
[Afbeelding]
Baseload bepaling en ML doen het wel gewoon..en prognoses worden ook netjes aangevuld, maar de historische reporting is helemaal kaduuk/padje af.

[Afbeelding].

Ik ga vanmiddag nog even afwachten kijken of het laden er wel bij komt. Anders ga ik denk ik ook maar clean beginnen. Wordt wel interessant zonder alle data, de baseloads waren net een beetje stabiel.

[thomvh]

Het lijkt er bij mij op dat het volgende aan de hand is. De oude entiteit bestaat niet meer. Deze heb ik nog wel in de config staan. De nieuwe entiteit staat ook in de config, maar deze wordt niet goed uitgelezen.

[thewhi]

thomvh schreef op donderdag 9 juli 2026 @ 13:00:
Het lijkt er bij mij op dat het volgende aan de hand is. De oude entiteit bestaat niet meer. Deze heb ik nog wel in de config staan. De nieuwe entiteit staat ook in de config, maar deze wordt niet goed uitgelezen.

hmm.. dat lijkt hetzelfde euvel als wat er bij mij aan de hand was met mijn batterij. Nu ik een nieuwe kale installatie heb gedaan wordt er echter helemaal niks meer weggeschreven in de balansreporting.

[thomvh]

thewhi schreef op donderdag 9 juli 2026 @ 13:13:
[...]

hmm.. dat lijkt hetzelfde euvel als wat er bij mij aan de hand was met mijn batterij. Nu ik een nieuwe kale installatie heb gedaan wordt er echter helemaal niks meer weggeschreven in de balansreporting.

Ik ga denk ik de baseload even hardcoden. Want anders gaat dit over een tijdje echt fout...

[thomvh]

Heel random, maar heb DAO herstart. Nu laat die alles weer netjes zien.

[thewhi]

thomvh schreef op donderdag 9 juli 2026 @ 13:30:
Heel random, maar heb DAO herstart. Nu laat die alles weer netjes zien.

Jemig! dat was ook hier de oplossing! Thanks!

Ik had ook al een aantal keren HA volledig opnieuw opgestart, maar blijkbaar heeft dat niet hetzelfde effect dan alleen het herstarten van de app binnen HA.

[thomvh]

Ik heb wel nog een followup vraag. Zaptec integratie tracks stroom niet precies genoeg. Dus je moet de sessie totals gebruiken maar als HA dan herstart kan het gebeuren dat je een spike krijgt. Die heb ik laatst gehad, deze heb ik in HA gefixt. Maar nu is mijn baseload een beetje skewed. Is dit makkelijk te fixen?

[storeman]

Update rondom de Frontend V2. Ik heb een PR aangemaakt. Er zijn nog wat openstaande zaken zoals genoemd in de PR, maar ik denk dat we een heel eind zijn.

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

[KC27]

storeman schreef op donderdag 9 juli 2026 @ 14:31:
Update rondom de Frontend V2. Ik heb een PR aangemaakt. Er zijn nog wat openstaande zaken zoals genoemd in de PR, maar ik denk dat we een heel eind zijn.

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

[Afbeelding]

Dank!
Ik ga er vandaag of morgen naar kijken.

[tomvandepoel3]

Ik ben benieuwd of dit gedrag ook bij andere gebruikers voorkomt. Normaal werkt de DAO planning voor mijn EV perfect maar ik heb nu al 2-3 keer gezien dat de auto gedurende 15 minuten in de ochtend (kosten zijn nog relatief hoog) wordt geladen terwijl er geen EV laden in de DAO grafiek te zien is voor die betreffende 15 minuten.

Dit was zo'n situatie eerder vandaag:
- EV SoC = 22%. Laden gewenst tot 50% voor 18:00 vandaag (morgen verwacht ik meer zon en mogelijk lagere kosten; daarnaast heb ik de auto tot morgenmiddag niet nodig)
- Planning met minimale kosten ziet er mooi uit (zie: geen EV laden om 10:30)

- In de optimalisatie log staat echter:

- En de HA entiteit gaat van Off naar On zodat er ook werkelijk geladen wordt (tegen IMO te hoge kosten).


Dit gebeurt zeker niet altijd maar is toch een beetje jammer.
Voor de volledigheid hierbij ook nog de volledige log file

code:

2026-07-09 10:30:00 info: Day Ahead Optimalisering versie: 2026.6.0
2026-07-09 10:30:00 info: Day Ahead Optimalisering gestart op: 09-07-2026 10:30:00
2026-07-09 10:30:00 info: Day Ahead Optimalisatie gestart: 09-07-2026 10:30:00 taak: calc_optimum
2026-07-09 10:30:00 info: Debug = False
2026-07-09 10:30:00 info: Zelf berekende baseload
2026-07-09 10:30:01 info: Start waarden: 
      uur                tijd  spot   p_l   p_t   base  pv_ac  pv_dc
0   10:30 2026-07-09 10:30:00 0.111 0.245 0.275  0.263  0.812      0
1   10:45 2026-07-09 10:45:00 0.102 0.234 0.264  0.239  0.780      0
2   11:00 2026-07-09 11:00:00 0.123 0.259 0.289  0.179  0.725      0
3   11:15 2026-07-09 11:15:00 0.100 0.231 0.261  0.156  0.693      0
4   11:30 2026-07-09 11:30:00 0.095 0.225 0.255  0.132  0.660      0
5   11:45 2026-07-09 11:45:00 0.093 0.223 0.253  0.098  0.714      0
6   12:00 2026-07-09 12:00:00 0.102 0.235 0.265  0.041  0.814      0
7   12:15 2026-07-09 12:15:00 0.083 0.212 0.242  0.007  0.868      0
8   12:30 2026-07-09 12:30:00 0.071 0.197 0.227 -0.027  0.922      0
9   12:45 2026-07-09 12:45:00 0.066 0.191 0.221  0.003  1.048      0
10  13:00 2026-07-09 13:00:00 0.071 0.196 0.226  0.089  1.232      0
11  13:15 2026-07-09 13:15:00 0.063 0.187 0.217  0.119  1.358      0
12  13:30 2026-07-09 13:30:00 0.048 0.169 0.199  0.149  1.485      0
13  13:45 2026-07-09 13:45:00 0.030 0.147 0.177  0.145  1.602      0
14  14:00 2026-07-09 14:00:00 0.037 0.156 0.186  0.114  1.741      0
15  14:15 2026-07-09 14:15:00 0.040 0.159 0.189  0.111  1.858      0
16  14:30 2026-07-09 14:30:00 0.039 0.158 0.188  0.107  1.975      0
17  14:45 2026-07-09 14:45:00 0.048 0.169 0.199  0.107  1.975      0
18  15:00 2026-07-09 15:00:00 0.035 0.154 0.184  0.116  1.896      0
19  15:15 2026-07-09 15:15:00 0.050 0.171 0.201  0.117  1.896      0
20  15:30 2026-07-09 15:30:00 0.067 0.192 0.222  0.118  1.896      0
21  15:45 2026-07-09 15:45:00 0.091 0.222 0.252  0.097  1.861      0
22  16:00 2026-07-09 16:00:00 0.073 0.199 0.230  0.043  1.814      0
23  16:15 2026-07-09 16:15:00 0.091 0.221 0.251  0.022  0.874      0
24  16:30 2026-07-09 16:30:00 0.099 0.231 0.261  0.001  0.857      0
25  16:45 2026-07-09 16:45:00 0.109 0.243 0.273  0.049  0.815      0
26  17:00 2026-07-09 17:00:00 0.090 0.219 0.249  0.165  0.753      0
27  17:15 2026-07-09 17:15:00 0.110 0.244 0.274  0.213  0.710      0
28  17:30 2026-07-09 17:30:00 0.114 0.249 0.279  0.261  0.668      0
29  17:45 2026-07-09 17:45:00 0.130 0.268 0.298  0.243  0.628      0
30  18:00 2026-07-09 18:00:00 0.123 0.259 0.289  0.174  0.594      0
31  18:15 2026-07-09 18:15:00 0.124 0.260 0.290  0.157  0.554      0
32  18:30 2026-07-09 18:30:00 0.137 0.277 0.307  0.140  0.515      0
33  18:45 2026-07-09 18:45:00 0.148 0.290 0.320  0.135  0.462      0
34  19:00 2026-07-09 19:00:00 0.144 0.285 0.315  0.128  0.397      0
35  19:15 2026-07-09 19:15:00 0.157 0.300 0.330  0.123  0.344      0
36  19:30 2026-07-09 19:30:00 0.174 0.321 0.351  0.118  0.292      0
37  19:45 2026-07-09 19:45:00 0.201 0.354 0.384  0.159  0.248      0
38  20:00 2026-07-09 20:00:00 0.191 0.342 0.372  0.254  0.209      0
39  20:15 2026-07-09 20:15:00 0.211 0.366 0.396  0.295  0.165      0
40  20:30 2026-07-09 20:30:00 0.239 0.400 0.430  0.336  0.122      0
41  20:45 2026-07-09 20:45:00 0.261 0.427 0.457  0.298  0.092      0
42  21:00 2026-07-09 21:00:00 0.258 0.422 0.453  0.193  0.066      0
43  21:15 2026-07-09 21:15:00 0.245 0.408 0.438  0.155  0.036      0
44  21:30 2026-07-09 21:30:00 0.222 0.379 0.409  0.116  0.006      0
45  21:45 2026-07-09 21:45:00 0.200 0.353 0.383  0.106  0.000      0
46  22:00 2026-07-09 22:00:00 0.221 0.378 0.408  0.115  0.009      0
47  22:15 2026-07-09 22:15:00 0.195 0.347 0.377  0.104  0.002      0
48  22:30 2026-07-09 22:30:00 0.175 0.322 0.352  0.094  0.000      0
49  22:45 2026-07-09 22:45:00 0.165 0.310 0.340  0.094  0.000      0
50  23:00 2026-07-09 23:00:00 0.176 0.323 0.353  0.101  0.000      0
51  23:15 2026-07-09 23:15:00 0.170 0.316 0.346  0.100  0.000      0
52  23:30 2026-07-09 23:30:00 0.157 0.301 0.331  0.100  0.000      0
53  23:45 2026-07-09 23:45:00 0.160 0.305 0.335  0.099  0.000      0
2026-07-09 10:30:01 info: No reduced hours applied for Sessy
2026-07-09 10:30:01 info: Reduced power applied during discharging at low soc, between 0% and 10% power is reduced from 1800W until 2700W
2026-07-09 10:30:01 info: Reduced power applied during discharging at low soc, between 10% and 20% power is reduced from 2700W until 3600W
2026-07-09 10:30:01 info: Reduced power applied during discharging at low soc, between 20% and 30% power is reduced from 3600W until 4200W
2026-07-09 10:30:01 info: Reduced power applied during discharging at low soc, between 30% and 40% power is reduced from 4200W until 4500W
2026-07-09 10:30:01 info: Reduced power applied during discharging at low soc, between 40% and 100% power is reduced from 4500W until 4500W
2026-07-09 10:30:01 info: Reduced power applied during charging at high soc, between 0% and 50% power is reduced from 5400W until 5400W
2026-07-09 10:30:01 info: Reduced power applied during charging at high soc, between 50% and 60% power is reduced from 5400W until 4950W
2026-07-09 10:30:01 info: Reduced power applied during charging at high soc, between 60% and 70% power is reduced from 4950W until 4500W
2026-07-09 10:30:01 info: Reduced power applied during charging at high soc, between 70% and 80% power is reduced from 4500W until 4050W
2026-07-09 10:30:01 info: Reduced power applied during charging at high soc, between 80% and 90% power is reduced from 4050W until 3300W
2026-07-09 10:30:01 info: Reduced power applied during charging at high soc, between 90% and 100% power is reduced from 3300W until 1500W
2026-07-09 10:30:01 info: Startwaarde SoC Sessy: 1.66666666666667%

2026-07-09 10:30:01 info: Boiler direct opwarmen staat uit
2026-07-09 10:30:01 info: Boiler setpoint 35.0 °C
2026-07-09 10:30:01 info: Boiler hysterese 0.8 K
2026-07-09 10:30:01 info: Boiler cooling rate 0.1 K/uur
2026-07-09 10:30:01 info: Boiler heating allowed below 34.6 °C
2026-07-09 10:30:01 info: Boiler opwarmen wordt ingepland tussen: 2026-07-09 10:30 en 2026-07-09 12:15
2026-07-09 10:30:01 info: Boiler verbruik in 1 kwartier: 0.75 kWh
2026-07-09 10:30:01 info: Prognose boiler:
                  tijd  act_temp  heat  elec  interval  cost  end_temp  end_value  netto_cost
0  2026-07-09 10:30:00    34.400 0.933 1.266         2 0.304    33.700     -0.359       0.664
1  2026-07-09 10:45:00    34.375 0.972 1.315         2 0.322    33.725     -0.346       0.669
2  2026-07-09 11:00:00    34.350 1.011 1.364         2 0.336    33.750     -0.334       0.670
3  2026-07-09 11:15:00    34.325 1.050 1.412         2 0.323    33.775     -0.321       0.643
4  2026-07-09 11:30:00    34.300 1.089 1.461         2 0.328    33.800     -0.308       0.636
5  2026-07-09 11:45:00    34.275 1.128 1.509         3 0.345    33.850     -0.282       0.628
6  2026-07-09 12:00:00    34.250 1.166 1.558         3 0.346    33.875     -0.269       0.616
7  2026-07-09 12:15:00    34.225 1.205 1.607         3 0.327    33.900     -0.257       0.584
8  2026-07-09 12:30:00    34.200 1.244 1.655         3 0.321    33.925     -0.244       0.565
9  2026-07-09 12:45:00    34.175 1.283 1.704         3 0.329    33.950     -0.231       0.559
10 2026-07-09 13:00:00    34.150 1.322 1.752         3 0.331    33.975     -0.218       0.549
11 2026-07-09 13:15:00    34.125 1.361 1.801         3 0.312    34.000     -0.205       0.517
12 2026-07-09 13:30:00    34.100 1.400 1.850         3 0.292    34.025     -0.192       0.484
13 2026-07-09 13:45:00    34.075 1.439 1.898         3 0.290    34.050     -0.180       0.470
14 2026-07-09 14:00:00    34.050 1.478 1.947         3 0.307    34.075     -0.167       0.474
15 2026-07-09 14:15:00    34.025 1.516 1.995         3 0.321    34.100     -0.154       0.475
16 2026-07-09 14:30:00    34.000 1.555 2.044         3 0.329    34.125     -0.141       0.470
17 2026-07-09 14:45:00    33.975 1.594 2.093         3 0.343    34.150     -0.128       0.472
18 2026-07-09 15:00:00    33.950 1.633 2.141         3 0.367    34.175     -0.115       0.483
19 2026-07-09 15:15:00    33.925 1.672 2.190         3 0.426    34.200     -0.103       0.528
20 2026-07-09 15:30:00    33.900 1.711 2.239         3 0.458    34.225     -0.090       0.547
21 2026-07-09 15:45:00    33.875 1.750 2.287         4 0.490    34.275     -0.064       0.555
22 2026-07-09 16:00:00    33.850 1.789 2.336         4 0.509    34.300     -0.051       0.561
23 2026-07-09 16:15:00    33.825 1.827 2.384         4 0.551    34.325     -0.038       0.589
24 2026-07-09 16:30:00    33.800 1.866 2.433         4 0.564    34.350     -0.026       0.590
25 2026-07-09 16:45:00    33.775 1.905 2.482         4 0.588    34.375     -0.013       0.600
26 2026-07-09 17:00:00    33.750 1.944 2.530         4 0.610    34.400      0.000       0.610
27 2026-07-09 17:15:00    33.725 1.983 2.579         4 0.656    34.425      0.013       0.644
28 2026-07-09 17:30:00    33.700 2.022 2.627         4 0.681    34.450      0.026       0.655
29 2026-07-09 17:45:00    33.675 2.061 2.676         4 0.709    34.475      0.038       0.670
30 2026-07-09 18:00:00    33.650 2.100 2.725         4 0.735    34.500      0.051       0.684
31 2026-07-09 18:15:00    33.625 2.139 2.773         4 0.769    34.525      0.064       0.705
32 2026-07-09 18:30:00    33.600 2.177 2.822         4 0.810    34.550      0.077       0.734
33 2026-07-09 18:45:00    33.575 2.216 2.870         4 0.856    34.575      0.090       0.766
34 2026-07-09 19:00:00    33.550 2.255 2.919         4 0.917    34.600      0.103       0.814
35 2026-07-09 19:15:00    33.525 2.294 2.968         4 0.977    34.625      0.115       0.862
36 2026-07-09 19:30:00    33.500 2.333 3.016         5 1.044    34.675      0.141       0.903
37 2026-07-09 19:45:00    33.475 2.372 3.065         5 1.124    34.700      0.154       0.970
38 2026-07-09 20:00:00    33.450 2.411 3.113         5 1.199    34.725      0.167       1.032
39 2026-07-09 20:15:00    33.425 2.450 3.162         5 1.278    34.750      0.180       1.098
40 2026-07-09 20:30:00    33.400 2.488 3.211         5 1.323    34.775      0.192       1.130
41 2026-07-09 20:45:00    33.375 2.527 3.259         5 1.319    34.800      0.205       1.113
42 2026-07-09 21:00:00    33.350 2.566 3.308         5 1.288    34.825      0.218       1.070
43 2026-07-09 21:15:00    33.325 2.605 3.356         5 1.262    34.850      0.231       1.031
44 2026-07-09 21:30:00    33.300 2.644 3.405         5 1.223    34.875      0.244       0.980
45 2026-07-09 21:45:00    33.275 2.683 3.454         5 1.191    34.900      0.257       0.934
46 2026-07-09 22:00:00    33.250 2.722 3.502         5 1.181    34.925      0.269       0.911
47 2026-07-09 22:15:00    33.225 2.761 3.551         5 1.151    34.950      0.282       0.869
48 2026-07-09 22:30:00    33.200 2.800 3.599         5 1.134    34.975      0.295       0.839
49 2026-07-09 22:45:00    33.175 2.838 3.648         5 1.135    35.000      0.308       0.827
50 2026-07-09 23:00:00    33.150 0.000 0.000         0 0.000     0.000      0.000       0.000
51 2026-07-09 23:15:00    33.125 0.000 0.000         0 0.000     0.000      0.000       0.000
52 2026-07-09 23:30:00    33.100 0.000 0.000         0 0.000     0.000      0.000       0.000
53 2026-07-09 23:45:00    33.075 0.000 0.000         0 0.000     0.000      0.000       0.000

2026-07-09 10:30:01 info: Instellingen voor laden van EV: Audi Q4
2026-07-09 10:30:01 info: Direct laden is uit
2026-07-09 10:30:01 info:  Ampere  Effic. Grid kW Accu kW
2026-07-09 10:30:01 info:    0.00    1.00    0.00    0.00
2026-07-09 10:30:01 info:    6.00    0.90    4.14    3.73
2026-07-09 10:30:01 info:    8.00    0.90    5.52    4.97
2026-07-09 10:30:01 info:   10.00    0.90    6.90    6.21
2026-07-09 10:30:01 info:   12.00    0.90    8.28    7.45
2026-07-09 10:30:01 info:   14.00    0.90    9.66    8.69
2026-07-09 10:30:01 info:   16.00    0.90   11.04    9.94
2026-07-09 10:30:01 info: Capaciteit accu: 78.0 kWh
2026-07-09 10:30:01 info: Maximaal laadvermogen: 11.04 kW
2026-07-09 10:30:01 info: Klaar met laden op: 09-07-2026 18:00:17
2026-07-09 10:30:01 info: Huidig laadniveau: 22.0 %
2026-07-09 10:30:01 info: Gewenst laadniveau:50.0 %
2026-07-09 10:30:01 info: Marge voor het laden: 0 %
2026-07-09 10:30:01 info: Locatie: home
2026-07-09 10:30:01 info: Ingeplugged:True
2026-07-09 10:30:01 info: Benodigde netto energie: 21.840 kWh
2026-07-09 10:30:01 info: Tijd nodig om te laden: 2:12 uur
2026-07-09 10:30:01 info: Afgerond naar hele intervallen: 9 kwartier
2026-07-09 10:30:01 info: Stand laden schakelaar: off
2026-07-09 10:30:01 info: Stand aantal ampere laden: 0.0 A
2026-07-09 10:30:01 info: Opladen wordt ingepland.
2026-07-09 10:30:01 info: Warmtepomp niet aanwezig - warmtepomp wordt niet ingepland
2026-07-09 10:30:01 info: Apparaat Yacuzzi_night direct starten staat uit
2026-07-09 10:30:01 info: Machine Yacuzzi_night wordt niet ingepland, want het planning-window ligt voorbij einde optimalisering
2026-07-09 10:30:01 info: Machine Yacuzzi_night wordt niet ingepland, want er is gekozen voor Uit
2026-07-09 10:30:01 info: Apparaat Yacuzzi_morning direct starten staat uit
2026-07-09 10:30:01 info: Machine Yacuzzi_morning wordt niet ingepland, want het planning-window ligt voorbij einde optimalisering
2026-07-09 10:30:01 info: Machine Yacuzzi_morning wordt niet ingepland, want er is gekozen voor Uit
2026-07-09 10:30:01 info: Apparaat Yacuzzi_day direct starten staat uit
2026-07-09 10:30:02 info: Machine Yacuzzi_day wordt niet ingepland, want er is gekozen voor Uit
2026-07-09 10:30:02 info: Apparaat Vaatwasser direct starten staat uit
2026-07-09 10:30:02 info: Machine Vaatwasser wordt niet ingepland, want in deze planning-window heeft de machine al gedraaid
2026-07-09 10:30:02 info: Machine Vaatwasser wordt niet ingepland, want er is gekozen voor Uit
2026-07-09 10:30:02 info: Apparaat Wasdroger direct starten staat uit
2026-07-09 10:30:02 info: Machine Wasdroger wordt niet ingepland, want er is gekozen voor Uit
2026-07-09 10:30:02 info: Apparaat Wasmachine direct starten staat uit
2026-07-09 10:30:02 info: Machine Wasmachine wordt niet ingepland, want er is gekozen voor Uit
2026-07-09 10:30:02 info: Strategie: minimale kosten
2026-07-09 10:30:02 info: Maximale fout (maximal gap): 0.005000 euro
2026-07-09 10:30:37 info: Rekentijd: 35.38 sec
2026-07-09 10:30:37 info: Het programma heeft een optimale oplossing gevonden.
2026-07-09 10:30:37 info: Waarde boiler om 23 uur: -0.68 kWh
2026-07-09 10:30:37 info: Laad volume in uur 7 12:15 0.0 kWh
2026-07-09 10:30:37 info: 1 1.0 5.4
2026-07-09 10:30:37 info: Laad volume in uur 8 12:30 0.0 kWh
2026-07-09 10:30:37 info: 1 1.0 5.4
2026-07-09 10:30:37 info: Laad volume in uur 9 12:45 0.0 kWh
2026-07-09 10:30:37 info: 1 1.0 5.4
2026-07-09 10:30:37 info: Laad volume in uur 11 13:15 0.0 kWh
2026-07-09 10:30:37 info: 1 1.0 5.4
2026-07-09 10:30:37 info: Laad volume in uur 12 13:30 0.0 kWh
2026-07-09 10:30:37 info: 1 1.0 5.4
2026-07-09 10:30:37 info: Laad volume in uur 13 13:45 0.0 kWh
2026-07-09 10:30:37 info: 1 1.0 5.4
2026-07-09 10:30:37 info: Laad volume in uur 14 14:00 0.0 kWh
2026-07-09 10:30:37 info: 1 1.0 5.4
2026-07-09 10:30:38 info: Laad volume in uur 15 14:15 0.0 kWh
2026-07-09 10:30:38 info: 1 1.0 5.4
2026-07-09 10:30:38 info: Laad volume in uur 16 14:30 0.0 kWh
2026-07-09 10:30:38 info: 1 1.0 5.4
2026-07-09 10:30:38 info: Laad volume in uur 17 14:45 0.0 kWh
2026-07-09 10:30:38 info: 0 0.062271882010049406 0.0
2026-07-09 10:30:38 info: 1 0.9377281179899506 5.4
2026-07-09 10:30:38 info: Laad volume in uur 18 15:00 0.0 kWh
2026-07-09 10:30:38 info: 0 0.12459822217856553 0.0
2026-07-09 10:30:38 info: 1 0.8754017778214345 5.4
2026-07-09 10:30:38 info: Laad volume in uur 19 15:15 0.0 kWh
2026-07-09 10:30:38 info: 0 0.21188067537417188 0.0
2026-07-09 10:30:38 info: 1 0.7881193246258281 5.4
2026-07-09 10:30:38 info: Laad volume in uur 20 15:30 0.0 kWh
2026-07-09 10:30:38 info: 0 0.29806840964901216 0.0
2026-07-09 10:30:38 info: 1 0.7019315903509878 5.4
2026-07-09 10:30:38 info: Laad volume in uur 22 16:00 0.0 kWh
2026-07-09 10:30:38 info: 0 0.471147431927341 0.0
2026-07-09 10:30:38 info: 1 0.528852568072659 5.4
2026-07-09 10:30:38 info: Laad volume in uur 23 16:15 0.0 kWh
2026-07-09 10:30:38 info: 0 0.8822177623785877 0.0
2026-07-09 10:30:38 info: 1 0.11778223762141227 5.4
2026-07-09 10:30:38 info: Laad volume in uur 26 17:00 0.0 kWh
2026-07-09 10:30:38 info: 0 0.6305916305916301 0.0
2026-07-09 10:30:38 info: 1 0.3694083694083698 5.4
2026-07-09 10:30:38 info: Ontlaad volume in uur 36 19:30 0.7307036661435963 kWh
2026-07-09 10:30:38 info: 1 0.6495143699054189 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 37 19:45 0.9843749999999999 kWh
2026-07-09 10:30:38 info: 1 0.8749999999999999 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 38 20:00 0.9843749999999999 kWh
2026-07-09 10:30:38 info: 1 0.8749999999999999 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 39 20:15 0.9843749999999999 kWh
2026-07-09 10:30:38 info: 1 0.8749999999999999 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 40 20:30 0.9843749999999999 kWh
2026-07-09 10:30:38 info: 1 0.8749999999999999 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 41 20:45 0.9843749999999999 kWh
2026-07-09 10:30:38 info: 1 0.8749999999999999 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 42 21:00 0.9843749999999999 kWh
2026-07-09 10:30:38 info: 1 0.8749999999999999 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 43 21:15 0.9843749999999999 kWh
2026-07-09 10:30:38 info: 1 0.8749999999999999 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 44 21:30 0.9782024222260084 kWh
2026-07-09 10:30:38 info: 1 0.8695132642008964 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 45 21:45 0.9311281959398676 kWh
2026-07-09 10:30:38 info: 1 0.8276695075021046 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 46 22:00 0.8554126612491149 kWh
2026-07-09 10:30:38 info: 1 0.7603668099992132 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 47 22:15 0.7692049661765111 kWh
2026-07-09 10:30:38 info: 1 0.6837377477124543 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 48 22:30 0.6632538689070192 kWh
2026-07-09 10:30:38 info: 1 0.5895589945840171 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 49 22:45 0.5718965866884215 kWh
2026-07-09 10:30:38 info: 1 0.5083525215008191 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 50 23:00 0.4931229521583358 kWh
2026-07-09 10:30:38 info: 1 0.4383315130296318 4.5
2026-07-09 10:30:38 info: Ontlaad volume in uur 51 23:15 0.4251996805111822 kWh
2026-07-09 10:30:38 info: 1 0.37795527156549524 4.5
2026-07-09 10:30:38 info: In- en uitgaande energie per kwartier batterij Sessy
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
 10:30   0.00     --   0.00   0.00   0.00     --   0.00     --   1.67
 10:45   0.00     --   0.00   0.00   0.00     --   0.00     --   1.67
 11:00   0.00     --   0.00   0.00   0.00     --   0.00     --   1.67
 11:15   0.00     --   0.00   0.00   0.00     --   0.00     --   1.67
 11:30   0.00     --   0.00   0.00   0.00     --   0.00     --   1.67
 11:45   0.00     --   0.00   0.00   0.00     --   0.00     --   1.67
 12:00   0.00     --   0.00   0.00   0.00     --   0.00     --   1.67
 12:15   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31   9.05
 12:30   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31  16.43
 12:45   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31  23.82
 13:00   0.00     --   0.00   0.00   0.00     --   0.00     --  23.82
 13:15   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31  31.20
 13:30   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31  38.58
 13:45   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31  45.96
 14:00   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31  53.35
 14:15   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31  60.73
 14:30   1.35  87.50   1.18   0.00   1.18  97.50   1.15  85.31  68.11
 14:45   1.27  87.50   1.11   0.00   1.11  97.50   1.08  85.31  75.04
 15:00   1.18  87.50   1.03   0.00   1.03  97.50   1.01  85.31  81.50
 15:15   1.06  87.50   0.93   0.00   0.93  97.50   0.91  85.31  87.32
 15:30   0.95  87.50   0.83   0.00   0.83  97.50   0.81  85.31  92.50
 15:45   0.00     --   0.00   0.00   0.00     --   0.00     --  92.50
 16:00   0.71  87.50   0.62   0.00   0.62  97.50   0.61  85.31  96.40
 16:15   0.16  87.50   0.14   0.00   0.14  97.50   0.14  85.31  97.27
 16:30   0.00     --   0.00   0.00   0.00     --   0.00     --  97.27
 16:45   0.00     --   0.00   0.00   0.00     --   0.00     --  97.27
 17:00   0.50  87.50   0.44   0.00   0.44  97.50   0.43  85.31 100.00
 17:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 17:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:30   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 18:45   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:00   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:15   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
 19:30  -0.73  87.50  -0.84   0.00  -0.84  97.50  -0.86  85.31  94.51
 19:45  -0.98  87.50  -1.12   0.00  -1.12  97.50  -1.15  85.31  87.11
 20:00  -0.98  87.50  -1.12   0.00  -1.12  97.50  -1.15  85.31  79.72
 20:15  -0.98  87.50  -1.12   0.00  -1.12  97.50  -1.15  85.31  72.32
 20:30  -0.98  87.50  -1.12   0.00  -1.12  97.50  -1.15  85.31  64.92
 20:45  -0.98  87.50  -1.12   0.00  -1.12  97.50  -1.15  85.31  57.53
 21:00  -0.98  87.50  -1.12   0.00  -1.12  97.50  -1.15  85.31  50.13
 21:15  -0.98  87.50  -1.12   0.00  -1.12  97.50  -1.15  85.31  42.73
 21:30  -0.98  87.50  -1.12   0.00  -1.12  97.50  -1.15  85.31  35.38
 21:45  -0.93  87.50  -1.06   0.00  -1.06  97.50  -1.09  85.31  28.39
 22:00  -0.86  87.50  -0.98   0.00  -0.98  97.50  -1.00  85.31  21.96
 22:15  -0.77  87.50  -0.88   0.00  -0.88  97.50  -0.90  85.31  16.18
 22:30  -0.66  87.50  -0.76   0.00  -0.76  97.50  -0.78  85.31  11.20
 22:45  -0.57  87.50  -0.65   0.00  -0.65  97.50  -0.67  85.31   6.90
 23:00  -0.49  87.50  -0.56   0.00  -0.56  97.50  -0.58  85.31   3.19
 23:15  -0.43  87.50  -0.49   0.00  -0.49  97.50  -0.50  85.31   0.00
 23:30   0.00     --   0.00   0.00   0.00     --   0.00     --   0.00
 23:45   0.00     --   0.00   0.00   0.00     --   0.00     --   0.00
Totaal   4.67          0.52   0.00   0.52         -0.26              
2026-07-09 10:30:42 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 10:30    0.00     0.00   0.00   0.55   0.26   0.00   0.00   0.00   0.81   0.00   -0.15  34.38   0.00
 10:45    0.00     0.00   0.00   0.54   0.24   0.00   0.00   0.00   0.78   0.00   -0.14  34.35   0.00
 11:00    0.00     0.00   0.00   0.55   0.18   0.00   0.00   0.00   0.72   0.00   -0.16  34.33   0.00
 11:15    0.00     0.00   0.00   0.54   0.16   0.00   0.00   0.00   0.69   0.00   -0.14  34.30   0.00
 11:30    0.00     0.00   0.00   0.53   0.13   0.00   0.00   0.00   0.66   0.00   -0.13  34.27   0.00
 11:45    0.00     0.00   0.00   0.62   0.10   0.00   0.00   0.00   0.71   0.00   -0.16  34.25   0.00
 12:00    0.00     0.00   0.00   0.02   0.04   0.75   0.00   0.00   0.81   0.00   -0.01  34.61   0.00
 12:15    1.35     0.00   1.24   0.00   0.01   0.75   0.00   0.00   0.87   0.26   -0.00  34.97   0.00
 12:30    1.35     0.00   0.46   0.00  -0.03   0.06   0.00   0.00   0.92   0.09   -0.00  34.98   0.00
 12:45    1.35     0.00   0.30   0.00   0.00   0.00   0.00   0.00   1.05   0.06   -0.00  34.95   0.00
 13:00    0.00     0.00   0.00   1.14   0.09   0.00   0.00   0.00   1.23   0.00   -0.26  34.93   0.00
 13:15    1.35     0.00   2.30   0.00   0.12   0.00   0.00   2.19   1.36   0.43   -0.00  34.90   0.00
 13:30    1.35     0.00   2.77   0.00   0.15   0.00   0.00   2.76   1.49   0.47   -0.00  34.88   0.00
 13:45    1.35     0.00   2.65   0.00   0.14   0.00   0.00   2.76   1.60   0.39   -0.00  34.85   0.00
 14:00    1.35     0.00   2.48   0.00   0.11   0.00   0.00   2.76   1.74   0.39   -0.00  34.83   0.00
 14:15    1.35     0.00   2.36   0.00   0.11   0.00   0.00   2.76   1.86   0.38   -0.00  34.80   0.00
 14:30    1.35     0.00   2.24   0.00   0.11   0.00   0.00   2.76   1.98   0.35   -0.00  34.78   0.00
 14:45    1.27     0.00   2.16   0.00   0.11   0.00   0.00   2.76   1.98   0.36   -0.00  34.75   0.00
 15:00    1.18     0.00   2.16   0.00   0.12   0.00   0.00   2.76   1.90   0.33   -0.00  34.73   0.00
 15:15    1.06     0.00   2.05   0.00   0.12   0.00   0.00   2.76   1.90   0.35   -0.00  34.70   0.00
 15:30    0.95     0.00   0.00   0.83   0.12   0.00   0.00   0.00   1.90   0.00   -0.18  34.68   0.00
 15:45    0.00     0.00   0.00   1.76   0.10   0.00   0.00   0.00   1.86   0.00   -0.44  34.65   0.00
 16:00    0.71     0.00   0.00   1.06   0.04   0.00   0.00   0.00   1.81   0.00   -0.24  34.63   0.00
 16:15    0.16     0.00   0.00   0.69   0.02   0.00   0.00   0.00   0.87   0.00   -0.17  34.60   0.00
 16:30    0.00     0.00   0.00   0.86   0.00   0.00   0.00   0.00   0.86   0.00   -0.22  34.58   0.00
 16:45    0.00     0.00   0.00   0.77   0.05   0.00   0.00   0.00   0.81   0.00   -0.21  34.55   0.00
 17:00    0.50     0.00   0.00   0.09   0.16   0.00   0.00   0.00   0.75   0.00   -0.02  34.53   0.00
 17:15    0.00     0.00   0.00   0.50   0.21   0.00   0.00   0.00   0.71   0.00   -0.14  34.50   0.00
 17:30    0.00     0.00   0.00   0.41   0.26   0.00   0.00   0.00   0.67   0.00   -0.11  34.48   0.00
 17:45    0.00     0.00   0.00   0.38   0.24   0.00   0.00   0.00   0.63   0.00   -0.11  34.45   0.00
 18:00    0.00     0.00   0.00   0.42   0.17   0.00   0.00   0.00   0.59   0.00   -0.12  34.43   0.00
 18:15    0.00     0.00   0.00   0.40   0.16   0.00   0.00   0.00   0.55   0.00   -0.12  34.40   0.00
 18:30    0.00     0.00   0.00   0.38   0.14   0.00   0.00   0.00   0.52   0.00   -0.12  34.38   0.00
 18:45    0.00     0.00   0.00   0.33   0.13   0.00   0.00   0.00   0.46   0.00   -0.10  34.35   0.00
 19:00    0.00     0.00   0.00   0.27   0.13   0.00   0.00   0.00   0.40   0.00   -0.08  34.33   0.00
 19:15    0.00     0.00   0.00   0.22   0.12   0.00   0.00   0.00   0.34   0.00   -0.07  34.30   0.00
 19:30    0.00     0.73   0.00   0.90   0.12   0.00   0.00   0.00   0.29   0.00   -0.32  34.28   0.00
 19:45    0.00     0.98   0.00   1.07   0.16   0.00   0.00   0.00   0.25   0.00   -0.41  34.25   0.00
 20:00    0.00     0.98   0.00   0.94   0.25   0.00   0.00   0.00   0.21   0.00   -0.35  34.23   0.00
 20:15    0.00     0.98   0.00   0.85   0.30   0.00   0.00   0.00   0.17   0.00   -0.34  34.20   0.00
 20:30    0.00     0.98   0.00   0.77   0.34   0.00   0.00   0.00   0.12   0.00   -0.33  34.18   0.00
 20:45    0.00     0.98   0.00   0.78   0.30   0.00   0.00   0.00   0.09   0.00   -0.36  34.15   0.00
 21:00    0.00     0.98   0.00   0.86   0.19   0.00   0.00   0.00   0.07   0.00   -0.39  34.13   0.00
 21:15    0.00     0.98   0.00   0.87   0.15   0.00   0.00   0.00   0.04   0.00   -0.38  34.10   0.00
 21:30    0.00     0.98   0.00   0.87   0.12   0.00   0.00   0.00   0.01   0.00   -0.36  34.08   0.00
 21:45    0.00     0.93   0.00   0.83   0.11   0.00   0.00   0.00   0.00   0.00   -0.32  34.05   0.00
 22:00    0.00     0.86   0.00   0.75   0.11   0.00   0.00   0.00   0.01   0.00   -0.31  34.03   0.00
 22:15    0.00     0.77   0.00   0.67   0.10   0.00   0.00   0.00   0.00   0.00   -0.25  34.00   0.00
 22:30    0.00     0.66   0.00   0.57   0.09   0.00   0.00   0.00   0.00   0.00   -0.20  33.98   0.00
 22:45    0.00     0.57   0.00   0.48   0.09   0.00   0.00   0.00   0.00   0.00   -0.16  33.95   0.00
 23:00    0.00     0.49   0.00   0.39   0.10   0.00   0.00   0.00   0.00   0.00   -0.14  33.93   0.00
 23:15    0.00     0.43   0.00   0.32   0.10   0.00   0.00   0.00   0.00   0.00   -0.11  33.90   0.00
 23:30    0.00     0.00   0.10   0.00   0.10   0.00   0.00   0.00   0.00   0.03   -0.00  33.88   0.00
 23:45    0.00     0.00   0.10   0.00   0.10   0.00   0.00   0.00   0.00   0.03   -0.00  33.85   0.00
Totaal   17.98    13.31  23.38  25.75   7.17   1.56   0.00  24.27  40.04   3.93   -8.34    NaN   0.00

2026-07-09 10:30:42 info: Consumption              23.38 (kWh)
2026-07-09 10:30:42 info: Cost consumption          3.93 (€)
2026-07-09 10:30:42 info: Tariff consumption        0.168 (€/kWh)
2026-07-09 10:30:42 info: Production               25.75 (kWh)
2026-07-09 10:30:42 info: Profit production        -8.34 (€)
2026-07-09 10:30:42 info: Tariff production         0.324 (€/kWh)

2026-07-09 10:30:42 info: 
Calculation profit after optimize in €
Cost before optimize             -2.48
Cost consumption      3.93
Cycle cost            0.00
Penalty cost          0.00
EV switch costs       0.00
Battery storage       0.06
Boiler storage        0.28
Profit production    -8.34
Total                -4.08
Cost after optimize              -4.08
Profit:                           1.59
2026-07-09 10:30:42 info: Doorzetten van alle settings naar HA
2026-07-09 10:30:42 info: Boiler opwarmen niet geactiveerd
2026-07-09 10:30:42 info: Boiler opwarmen ingepland vanaf: 2026-07-09 12:00:00 met 3 interval(len)
2026-07-09 10:30:42 info: Boiler temperatuur 33.9 °C,  waardering: -0.678 kWh = -0.18 euro
2026-07-09 10:30:43 info: Grid balanceren: off
2026-07-09 10:30:43 info: Grid set point: -2195.0 W
2026-07-09 10:30:43 info: Inzet-factor laden Audi Q4 per stop
2026-07-09 10:30:43 info:   uur         0.0A          6.0A          8.0A         10.0A         12.0A         14.0A         16.0A   cons   power     on   off  part bound
2026-07-09 10:30:43 info: 10:30  0.9999(1.0)   0.0000(0.0)   0.0000(0.0)   0.0001(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  6.900    0.0   0.0   1.0   0.0
2026-07-09 10:30:43 info: 10:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 11:00  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 11:15  0.9999(1.0)   0.0000(0.0)   0.0001(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  5.520    0.0   0.0   1.0   0.0
2026-07-09 10:30:43 info: 11:30  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 11:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 12:00  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 12:15  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 12:30  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 12:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 13:00  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 13:15  0.2078(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.7922(1.0)  2.186  11.040    0.0   0.0   1.0   0.0
2026-07-09 10:30:43 info: 13:30  0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   1.0000(1.0)  2.760  11.040    1.0   0.0   0.0   0.0
2026-07-09 10:30:43 info: 13:45  0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   1.0000(1.0)  2.760  11.040    1.0   0.0   0.0   0.0
2026-07-09 10:30:43 info: 14:00  0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   1.0000(1.0)  2.760  11.040    1.0   0.0   0.0   0.0
2026-07-09 10:30:43 info: 14:15  0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   1.0000(1.0)  2.760  11.040    1.0   0.0   0.0   0.0
2026-07-09 10:30:43 info: 14:30  0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   1.0000(1.0)  2.760  11.040    1.0   0.0   0.0   0.0
2026-07-09 10:30:43 info: 14:45  0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   1.0000(1.0)  2.760  11.040    1.0   0.0   0.0   0.0
2026-07-09 10:30:43 info: 15:00  0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   1.0000(1.0)  2.760  11.040    1.0   0.0   0.0   0.0
2026-07-09 10:30:43 info: 15:15  0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   1.0000(1.0)  2.760  11.040    1.0   0.0   0.0   1.0
2026-07-09 10:30:43 info: 15:30  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 15:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 16:00  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 16:15  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 16:30  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 16:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 17:00  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 17:15  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 17:30  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 17:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: 18:00  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0
2026-07-09 10:30:43 info: Audi Q4 wordt geladen tussen 2026-07-09 10:30:00 en 2026-07-09 15:30:00
2026-07-09 10:30:43 info: Aantal partial stops:  3
2026-07-09 10:30:43 info: Aantal boundary stops:  1
2026-07-09 10:30:43 info: Aantal start/stops:  6
2026-07-09 10:30:43 info: Penalty per start/stop: 0.000
2026-07-09 10:30:43 info: Totale switch kosten: 0.00
2026-07-09 10:30:43 info: Berekeningsuitkomst voor opladen van Audi Q4:
2026-07-09 10:30:43 info: - aantal ampere 10.0A (was 0.0A)
2026-07-09 10:30:43 info: - stand schakelaar 'on' (was 'off')
2026-07-09 10:30:43 info: - positie: home
2026-07-09 10:30:43 info: - ingeplugd: True
2026-07-09 10:30:43 info: Laden van Audi Q4 aangezet met 10.0 ampere via 'input_number.dao_ev_set_charging_ampere'
2026-07-09 10:30:43 info: Evaluatie status laden Audi Q4 op 2026-07-09 10:30
2026-07-09 10:30:43 info: - schakelaar laden: on
2026-07-09 10:30:43 info: - aantal ampere: 10.0
2026-07-09 10:30:43 info: Cycle cost Sessy: 0.00 euro
2026-07-09 10:30:43 info: Netto vermogen naar(+)/uit(-) omvormer Sessy: 0 W 
2026-07-09 10:30:43 info: Vermogen uit batterij: 0W
2026-07-09 10:30:43 info: Vermogen dat binnenkomt van pv: 0W
2026-07-09 10:30:43 info: Vermogen dat binnenkomt van ac: 0W
2026-07-09 10:30:43 info: Waarde SoC na eerste uur: 1.7%
2026-07-09 10:30:43 info: Apparaat: Yacuzzi_night
2026-07-09 10:30:43 info: Programma: Uit
2026-07-09 10:30:43 info: Apparaat: Yacuzzi_morning
2026-07-09 10:30:43 info: Programma: Uit
2026-07-09 10:30:43 info: Apparaat: Yacuzzi_day
2026-07-09 10:30:43 info: Programma: Uit
2026-07-09 10:30:43 info: Apparaat: Vaatwasser
2026-07-09 10:30:43 info: Programma: Uit
2026-07-09 10:30:43 info: Apparaat: Wasdroger
2026-07-09 10:30:43 info: Programma: Uit
2026-07-09 10:30:43 info: Apparaat: Wasmachine
2026-07-09 10:30:43 info: Programma: Uit

Vragen/suggestie van harte welkom

[Batavia]

tomvandepoel3 schreef op donderdag 9 juli 2026 @ 16:45:
Ik ben benieuwd of dit gedrag ook bij andere gebruikers voorkomt. Normaal werkt de DAO planning voor mijn EV perfect maar ik heb nu al 2-3 keer gezien dat de auto gedurende 15 minuten in de ochtend (kosten zijn nog relatief hoog) wordt geladen terwijl er geen EV laden in de DAO grafiek te zien is voor die betreffende 15 minuten.

Dit was zo'n situatie eerder vandaag:
- EV SoC = 22%. Laden gewenst tot 50% voor 18:00 vandaag (morgen verwacht ik meer zon en mogelijk lagere kosten; daarnaast heb ik de auto tot morgenmiddag niet nodig)
- Planning met minimale kosten ziet er mooi uit (zie: geen EV laden om 10:30)
[Afbeelding]
- In de optimalisatie log staat echter:
[Afbeelding]
- En de HA entiteit gaat van Off naar On zodat er ook werkelijk geladen wordt (tegen IMO te hoge kosten).
[Afbeelding]

Dit gebeurt zeker niet altijd maar is toch een beetje jammer.
Voor de volledigheid hierbij ook nog de volledige log file

[...]


Vragen/suggestie van harte welkom

Hoe/wanneer worden je vertrektijden berekend. Ik heb dit wel eens gehad dat als ik om 7 uur sochtends een nieuwe vertrektijd/soc target laat berekenen hij soms nog die dag om 8 uur wilt vertrekken. Had toen een fout zitten in hoe hij keek naar de eindtijd. Je bent sochtends maar tot 1 uur die dag data en dat is een erg klein window


Waar ik zelf nu tegen aan loop is dat als mijn ev sensoren niet beschikbaar zijn heel de dao berekening crasht. Ik zou liever willen dat hij dan alleen de auto overslaat alsof die er niet was

[ Voor 3% gewijzigd door Batavia op 09-07-2026 17:22 ]

[tomvandepoel3]

Batavia schreef op donderdag 9 juli 2026 @ 17:17:
[...]

Hoe/wanneer worden je vertrektijden berekend. Ik heb dit wel eens gehad dat als ik om 7 uur sochtends een nieuwe vertrektijd/soc target laat berekenen hij soms nog die dag om 8 uur wilt vertrekken. Had toen een fout zitten in hoe hij keek naar de eindtijd. Je bent sochtends maar tot 1 uur die dag data en dat is een erg klein window

De nieuwe vertrektijd en soc target zijn vanochtend vroeg om 8:15 in HA gezet; dus ruim genoeg tijd voor DAO om erop te reageren (denk ik).

Wat me, nu pas, opvalt in de log is de volgende regels

code:

2026-07-09 10:30:43 info: Inzet-factor laden Audi Q4 per stop
2026-07-09 10:30:43 info:   uur         0.0A          6.0A          8.0A         10.0A         12.0A         14.0A         16.0A   cons   power     on   off  part bound
2026-07-09 10:30:43 info: 10:30  0.9999(1.0)   0.0000(0.0)   0.0000(0.0)   0.0001(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  6.900    0.0   0.0   1.0   0.0
2026-07-09 10:30:43 info: 10:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0

Ik zie om 10:30 een inzet factor van 0.9999 bij 0 A en 0.0001 bij 10 A.
Misschien een tolerantie issue waardoor DAO toch besluit om met 10 A te gaan laden?

[tomvandepoel3]

Batavia schreef op donderdag 9 juli 2026 @ 17:17:
[...]

Waar ik zelf nu tegen aan loop is dat als mijn ev sensoren niet beschikbaar zijn heel de dao berekening crasht. Ik zou liever willen dat hij dan alleen de auto overslaat alsof die er niet was

Ik gebruik in mijn DAO config, als workaround, eigen HA template sensoren (b.v. voor de ev SoC) een soort wrapper om de echte ev sensoren. Daarin check ik of de echte sensoren “unavailable” zijn en zet dan een default waarde (b.v. 100% voor de SoC) waardoor de DAO berekening niet crashed maar er ook niet geladen gaat worden.

[hemertje]

hemertje schreef op dinsdag 7 juli 2026 @ 11:23:
[...]


zoals @Bravo hierboven aangeeft kan ik de WP toch niet apart meten en in de voorspellingen laten opnemen want met apart opnemen dan wordt die niet meegenomen in de baseload en dus verbruiksberekeningen?

tenminste zo heb ik het laatst ook al een keer eerder begrepen van je?

met 56 dagen bereken je het gemiddelde over 2 maanden, met de seizoenswisselingen reken je dan naar mijn idee te krap of te ruim afhankelijk of we richting zomer of winter gaan...

of ik snap de uitgangspunten van de berekeningen nog niet?

wil iemand me deze nog even uitleggen?

[storeman]

@hemertje Ik doe even een paar aannames. De baseload wordt berekend door het totale verbruik minus alle bekende factoren (=machines, boiler, ev; dus planbare zaken).

Als je de WP mee wil nemen in je baseload, dan moet je hem dus niet toevoegen aan de verbruikssensoren, dan zal deze inderdaad in je baseload komen omdat DAO alleen de bulk ziet. In dat scenario lijkt het me inderdaad heel wenselijk om de periode in te korten. Er is echter geen relatie tussen baseload en het weer, dus de voorspelling zal er altijd (fors) naast zitten.

Beter is om je warmtepomp aan te laten sturen of te laten plannen door DAO. Zelfs als je de aansturing niet gebruikt vanuit HA. De voorspelling van de energievraag zal veel beter in de buurt komen van wat er daadwerkelijk gedraaid zal worden. Ook al zal het op uurbasis niet exact kloppen, richting NoM wil je vooral voldoende beschikbaar hebben om zo lang mogelijk op NoM te draaien.

Duidelijker zo?

[ Voor 5% gewijzigd door storeman op 10-07-2026 00:07 ]

[tomvandepoel3]

tomvandepoel3 schreef op donderdag 9 juli 2026 @ 17:53:
[...]

Wat me, nu pas, opvalt in de log is de volgende regels

code:

2026-07-09 10:30:43 info: Inzet-factor laden Audi Q4 per stop
2026-07-09 10:30:43 info:   uur         0.0A          6.0A          8.0A         10.0A         12.0A         14.0A         16.0A   cons   power     on   off  part bound
2026-07-09 10:30:43 info: 10:30  0.9999(1.0)   0.0000(0.0)   0.0000(0.0)   0.0001(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  6.900    0.0   0.0   1.0   0.0
2026-07-09 10:30:43 info: 10:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0

Ik zie om 10:30 een inzet factor van 0.9999 bij 0 A en 0.0001 bij 10 A.
Misschien een tolerantie issue waardoor DAO toch besluit om met 10 A te gaan laden?

Na wat debuggen ben ik ervan overtuigd dat het probleem veroorzaakt wordt door inzet factoren met een hele kleine (b.v. 0.0001) waarde die zijn ontstaan door normale numerieke instabiliteit in de complexe berekeningen.

De for loop in day_ahead.py (regels #3762 - #3775) start het laden op basis van de eerste positieve ev_charge_stage met een waarde groter dan 0 (dus 0.0001 triggert - onterecht IMO - het laden). De break in de for loop zorgt er tevens voor dat de eerste waarde groter dan 0 wordt gebruikt en er niet wordt verder gekeken naar "betere" laadstroom waarden.

Hierdoor wordt er dus soms (hier met 14A) geladen terwijl dit niet echt de bedoeling is. Dit was mijn oorspronkelijk observatie.

code:

2026-07-10 05:45:48 info: Inzet-factor laden Audi Q4 per stop
2026-07-10 05:45:48 info:   uur         0.0A          6.0A          8.0A         10.0A         12.0A         14.0A         16.0A   cons   power     on   off  part bound
2026-07-10 05:45:48 info: 05:45  0.9999(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0001(1.0)   0.0000(0.0)  0.000  9.660    0.0   0.0   1.0   0.0

Of er wordt met een te lage stroom (hier 6A) geladen terwijl dit eigenlijk met een grotere waarde (hier 14A) zou moeten; zie ik nu ook gebeuren.

code:

2026-07-10 11:30:32 info:   uur         0.0A          6.0A          8.0A         10.0A         12.0A         14.0A         16.0A   cons   power     on   off  part bound
2026-07-10 11:30:32 info: 11:30  0.6227(1.0)   0.0001(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.3772(1.0)  1.041  15.180    0.0   0.0   1.0   0.0

@KC27 zit ik op het juiste spoor?

[KC27]

tomvandepoel3 schreef op donderdag 9 juli 2026 @ 17:53:
[...]


De nieuwe vertrektijd en soc target zijn vanochtend vroeg om 8:15 in HA gezet; dus ruim genoeg tijd voor DAO om erop te reageren (denk ik).

Wat me, nu pas, opvalt in de log is de volgende regels

code:

2026-07-09 10:30:43 info: Inzet-factor laden Audi Q4 per stop
2026-07-09 10:30:43 info:   uur         0.0A          6.0A          8.0A         10.0A         12.0A         14.0A         16.0A   cons   power     on   off  part bound
2026-07-09 10:30:43 info: 10:30  0.9999(1.0)   0.0000(0.0)   0.0000(0.0)   0.0001(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  6.900    0.0   0.0   1.0   0.0
2026-07-09 10:30:43 info: 10:45  1.0000(1.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)   0.0000(0.0)  0.000  0.000    0.0   1.0   0.0   0.0

Ik zie om 10:30 een inzet factor van 0.9999 bij 0 A en 0.0001 bij 10 A.
Misschien een tolerantie issue waardoor DAO toch besluit om met 10 A te gaan laden?

Ik ga hier naar kijken, maar ik ben bezig met het wegwerken van een achterstand aan eerder gemelde issues. Je kunt dit gedrag ook voorkomen door een kleine penalty te configureren die aan- en uitschakelen van het laden ontmoedigt. Bijvoorbeeld:

code:

"switch_cost" :  0.001

[hemertje]

storeman schreef op vrijdag 10 juli 2026 @ 00:05:
@hemertje Ik doe even een paar aannames. De baseload wordt berekend door het totale verbruik minus alle bekende factoren (=machines, boiler, ev; dus planbare zaken).

Als je de WP mee wil nemen in je baseload, dan moet je hem dus niet toevoegen aan de verbruikssensoren, dan zal deze inderdaad in je baseload komen omdat DAO alleen de bulk ziet. In dat scenario lijkt het me inderdaad heel wenselijk om de periode in te korten. Er is echter geen relatie tussen baseload en het weer, dus de voorspelling zal er altijd (fors) naast zitten.

Beter is om je warmtepomp aan te laten sturen of te laten plannen door DAO. Zelfs als je de aansturing niet gebruikt vanuit HA. De voorspelling van de energievraag zal veel beter in de buurt komen van wat er daadwerkelijk gedraaid zal worden. Ook al zal het op uurbasis niet exact kloppen, richting NoM wil je vooral voldoende beschikbaar hebben om zo lang mogelijk op NoM te draaien.

Duidelijker zo?

@storeman Klopt, zo zitten wij het ook in elkaar.

Baseload: WP staat niet in de verbruikssensoren. In calc_baseloads trek ik totale WP-kWh af (heishamon_wp_energy_kwh = CV + koelen + tapwater), plus EV, boiler-backup en batterij. Korte periode (18 dagen) rond de seizoenswissel — geen 56 dagen over zomer+winter.

Baseload ≠ weer: eens dat forecast-baseload geen graaddagen kent. Daarom CV niet via baseload terug in de planning, maar via heating (graaddagen × factor, stooklijn-offset) met dao_wp_enabled aan. Tapwater via boiler + dao_mag_dhw_plannen.

Warmtepomp buiten DAO: comfort en scheduler via HeishaMoNR van Ed Terbak (Node-RED + HeishaMon): https://github.com/edterbak/HeishaMoNR — CCC/RTC, zomer Cool only, Solar²DHW bij export. DAO zit daar bovenop: alleen stooklijn-offset (winter) en gepland tapwater; Ed's flows wijzig ik niet. Keten: DAO → node_red_start_dhw_run → Force-DHW; tijdens DAO-run Solar²DHW uit via dao_dhw_enabled.


Wat in DAO ontbreekt (bij ons ook):

• geen koelmodel — koelverbruik wél uit history, niet in forecast
• geen feedback verwacht vs gerealiseerde winst → parameters
• degree_days_factor handmatig, niet zelflerend
• geen vloer-inertie / warmtebuffer
• geen automatische seizoensflip dao_wp_enabled

[hemertje]

storeman schreef op zondag 5 juli 2026 @ 00:04:
Ik ben bezig geweest om de frontend op te frissen. Ik heb een stukje van de webserver herschreven en ik hoor graag jullie feedback. Ik heb een discussion geopend op github:

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

vraagje, nu zijn de uikomsten de grafieken weergegeven in een plaatje
is het ook mogelijk dat je echte grafieken weergeeft zodat je daar overheen kunt hoveren en de grafieken beter afleesbaar zijn?

[storeman]

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

Ik heb zojuist nog een en ander aangepast en er is een docker-image beschikbaar (amd64 only). De image is te gebruiken via:

YAML:

....
  dao:
    image: storeman/dao:uiv2

Er wordt hierbij een kolom toegevoegd aan de SQLite database (variabel.aggregate) en de defaults worden ingesteld.

[bvdnoort]

KC27 schreef op woensdag 4 maart 2026 @ 19:56:
[...]

Ziet er erg mooi uit! Mijn complimenten
Het staat wel om mijn "to do" lijst, maar is moeilijker dan het lijkt.
De data die getoond worden in de API worden op dezelfde wijze berekend als de data in reports\grid en report\balans.
De geschiedenis van die data staan in de database van HA en de meterstanden daarvan worden maar eens per uur opgeslagen.
Er is ook een short-term tabel maar die werkt weer anders. Dus ik moet nog flink wat omzetten.
De prognose data staan in een tabel in de DAO database. Als je daarmee tevreden bent kan ik dat waarschijnlijk sneller maken met als extra parameter "prognose=1".
Alle data in deze tabel uit de kwartier (of uur)-berekening worden opgeslagen in de prognose tabel:

code:

2026-03-04 19:45:07 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 19:45    0.00     1.01   0.00   0.88   0.08   0.00   0.06   0.00   0.00   0.00   -0.29  50.98   0.00
 20:00    0.00     1.04   0.00   0.91   0.07   0.00   0.06   0.00   0.00   0.00   -0.31  50.85   0.00
 20:15    0.00     0.60   0.00   0.47   0.07   0.00   0.06   0.00   0.00   0.00   -0.15  50.73   0.00
 20:30    0.00     0.12   0.00   0.00   0.07   0.00   0.06   0.00   0.00   0.00   -0.00  50.60   0.00
 20:45    0.00     0.12   0.00   0.00   0.07   0.00   0.06   0.00   0.00   0.00   -0.00  50.48   0.00
 21:00    0.00     0.30   0.00   0.18   0.06   0.00   0.06   0.00   0.00   0.00   -0.05  50.35   0.00
 21:15    0.00     0.12   0.00   0.00   0.06   0.00   0.06   0.00   0.00   0.00   -0.00  50.22   0.00
 21:30    0.00     0.00   0.14   0.00   0.06   0.00   0.08   0.00   0.00   0.04   -0.00  50.10   0.00
 21:45    0.00     0.00   0.13   0.00   0.06   0.00   0.08   0.00   0.00   0.04   -0.00  49.98   0.00
......

Is dat iets?

@KC27 Zou je nog in staat zijn om deze 'prognose=1' optie toe te voegen aan een komende update? Dat zou zeer gewaardeerd worden.

[KC27]

bvdnoort schreef op maandag 13 juli 2026 @ 20:59:
[...]

@KC27 Zou je nog in staat zijn om deze 'prognose=1' optie toe te voegen aan een komende update? Dat zou zeer gewaardeerd worden.

Goed dat je me eraan herinnert.
Ik zet het op mijn todo-lijst.

[storeman]

@KC27 @bvdnoort de /v2/api/data endpoint (in de rc voor deze maand) kan data teruggeven in een bepaalde range. Grootste voordeel is de performance, deze data komt heel snel en met een heel dun laagje uit de DAO-database.

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

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

Deze geeft voor alle velden zowel de value (v) als de forecast (f) terug. Sample:

[
  {
    "ts": "2026-07-01 00:00",
    "bat_in": {
      "f": 0.0,
      "v": null
    },
    "bat_out": {
      "f": 0.29928125,
      "v": null
    },
    "cons": {
      "f": 0.0,
      "v": 0.197
    },
    "cost": {
      "f": 0.0,
      "v": 0.0652561712
    },
    "da": {
      "f": null,
      "v": 0.161625
    },
    "prod": {
      "f": 0.053281249999999954,
      "v": 0.0
    },
    "profit": {
      "f": -0.017482414640624985,
      "v": 0.0
    },
    "pv_ac": {
      "f": 0.0,
      "v": null
    },
    "pv_dc": {
      "f": 0.006675889249891042,
      "v": null
    },
    "soc": {
      "f": 49.0,
      "v": null
    }
  },...
]

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

[firecaps30]

Bij het uitvoeren van de ML training krijg ik een keyerror UTC, iemand enig idee?

code:

2026-07-14 16:52:02 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3641, in get_loc
    return self._engine.get_loc(casted_key)
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  File "pandas/_libs/index.pyx", line 168, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 197, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 7668, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 7676, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'utc'

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

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

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

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

[KC27]

firecaps30 schreef op dinsdag 14 juli 2026 @ 17:00:
Bij het uitvoeren van de ML training krijg ik een keyerror UTC, iemand enig idee?

code:

2026-07-14 16:52:02 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/pandas/core/indexes/base.py", line 3641, in get_loc
    return self._engine.get_loc(casted_key)
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  File "pandas/_libs/index.pyx", line 168, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/index.pyx", line 197, in pandas._libs.index.IndexEngine.get_loc
  File "pandas/_libs/hashtable_class_helper.pxi", line 7668, in pandas._libs.hashtable.PyObjectHashTable.get_item
  File "pandas/_libs/hashtable_class_helper.pxi", line 7676, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: 'utc'

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

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

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

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

Het lijkt erop dat de sensor(en) die je hebt opgegeven bij "entities_sensors" geen data bevat(ten).

[firecaps30]

KC27 schreef op dinsdag 14 juli 2026 @ 23:16:
[...]

Het lijkt erop dat de sensor(en) die je hebt opgegeven bij "entities_sensors" geen data bevat(ten).

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

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

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


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

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

"entities battery production": waarde battery discharge power, in Watt. Wat de accu uit gaat.

[KC27]

firecaps30 schreef op woensdag 15 juli 2026 @ 09:12:
[...]

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

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

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


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

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

"entities battery production": waarde battery discharge power, in Watt. Wat de accu uit gaat.

Volgens mij kloppen ze allemaal.

[thomvh]

@KC27 Is er een DB trucje hoe ik dit kan oplossen? De waarde is al gefixt in Home Assistant maar DAO lijkt er nog wel mee te rekenen.

[thewhi]

thomvh schreef op donderdag 16 juli 2026 @ 10:58:
@KC27 Is er een DB trucje hoe ik dit kan oplossen? De waarde is al gefixt in Home Assistant maar DAO lijkt er nog wel mee te rekenen.
[Afbeelding]

Probeer eens een herstart van de App binnen Home Assistant. Dat heeft bij mij al een paar keer de reporting hersteld.

[thomvh]

thewhi schreef op donderdag 16 juli 2026 @ 14:11:
[...]


Probeer eens een herstart van de App binnen Home Assistant. Dat heeft bij mij al een paar keer de reporting hersteld.

Helaas... Al geprobeerd.

[KC27]

thomvh schreef op donderdag 16 juli 2026 @ 16:13:
[...]

Helaas... Al geprobeerd.

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

[storeman]

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

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

[stat]

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

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

[Bravo]

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

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

Als je wil dat hij eerder klaar is, dan verschuif je toch het 'end_window_machine' tot het tijdstip dat de machine klaar moet zijn en laat je DAO verder zijn ding doen?

[thomvh]

KC27 schreef op donderdag 16 juli 2026 @ 23:19:
[...]

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

Allebei gedaan.

[thomvh]

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

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

Nee, ik heb alleen in HA vanuit de developer tools de verkeerde waarde gereset. De laadpaal integratie die geeft die gekke waarde neer wanneer er tijdens het laden HA herstart wordt.