Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[KC27]

@KVan
Welke entity heb je gedefinieerd om de "entity_set_operating_mode" van je batterij te kunnen zetten en hoe heb je die gedefinieerd?
Want het gaat niet fout bij je machine, maar bij je batterij.
Lees nog eens goed in de wiki hoe je deze instelt: https://github.com/cornee...alle-instellingen#battery

[KVan]

KC27 schreef op zondag 27 september 2026 @ 14:29:
@KVan
Welke entity heb je gedefinieerd om de "entity_set_operating_mode" van je batterij te kunnen zetten en hoe heb je die gedefinieerd?
Want het gaat niet fout bij je machine, maar bij je batterij.
Lees nog eens goed in de wiki hoe je deze instelt: https://github.com/cornee...alle-instellingen#battery

Thanks @KC27 dat was hem idd. Ik had strategy en operating _mode door elkaar gehaald en probeerde de strategy met operating mode te kiezen. De HA entiteit had dus geen aan/uit als mogelijkheden maat minimize cost/minimize consumption.

[thesaxofonist]

Ik wil dat mijn DC-gekoppelde batterij overdag alleen zonne-energie gaat laden, dus niet vanaf het net. Maar 's nachts mag hij wel vanaf het net laden. Ik meende dat op te lossen door 'reduced hours' toe te voegen onder de charge-stages. Ik hoopte dat ik daarmee het laden overdag (vanuit het net) kon tegenhouden. Maar dat werkt helaas niet. Heeft iemand nog een idee?

Is het mogelijk om 'reduced hours' alleen te gebruiken voor laden (en niet voor ontladen)? Ik kreeg dat niet werkend.

[ Voor 13% gewijzigd door thesaxofonist op 27-09-2026 19:23 ]

[oscaarbasgitaar]

@KC27
Intussen al wat verder gevorderd.
Ingeven PV, boiler en warmtepomp lijken gelukt te zijn.
Voorlopig doe ik er enkel enkele dagen testruns mee, gewoon om enkele dagen te kijken welke stuursignalen eruit komen. Pas wanneer ik het helemaal vertrouw gaan we er ook actief mee aan de slag gaan :-)
(Ik ben geen computerspecialist, maar ben beroepshalve wel met slimme sturing van energie bezig. Ik heb al teveel commerciële EMS-en gezien die bullshit beslissingen nemen.)

Waar ik nu mee zit: ik heb een hybride Solis-omvormer en een pylontech thuisbatterij.
Via de omvormer is er een "AI"-EMS die de batterij aanstuurt op basis van historisch verbruiksprofiel, Epex en weersvoorspelling.
En, die doet dat goed eigenlijk, en ik volg het principe if it aint broke, don't try to fix it...
zie hieronder: eerst injecteren tegen fatsoenlijk injectietarief, daarna batterij laden, als de batterij vol zit omvormervermogen curtailen, bij lage prijzen batterij SOC reserveren voor latere hogere prijzen,...


Mijn warmtepomp (Ecoforest) heeft in principe via epex ook een sturing.
Maar die draait helemaal niet stabiel (haalt soms geen epex-prijzen binnen) schakelt soms op een verkeerd tijdstip,...
De piek van ca. 45 minuten rond 17 uur is de warmtepomp die inschakelt: ze heeft 3 nuttige uren niets gedaan, en net wanneer de prijs begint te stijgen schiet ze aan?

Ik gebruik jouw Add-on dus in eerste instantie daarvoor.

Op zich lijkt het me ook niet verkeerd: in zelfconsumptie / lage DA-prijzen is voor mij de beslissingsboom als volgt:
Overschot PV -> eerst warmte maken -> daarna kleine verschuifbare lasten inschakelen (wasmachine / vaatwas) -> pas als laatste thuisbatterij i.f.v. de baseload.

Een laadpaal is er nog niet, die zou afhankelijk van de SOC voor of na de warmtepomp moeten komen.

En dus nu mijn vraag:
wat lijkt jou de beste keuze de batterij toch meenemen in de DAO berekening, en eventueel niet mee sturen of die buiten DAO en de berekening houden en ze dus echt houden voor de baseload?

[Knielen]

@oscaarbasgitaar Als ik zou was zou ik toch nog eens overwegen om alles door DAO aan te laten sturen, iets met 2 kapiteins op 1 schip. Als je omvormer geen weet heeft van wat er verder in huis gebeurd zal het nooit optimaal gaan werken en dus ook geen rekening houden met dat mooie prioriteitenlijstje wat je in je bericht zet.

[oscaarbasgitaar]

@Knielen Da's exact waarom ik de vraag stel.

Wat ik hoop dat DAO zou kunnen zijn is de "CEO" die de grootste beslissingen (warmte & in de toekomst laadpaal) neemt. En dan Solis als lager kader medewerker die op zich niet meer hoeft te weten waarom en op wat dit gebruik gebaseerd is, maar enkel nog de baseload voor zijn rekening neemt. Die zal op termijn -denk ik- toch wel zien dat het grootste verbruik al verschoven is naar de goedkopere uren.

Wat ik zeker niet wil is 1kWh van het net kopen om in een batterij op te slaan om er later warmte mee te maken. Want voor elke kWh die in de batterij gaat komt er ongeveer maar 0,75kWh terug uit en die heeft ook een batterijkost van ca. 7c€/kWh (aankoopkost batterij / (laadcycli x capaciteit)).

[KC27]

oscaarbasgitaar schreef op maandag 28 september 2026 @ 09:19:
@Knielen Da's exact waarom ik de vraag stel.

Wat ik hoop dat DAO zou kunnen zijn is de "CEO" die de grootste beslissingen (warmte & in de toekomst laadpaal) neemt. En dan Solis als lager kader medewerker die op zich niet meer hoeft te weten waarom en op wat dit gebruik gebaseerd is, maar enkel nog de baseload voor zijn rekening neemt. Die zal op termijn -denk ik- toch wel zien dat het grootste verbruik al verschoven is naar de goedkopere uren.

Wat ik zeker niet wil is 1kWh van het net kopen om in een batterij op te slaan om er later warmte mee te maken. Want voor elke kWh die in de batterij gaat komt er ongeveer maar 0,75kWh terug uit en die heeft ook een batterijkost van ca. 7c€/kWh (aankoopkost batterij / (laadcycli x capaciteit)).

Als je je batterij goed configureert in DAO (met de juiste efficiencies en eventueel cyclecost) zal DAO de batterij alleen inzetten als het volgens jou regels rendabel is.
De door jou genoemde batterijkost lijkt me hoog gekozen.
Je kunt ook redeneren (zoals ik): die kosten heb ik gehad en ik ga proberen om deze zo snel mogelijk terug te verdienen. Je verdient niks terug als je batterij stil staat omdat hij maar 6 c€/kWh terugverdient.
Om die reden heb ik de cyclecost op 1 c€/kWh gezet.

[Voogel]

@KC27 het lijkt er op dat de "entity adjust heating curve" blijft staan op de laatste waarde wanneer de warmtepomp eerst wel en later niet meer nodig is volgens DAO, klopt dat en is dat bewust? Zou het niet handiger zijn om deze naar 0 te zetten wanneer er geen warmtepomp inzet nodig is?

[oscaarbasgitaar]

Ik heb besloten om de batterij wel in te geven en voorlopig de signalen die ik krijg niet te gebruiken, maar te vergelijken met wat de batterij door de sturing via de solis-EMS doet.
In principe zou dit relatief gelijk moeten lopen.
Als dat niet zo is ga'k eerst de analyse maken hoe dit komt en of ik de batterij alsnog aanstuur vanuit DAO of ze helemaal uit de berekening hier haal. Dit is, denk ik, ook wel een leuke benchmark voor zowel de solis-EMS als de DAO.

In de solis EMS geef ik de batterijkost 8c€/kWh, dus doe ik het hier ook.
Meningen zijn daarover verdeeld: enerzijds heb je de kost inderdaad al gemaakt, anderzijds is elk gebruik van de batterij wel oorzaak van het dalen van het aantal bruikbare cycli.
Bovendien wijzen studies uit dat intensief met wisselende vermogens inzetten van een batterij een negatieve invloed heeft op de levensduur van de batterij: ik wil ze dus uiteraard wel gebruiken, maar bewust. Anderzijds is een batterij in de winter lang ongebruikt laten staan dan óók weer niet goed. @KC27 het zou daarom wel een leuke extra feature zijn om dus toe te voegen om de hoeveel dagen je als user wilt dat je batterij een helemaal op en af gaat: dit kan ik namelijk bij de solis EMS ook ingeven. Maar dat bemoeilijkt de oefening wel heel wat aangezien je niet enkel 1,5 dag vooruit moet kijken...

Ik heb momenteel ook een integratie lopen die me voorspelling van benodigde warmte voor de komende dagen geeft. Op termijn wil ik daarmee misschien via flex setting de degree days factor aanpassen. Het doel is om uiteindelijk de thermische massa van ons huis als buffer voor warmte te gaan gebruiken: bij aangekondigde koudegolven gaat doorgaands ook de prijs van stroom omhoog. Als ik dan op voorhand aan lagere prijzen het setpunt kan verhogen van 20,5 naar bv 21,5, dan heb ik ook minder warmte nodig op die dure momenten.

Voorlopig staat de WP nog op false omdat ik nog geen gemeten geleverde warmte heb en DAO geen weg kan met die null-waarde.

Nog enkele vragen / opmerkingen :
Ik heb bij de report enkel de WP ingegeven en niet de boiler, omdat de boiler ook de WP is.
Aangezien dit in de boilersettings ook zo moest aangeduid worden, klopt dit?

Koeling is voorlopig niet inbegrepen: nu is dat voor mij niet zo'n dingetje aangezien we geothermisch passief kunnen koelen, maar met afgelopen zomer in het achterhoofd waarop de prijzen soms heel hard de pan uit vlogen, kan het misschien ook wel een leuke extra feature worden.


En dus mijn settings:

code:

{
  "config_version": 2,
  "homeassistant": {},
  "database ha": {
    "engine": "mysql",
    "port": 3306,
    "database": "homeassistant",
    "username": "homeassistant",
    "password": "!secret db_ha_password"
  },
  "database da": {
    "engine" : "mysql",
    "database": "day_ahead",
    "username": "day_ahead",
    "password": "!secret db_da_password"
},
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "energy_taxes_consumption": {
      "2025-01-01": 0.1212
    },
    "energy_taxes_production": {
      "2025-01-01": -0.015
    },
    "cost_supplier_consumption": {
      "2025-01-01": 0.0
    },
    "cost_supplier_production": {
      "2025-01-01": 0.0
    },
    "vat_consumption": {
      "2025-01-01": 6.0
    },
    "vat_production": {
      "2025-01-01": 0.0
    },
    "multiplier_consumption": {
      "2025-01-01": 1.02
    },
    "multiplier_production": {
      "2025-01-01": 0.98
    },
    "last_invoice": "2026-09-01",
    "tax_refund": true,
    "regular high": 0.3,
    "regular low": 0.3,
    "switch to low": 23
  },
  "logging_level": "info",
  "use_calc_baseload": false,
  "baseload_calc_periode": 56,
  "baseload": [
    0.25,
    0.20,
    0.16,
    0.16,
    0.16,
    0.16,
    0.16,
    0.3,
    0.36,
    0.36,
    0.4,
    0.4,
    0.4,
    0.4,
    0.4,
    0.4,
    0.4,
    0.5,
    0.6,
    0.7,
    0.7,
    0.4,
    0.4,
    0.3
  ],
  "graphical_backend": "",
  "graphics": {
    "style": "bmh",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": true,
    "prices_spot": false,
    "average_consumption": true,
    "show": "true"
  },
  "interval": "15min",
  "strategy": "minimize cost",
  "max_gap": 0.005,
  "notifications": {
    "opstarten": false,
    "berekening": false
  },
  "grid": {
    "max_power": 11.0
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "Pylontech",
      "entity actual level": "sensor.solis_inverter_110c72228250003_solis_remaining_battery_capacity",
      "capacity": 6.75,
      "upper limit": 100,
      "lower limit": 20,
      "optimal_lower_level": 15,
      "penalty_low_soc": 0.0025,
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 250.0,
          "efficiency": 0.85
        },
        {
          "power": 500.0,
          "efficiency": 0.88
        },
        {
          "power": 750.0,
          "efficiency": 0.90
        },
        {
          "power": 1000.0,
          "efficiency": 0.91
        },
        {
          "power": 1500.0,
          "efficiency": 0.965
        },
        {
          "power": 2000.0,
          "efficiency": 0.92
        },
        {
          "power": 2500.0,
          "efficiency": 0.93
        },
        {
          "power": 3300.0,
          "efficiency": 0.94
        }
      ],
      "discharge_stages": [
        {
          "power": 0.0,
          "efficiency": 1.0
        },
        {
          "power": 250.0,
          "efficiency": 0.82
        },
        {
          "power": 500.0,
          "efficiency": 0.86
        },
        {
          "power": 750.0,
          "efficiency": 0.88
        },
        {
          "power": 1000.0,
          "efficiency": 0.90
        },
        {
          "power": 1500.0,
          "efficiency": 0.92
        },
        {
          "power": 2000.0,
          "efficiency": 0.92
        },
        {
          "power": 2500.0,
          "efficiency": 0.93
        },
        {
          "power": 3300.0,
          "efficiency": 0.94
        }
      ],
      "dc_to_bat efficiency": 0.94,
      "dc_to_bat max power": 3500,
      "bat_to_dc efficiency": 0.94,
      "bat_to_dc max power": 3500,
      "cycle cost": 0.08,
      "entity_set_power_feedin": "input_number.dao_batt_feed_in",
      "entity_set_operating_mode": "input_select.dao_batt_operating_mode",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "entity_stop_inverter": "input_datetime.dao_batt_stop_inverter",
      "entity_from_battery": "input_number.dao_batt_from_battery",
      "entity_from_pv": "input_number.dao_batt_from_pv",
      "entity_from_ac": "input_number.dao_batt_from_ac",
      "entity_calculated_soc": "input_number.dao_batt_soc",
      "entity_balance_switch": "input_boolean.dao_batt_balance_switch",
      "solar": [
      {
          "name": "PV panelen",
          "entity_pv_switch": "input_boolean.dao_pv_switch",
          "ml_prediction": false,
          "ml_training_start_date": "2000-01-01",
          "entities_sensors": [
           "sensor.netto_pv"
          ],
          "max power": 5.5,
          "strings": [
            {
              "tilt": 11,
              "orientation": -45,
              "capacity": 3.32,
              "yield": 0.0076
            },
            {
              "tilt": 11,
              "orientation": 45,
              "capacity": 3.32,
              "yield": 0.0076
            }
         ]
       }
     ]
    }
  ],
  "solar": [],
  "electric_vehicle": [],
  "machines": [],
  "boiler": {
    "boiler_present": true,
    "boiler heated by heatpump": true,
    "entity actual temp.": "sensor.utility_room_ecogeo_1_6_kw_ww_temperature",
    "entity setpoint": "sensor.utility_room_ecogeo_1_6_kw_ww_temperature_configured",
    "entity hysterese": "input_number.delta_t_ww",
    "cop": 2.65,
    "cooling rate": 0.25,
    "volume": 300,
    "heating allowed below": 50.5,
    "elec. power": 2000,
    "activate service": "turn_on",
    "activate entity": "input_boolean.dao_ww"
  },
  "heating": {
    "heater present": false,
    "entity hp enabled": "binary_sensor.utility_room_ecogeo_1_6_kw_current_heating_pump_state",
    "entity hp heat demand": "binary_sensor.utility_room_ecogeo_1_6_kw_direct_outlet_dg1",
    "entity hp heat produced": "sensor.geleverde_warmte_vandaag",
    "adjustment": "heating curve",
    "degree days factor": 7.9,
    "stages": [
    { "max_power": 210,  "cop": 2.8 },
    { "max_power": 400,  "cop": 3.3 },
    { "max_power": 700,  "cop": 4.1 },
    { "max_power": 1100, "cop": 4.0 },
    { "max_power": 1600, "cop": 3.8 },
    { "max_power": 2000, "cop": 3.4 }
    ],
  "entity hp power": "input_number.dao_wp_vermogen",
  "entity adjust heating curve": "input_number.dao_stooklijn",
  "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_energie_import"],
    "entities grid production": ["sensor.p1_meter_energie_export"],
    "entities solar production ac": [],
    "entities solar production dc": ["sensor.solis_inverter_110c72228250003_solis_energy_total"],
    "entities ev consumption": [],
    "entities wp consumption": ["sensor.energy_socket_energy_import"],
    "entities boiler consumption": [],
    "entities machine consumption": [],
    "entities battery consumption": ["sensor.solis_inverter_110c72228250003_solis_total_energy_charged"],
    "entities battery production": ["sensor.solis_inverter_110c72228250003_solis_total_energy_discharged"]
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "0125",
        "action": "get_meteo_data"
      },
      {
        "time": "0425",
        "action": "get_meteo_data"
      },
      {
        "time": "0725",
        "action": "get_meteo_data"
      },
      {
        "time": "1025",
        "action": "get_meteo_data"
      },
      {
        "time": "1325",
        "action": "get_meteo_data"
      },
      {
        "time": "1625",
        "action": "get_meteo_data"
      },
      {
        "time": "1925",
        "action": "get_meteo_data"
      },
      {
        "time": "2225",
        "action": "get_meteo_data"
      },
      {
        "time": "1255",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1325",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1355",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1425",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1455",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1525",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "xx58",
        "action": "calc_optimum"
      },
      {
        "time": "xx13",
        "action": "calc_optimum"
      },
      {
        "time": "xx28",
        "action": "calc_optimum"
      },
      {
        "time": "xx43",
        "action": "calc_optimum"
      },
      {
        "time": "2350",
        "action": "clean_data"
      }
    ]
  },
  "meteoserver_attempts": 2
}

[rescla]

Voor het geval iemand nog twijfelde of DAO meerdere cycli per dag aan kon: Is overigens de eerste keer sinds tijden dat ik laad en ontlaad zie in de ochtend.

[ErnstH]

Hier is DAO inderdaad ook druk bezig de komende +/- 36 uur!

[Beekforel]

Is dat dan omdat jullie accu sneller kan laden/ontladen oid? Bij mij maar minimale activiteiten op de accu.

[rescla]

Beekforel schreef op dinsdag 29 september 2026 @ 16:01:
Is dat dan omdat jullie accu sneller kan laden/ontladen oid? Bij mij maar minimale activiteiten op de accu.

Kan je efficiëntie of afschrijving zijn denk ik, capaciteit en laadsnelheid zou niet uit moeten maken. Heb je je config al een keer gepost (in een quote)?

[edterbak]

Wat is nu de geadviseerde route om met DAO meerdere batterijen aan te sturen?

1 - Moet ik DAO voeden met 1 virtuele batterij met alle gegevens.
2 - Moet ik DAO voeden met 3 separate batterijen en de werkelijke informatie per batterij.

Ik hang nog een beetje omhoog met deze vraag. Ik heb wat sturing nodig. Advies.

Optie 1, dan moet ik de output van DAO verwerken en zelf daarop de batterij aansturen.
Optie 2, dan is DAO zelf in control over iedere batterij.

Het scenario dat ik heb is dat ik 2 verschillende batterijen heb. 1 venus A en 2x venus E, allen een eigen fase..

Gr.

[Beekforel]

rescla schreef op dinsdag 29 september 2026 @ 18:10:
[...]

Kan je efficiëntie of afschrijving zijn denk ik, capaciteit en laadsnelheid zou niet uit moeten maken. Heb je je config al een keer gepost (in een quote)?

Eerder wel eens maar ook wel weer eens wat aan veranderd. Achter de battery zitten 3 Marstek Venus A batterijen die ik via Home Assistant als 1 heb gemaakt. De aansturing werkt vlekkeloos.

JSON:

{
  "config_version": 2,
  "homeassistant": {
    "ip_address": "supervisor",
    "protocol_api": "http"
  },
  "database_ha": {
    "engine": "sqlite",
    "db_path": "/homeassistant",
    "database": "home-assistant_v2.db"
  },
  "database_da": {
    "engine": "sqlite",
    "db_path": "../data",
    "database": "day_ahead.db"
  },
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "energy_taxes_consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161
    },
    "energy_taxes_production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161,
      "2027-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.01653,
      "2026-04-29": 0.0205
    },
    "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.01653,
      "2026-04-29": -0.0205
    },
    "vat_consumption": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0
    },
    "vat_production": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0
    },
    "multiplier_consumption": {
      "2000-01-01": 1.0
    },
    "multiplier_production": {
      "2000-01-01": 1.0
    },
    "last_invoice": "2026-08-07",
    "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": 28,
  "baseload": [
    0.223, 0.264, 0.471, 0.606, 0.566, 0.442, 0.307, 0.417, 0.515, 0.707, 0.687,
    0.902, 1.192, 1.18, 1.16, 1.094, 0.906, 1.085, 0.562, 0.29, 0.119, 0.188,
    0.27, 0.293
  ],
  "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.03,
  "notifications": {
    "notification_entity": "input_text.dao_notification",
    "opstarten": false,
    "berekening": false,
    "last_activity_entity": "input_datetime.dao_last_activity"
  },
  "grid": {
    "max_power": 17.0,
    "entity_balance_switch": "input_boolean.dao_battery_balance_mode"
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "Marstek",
      "entity_actual_level": "sensor.dao_battery_soc_combined",
      "capacity": 12.4,
      "upper_limit": 100,
      "lower_limit": 11,
      "penalty_low_soc": 0.0025,

      "charge_stages": [
        { "power": 0.0, "efficiency": 1.0 },
        { "power": 200.0, "efficiency": 0.9 },
        { "power": 2250.0, "efficiency": 0.97 },
        { "power": 4500.0, "efficiency": 0.95 }
      ],

      "discharge_stages": [
        { "power": 0.0, "efficiency": 1.0 },
        { "power": 200.0, "efficiency": 0.9 },
        { "power": 2250.0, "efficiency": 0.97 },
        { "power": 4500.0, "efficiency": 0.95 }
      ],

      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],

      "minimum_power": 200,

      "dc_to_bat_efficiency": 0.95,
      "bat_to_dc_efficiency": 0.95,

      "cycle_cost": 0.05,

      "entity_set_power_feedin": "input_number.dao_battery_power_feedin",
      "entity_set_operating_mode": "input_select.dao_battery_operating_mode",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "entity_stop_inverter": "input_datetime.dao_battery_stop",

      "solar": []
    }
  ],
  "solar": [
    {
      "name": "growatt1",
      "entity_pv_switch": "switch.growatt1_inverter_enable",
      "tilt": 55.0,
      "orientation": -30.0,
      "capacity": 4.34,
      "yield_factor": 0.0102175,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": ["sensor.growatt1_total_energy_production"],
      "max_power": 3.6
    },
    {
      "name": "growatt2",
      "entity_pv_switch": "switch.growatt2_inverter_enable",
      "tilt": 55.0,
      "orientation": -30.0,
      "capacity": 6.885,
      "yield_factor": 0.016305,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": ["sensor.growatt2_total_energy_production"],
      "max_power": 6.0
    }
  ],
  "machines": [
    {
      "name": "ariston_boost",
      "programs": [
        {
          "name": "off",
          "power": []
        },
        {
          "name": "boost-1",
          "power": [1300.0, 1300.0, 1300.0, 1300.0]
        },
        {
          "name": "boost-2",
          "power": [
            1300.0, 1300.0, 1300.0, 1300.0, 1300.0, 1300.0, 1300.0, 1300.0
          ]
        }
      ],
      "entity_start_window": "input_datetime.dao_ariston_boost_start_window",
      "entity_end_window": "input_datetime.dao_ariston_boost_end_window",
      "entity_selected_program": "input_select.dao_ariston_boost_selected_program",
      "entity_calculated_start": "input_datetime.dao_ariston_boost_calculated_start",
      "entity_calculated_end": "input_datetime.dao_ariston_boost_calculated_end"
    }
  ],
  "boiler": {
    "boiler_present": false,
    "entity_actual_temp.": "sensor.ariston_temperatuur",
    "entity_setpoint": "input_number.dao_boiler_setpoint",
    "entity_hysterese": "input_number.dao_boiler_hysterese",
    "cop": 1.9,
    "cooling_rate": 0.4,
    "volume": 100,
    "heating_allowed_below": 44,
    "elec._power": 190,
    "boiler_heated_by_heatpump": true,
    "activate_service": "press",
    "activate_entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater_present": true,
    "degree_days_factor": "sensor.dao_degree_days_factor",
    "adjustment": "heating curve",
    "stages": [
      {
        "max_power": 0.0,
        "cop": 8.0
      },
      {
        "max_power": 300.0,
        "cop": 5.5
      },
      {
        "max_power": 500.0,
        "cop": 4.8
      },
      {
        "max_power": 700.0,
        "cop": 4.2
      },
      {
        "max_power": 900.0,
        "cop": 3.8
      },
      {
        "max_power": 1100.0,
        "cop": 3.4
      },
      {
        "max_power": 1400.0,
        "cop": 3.0
      }
    ],
    "entity_adjust_heating_curve": "input_number.dao_heating_curve_adjustment",
    "adjustment_factor": 0.1,
    "min_run_length": 1,
    "entity_hp_cop": "sensor.aquarea_cop",
    "entity_hp_heat_produced": "sensor.aquarea_heatpump_dao_panasonic_heat_power_produced_today"
  },
  "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.verbruik_totaal"],
    "entities_grid_production": ["sensor.productie_totaal"],
    "entities_solar_production_ac": [
      "sensor.growatt1_total_energy_production_persistent",
      "sensor.growatt2_total_energy_production_persistent"
    ],
    "entities_solar_production_dc": [],
    "entities_ev_consumption": ["sensor.smartevse_8876_evtotalenergycharged"],
    "entities_wp_consumption": [
      "sensor.panasonic_heat_pump_s0_watthourtotal_1",
      "sensor.panasonic_heat_pump_s0_watthourtotal_2"
    ],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.marstek_m2_lifetime_charging_energy",
      "sensor.marstek_m3_lifetime_charging_energy"
    ],
    "entities_battery_production": [
      "sensor.marstek_m2_lifetime_discharging_energy",
      "sensor.marstek_m3_lifetime_discharging_energy"
    ],
    "entities_machine_consumption": ["sensor.boiler_energy_corrected"]
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "0430",
        "action": "get_meteo_data"
      },
      {
        "time": "1030",
        "action": "get_meteo_data"
      },
      {
        "time": "0935",
        "action": "calc_baseloads"
      },
      {
        "time": "1630",
        "action": "get_meteo_data"
      },
      {
        "time": "2230",
        "action": "get_meteo_data"
      },
      {
        "time": "1305",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1310",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1400",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1555",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1655",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "xx00",
        "action": "calc_optimum"
      },
      {
        "time": "xx15",
        "action": "calc_optimum"
      },
      {
        "time": "xx30",
        "action": "calc_optimum"
      },
      {
        "time": "xx45",
        "action": "calc_optimum"
      },
      {
        "time": "2350",
        "action": "train_ml_predictions"
      },
      {
        "time": "2359",
        "action": "clean_data"
      }
    ]
  },
  "meteoserver_attempts": 2
}

Ik heb electric_vehicle er even uit gehaald, anders is het teveel karakters voor GoT.

[pimNH]

Beekforel schreef op dinsdag 29 september 2026 @ 20:34:
[...]

Eerder wel eens maar ook wel weer eens wat aan veranderd. Achter de battery zitten 3 Marstek Venus A batterijen die ik via Home Assistant als 1 heb gemaakt. De aansturing werkt vlekkeloos.

[...]


Ik heb electric_vehicle er even uit gehaald, anders is het teveel karakters voor GoT.

Ik heb het als volgt gedaan met twee marsteks:

{

"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": {

"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": "2022-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.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.6,

0.3,

0.3,

0.3,

0.3,

0.14,

0.14

],

"graphical_backend": "",

"graphics": {

"style": "default",

"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": 17.0,

"entity_balance_switch": "input_boolean.DAO_Bat_balance"

},

"history": {

"save_days": 7

},

"dashboard": {

"port": 5000

},

"battery": [

{

"name": "Marstek 1",

"entity_actual_level": "sensor.marstek1_battery_soc",

"capacity": 5,

"upper_limit": 100,

"lower_limit": 10,

"optimal_lower_level": 12,

"penalty_low_soc": 0.0025,

"charge stages": [

{

"power": 0.0,

"efficiency": 1

},

{

"power": 100,

"efficiency": 0.1089

},

{

"power": 200,

"efficiency": 0.5377

},

{

"power": 300,

"efficiency": 0.7095

},

{

"power": 400,

"efficiency": 0.7789

},

{

"power": 500,

"efficiency": 0.8273

},

{

"power": 600,

"efficiency": 0.8576

},

{

"power": 700,

"efficiency": 0.878

},

{

"power": 800,

"efficiency": 0.8921

},

{

"power": 900,

"efficiency": 0.9041

},

{

"power": 1000,

"efficiency": 0.9137

},

{

"power": 1100,

"efficiency": 0.9197

},

{

"power": 1200,

"efficiency": 0.9256

},

{

"power": 1300,

"efficiency": 0.9298

},

{

"power": 1400,

"efficiency": 0.9341

},

{

"power": 1500,

"efficiency": 0.9365

},

{

"power": 1600,

"efficiency": 0.9404

},

{

"power": 1700,

"efficiency": 0.9416

},

{

"power": 1800,

"efficiency": 0.9431

},

{

"power": 1900,

"efficiency": 0.9440

},

{

"power": 2000,

"efficiency": 0.9453

},

{

"power": 2100,

"efficiency": 0.9460

},

{

"power": 2200,

"efficiency": 0.9471

},

{

"power": 2300,

"efficiency": 0.9485

},

{

"power": 2400,

"efficiency": 0.9490

},

{

"power": 2500,

"efficiency": 0.9485

}

],

"discharge stages": [

{

"power": 0.0,

"efficiency": 1

},

{

"power": 100,

"efficiency": 0.5053

},

{

"power": 200,

"efficiency": 0.644

},

{

"power": 300,

"efficiency": 0.7146

},

{

"power": 400,

"efficiency": 0.7581

},

{

"power": 500,

"efficiency": 0.7855

},

{

"power": 600,

"efficiency": 0.8048

},

{

"power": 700,

"efficiency": 0.8181

},

{

"power": 800,

"efficiency": 0.8276

},

{

"power": 900,

"efficiency": 0.8352

},

{

"power": 1000,

"efficiency": 0.8414

},

{

"power": 1100,

"efficiency": 0.8450

},

{

"power": 1200,

"efficiency": 0.8482

},

{

"power": 1300,

"efficiency": 0.8510

},

{

"power": 1400,

"efficiency": 0.8522

},

{

"power": 1500,

"efficiency": 0.8533

},

{

"power": 1600,

"efficiency": 0.8552

},

{

"power": 1700,

"efficiency": 0.8556

},

{

"power": 1800,

"efficiency": 0.8554

},

{

"power": 1900,

"efficiency": 0.8547

},

{

"power": 2000,

"efficiency": 0.8540

},

{

"power": 2100,

"efficiency": 0.8543

},

{

"power": 2200,

"efficiency": 0.8543

},

{

"power": 2300,

"efficiency": 0.8552

},

{

"power": 2400,

"efficiency": 0.8555

},

{

"power": 2500,

"efficiency": 0.8553

}

],

"minimum_power": 100,

"dc_to_bat_efficiency": 1.0,

"bat_to_dc_efficiency": 1.0,

"cycle_cost": 0.02,

"entity_set_power_feedin": "input_number.DAO_Bat_pwr",

"entity_set_operating_mode": "input_select.DAO_Bat_opmode",

"entity_set_operating_mode_on": "Aan",

"entity_set_operating_mode_off": "Uit",

"solar": []

},

{

"name": "Marstek 2",

"entity_actual_level": "sensor.marstek2_battery_soc",

"capacity": 5,

"upper_limit": 100,

"lower_limit": 10,

"optimal_lower_level": 12,

"penalty_low_soc": 0.0025,

"charge stages": [

{

"power": 0.0,

"efficiency": 1

},

{

"power": 100,

"efficiency": 0.1089

},

{

"power": 200,

"efficiency": 0.5377

},

{

"power": 300,

"efficiency": 0.7095

},

{

"power": 400,

"efficiency": 0.7789

},

{

"power": 500,

"efficiency": 0.8273

},

{

"power": 600,

"efficiency": 0.8576

},

{

"power": 700,

"efficiency": 0.878

},

{

"power": 800,

"efficiency": 0.8921

},

{

"power": 900,

"efficiency": 0.9041

},

{

"power": 1000,

"efficiency": 0.9137

},

{

"power": 1100,

"efficiency": 0.9197

},

{

"power": 1200,

"efficiency": 0.9256

},

{

"power": 1300,

"efficiency": 0.9298

},

{

"power": 1400,

"efficiency": 0.9341

},

{

"power": 1500,

"efficiency": 0.9365

},

{

"power": 1600,

"efficiency": 0.9404

},

{

"power": 1700,

"efficiency": 0.9416

},

{

"power": 1800,

"efficiency": 0.9431

},

{

"power": 1900,

"efficiency": 0.9440

},

{

"power": 2000,

"efficiency": 0.9453

},

{

"power": 2100,

"efficiency": 0.9460

},

{

"power": 2200,

"efficiency": 0.9471

},

{

"power": 2300,

"efficiency": 0.9485

},

{

"power": 2400,

"efficiency": 0.9490

},

{

"power": 2500,

"efficiency": 0.9485

}

],

"discharge stages": [

{

"power": 0.0,

"efficiency": 1

},

{

"power": 100,

"efficiency": 0.5053

},

{

"power": 200,

"efficiency": 0.644

},

{

"power": 300,

"efficiency": 0.7146

},

{

"power": 400,

"efficiency": 0.7581

},

{

"power": 500,

"efficiency": 0.7855

},

{

"power": 600,

"efficiency": 0.8048

},

{

"power": 700,

"efficiency": 0.8181

},

{

"power": 800,

"efficiency": 0.8276

},

{

"power": 900,

"efficiency": 0.8352

},

{

"power": 1000,

"efficiency": 0.8414

},

{

"power": 1100,

"efficiency": 0.8450

},

{

"power": 1200,

"efficiency": 0.8482

},

{

"power": 1300,

"efficiency": 0.8510

},

{

"power": 1400,

"efficiency": 0.8522

},

{

"power": 1500,

"efficiency": 0.8533

},

{

"power": 1600,

"efficiency": 0.8552

},

{

"power": 1700,

"efficiency": 0.8556

},

{

"power": 1800,

"efficiency": 0.8554

},

{

"power": 1900,

"efficiency": 0.8547

},

{

"power": 2000,

"efficiency": 0.8540

},

{

"power": 2100,

"efficiency": 0.8543

},

{

"power": 2200,

"efficiency": 0.8543

},

{

"power": 2300,

"efficiency": 0.8552

},

{

"power": 2400,

"efficiency": 0.8555

},

{

"power": 2500,

"efficiency": 0.8553

}

],

"minimum_power": 100,

"dc_to_bat_efficiency": 1.0,

"bat_to_dc_efficiency": 1.0,

"cycle_cost": 0.02,

"entity_set_power_feedin": "input_number.DAO_Bat_pwr_2",

"entity_set_operating_mode": "input_select.DAO_Bat_opmode_2",

"entity_set_operating_mode_on": "Aan",

"entity_set_operating_mode_off": "Uit",

"solar": []

}

],

"solar": [

{

"name": "achter",

"entity_pv_switch": "input_boolean.ZonnepanelenUit",

"tilt": 41.0,

"orientation": -65.0,

"capacity": 5.0,

"yield_factor": 0.01852,

"strings": [],

"ml_prediction": true,

"ml_training_start_date": "2000-01-01",

"entities_sensors": [

"sensor.sn_3020730749_pv_gen_meter"

]

}

],

"electric_vehicle": [],

"machines": [

{

"name": "vaatwasser",

"programs": [

{

"name": "auto",

"power": [

2.0,

2.0,

0.1,

0.1,

2.0,

0.14,

0.14,

0.14

]

},

{

"name": "Uit",

"power": []

}

],

"entity_start_window": "input_datetime.dao_vaatwasser_start_window",

"entity_end_window": "input_datetime.dao_vaatwasser_end_window",

"entity_selected_program": "input_select.dao_vaatwasser_programma",

"entity_calculated_start": "input_datetime.dao_vaatwasser_calculated_start",

"entity_calculated_end": "input_datetime.dao_vaatwasser_calculated_end"

},

{

"name": "Koelkast",

"programs": [

{

"name": "Kouder",

"power": [

1.55,

1.55,

1.45,

1.35,

1.35,

1.35,

1.25,

1.25,

1.25,

1.15,

1.15,

1.05,

1.05,

0.95,

0.85,

0.75

]

},

{

"name": "Uit",

"power": []

}

],

"entity_start_window": "input_datetime.dao_koelkast_start_window",

"entity_end_window": "input_datetime.dao_koelkast_end_window",

"entity_selected_program": "input_select.dao_koelkast_programma",

"entity_calculated_start": "input_datetime.dao_koelkast_calculated_start",

"entity_calculated_end": "input_datetime.dao_koelkast_calculated_end"

},

{

"name": "WPBoiler",

"programs": [

{

"name": "Aan",

"power": [

1.0,

1.1,

1.2

]

},

{

"name": "Uit",

"power": []

}

],

"entity_start_window": "input_datetime.dao_wpboiler_start_window",

"entity_end_window": "input_datetime.dao_wpboiler_end_window",

"entity_selected_program": "input_select.dao_wpboiler_programma",

"entity_calculated_start": "input_datetime.dao_wpboiler_calculated_start",

"entity_calculated_end": "input_datetime.dao_wpboiler_calculated_end"

}

],

"boiler": {

"boiler_present": false,

"entity actual temp.": "sensor.ecodan_heatpump_dhw_current_temp",

"entity setpoint": "sensor.ecodan_heatpump_dhw_setpoint_value",

"entity hysterese": 15,

"cop": 2.2,

"cooling rate": 0.2,

"volume": 200,

"heating allowed below": 45,

"elec. power": 1500,

"activate service": "turn_on",

"activate entity": "input_boolean.forcedhwhelper"

},

"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.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.sn_3020730749_pv_gen_meter"

],

"entities_solar_production_dc": [],

"entities_ev_consumption": [

"sensor.laadpunt_total_energy"

],

"entities_wp_consumption": [],

"entities_boiler_consumption": [],

"entities_battery_consumption": [

"sensor.marstek1_total_charging_energy"

],

"entities_battery_production": [

"sensor.marstek1_total_discharging_energy"

],

"entities_machine_consumption": []

},

"scheduler": {

"active": true,

"schedule": [

{

"time": "0432",

"action": "get_meteo_data"

},

{

"time": "1031",

"action": "get_meteo_data"

},

{

"time": "1633",

"action": "get_meteo_data"

},

{

"time": "2234",

"action": "get_meteo_data"

},

{

"time": "1256",

"action": "get_day_ahead_prices"

},

{

"time": "1340",

"action": "get_day_ahead_prices"

},

{

"time": "1455",

"action": "get_day_ahead_prices"

},

{

"time": "1554",

"action": "get_day_ahead_prices"

},

{

"time": "1655",

"action": "get_day_ahead_prices"

},

{

"time": "xx00",

"action": "calc_optimum"

},

{

"time": "xx15",

"action": "calc_optimum"

},

{

"time": "xx30",

"action": "calc_optimum"

},

{

"time": "xx45",

"action": "calc_optimum"

},

{

"time": "2352",

"action": "clean_data"

}

]

},

"meteoserver_attempts": 2

}

[rescla]

Beekforel schreef op dinsdag 29 september 2026 @ 20:34:
[...]

Eerder wel eens maar ook wel weer eens wat aan veranderd. Achter de battery zitten 3 Marstek Venus A batterijen die ik via Home Assistant als 1 heb gemaakt. De aansturing werkt vlekkeloos.

[...]


Ik heb electric_vehicle er even uit gehaald, anders is het teveel karakters voor GoT.

Het grootste verschil dat ik zie is dit:

code:

      "dc_to_bat_efficiency": 0.98,
      "bat_to_dc_efficiency": 0.98,
      "cycle_cost": 0.01,

Maar het is ook niet zo dat hij per-se die cycle MOET pakken natuurlijk. Als het met jouw instellingen niet fiscaal aantrekkelijk is kan hij hem gewoon skippen. In totaal is het voor de 2 cycli die er nu in staan 4.56 Euro winst, op ik denk in totaal zo rond de 60kWh. Dus zo veel levert het niet op.

[KC27]

Voogel schreef op dinsdag 29 september 2026 @ 10:28:
@KC27 het lijkt er op dat de "entity adjust heating curve" blijft staan op de laatste waarde wanneer de warmtepomp eerst wel en later niet meer nodig is volgens DAO, klopt dat en is dat bewust? Zou het niet handiger zijn om deze naar 0 te zetten wanneer er geen warmtepomp inzet nodig is?

Als je in DAO de wp uit zet (door "heater_present":false of via "entity_hp_enabled"). Dan verandert DAO niks meer aan de waarde in "entity adjust heating curve".
Als in de planning de wp "uit" gaat dan blijft DAO die waarde wel veranderen. Meestal zal de stooklijn dan omlaag gaan.

[Beekforel]

rescla schreef op dinsdag 29 september 2026 @ 22:25:
[...]

Het grootste verschil dat ik zie is dit:

code:

      "dc_to_bat_efficiency": 0.98,
      "bat_to_dc_efficiency": 0.98,
      "cycle_cost": 0.01,

Maar het is ook niet zo dat hij per-se die cycle MOET pakken natuurlijk. Als het met jouw instellingen niet fiscaal aantrekkelijk is kan hij hem gewoon skippen. In totaal is het voor de 2 cycli die er nu in staan 4.56 Euro winst, op ik denk in totaal zo rond de 60kWh. Dus zo veel levert het niet op.

Ja zo is het ook. Ben ook wel tevreden over hoe het nu werkt, maar altijd nieuwsgierig of het beter kan natuurlijk.

De meeste mensen met batterijen om mij heen hebben vooral focus op 0 import/export merk ik. De energiemaatschappij is evil en met 0 ben je het beste uit, toch?

[rescla]

Beekforel schreef op woensdag 30 september 2026 @ 10:11:
[...]

Ja zo is het ook. Ben ook wel tevreden over hoe het nu werkt, maar altijd nieuwsgierig of het beter kan natuurlijk.

De meeste mensen met batterijen om mij heen hebben vooral focus op 0 import/export merk ik. De energiemaatschappij is evil en met 0 ben je het beste uit, toch?

Mijn ouders ook. Op zich is het ook wel fijn om het gevoel van zelfstandigheid te hebben natuurlijk. En lang niet iedereen "snapt" elektra. Vanaf volgend jaar gaat het financiële verschil van NoM ten opzichte van kostenoptimalisatie ook omlaag, dus het is dan nog minder belangrijk dan nu Maar het betekent wel dat je in een gemiddelde Nederlandse winter de accu vrijwel niet gebruikt, dus dat is wel jammer. Zeker als er grote spread is qua kosten en je toch al niet je verbruik efficient verschuift.

[ErnstH]

Wij zijn sinds kort van het gas af, en de warmtepomp-boiler wordt nu ook door DAO aangestuurd (ipv simpelweg om 14.00h)! Ik had wel eerst nog een probleempje dat ik dacht dat hystereses een negatief getal moest zijn.. :)

Andere vraag: is er al een manier op de Zonneplan Zonnebonus correct te implementeren (dus niet via de "vlakke" multiplier)? Of komt er een optie om zelf DAO van prijsinformatie te voorzien, die je dan simpelweg zelf op elk mogelijke manier kan invullen?

[KVan]

rescla schreef op woensdag 30 september 2026 @ 10:16:
[...]

Mijn ouders ook. Op zich is het ook wel fijn om het gevoel van zelfstandigheid te hebben natuurlijk. En lang niet iedereen "snapt" elektra. Vanaf volgend jaar gaat het financiële verschil van NoM ten opzichte van kostenoptimalisatie ook omlaag, dus het is dan nog minder belangrijk dan nu Maar het betekent wel dat je in een gemiddelde Nederlandse winter de accu vrijwel niet gebruikt, dus dat is wel jammer. Zeker als er grote spread is qua kosten en je toch al niet je verbruik efficient verschuift.

In de winter ga je wel degelijk de accu vanuit het net opladen op de "goedkope" momenten (nog steeds relatief duur, maar wel minder duur dan in de avaond). S'avonds stuur je dan die stroom weer terug het net op als hij duur is net als in de zomer. Het voordeel zal enkel kleiner zijn omdat er geen zonnestroom bij zit

Volgend jaar wordt eea flink anders. Dan zal het lang niet zo vaak gunstig zijn om stroom terug te verkopen omdat de belasting niet goed gemaakt wordt, DAO stuurt in die periodes automatisch "0 op de meter" aan. Wanneer de prijsverschillen groot genoeg zijn (of je overschot zonnestroom hebt) gaat hij nog steeds terugleveren.

Ik ben mid augustus DAO gaan gebruiken met Zonneplan en heb ondertussen -90Eur kosten. Ik heb er een simulatie naast lopen die 0 op de meter simuleerd en dan zouden de 520 kWh die ik boven op mijn zonnepanelen nodig had mij 148Eur gekost hebben met een vast contract, een voordeel van 238Euro in anderhalve maand dus.

[rescla]

KVan schreef op woensdag 30 september 2026 @ 14:50:
[...]

In de winter ga je wel degelijk de accu vanuit het net opladen op de "goedkope" momenten (nog steeds relatief duur, maar wel minder duur dan in de avaond). S'avonds stuur je dan die stroom weer terug het net op als hij duur is net als in de zomer. Het voordeel zal enkel kleiner zijn omdat er geen zonnestroom bij zit

Volgend jaar wordt eea flink anders. Dan zal het lang niet zo vaak gunstig zijn om stroom terug te verkopen omdat de belasting niet goed gemaakt wordt, DAO stuurt in die periodes automatisch "0 op de meter" aan. Wanneer de prijsverschillen groot genoeg zijn (of je overschot zonnestroom hebt) gaat hij nog steeds terugleveren.

Ik ben mid augustus DAO gaan gebruiken met Zonneplan en heb ondertussen -90Eur kosten. Ik heb er een simulatie naast lopen die 0 op de meter simuleerd en dan zouden de 520 kWh die ik boven op mijn zonnepanelen nodig had mij 148Eur gekost hebben met een vast contract, een voordeel van 238Euro in anderhalve maand dus.

Ik bedoel dat als je een accu instelt op "zelfverbruik/NoM" dat je daar alleen wat aan hebt als je zonnepanelen daadwerkelijk meer produceren dan dat je verbruikt. Dus iedereen die nu blij is met accu's omdat ze dan "geen stroom gebruiken van het net", gebruikt z'n accu niet in de winter, tenzij ze de strategie aanpassen.

Als je de accu met DAO aanstuurt met minimize cost werkt het gewoon prima uiteraard

[KVan]

rescla schreef op woensdag 30 september 2026 @ 15:31:
[...]

Ik bedoel dat als je een accu instelt op "zelfverbruik/NoM" dat je daar alleen wat aan hebt als je zonnepanelen daadwerkelijk meer produceren dan dat je verbruikt. Dus iedereen die nu blij is met accu's omdat ze dan "geen stroom gebruiken van het net", gebruikt z'n accu niet in de winter, tenzij ze de strategie aanpassen.

Als je de accu met DAO aanstuurt met minimize cost werkt het gewoon prima uiteraard

Klopt,
Met een vast contract en nul op de meter (wat een Deye, maar vast zowat alle inverters) prima zelf kan bereik je het maximum dat met een vast conctract kan.
Met een dynamisch contract is 0 op de meter zoals de inverter dat doet zelfs een magere strategie want de accu/omvormer houd de meter op nul zodra de zonnepanelen minder stroom opwekken dan je verbruikt. Dat is meestal niet het duurste moment. I heb niet echt geprobeert hoe DAO hiermee omgaat maar ga er van uit dat hij de 0 op de meter periode naar het duurste stuk verschuift en de rest uit het net trekt (zolang je geen overschot zonnestroom hebt natuurlijk).
Verder vermoed ik dat DAO de batterij gaat opladen in de goedkoopste periode ook als je 0 op de meter strategie voert als er tekort aan zonnestroom is.

[hemertje]

hemertje schreef op woensdag 16 september 2026 @ 08:17:
Goedemorgen,

nav onderstaande berekening


[...]

Omdat er geen oplossing is wordt het beoogd verbruikt met de oplossing niet getoond?

Is het niet logischer om de beoorde verbruik (hoogste grafiek) en de andere normale grafieken te tonen met in de grafiek een melding 'Geen oplossing voor: minimize cost'

Dan weet je als gebruiker wat er aan de hand is ipv de meteo grafiek te tonen.

[Afbeelding]

kan iemand mij uitleggen waarom ik soms alleen de metedata zie?
en waarom dit voorkomt?

[rescla]

hemertje schreef op woensdag 30 september 2026 @ 21:22:
[...]


kan iemand mij uitleggen waarom ik soms alleen de metedata zie?
en waarom dit voorkomt?

Ik snap de vraag niet helemaal, maar de meteodata wordt getoond als dat er meteodata is opgehaald nadat de laatste optimaliseerberekening heeft gedraaid. In de config onder scheduler kan je zien wanneer dat zou moeten gebeuren. Dat je altijd de meteodata ziet als de berekening blijft falen voor lange periodes is daar een gevolg van.

[ErnstH]

hemertje schreef op woensdag 30 september 2026 @ 21:22:
[...]


kan iemand mij uitleggen waarom ik soms alleen de metedata zie?
en waarom dit voorkomt?

Hij laat gewoon het resultaat van de laatste actie zien.

[KVan]

hemertje schreef op woensdag 30 september 2026 @ 21:22:
[...]


kan iemand mij uitleggen waarom ik soms alleen de metedata zie?
en waarom dit voorkomt?

Je ziet het resultaat van de laatste actie, in dit geval meteo. Bovenaan staan pijltjes waarmee je ook eerdere tijdstippen door kan bladeren. - LOL, de server liep flink achter deze was al meermaals beantwoord.

[ Voor 9% gewijzigd door KVan op 01-10-2026 11:21 ]

[buiter]

Even een vraag.
Ik snap dat je DOA instelt en er verder niet naar omkijkt, maar wordt er ook gewerkt aan een iets gebruiksvriendelijkere/geilere interface?
Of ben ik de enige die gegenereerde grafieken als jpg een beetje primitief vindt?
Ook het configureren van DAO is toch niet helemaal anno 2026?
En nee, UI V2 is dat ook niet.

Misschien ben ik te kritisch, ik zou het namelijk zelf niet kunnen.
Of is juist de presentatie en interactie het lastigst te bouwen?

Omdat energiebeheer komend jaar veel belangrijker wordt heb ik ook nog wel een paar suggesties:
Elektrisch laden inplannen, opwarmen boiler uitstellen op basis van gedrag en zon, samenvatting van de dag in begrijpelijk taal, baseload op basis van historie en weerstation selecteren.

Update: Met AI een mockup laten maken

Suggestie van landingspagina:


Suggestie voor baseload:


En suggestie voor het inplannen van de auto:

[ Voor 42% gewijzigd door buiter op 01-10-2026 17:21 ]

[Koplopert]

Sinds een jaartje heb ik DAO in gebruik. Eerst om een virtuele batterij aan te sturen, sinds een week of twee stuurt-ie een echte aan. Ik ben er erg tevreden over!

Nu probeer The Ultimate DAO Graph te bouwen en loop tegen een issue aan.



Ik haal de prognoses en historie binnen via de API. Voor bat_in en bat_uit gaat dat prima. Voor de pv_ac krijg ik alleen de prognose te zien. Als ik de entitity attributes bekijk, dan zijn ook alleen de prognoses gevuld, alle waardes uit het verleden ('recorded') hebben de waarde 0. De stippellijn is de prognose van SolCast. Die weet niks over mijn historische waarden, dus dat blijft altijd een voorspelling, ook voor het verleden.

De juiste entity is ingevuld bij de report entities in de config en via het DAO dashboard krijg ik wel historische waardem te zien. Enig idee wat er mis kan zijn?

De rest call is: (niet wezenlijk anders dan van bat_in en bat_out)

code:

  - resource: http://192. ... :5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 300
    sensor:
      - name: DAO PV AC
        unique_id: dao_pv_ac
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

En verder (en ik heb het gevoel dat dit al eerder is langsgekomen), is het mogelijk 15-min data uit de api te halen ipv uurdata?

[ Voor 5% gewijzigd door Koplopert op 01-10-2026 13:33 ]

[Torch1969]

buiter schreef op donderdag 1 oktober 2026 @ 13:06:
Even een vraag.
Ik snap dat je DOA instelt en er verder niet naar omkijkt, maar wordt er ook gewerkt aan een iets gebruiksvriendelijkere/geilere interface?
Of ben ik de enige die gegenereerde grafieken als jpg een beetje primitief vindt?
Ook het configureren van DAO is toch niet helemaal anno 2026?
En nee, UI V2 is dat ook niet.

Misschien ben ik te kritisch, ik zou het namelijk zelf niet kunnen.
Of is juist de presentatie en interactie het lastigst te bouwen?

Omdat energiebeheer komend jaar veel belangrijker wordt heb ik ook nog wel een paar suggesties:
Elektrisch laden inplannen, opwarmen boiler uitstellen op basis van gedrag en zon, samenvatting van de dag in begrijpelijk taal, baseload op basis van historie en weerstation selecteren.

Update: Met AI een mockup laten maken

Suggestie van landingspagina:
[Afbeelding]

Suggestie voor baseload:
[Afbeelding]

En suggestie voor het inplannen van de auto:
[Afbeelding]

Hoi @buiter leuk dat je creatief meedenkt. De gui is duidelijk niet het belangrijkste aspect van DAO, dat is de uitmuntende functionaliteit onder de motorkap. Er zijn maar een paar ontwikkelaars betrokken en die stoppen hun vrije tijd en ziel en zaligheid hier voor ons in. Had je je dit gerealiseerd voordat je je bericht hier plaatste?

[Torch1969]

Koplopert schreef op donderdag 1 oktober 2026 @ 13:32:
Sinds een jaartje heb ik DAO in gebruik. Eerst om een virtuele batterij aan te sturen, sinds een week of twee stuurt-ie een echte aan. Ik ben er erg tevreden over!

Nu probeer The Ultimate DAO Graph te bouwen en loop tegen een issue aan.

[Afbeelding]

Ik haal de prognoses en historie binnen via de API. Voor bat_in en bat_uit gaat dat prima. Voor de pv_ac krijg ik alleen de prognose te zien. Als ik de entitity attributes bekijk, dan zijn ook alleen de prognoses gevuld, alle waardes uit het verleden ('recorded') hebben de waarde 0. De stippellijn is de prognose van SolCast. Die weet niks over mijn historische waarden, dus dat blijft altijd een voorspelling, ook voor het verleden.

De juiste entity is ingevuld bij de report entities in de config en via het DAO dashboard krijg ik wel historische waardem te zien. Enig idee wat er mis kan zijn?

De rest call is: (niet wezenlijk anders dan van bat_in en bat_out)

code:

  - resource: http://192. ... :5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 300
    sensor:
      - name: DAO PV AC
        unique_id: dao_pv_ac
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

En verder (en ik heb het gevoel dat dit al eerder is langsgekomen), is het mogelijk 15-min data uit de api te halen ipv uurdata?

Ik gebruik voor de historische data de historie van de (state van de) entiteit zelf waarin je de voorspelling opslaat. De state van die entiteit bevat de voorspelling van dat uur, en daarmee heb je de historie dus gewoon in HA zelf zitten. Zie de grijze balkjes in onderstaande grafiek. De rode zijn de voorspelling uit het data attribuut van de entiteit.

[Dogooder]

buiter schreef op donderdag 1 oktober 2026 @ 13:06:
Even een vraag.
Ik snap dat je DOA instelt en er verder niet naar omkijkt, maar wordt er ook gewerkt aan een iets gebruiksvriendelijkere/geilere interface?
Of ben ik de enige die gegenereerde grafieken als jpg een beetje primitief vindt?
Ook het configureren van DAO is toch niet helemaal anno 2026?
En nee, UI V2 is dat ook niet.

Misschien ben ik te kritisch, ik zou het namelijk zelf niet kunnen.
Of is juist de presentatie en interactie het lastigst te bouwen?

Omdat energiebeheer komend jaar veel belangrijker wordt heb ik ook nog wel een paar suggesties:
Elektrisch laden inplannen, opwarmen boiler uitstellen op basis van gedrag en zon, samenvatting van de dag in begrijpelijk taal, baseload op basis van historie en weerstation selecteren.

Update: Met AI een mockup laten maken

Suggestie van landingspagina:
[Afbeelding]

Suggestie voor baseload:
[Afbeelding]

En suggestie voor het inplannen van de auto:
[Afbeelding]

DAO is bedacht als add on voor home assistant. Je suggesties kunnen eigenlijk allemaal al met home assistant. EV inplannen, boiler inplannen, vaatwasser, wasmachine, elk apparaat jij wilt, baseload bereken op basis van historie. Dat kan DAO al allemaal en met home assistant kan je daar een mooie gui voor maken.

Je AI suggesties hebben ook veel weg van home assistant

[hemertje]

rescla schreef op woensdag 30 september 2026 @ 21:39:
[...]

Ik snap de vraag niet helemaal, maar de meteodata wordt getoond als dat er meteodata is opgehaald nadat de laatste optimaliseerberekening heeft gedraaid. In de config onder scheduler kan je zien wanneer dat zou moeten gebeuren. Dat je altijd de meteodata ziet als de berekening blijft falen voor lange periodes is daar een gevolg van.

Meteo data wordt toch 1x per dag opgehaald?
Berekeningen ieder kwartier uitgevoerd?

Dus dan verwacht ik het resultaat van de berekeningen, niet de meteo data die een paar uur eerder is opgehaald?

[thomvh]

hemertje schreef op donderdag 1 oktober 2026 @ 23:05:
[...]


Meteo data wordt toch 1x per dag opgehaald?
Berekeningen ieder kwartier uitgevoerd?

Dus dan verwacht ik het resultaat van de berekeningen, niet de meteo data die een paar uur eerder is opgehaald?

Zie je dit constant ofzo? Want als jij toevallig net na de meteo data kijkt zie je dat tot de hercalculatie heeft plaatsgevonden.

[dannyll]

Kunnen jullie eens meekijken? Mijn baseload geeft nog negatieve waarden. Dat kan natuurlijk niet kloppen. Ik vermoed dat mijn sensoren van mijn batterij nog niet goed ingesteld staan. Wat gaat er fout volgens jullie en waar moet ik dit aanpassen?

[thomvh]

dannyll schreef op vrijdag 2 oktober 2026 @ 11:21:
Kunnen jullie eens meekijken? Mijn baseload geeft nog negatieve waarden. Dat kan natuurlijk niet kloppen. Ik vermoed dat mijn sensoren van mijn batterij nog niet goed ingesteld staan. Wat gaat er fout volgens jullie en waar moet ik dit aanpassen?

[Afbeelding]

Waar gaat die productie heen van de zonnepanelen? Kun je dat achterhalen?

[Deikke]

Tussen 7 en 9 wordt er teruggeleverd, maar is er geen PV productie/accu opbrengst. Komt wellicht uit de accu, die lijkt namelijk 4.5kwh terug te leveren tussen 9 en 10. Wellicht is de sensor een tijdlang niet geupdate?

[dannyll]

thomvh schreef op vrijdag 2 oktober 2026 @ 11:23:
[...]

Waar gaat die productie heen van de zonnepanelen? Kun je dat achterhalen?

op dat moment nog terug het net in. De batterij is gisteren om 14.00uur met 2kw gaan laden

[dannyll]

Deikke schreef op vrijdag 2 oktober 2026 @ 11:28:
Tussen 7 en 9 wordt er teruggeleverd, maar is er geen PV productie/accu opbrengst. Komt wellicht uit de accu, die lijkt namelijk 4.5kwh terug te leveren tussen 9 en 10. Wellicht is de sensor een tijdlang niet geupdate?

Ik denk dat je gelijk hebt. De sensor geeft de waarde dus te laat terug waardoor deze in het verkeerde uur komt

[buiter]

Torch1969 schreef op donderdag 1 oktober 2026 @ 20:02:
[...]

Hoi @buiter leuk dat je creatief meedenkt. De gui is duidelijk niet het belangrijkste aspect van DAO, dat is de uitmuntende functionaliteit onder de motorkap. Er zijn maar een paar ontwikkelaars betrokken en die stoppen hun vrije tijd en ziel en zaligheid hier voor ons in. Had je je dit gerealiseerd voordat je je bericht hier plaatste?

Zeker realiseer ik me dat, waaruit zou blijken dat ik niet besef?
Omdat ik commentaar heb?
DAO als tool is super en waardeer ik, alleen het visuele gedeelte is gewoon niet sexy.
Waarom heeft DAO in de basis een blauwe achtergrond?
Dat mag wat mij betreft in de eerstvolgende release gewoon wit gemaakt worden.

Ik heb Claude gevraagd voor een vebeterde configuratiepagina (en dat heeft ie gebouwd) en dat werkt goed.
De nieuwe configuratie schijft ie weg naar de JSON file.
Daarmee heb ik tegelijk en check op fouten, eventuele opmerkingen bij velden etc etc.
Veel gebruiksvriendelijker en handiger dan werken in een JSON bestand. Vandaar ook mijn post.

Over het inplannen van de auto
Volgens mij houdt DAO pas rekening met het laden van de auto als deze wordt ingeplugd. Dat is een beetje laat als DAO daarvoor net de accu heeft leeg laten lopen. Daarom wil ik graag dat DAO rekening houdt met geplande laadmomenten. Straks in de winter heb ik misschien ook liever dat DAO spaarzamer is met de thuisaccu om mijn auto gunstig op te laden. Je kunt dicuseren over wat wenselijk is omdat je pas één dag vooruit weet wat de prijzen zijn.

Dat is trouwens niet helemaal waar.
Op deze website zie je een verwachting van de komende 7 dagen: https://wattwanneer.nl/
Geen idee hoe betrouwbaar zoeits is.

Met de configuratie van "machines" is er nog wel ruimte voor het aanmaken van geplande energieverbruikers.
Dan maak ik daarin misschien wel een configuratie van een auto/laadpaal aan.

Dogooder schreef op donderdag 1 oktober 2026 @ 20:36:
[...]

DAO is bedacht als add on voor home assistant. Je suggesties kunnen eigenlijk allemaal al met home assistant. EV inplannen, boiler inplannen, vaatwasser, wasmachine, elk apparaat jij wilt, baseload bereken op basis van historie. Dat kan DAO al allemaal en met home assistant kan je daar een mooie gui voor maken.

Je AI suggesties hebben ook veel weg van home assistant

Dat klopt, het inplannen van zaken kan in HA zelf. Maar het is toch zeer functioneel dat essentiële informatie/configuratie gewoon in DAO beschikbaar is?

[konehead]

buiter schreef op donderdag 1 oktober 2026 @ 13:06:
Even een vraag.
Ik snap dat je DOA instelt en er verder niet naar omkijkt, maar wordt er ook gewerkt aan een iets gebruiksvriendelijkere/geilere interface?
Of ben ik de enige die gegenereerde grafieken als jpg een beetje primitief vindt?
Ook het configureren van DAO is toch niet helemaal anno 2026?
En nee, UI V2 is dat ook niet.

Misschien ben ik te kritisch, ik zou het namelijk zelf niet kunnen.
Of is juist de presentatie en interactie het lastigst te bouwen?

Omdat energiebeheer komend jaar veel belangrijker wordt heb ik ook nog wel een paar suggesties:
Elektrisch laden inplannen, opwarmen boiler uitstellen op basis van gedrag en zon, samenvatting van de dag in begrijpelijk taal, baseload op basis van historie en weerstation selecteren.

Update: Met AI een mockup laten maken

Suggestie van landingspagina:
[Afbeelding]

Suggestie voor baseload:
[Afbeelding]

En suggestie voor het inplannen van de auto:
[Afbeelding]

Dankjewel voor je inspiratie. Vanwege het geweldige werk van de DAO ontwikkelaars, kan je dit helemaal zelf maken met de API interface. Zie hieronder obv echte data. Merk op dat mijn DAO 1,5 dag heeft uitgestaan, inverter was gestopt (heeft Growatt gefixed. Vandaar de lage opbrengst.

[Doopy-X-]

konehead schreef op vrijdag 2 oktober 2026 @ 14:28:
[...]

Dankjewel voor je inspiratie. Vanwege het geweldige werk van de DAO ontwikkelaars, kan je dit helemaal zelf maken met de API interface. Zie hieronder obv echte data. Merk op dat mijn DAO 1,5 dag heeft uitgestaan, inverter was gestopt (heeft Growatt gefixed. Vandaar de lage opbrengst.

[Afbeelding]

Dat ziet er prachtig uit, zou je de yaml kunnen delen?

[hemertje]

thomvh schreef op donderdag 1 oktober 2026 @ 23:19:
[...]

Zie je dit constant ofzo? Want als jij toevallig net na de meteo data kijkt zie je dat tot de hercalculatie heeft plaatsgevonden.

nee af en toe
maar dan zie ik dat de meteo bv een paar uur eerder is opgehaald terwijl de berekeningen ieder kwartier draaien

[hemertje]

buiter schreef op vrijdag 2 oktober 2026 @ 11:58:
[...]

Zeker realiseer ik me dat, waaruit zou blijken dat ik niet besef?
Omdat ik commentaar heb?
DAO als tool is super en waardeer ik, alleen het visuele gedeelte is gewoon niet sexy.
Waarom heeft DAO in de basis een blauwe achtergrond?
Dat mag wat mij betreft in de eerstvolgende release gewoon wit gemaakt worden.

Ik heb Claude gevraagd voor een vebeterde configuratiepagina (en dat heeft ie gebouwd) en dat werkt goed.
De nieuwe configuratie schijft ie weg naar de JSON file.
Daarmee heb ik tegelijk en check op fouten, eventuele opmerkingen bij velden etc etc.
Veel gebruiksvriendelijker en handiger dan werken in een JSON bestand. Vandaar ook mijn post.

Over het inplannen van de auto
Volgens mij houdt DAO pas rekening met het laden van de auto als deze wordt ingeplugd. Dat is een beetje laat als DAO daarvoor net de accu heeft leeg laten lopen. Daarom wil ik graag dat DAO rekening houdt met geplande laadmomenten. Straks in de winter heb ik misschien ook liever dat DAO spaarzamer is met de thuisaccu om mijn auto gunstig op te laden. Je kunt dicuseren over wat wenselijk is omdat je pas één dag vooruit weet wat de prijzen zijn.

Dat is trouwens niet helemaal waar.
Op deze website zie je een verwachting van de komende 7 dagen: https://wattwanneer.nl/
Geen idee hoe betrouwbaar zoeits is.

Met de configuratie van "machines" is er nog wel ruimte voor het aanmaken van geplande energieverbruikers.
Dan maak ik daarin misschien wel een configuratie van een auto/laadpaal aan.


[...]

Dat klopt, het inplannen van zaken kan in HA zelf. Maar het is toch zeer functioneel dat essentiële informatie/configuratie gewoon in DAO beschikbaar is?

met het laden van je auto uit je thuisaccu heb je 3x laadverliezen (accu in > accu uit > auto in)
het is gunstiger om je auto direct uit het net te laten laden wanneer de prijzen gunstig zijn

[mgroen81]

hemertje schreef op vrijdag 2 oktober 2026 @ 16:50:
[...]


met het laden van je auto uit je thuisaccu heb je 3x laadverliezen (accu in > accu uit > auto in)
het is gunstiger om je auto direct uit het net te laten laden wanneer de prijzen gunstig zijn

Als de prijzen gunstig zijn kan het prima uit. Zeker met 400v systemen met een hoger dan 95% roundtrip efficiëntie.

[konehead]

Doopy-X- schreef op vrijdag 2 oktober 2026 @ 14:35:
[...]


Dat ziet er prachtig uit, zou je de yaml kunnen delen?

Dank Dank! Stuur mij ff een DM met je email, dan stuur ik hem op (is meer dan 300 regels code )

[anboni]

konehead schreef op vrijdag 2 oktober 2026 @ 19:53:
[...]

Dank Dank! Stuur mij ff een DM met je email, dan stuur ik hem op (is meer dan 300 regels code )

Misschien kan @KC27 'm als voorbeeld in de github opnemen?

[konehead]

anboni schreef op vrijdag 2 oktober 2026 @ 19:59:
[...]

Misschien kan @KC27 'm als voorbeeld in de github opnemen?

Vanmiddag een update gemaakt: Actual vs FC en Vandaag en Morgen. Goed idee qua github, laat maar weten of dit voorbeeld waardig is :)

[pimNH]

konehead schreef op vrijdag 2 oktober 2026 @ 20:08:
[...]

[Afbeelding][Afbeelding] Vanmiddag een update gemaakt: Actual vs FC en Vandaag en Morgen. Goed idee qua github, laat maar weten of dit voorbeeld waardig is :)

Ik ben ook wel geïnteresseerd, is het ook mogelijk om verbruik van ingeplande apparaten uit de api te halen?

[KC27]

konehead schreef op vrijdag 2 oktober 2026 @ 20:08:
[...]

[Afbeelding][Afbeelding] Vanmiddag een update gemaakt: Actual vs FC en Vandaag en Morgen. Goed idee qua github, laat maar weten of dit voorbeeld waardig is :)

Stuur een kopie van die DM maar naar @Torch1969
Hij is de primaire maintainer van de Wiki.
Dan zal het snel in de Wiki komen en hij zal ongetwijfeld ook hier een link naar die pagina plaatsen.

[hemertje]

mgroen81 schreef op vrijdag 2 oktober 2026 @ 17:55:
[...]

Als de prijzen gunstig zijn kan het prima uit. Zeker met 400v systemen met een hoger dan 95% roundtrip efficiëntie.

volgens mij is er geen systeem dat boven de 86-90% RTE uit komt?

[The Source]

Torch1969 schreef op donderdag 1 oktober 2026 @ 20:02:
[...]

Hoi @buiter leuk dat je creatief meedenkt. De gui is duidelijk niet het belangrijkste aspect van DAO, dat is de uitmuntende functionaliteit onder de motorkap. Er zijn maar een paar ontwikkelaars betrokken en die stoppen hun vrije tijd en ziel en zaligheid hier voor ons in. Had je je dit gerealiseerd voordat je je bericht hier plaatste?

Nu moet ik ook van mij laten horen, want ik ben ook voor een makkelijkere configuratie en interface. Echter heb ik mijn mond gehouden omdat ik weet dat dit een hobbyproject is dat enorm veel tijd vraagt van jullie en het doel is niet om iemand te beledigen. Ik ben zeer tevreden over DAO, het is een geweldig project en juist daarom hebben zullen gebruikers meningen hebben.

Ik denk wel dat er over de toekomst nagedacht moet worden. Het is nu vooral op de Nederlandse markt gericht, met Nederlandse uitleg. De configuratie is zelfs voor gevorderden niet makkelijk omdat JSON erg kieskeurig is en geen comments verdraagt. Mocht er behoefte zijn om in de toekomst een groter publiek te bereiken, dan is mijn suggestie om aan de interface te werken.

Er zijn projecten zoals EMHASS die hetzelfde doen, maar wel een interface voor config hebben. En dan is er EVCC dat erg makkelijk qua config is en ook met een optimizer bezig is. Hier zit wel een verdienmodel aan vast.

Ik weet niet of jullie met Claude programmeren en hoe jullie daarover denken, maar voor interface en presentatie is dat een eitje (en wat tokens) om dat te genereren. Als ik op mijn werk zie hoe mijn senior Node.js-developer tegenwoordig dingen doet, dan is het gewoon bangelijk. Zeker omdat je zegt dat voor jullie de interface niet een hoge prioriteit heeft, zou dit misschien m.b.v. Claude te maken kunnen zijn. High impact, low effort. De core onder de moterkap waar de kracht in zit kan dan nog steeds handmatig gemaakt worden.

Nogmaals, dit is een suggestie om jullie harde werk bij een groot publiek te introduceren. Dus zie het als een suggestie en compliment.

buiter schreef op vrijdag 2 oktober 2026 @ 11:58:
[...]
Op deze website zie je een verwachting van de komende 7 dagen: https://wattwanneer.nl/
Geen idee hoe betrouwbaar zoeits is.

Redelijk betrouwbaar
Iig betrouwbaar genoeg om de goedkoopste 4 of 6 uurs tijdvakken in de week te bepalen voor het laden van een auto bv.

[ Voor 15% gewijzigd door The Source op 02-10-2026 22:39 ]

[KC27]

The Source schreef op vrijdag 2 oktober 2026 @ 22:34:
[...]


Nu moet ik ook van mij laten horen, want ik ben ook voor een makkelijkere configuratie en interface. Echter heb ik mijn mond gehouden omdat ik weet dat dit een hobbyproject is dat enorm veel tijd vraagt van jullie en het doel is niet om iemand te beledigen. Ik ben zeer tevreden over DAO, het is een geweldig project en juist daarom hebben zullen gebruikers meningen hebben.

Ik denk wel dat er over de toekomst nagedacht moet worden. Het is nu vooral op de Nederlandse markt gericht, met Nederlandse uitleg. De configuratie is zelfs voor gevorderden niet makkelijk omdat JSON erg kieskeurig is en geen comments verdraagt. Mocht er behoefte zijn om in de toekomst een groter publiek te bereiken, dan is mijn suggestie om aan de interface te werken.

Er zijn projecten zoals EMHASS die hetzelfde doen, maar wel een interface voor config hebben. En dan is er EVCC dat erg makkelijk qua config is en ook met een optimizer bezig is. Hier zit wel een verdienmodel aan vast.

Ik weet niet of jullie met Claude programmeren en hoe jullie daarover denken, maar voor interface en presentatie is dat een eitje (en wat tokens) om dat te genereren. Als ik op mijn werk zie hoe mijn senior Node.js-developer tegenwoordig dingen doet, dan is het gewoon bangelijk. Zeker omdat je zegt dat voor jullie de interface niet een hoge prioriteit heeft, zou dit misschien m.b.v. Claude te maken kunnen zijn. High impact, low effort. De core onder de moterkap waar de kracht in zit kan dan nog steeds handmatig gemaakt worden.

Nogmaals, dit is een suggestie om jullie harde werk bij een groot publiek te introduceren. Dus zie het als een suggestie en compliment.


[...]

Redelijk betrouwbaar
Iig betrouwbaar genoeg om de goedkoopste 4 of 6 uurs tijdvakken in de week te bepalen voor het laden van een auto bv.
[Afbeelding]

Er ligt een ontwerp voor een config-gui van @simnet .
Door tijdgebrek (wie kent hem niet) is dit blijven liggen.
@storeman is - as we speak - bezig met het default maken van V2-GUI en als dat klaar is gaat hij de config-gui van @simnet actualiseren en activeren.
@Dogooder heeft intussen een complete CI-workflow met bijbehorende test-suites geschreven zodat alle codewijzigingen eerst worden getest voordat ze met de main-branche worden gemerged.
Tenslotte ben ik zelf afgelopen maand druk geweest met het implementeren van het verleggen van de planningshorizon m.b.v. prijsvoorspellingen (diverse bronnen) voorlopig tot 96 uur voorbij de door epex vastgestelde prijshorizon.
Sneak-preview:


Als jullie dit allemaal niet snel/geil/sexy genoeg vinden: er zijn genoeg andere goede alternatieven (emhass, evcc, gbb) voor DAO.

[Doopy-X-]

KC27 schreef op vrijdag 2 oktober 2026 @ 23:34:
[...]

Er ligt een ontwerp voor een config-gui van @simnet .
Door tijdgebrek (wie kent hem niet) is dit blijven liggen.
@storeman is - as we speak - bezig met het default maken van V2-GUI en als dat klaar is gaat hij de config-gui van @simnet actualiseren en activeren.
@Dogooder heeft intussen een complete CI-workflow met bijbehorende test-suites geschreven zodat alle codewijzigingen eerst worden getest voordat ze met de main-branche worden gemerged.
Tenslotte ben ik zelf afgelopen maand druk geweest met het implementeren van het verleggen van de planningshorizon m.b.v. prijsvoorspellingen (diverse bronnen) voorlopig tot 96 uur voorbij de door epex vastgestelde prijshorizon.
Sneak-preview:
[Afbeelding]

Als jullie dit allemaal niet snel/geil/sexy genoeg vinden: er zijn genoeg andere goede alternatieven (emhass, evcc, gbb) voor DAO.

Thanks voor de update en sneak peak! Er komen zo te zien coole dingen aan en volgens mij waardeert iedereen de geweldige werking van dit project en de tijd die erin wordt gestoken. Uiteindelijk gaat het om het innerlijk, niet om de looks 😎

[KVan]

@KC27 ik ben het in ieder geval eens met het motto: "functie voor vorm" dat je (jullie) hier volgen. Ik had al je GitHub gezien met langere termijn voorspellingen, die wordt vast in de winter periode erg handig daar zie je in historische data vaak grote dag na dag verschillen. Cudos voor het harde werk hier!

Wat een "geile" interface betreft: waarom niet een aantal verschillende naast elkaar laten bestaan. Je hebt al een api, dus kunnen er neven projecten die grafische kant maken. Op die manier kan je de functie geconcentreerd houden en krijgen gebruikers keuze wat ze graag willen.

Hetzelfde zou kunnen met repositories voor de automatisering, bijvoorbeeld per merk omvormer. Hier wordt het wel moeilijk met aansturen van apparaten, maar de basis sturing van de inverter moet kunnen.

Er zullen mensen moeten opstaan om dit te doen, voor het core team is het dan niet meer dan een lijst met links naar mogelijkheden die naast de bestaande interface werken (met de nodige disclaimer). Op die manier bedien je mij, die aan de core functionaliteit genoeg heeft maar ook diegene die graag een mooie grafisch uitgebreide interface ziet (ik vind een dergelijke interface best interessant maar nodig is wat anders).

[DaBit]

KC27 schreef op vrijdag 2 oktober 2026 @ 23:34:
Tenslotte ben ik zelf afgelopen maand druk geweest met het implementeren van het verleggen van de planningshorizon m.b.v. prijsvoorspellingen (diverse bronnen) voorlopig tot 96 uur voorbij de door epex vastgestelde prijshorizon.

Kijk, daar word ik dan weer vrolijk van!

GUI's, ach, overrated. Als er een knopje of vinkje op zit wat doet dat het moet doen, het presenteert de informatie die je wil zien en je hoeft niet 5x te klikken als het in 1x ook had gekund dan is het al gauw goed genoeg. De rest is mode. Over 2 jaar zijn we denk ik wel op het punt dat de X Athena Widgets of Motif gepresenteerd wordt als 'de designtaal van 2029, het minimalistische design laat meer ruimte over voor echte informatie en leid minder af, blablabla blabla bla'.

[oscaarbasgitaar]

Helemaal eens dat "mooie plaatjes met een fancy strik errond" bijkomstig zijn aan het doel van de Add-on: kosten besparen.

Na een weekje monitoren snap ik best wel dat deze add-on mijn thuisbatterij beter zou aansturen dan de Solis-"AI"-EMS. Dus ben ik overgeschakeld van de solis-API-integratie naar de modbusversie om zo de batterij te sturen. De API heeft namelijk wel af en toe wat issues met stabiliteit. De twee naast elkaar draaien heeft geen zin: veel modbus requests zorgen ervoor dat de API minder vlot draait.

Gevolg is wel dat ik een hele hoop zaken moet aanpassen en ook een hoop data van anderhalf jaar dat ik met HA bezig ben verlies (oa energiedashboard).
Je kan dat wel overzetten, maar da's dan weer een hele hoop werk en die data kan ik extern nog steeds ophalen via de soliscloud...

Waar ik wel mee struggle is de "reports".
Meestal krijg ik een foutmelding (internal server error - ValueError: NaTType does not support strftime) heel uitzonderlijk lukt het wel eens, maar ook dan blijft het instabiel: als ik dan bijvoorbeeld een andere periode wil of van tabel naar charts wil overschakelen krijg ik terug die error.

Ik heb al zitten zoeken in dit forum en heb 1 gelijkaardige melding gevonden, daar bleek het om een soort bug te gaan.

@KC27: ik hoop dat ik hieronder genoeg info uit de debug-log voor je aanlever om dit te kunnen uitzoeken. Het stelt verder geen problemen, de berekeningen werken, dit is voor mij geen noodzakelijke feature. Ik snap dat jullie dit allemaal vrijwillig doen, kijk zelf maar wanneer je hier tijd voor zou kunnen vinden, ik ga je zeker niet opjagen.

code:

Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 340, in menu
    return reports("reports")
  File "/root/dao/webserver/app/routes.py", line 731, in reports
    report_df = report.get_grid_data(active_period, _tot=tot)
  File "/root/dao/prog/da_report.py", line 2214, in get_grid_data
    df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
  File "/root/dao/prog/da_report.py", line 3054, in get_price_data
    df_da = self.db_da.get_column_data(
        "values", "da", start=start, end=end, agg_func=agg_func
    )
  File "/root/dao/lib/db_manager.py", line 491, in get_column_data
    end = end.strftime("%Y-%m-%d %H:%M")
  File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime
ValueError: NaTType does not support strftime
[2026-09-30 16:19:39,005] fout in app: Exception on / [POST]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 340, in menu
    return reports("reports")
  File "/root/dao/webserver/app/routes.py", line 731, in reports
    report_df = report.get_grid_data(active_period, _tot=tot)
  File "/root/dao/prog/da_report.py", line 2214, in get_grid_data
    df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
  File "/root/dao/prog/da_report.py", line 3054, in get_price_data
    df_da = self.db_da.get_column_data(
        "values", "da", start=start, end=end, agg_func=agg_func
    )
  File "/root/dao/lib/db_manager.py", line 491, in get_column_data
    end = end.strftime("%Y-%m-%d %H:%M")
  File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime

De voorspellingshorizon verlengen heeft ook mijn voorkeur
De vraag is voor mij wel in welke mate 4 dagen vooruit kijken met bovendien nog een onzekerheidsfactor veel invloed heeft op de actie voor komend kwartier / uur.
Volgens mij is anderhalve dag meer dan voldoende: dus tussen middernacht en het moment dat je de epex prijs voor morgen terug hebt.
Maar ik ga jullie niet tegenhouden

[ Voor 4% gewijzigd door oscaarbasgitaar op 03-10-2026 09:59 ]

[simnet]

oscaarbasgitaar schreef op zaterdag 3 oktober 2026 @ 09:52:
Helemaal eens dat "mooie plaatjes met een fancy strik errond" bijkomstig zijn aan het doel van de Add-on: kosten besparen.

Na een weekje monitoren snap ik best wel dat deze add-on mijn thuisbatterij beter zou aansturen dan de Solis-"AI"-EMS. Dus ben ik overgeschakeld van de solis-API-integratie naar de modbusversie om zo de batterij te sturen. De API heeft namelijk wel af en toe wat issues met stabiliteit. De twee naast elkaar draaien heeft geen zin: veel modbus requests zorgen ervoor dat de API minder vlot draait.

Gevolg is wel dat ik een hele hoop zaken moet aanpassen en ook een hoop data van anderhalf jaar dat ik met HA bezig ben verlies (oa energiedashboard).
Je kan dat wel overzetten, maar da's dan weer een hele hoop werk en die data kan ik extern nog steeds ophalen via de soliscloud...

Waar ik wel mee struggle is de "reports".
Meestal krijg ik een foutmelding (internal server error - ValueError: NaTType does not support strftime) heel uitzonderlijk lukt het wel eens, maar ook dan blijft het instabiel: als ik dan bijvoorbeeld een andere periode wil of van tabel naar charts wil overschakelen krijg ik terug die error.

Ik heb al zitten zoeken in dit forum en heb 1 gelijkaardige melding gevonden, daar bleek het om een soort bug te gaan.

@KC27: ik hoop dat ik hieronder genoeg info uit de debug-log voor je aanlever om dit te kunnen uitzoeken. Het stelt verder geen problemen, de berekeningen werken, dit is voor mij geen noodzakelijke feature. Ik snap dat jullie dit allemaal vrijwillig doen, kijk zelf maar wanneer je hier tijd voor zou kunnen vinden, ik ga je zeker niet opjagen.

code:

Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 340, in menu
    return reports("reports")
  File "/root/dao/webserver/app/routes.py", line 731, in reports
    report_df = report.get_grid_data(active_period, _tot=tot)
  File "/root/dao/prog/da_report.py", line 2214, in get_grid_data
    df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
  File "/root/dao/prog/da_report.py", line 3054, in get_price_data
    df_da = self.db_da.get_column_data(
        "values", "da", start=start, end=end, agg_func=agg_func
    )
  File "/root/dao/lib/db_manager.py", line 491, in get_column_data
    end = end.strftime("%Y-%m-%d %H:%M")
  File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime
ValueError: NaTType does not support strftime
[2026-09-30 16:19:39,005] fout in app: Exception on / [POST]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 340, in menu
    return reports("reports")
  File "/root/dao/webserver/app/routes.py", line 731, in reports
    report_df = report.get_grid_data(active_period, _tot=tot)
  File "/root/dao/prog/da_report.py", line 2214, in get_grid_data
    df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
  File "/root/dao/prog/da_report.py", line 3054, in get_price_data
    df_da = self.db_da.get_column_data(
        "values", "da", start=start, end=end, agg_func=agg_func
    )
  File "/root/dao/lib/db_manager.py", line 491, in get_column_data
    end = end.strftime("%Y-%m-%d %H:%M")
  File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime

De voorspellingshorizon verlengen heeft ook mijn voorkeur
De vraag is voor mij wel in welke mate 4 dagen vooruit kijken met bovendien nog een onzekerheidsfactor veel invloed heeft op de actie voor komend kwartier / uur.
Volgens mij is anderhalve dag meer dan voldoende: dus tussen middernacht en het moment dat je de epex prijs voor morgen terug hebt.
Maar ik ga jullie niet tegenhouden

Misschien net te laat, maar je kunt met deze de metingen van sensoren migreren:
https://github.com/mayerwin/HA-Merge-Sensor-History

[KC27]

Wellicht ten overvloede voor gebruikers die mooie plaatjes willen in HA:
Met Power Flow Card Plus krijg je inzicht in de actuele vermogens van je woning:

[Doopy-X-]

KC27 schreef op zaterdag 3 oktober 2026 @ 13:51:
Wellicht ten overvloede voor gebruikers die mooie plaatjes willen in HA:
Met Power Flow Card Plus krijg je inzicht in de actuele vermogens van je woning:
[Afbeelding]

Check, die heb ik van de week ook voor alle verdiepingen toegevoegd

[ Voor 9% gewijzigd door Doopy-X- op 03-10-2026 16:29 ]

[hemertje]

KC27 schreef op vrijdag 2 oktober 2026 @ 23:34:
[...]
Tenslotte ben ik zelf afgelopen maand druk geweest met het implementeren van het verleggen van de planningshorizon m.b.v. prijsvoorspellingen (diverse bronnen) voorlopig tot 96 uur voorbij de door epex vastgestelde prijshorizon.
Sneak-preview:
[Afbeelding]

Als jullie dit allemaal niet snel/geil/sexy genoeg vinden: er zijn genoeg andere goede alternatieven (emhass, evcc, gbb) voor DAO.

Hoi @KC27 , mooi dat de horizon wordt verlengd.

Een sterilisatierun is voor mij precies het geval dat dat nodig heeft. Bij mij is het een warmtepompboiler (Panasonic Aquarea, 300 L):
tot circa 52 °C draait alleen de compressor (gemiddeld 1,9 kW, COP circa 3), daarboven schakelt de backup-heater van 3 kW bij, en een sterilisatierun naar 65 °C is bijna volledig weerstandsverwarming.
Nu draait hij via Ed's Node-RED scheduler elke vrijdag 12:30, dus los van de prijs.

Zou dit in DAO planbaar kunnen worden, met een interval (bijvoorbeeld 7 dagen), een eindtemperatuur, een vermogen en COP voor de heater, en een entiteit die de run start?
Ik meet volgende week de energie van een run en lever de cijfers graag aan.
Ik heb ook een concept met metingen over de modellering van de tank (gelaagdheid, variabel vermogen) dat ik graag deel als dat nuttig is.

[simnet]

hemertje schreef op zaterdag 3 oktober 2026 @ 19:25:
[...]


Hoi @KC27 , mooi dat de horizon wordt verlengd.

Een sterilisatierun is voor mij precies het geval dat dat nodig heeft. Bij mij is het een warmtepompboiler (Panasonic Aquarea, 300 L):
tot circa 52 °C draait alleen de compressor (gemiddeld 1,9 kW, COP circa 3), daarboven schakelt de backup-heater van 3 kW bij, en een sterilisatierun naar 65 °C is bijna volledig weerstandsverwarming.
Nu draait hij via Ed's Node-RED scheduler elke vrijdag 12:30, dus los van de prijs.

Zou dit in DAO planbaar kunnen worden, met een interval (bijvoorbeeld 7 dagen), een eindtemperatuur, een vermogen en COP voor de heater, en een entiteit die de run start?
Ik meet volgende week de energie van een run en lever de cijfers graag aan.
Ik heb ook een concept met metingen over de modellering van de tank (gelaagdheid, variabel vermogen) dat ik graag deel als dat nuttig is.

Heel eerlijk: ik zou dit soort risicovolle veiligheidsdingen nooit willen proberen te sturen. Legionellabacterien / veteranenziekte is echt geen grapje en daar gaan mensen aan dood.

Ik zou het ook niet op mn geweten willen hebben dat het fout gaat door een wel bedoeld, maar verkeerd advies.

[workzone]

simnet schreef op zaterdag 3 oktober 2026 @ 19:43:
[...]


Heel eerlijk: ik zou dit soort risicovolle veiligheidsdingen nooit willen proberen te sturen. Legionellabacterien / veteranenziekte is echt geen grapje en daar gaan mensen aan dood.

Ik zou het ook niet op mn geweten willen hebben dat het fout gaat door een wel bedoeld, maar verkeerd advies.

Mijn WPB reset de legionella run timer als ik het vat zelf naar de juiste temperatuur opstook.
Je zou haast verwachten dat andere boilers dit ook op deze manier doen.

[oscaarbasgitaar]

simnet schreef op zaterdag 3 oktober 2026 @ 11:05:
[...]


Misschien net te laat, maar je kunt met deze de metingen van sensoren migreren:
https://github.com/mayerwin/HA-Merge-Sensor-History

vriendelijk bedankt, maar te laat inderdaad.

[Oilman]

simnet schreef op zaterdag 3 oktober 2026 @ 19:43:
[...]


Heel eerlijk: ik zou dit soort risicovolle veiligheidsdingen nooit willen proberen te sturen. Legionellabacterien / veteranenziekte is echt geen grapje en daar gaan mensen aan dood.

Ik zou het ook niet op mn geweten willen hebben dat het fout gaat door een wel bedoeld, maar verkeerd advies.

Volledig off-topic. Ik heb nog nooit gelezen dat er iemand uberhaupt een legionella besmetting thuis heeft opgelopen op het boilervat niet vaak genoeg opgestookt werd. Net alsof iedereen die terug komt van zomervakantie netjes z'n leidingen doorspoelt, terwijl dan de kans op een hoge concentratie legionella een stuk hoger is dan een vat dat regelmatig 'leeg' getapt wordt.

Bij mijn eigen analyse van het stookgedrag van mijn boilervat met de WP, kwam ik tot de conclusie dat gewoon domweg iedere middag (bijna) forceren om 1300 uur het voordeligste uitpakt. Meeste kans op PV opbrengst, normaliter de hoogste temperatuur, vaak acceptabele kWh prijzen. Vooral voorkomen dat het ding 's avonds te leeg gaat en dan op de duurste uren van de dag een DHW run gaat draaien + WAF . Gaan schuiven met het tijdstip op de dag leverde praktisch niets op bij de analyse van afgelopen jaar. Dat is als captain hindsight, met een voorspelling erbij gaat het ook wel eens fout, bijv dat de zon op het voorspelde moment het af laat weten.

[hemertje]

simnet schreef op zaterdag 3 oktober 2026 @ 19:43:
[...]


Heel eerlijk: ik zou dit soort risicovolle veiligheidsdingen nooit willen proberen te sturen. Legionellabacterien / veteranenziekte is echt geen grapje en daar gaan mensen aan dood.

Ik zou het ook niet op mn geweten willen hebben dat het fout gaat door een wel bedoeld, maar verkeerd advies.

Hoi SImnet,

los van het feit dat ik ook twijfel aan een legionelle besmetting thuis, kan je wanneer je deze toch wekelijks draait deze het beste optimaal plannen ipv ongecontroleerd draaien tijdens de dure uren?

[hemertje]

Oilman schreef op zaterdag 3 oktober 2026 @ 20:21:
[...]

Volledig off-topic. Ik heb nog nooit gelezen dat er iemand uberhaupt een legionella besmetting thuis heeft opgelopen op het boilervat niet vaak genoeg opgestookt werd. Net alsof iedereen die terug komt van zomervakantie netjes z'n leidingen doorspoelt, terwijl dan de kans op een hoge concentratie legionella een stuk hoger is dan een vat dat regelmatig 'leeg' getapt wordt.

Bij mijn eigen analyse van het stookgedrag van mijn boilervat met de WP, kwam ik tot de conclusie dat gewoon domweg iedere middag (bijna) forceren om 1300 uur het voordeligste uitpakt. Meeste kans op PV opbrengst, normaliter de hoogste temperatuur, vaak acceptabele kWh prijzen. Vooral voorkomen dat het ding 's avonds te leeg gaat en dan op de duurste uren van de dag een DHW run gaat draaien + WAF . Gaan schuiven met het tijdstip op de dag leverde praktisch niets op bij de analyse van afgelopen jaar. Dat is als captain hindsight, met een voorspelling erbij gaat het ook wel eens fout, bijv dat de zon op het voorspelde moment het af laat weten.

nadeel is dat een WP globaal tot een 52GrC warmwater maakt via de compressor met een hogere COP, daarboven tot bv 65GrC draait het volledig op de elektrische element van de backup heater met een COP van 1.

[hemertje]

Hoi Corné, @KC27 e.a.

nu de winter eraan komt, een vraag van mij over verwarmen met de warmtepomp.

Ik heb een Panasonic 7kW lucht/water warmtepomp die ik nu aanstuur met Ed's Node Red.
Tot nu toe gebruik ik DAO voor het laden en ontladen van de Zendure accu's en sinds kort ook voor de boiler (warm water, via Ed's Node Red).

Ik wil graag in de winterperiode de lage dynamische stroomprijzen (overdag en 's nachts) gebruiken om het huis een beetje extra op te warmen, zodat de warmtepomp tijdens de dure uren uit kan.
Het huis werkt dan als een soort warmteaccu.
Voordat ik iets instel wil ik graag zeker weten dat ik begrijp wat DAO nu al doet.

Hieronder een opsomming zoals ik nu snap hoe DAO werkt (zeg het aub als ik het fout heb):

• DAO rekent per dag uit hoeveel warmte het huis nodig heeft (op basis van de graaddagen) en zet de warmtepomp vooral in de goedkoopste uren aan?
• De stooklijn kan met de prijs meeschuiven: bij een dure prijs iets lager, bij een lage prijs iets hoger?
• DAO weet niet wat de temperatuur in huis is. Het weet dus ook niet hoe lang de pomp uit kan voordat het te koud wordt?

Nu mijn vragen:

1. Klopt dit, of is er al een manier om het huis als warmtebuffer te gebruiken die ik gemist heb?

2. Staat het op de planning dat DAO rekening houdt met de binnentemperatuur, met een grens naar boven en naar beneden?
Dan kan DAO op lage prijzen extra verwarmen en de pomp in de dure uren uit laten, zonder dat het te koud wordt. Past dat misschien bij de langere planning waar je aan werkt?

3. Zo niet: is een simpele tussenstap mogelijk?
Bijvoorbeeld: boven een bepaalde prijs, of in vaste uren in de avondpiek, mag de pomp niet verwarmen (warm water blijft gewoon mogelijk), met een veiligheidsgrens op de binnentemperatuur.

4. Een vraag over het verbruik van de warmtepomp. Ik heb de vermogenssensor van de pomp in de DAO-instellingen staan, maar de pompsturing van DAO staat uit. Klopt het dat het pompverbruik dan van de netafname wordt afgetrokken en dus niet in de basislast terechtkomt? Of komt het er juist wel in?

5. Een vraag over de instelling adjustment factor (de stooklijn die met de prijs meeschuift). In de documentatie staat "K/10%": zoveel graden verschuiving als de prijs 10% van het daggemiddelde afwijkt. In de code (utils.py, calc_adjustment_heatcurve) staat:

code:

adjustment = round(-adjustment_factor * (price_act - price_avg) * 100 / price_avg, 1)

en in het commentaar "0,4 K per 10% = 0.04 K/%".

Dat is graden per procent, dus 10 keer zoveel als de documentatie zegt.
Voorbeeld: met adjustment_factor: 2.0 (gelezen als 2 graden per 10%) geeft de code -20 graden als de prijs 10% boven het gemiddelde zit.

Mijn schuifregelaar in Home Assistant gaat maar van -3 tot +3. Welke van de twee is de bedoeling, de documentatie of de code?
En zou een melding in de log kunnen komen als de berekende waarde buiten die schuifregelaar valt?

Bij mij staat de warmtepompsturing van DAO nog uit, dus er is nog niets mis gegaan.

Wat achtergrondinformatie die ik gevonden heb:
Onderzoek met echte woningen laat zien dat slim sturen van een warmtepomp op stroomprijs (in de literatuur "MPC" genoemd: een regeling die met een rekenmodel van het huis en voorspellingen vooruit plant) ongeveer 2 tot 6% kan besparen, en dat het grootste deel daarvan al komt van het uitzetten van de pomp in de avondpiek.
Een proef van 125 dagen gaf 9%, terwijl een korte proef van een paar dagen 34% liet zien.
Ik verwacht dus geen wonderen, maar de avondpiek-stap lijkt me een mooie eerste stap. Ik denk graag mee en test mee, en meet dan met vergelijkbare dagen, wanneer er eventueel een testversie komt.

Een vergelijkbaar project dat het huis zelf leert kennen uit meetdata (warmteverlies, thermische massa, zon), is NeedForHeat van Windesheim (CC BY 4.0):
https://github.com/energi...orheat-diagnosis-software

Alvast hartelijk dank voor jullie reacties...

[thomvh]

@KC27
Ik heb twee PR's geopend op Gitlab:

• PV EV entiteit. Deze geeft aan of DAO verwacht dat de PV surcharge naar de auto gaat.https://github.com/corneel27/day-ahead/pull/874
• Soort van Zonnebonus toegevoegd aan de berekening. https://github.com/corneel27/day-ahead/pull/876

Feedback is welkom!

[Wilin]

hemertje schreef op zaterdag 3 oktober 2026 @ 19:25:
[...]


Hoi @KC27 , mooi dat de horizon wordt verlengd.

Een sterilisatierun is voor mij precies het geval dat dat nodig heeft.

...

Zou dit in DAO planbaar kunnen worden, met een interval (bijvoorbeeld 7 dagen), een eindtemperatuur, een vermogen en COP voor de heater, en een entiteit die de run start?


...

Ik heb mijn legionella run op de volgende manier ingepland:

• het is een machine in DAO
• op zaterdag om 17 loopt er een automatisatie die de window correct inplant op zondag en het programma aanzet.
• wanneer DAO aangeeft dat de run best begint, zet een automatisatie de boiler aan op 60C
• wanneer het verbruik terugvalt wordt het programma terug uit gezet.

[mgroen81]

hemertje schreef op vrijdag 2 oktober 2026 @ 21:35:
[...]


volgens mij is er geen systeem dat boven de 86-90% RTE uit komt?

Jazeker wel. Hoe hoger het voltage, hoe hoger het potentiële efficiëntie. Bij 800v nog iets hoger. Eigenlijk is dit het grote nadeel van de 48v systemen.

Ik gebruik zelf een Fronius Symo 10.0 en een 52kWh 400V battery. 98℅ eff.

[ Voor 8% gewijzigd door mgroen81 op 04-10-2026 00:10 ]

[workzone]

mgroen81 schreef op zondag 4 oktober 2026 @ 00:07:
[...]

Jazeker wel. Hoe hoger het voltage, hoe hoger het potentiële efficiëntie. Bij 800v nog iets hoger. Eigenlijk is dit het grote nadeel van de 48v systemen.

Ik gebruik zelf een Fronius Symo 10.0 en een 52kWh 400V battery. 98℅ eff.

De meeste accu cellen blijven alleen al steken bij een efficiency van max 97%, dus een RTE van 98% lijkt me niet haalbaar. Als je systeem heel erg efficient is zit je misschien rond de 90 tot 92%.

[simnet]

hemertje schreef op zaterdag 3 oktober 2026 @ 20:37:
[...]


Hoi SImnet,

los van het feit dat ik ook twijfel aan een legionelle besmetting thuis, kan je wanneer je deze toch wekelijks draait deze het beste optimaal plannen ipv ongecontroleerd draaien tijdens de dure uren?

Uiteindelijk moet je het zelf weten, maar hou op zijn minst rekening met gelaagdheid van je vat en zorg dat het hele vat, inclusief de onderste lagen op temperatuur komen en die ook lang genoeg aanhouden.

ISSO 55.1 is een leuke om te lezen. Gaat over gehele installaties en niet in een particuliere opzet, maar het geeft wel de diepte van de wetgeving aan.

Ik laat in ieder geval mijn boiler dat lekker zelf uitzoeken.

Ow en spoelen is leuk, maar legionella zit grotendeels in de biofilm in de leidingen en niet los in het water. Dus dat heeft beperkt nut.

[ Voor 19% gewijzigd door simnet op 04-10-2026 00:33 ]

[Torch1969]

hemertje schreef op zaterdag 3 oktober 2026 @ 20:37:
[...]


Hoi SImnet,

los van het feit dat ik ook twijfel aan een legionelle besmetting thuis, kan je wanneer je deze toch wekelijks draait deze het beste optimaal plannen ipv ongecontroleerd draaien tijdens de dure uren?

Die optimale planning, zonder omkijken en fancy aansturingen, is er. Elke zondagmiddag om 13u.

[buiter]

KC27 schreef op zaterdag 3 oktober 2026 @ 13:51:
Wellicht ten overvloede voor gebruikers die mooie plaatjes willen in HA:
Met Power Flow Card Plus krijg je inzicht in de actuele vermogens van je woning:
[Afbeelding]

Die hebben we al ;-) Maar dat is over het actueel verbruik.

Over de keuze bij DAO ben ik het eens met het principe eens "functie boven vorm". En misschien heb ik de indruk gewekt dat het mij om de grafieken gaat. Maar dat klopt niet.

Mijn belangrijkste punt is dat de configuratie van DAO met een JSON file een zeer hoge drempel opwerpt. Als de JSON vervangen zou worden door een normaal configuratiepagina met alle onderdelen dan is de plugin al een stuk toegankelijker.

En naar mijn idee werkt de plugin heel goed dus leek het me tijd om de visuals een keer bespreekbaar te maken.

[DaBit]

simnet schreef op zondag 4 oktober 2026 @ 00:26:
ISSO 55.1 is een leuke om te lezen. Gaat over gehele installaties en niet in een particuliere opzet, maar het geeft wel de diepte van de wetgeving aan.

Die zit uiteraard weer achter een paywall, grmbl. 109 euro.

Aangezien jij verstand van zaken lijkt te hebben: ik heb een COP=1 electrische boiler voor de gasketel staan die ik inschakel als het uitkan (electriciteit goedkoper dan gas; staat in DAO als 'electrische auto'). De gasketel verwarmt na tot 58C indien nodig.

Bovenop de prijsberekenening zit logica die zegt 'als het een week of meer geleden is dat de boiler de 65C aangetikt heeft en het is zondag dan is het setpoint minimaal 60C'. Dan staat die boiler dus de hele zondag op hoge temperatuur en ben ik er zeker van dat alles goed doorverwarmd is.
In de winter doet die boiler niet veel en dan heb ik zo wekelijks op zondag toch de beestjeskoken-run. Waait het nou op maandag heel hard dan kan het met deze simpele logica zijn dat de volgende legionellarun 2 weken min een dag op zich laat wachten. Daar staat dan weer tegenover dat het water in de boiler dan ook maar 10-15 graden is.

Ik ga je niet vragen om te zeggen of het zo goed is, maar ik kan wel vragen of je problemen ziet, toch?

[hemertje]

Wilin schreef op zaterdag 3 oktober 2026 @ 23:48:
[...]

Ik heb mijn legionella run op de volgende manier ingepland:

• het is een machine in DAO
• op zaterdag om 17 loopt er een automatisatie die de window correct inplant op zondag en het programma aanzet.
• wanneer DAO aangeeft dat de run best begint, zet een automatisatie de boiler aan op 60C
• wanneer het verbruik terugvalt wordt het programma terug uit gezet.

goedeorgen @Wilin

wil jeje code hier ter inspiratie eens delen?

[hemertje]

Torch1969 schreef op zondag 4 oktober 2026 @ 08:59:
[...]

Die optimale planning, zonder omkijken en fancy aansturingen, is er. Elke zondagmiddag om 13u.

dan laadt de EV hier ook al op

[simnet]

DaBit schreef op zondag 4 oktober 2026 @ 09:21:
[...]
Ik ga je niet vragen om te zeggen of het zo goed is, maar ik kan wel vragen of je problemen ziet, toch?

Haha, vragen kan altijd
En ik wil zeker niet zeggen dat ik er verstand van heb. Ik ben geen bioloog of waterbeheer deskundige. Ik weet dit toevallig doordat een van mijn klanten waterbeheer doet.

Het enige waar ik je op kan wijzen is te zorgen dat je (hele) vat lang genoeg op temperatuur blijft. Mijn boiler meet en regelt dat zelf, conform wetgeving en veiligheidsnormen. Ik ga als leek mijn boiler niet overrulen en denken dat ik het beter weet.
Ik stuur ook puur de compressor en electrisch element aan, maar alleen als energy buffer. Ik zet het smartgrid contact aan als het voordelig is of als ik over heb. De rest laat ik het regelsysteem van de boiler oplossen.
Beetje vergelijkbaar met dat ik mijn battery de NoM laat regelen als dat nodig is, in plaats van zelf een PID controller gebruiken.

[Isdatzo]

Enigszins offtopic maar m.i. is er bij normaal gebruik voldoende doorspoeling van het boilervat en is daarmee het risico op een besmetting minimaal. Daarnaast zijn de personen die onder mijn douche staan gezond en behoren niet tot een risicogroep.

Derhalve doe ik dus niet actief aan legionellapreventie, tenzij er gedurende een langere periode geen of weinig gebruik is gemaakt van warm water (denk aan vakantieperioden). Verder moet iedereen natuurlijk doen waar ze zich prettig bij voelen, maar persoonlijk zie ik geen noodzaak om de boel wekelijks tot 60 graden op te stoken.

[Wilin]

hemertje schreef op zondag 4 oktober 2026 @ 09:34:
[...]


goedeorgen @Wilin

wil jeje code hier ter inspiratie eens delen?

YAML: options.json

  "machines": [
    {
    "name" : "Boiler legionella",
    "programs" : [
      {
        "name": "Uit",
        "power": []
      },
      {
        "name": "Aan",
        "power": [1050, 1050, 1050, 1050, 1050, 1050, 1050]
      }
    ],
    "entity start window" : "input_datetime.dao_legionella_start_slot_vraag",
    "entity end window" : "input_datetime.dao_legionella_eind_slot_vraag",
    "entity selected program" : "input_select.dao_legionella_modus_vraag",
    "entity calculated start" : "input_datetime.dao_legionella_start_berekend",
    "entity calculated end" : "input_datetime.dao_legionella_eind_berekend"
    }
  ]

[oscaarbasgitaar]

Het klopt dat legionella een aandachtspunt is, maar het is ook waar dat er weinig tot geen gevallen van besmetting zijn in woningen waar doorgaande wekelijks voldoende gebruik is en er dus geen lang stilstaand water tussen 25 en 45° is.

Wat een volledige sterilisatie-run zou moeten zijn: boilervat lang boven 65° én álle warm water leidingen 3 minuten spoelen met heet water.

Dat eerste kan je nog wel inplannen. Dat tweede doet werkelijk niemand.

De dag dat iemand in het huis woont die respiratoir gevoelig is (de bacteriën verspreiden zich via verneveling, besmet water drinken kan theoretisch geen kwaad) of een verzwakte gezondheid heeft zou ik er zelf ook aandacht zal schenken. Maar vooralsnog staat ons boilervat op 56° ingesteld.

[mgroen81]

workzone schreef op zondag 4 oktober 2026 @ 00:25:
[...]

De meeste accu cellen blijven alleen al steken bij een efficiency van max 97%, dus een RTE van 98% lijkt me niet haalbaar. Als je systeem heel erg efficient is zit je misschien rond de 90 tot 92%.

Dat zei ik niet. Ik had het over 98% efficiëntie. Dus ongeveer 95%RTE. Ook na gemeten natuurlijk.

[Doopy-X-]

konehead schreef op vrijdag 2 oktober 2026 @ 20:08:
[...]

[Afbeelding][Afbeelding] Vanmiddag een update gemaakt: Actual vs FC en Vandaag en Morgen. Goed idee qua github, laat maar weten of dit voorbeeld waardig is :)

Veel dank voor het delen via de mail, hopelijk snel ook voor anderen te gebruiken via de wiki.
Ik miste de verschillende entiteiten nog die nodig waren voor een goede planning dus ik ben best een tijdje met AI bezig geweest deze op te zetten en ik heb hier en daar nog wat aan je voorbeeld getweaked maar het is gelukt

Ik heb het nu als dashboard opgenomen in Home Assistant:

[konehead]

Doopy-X- schreef op zondag 4 oktober 2026 @ 19:33:
[...]


Veel dank voor het delen via de mail, hopelijk snel ook voor anderen te gebruiken via de wiki.
Ik miste de verschillende entiteiten nog die nodig waren voor een goede planning dus ik ben best een tijdje met AI bezig geweest deze op te zetten en ik heb hier en daar nog wat aan je voorbeeld getweaked maar het is gelukt

Ik heb het nu als dashboard opgenomen in Home Assistant:
[Afbeelding]

Kijk hem gaan!!! hahaha, die SOC lijn is ook vet! Samen maken we het beter. Ik ben wel bang dat ik de verkeerde versie heb gestuurd. Ik heb ook een knopje vandaag en morgen en Werkelijk / Plan. Heb zelf 24uur gedaan, past precies als pop-up op mijn tablet in de woonkamer.

[ Voor 12% gewijzigd door konehead op 04-10-2026 21:05 ]

[Frankvbr]

Wilin schreef op zaterdag 3 oktober 2026 @ 23:48:
[...]

Ik heb mijn legionella run op de volgende manier ingepland:

• het is een machine in DAO
• op zaterdag om 17 loopt er een automatisatie die de window correct inplant op zondag en het programma aanzet.
• wanneer DAO aangeeft dat de run best begint, zet een automatisatie de boiler aan op 60C
• wanneer het verbruik terugvalt wordt het programma terug uit gezet.

Ik heb een andere warmtepomp maar zelfde probleem met verwarmingsrun op elektrisch element.
Ik heb het nu anders opgelost:
- Automation die 1x per week (zaterdagavond 20.00) de doeltemperatuur omhoog zet naar 70 graden (vanwege gelaagdheid vat better safe then sorry).
- DAO houdt dan rekening met de huidige temperatuur van het vat (wat normaliter schommelt tussen de 42 en 50 graden) en plant hem ergens tussen zaterdag 20.00 uur en zonder 20.00 uur in.
(Zondag leek mij gunstigste als combinatie van kinderen die uitgebreid in bad gaan i.c.m. dat tarieven op zondag altijd goedkoper zijn. Als DAO week vooruit kan plannen wordt het wellicht anders).
DAO pakt dan het juiste tijdstip, maar het verbruik zal in praktijk alleen iets hoger liggen.
- Een losse automation die een alert stuurt als het tapwater niet boven 67 graden is geweest in de afgelopen 7 dagen.


Voor het vat regulier verwarmen alsvolgt gedaan:
- Vat zelf ingesteld op 44 graden oid met hysterese van 3 graden.
- DAO werkt met doeltemperatuur van 50 graden met hysterese van 3 graden oid.
- In praktijk zorgt DAO dat vat elke dag op gunstig tijdstip naar 50 graden gaat. Mocht temperatuur teveel dalen, verwarmt warmtepomp alsnog op ongunstigere tijd (geen warmwatertekort). Mocht dat te vaak gebeuren dan wordt doeltemperatuur hoger.

DAO kent natuurlijk hier en daar wat beperkingen, maar daar is omheen te werken, verder is het fantastisch dat mensen hier tijd in steken.
Verder gewoon fijn om met elkaar ervaringen te delen hoe mensen dit aanpakken (misschien kunnen we daar in helpen door verschillende situatie's + aanpak in de wiki te zetten).

Ben wel eens dat de config file soms complex is (alsin een foutje is snel gemaakt), maar het zijn hier tweakers. Zelf een beetje tijd in steken mag ook wel.

[ Voor 3% gewijzigd door Frankvbr op 05-10-2026 12:50 ]

[DaBit]

simnet schreef op zondag 4 oktober 2026 @ 12:30:
Het enige waar ik je op kan wijzen is te zorgen dat je (hele) vat lang genoeg op temperatuur blijft. Mijn boiler meet en regelt dat zelf, conform wetgeving en veiligheidsnormen. Ik ga als leek mijn boiler niet overrulen en denken dat ik het beter weet.

Ik laat mijn subsystemen ook zoveel mogelijk autonoom hun werk doen, maar dat was met de boiler expliciet niet de bedoeling. Die was en is goedkope overtollige-energie opslag (250 euro voor 6kWh). Maar 'lang genoeg op temperatuur' word gegarandeerd door 'de hele zondag op minstens 60C setpoint'
(in theorie kan iemand nog telkens wat water tappen en zo voorkomen dat het boilervat de temperatuur haalt, maar het is niet realistisch dat dat een heel etmaal lang gebeurt)

Isdatzo schreef op zondag 4 oktober 2026 @ 12:36:
maar persoonlijk zie ik geen noodzaak om de boel wekelijks tot 60 graden op te stoken.

Het is net zoiets als een kunstmestfabriek als buurman. Het risico dat het misgaat is klein, maar de gevolgen zijn groot mocht het een keer gebeuren.

Wat er aan extra energie voor die anti-legionella-en-andere-beestjes-run nodig is valt reuze mee en werk heb je er ook niet aan, dus waarom zou je het risico lopen....

Dat concept 'hou apparaat nog een tijd X op setpoint geactiveerd' wat je voor dingen als boilers, EV's, en thuisbatterijen enzo wel wil (batterijen moeten cellen balanceren, boilers moeten doorwarmen) doe ik nu vanuit logica buiten DAO. Zou geen kwaad kunnen als DAO de operating_mode/charge_switch zelf langer actief zou kunnen houden. Maar volgens mij is dat nog best harig om te maken.

[Beekforel]

@DaBit dat kun je toch prima oplossen met een extra "program" voor de "machine"?

[hemertje]

hemertje schreef op zaterdag 3 oktober 2026 @ 21:38:
Hoi Corné, @KC27 e.a.

nu de winter eraan komt, een vraag van mij over verwarmen met de warmtepomp.

Ik heb een Panasonic 7kW lucht/water warmtepomp die ik nu aanstuur met Ed's Node Red.
Tot nu toe gebruik ik DAO voor het laden en ontladen van de Zendure accu's en sinds kort ook voor de boiler (warm water, via Ed's Node Red).

Ik wil graag in de winterperiode de lage dynamische stroomprijzen (overdag en 's nachts) gebruiken om het huis een beetje extra op te warmen, zodat de warmtepomp tijdens de dure uren uit kan.
Het huis werkt dan als een soort warmteaccu.
Voordat ik iets instel wil ik graag zeker weten dat ik begrijp wat DAO nu al doet.

Hieronder een opsomming zoals ik nu snap hoe DAO werkt (zeg het aub als ik het fout heb):

• DAO rekent per dag uit hoeveel warmte het huis nodig heeft (op basis van de graaddagen) en zet de warmtepomp vooral in de goedkoopste uren aan?
• De stooklijn kan met de prijs meeschuiven: bij een dure prijs iets lager, bij een lage prijs iets hoger?
• DAO weet niet wat de temperatuur in huis is. Het weet dus ook niet hoe lang de pomp uit kan voordat het te koud wordt?

Nu mijn vragen:

1. Klopt dit, of is er al een manier om het huis als warmtebuffer te gebruiken die ik gemist heb?

2. Staat het op de planning dat DAO rekening houdt met de binnentemperatuur, met een grens naar boven en naar beneden?
Dan kan DAO op lage prijzen extra verwarmen en de pomp in de dure uren uit laten, zonder dat het te koud wordt. Past dat misschien bij de langere planning waar je aan werkt?

3. Zo niet: is een simpele tussenstap mogelijk?
Bijvoorbeeld: boven een bepaalde prijs, of in vaste uren in de avondpiek, mag de pomp niet verwarmen (warm water blijft gewoon mogelijk), met een veiligheidsgrens op de binnentemperatuur.

4. Een vraag over het verbruik van de warmtepomp. Ik heb de vermogenssensor van de pomp in de DAO-instellingen staan, maar de pompsturing van DAO staat uit. Klopt het dat het pompverbruik dan van de netafname wordt afgetrokken en dus niet in de basislast terechtkomt? Of komt het er juist wel in?

5. Een vraag over de instelling adjustment factor (de stooklijn die met de prijs meeschuift). In de documentatie staat "K/10%": zoveel graden verschuiving als de prijs 10% van het daggemiddelde afwijkt. In de code (utils.py, calc_adjustment_heatcurve) staat:

code:

adjustment = round(-adjustment_factor * (price_act - price_avg) * 100 / price_avg, 1)

en in het commentaar "0,4 K per 10% = 0.04 K/%".

Dat is graden per procent, dus 10 keer zoveel als de documentatie zegt.
Voorbeeld: met adjustment_factor: 2.0 (gelezen als 2 graden per 10%) geeft de code -20 graden als de prijs 10% boven het gemiddelde zit.

Mijn schuifregelaar in Home Assistant gaat maar van -3 tot +3. Welke van de twee is de bedoeling, de documentatie of de code?
En zou een melding in de log kunnen komen als de berekende waarde buiten die schuifregelaar valt?

Bij mij staat de warmtepompsturing van DAO nog uit, dus er is nog niets mis gegaan.

Wat achtergrondinformatie die ik gevonden heb:
Onderzoek met echte woningen laat zien dat slim sturen van een warmtepomp op stroomprijs (in de literatuur "MPC" genoemd: een regeling die met een rekenmodel van het huis en voorspellingen vooruit plant) ongeveer 2 tot 6% kan besparen, en dat het grootste deel daarvan al komt van het uitzetten van de pomp in de avondpiek.
Een proef van 125 dagen gaf 9%, terwijl een korte proef van een paar dagen 34% liet zien.
Ik verwacht dus geen wonderen, maar de avondpiek-stap lijkt me een mooie eerste stap. Ik denk graag mee en test mee, en meet dan met vergelijkbare dagen, wanneer er eventueel een testversie komt.

Een vergelijkbaar project dat het huis zelf leert kennen uit meetdata (warmteverlies, thermische massa, zon), is NeedForHeat van Windesheim (CC BY 4.0):
https://github.com/energi...orheat-diagnosis-software

Alvast hartelijk dank voor jullie reacties...

wil iemand mij verder op weg helpen?

[hemertje]

Beste allemaal,

nog een aantal vragen voor de overgang na 1 januari (wanneer het salderen stopt):

1. Tax refund
In mijn instellingen staat "tax refund": true. Per 1 januari moet dat false. Komt er een datumtabel (zoals bij de tarieven), of moet ik hem op 1 januari met de hand omzetten?

2. Strategie
In de code zie ik dat "minimize consumption" eerst de levering aan het net minimaliseert en daarbinnen de kosten.
Klopt dat?
Is "minimize cost" met de tarieven voor 2027 (teruglevering zonder belasting) in de praktijk bijna hetzelfde?
Mijn prioriteit is zelfconsumptie en CO2, minder het handelen.

3. Balance switch
Ik gebruik "entity balance switch" voor kwartieren waarin DAO nul op de meter wil.
Kan DAO die kwartieren aan elkaar laten vastzitten (minimaal bijvoorbeeld 30 minuten), zodat mijn regelaar niet elk kwartier opnieuw begint?

4. Nachtlast
Mijn plan houdt de accu 's nachts op 71% terwijl het huis circa 0,5 kW afneemt.
De laagste trap in mijn stages is 500 W met rendement 0,88.
Kan het zijn dat DAO daarom de nachtlast niet uit de accu dekt, en kan ik dat beïnvloeden met de stages?

5. Proefrun
Is er een manier om DAO een plan te laten berekenen met andere opties zonder dat het naar HA schrijft?
Ik wil graag zien wat het plan zonder saldering doet, voordat het zover is.

Wederom bedankt en gegroet,

Hemertje

[KC27]

hemertje schreef op zaterdag 3 oktober 2026 @ 21:38:
Hoi Corné, @KC27 e.a.

nu de winter eraan komt, een vraag van mij over verwarmen met de warmtepomp.

Ik heb een Panasonic 7kW lucht/water warmtepomp die ik nu aanstuur met Ed's Node Red.
Tot nu toe gebruik ik DAO voor het laden en ontladen van de Zendure accu's en sinds kort ook voor de boiler (warm water, via Ed's Node Red).

Ik wil graag in de winterperiode de lage dynamische stroomprijzen (overdag en 's nachts) gebruiken om het huis een beetje extra op te warmen, zodat de warmtepomp tijdens de dure uren uit kan.
Het huis werkt dan als een soort warmteaccu.
Voordat ik iets instel wil ik graag zeker weten dat ik begrijp wat DAO nu al doet.

Hieronder een opsomming zoals ik nu snap hoe DAO werkt (zeg het aub als ik het fout heb):

• DAO rekent per dag uit hoeveel warmte het huis nodig heeft (op basis van de graaddagen) en zet de warmtepomp vooral in de goedkoopste uren aan?
• De stooklijn kan met de prijs meeschuiven: bij een dure prijs iets lager, bij een lage prijs iets hoger?
• DAO weet niet wat de temperatuur in huis is. Het weet dus ook niet hoe lang de pomp uit kan voordat het te koud wordt?

Nu mijn vragen:

1. Klopt dit, of is er al een manier om het huis als warmtebuffer te gebruiken die ik gemist heb?

Nee nog niet echt, staat wel op mijn todo-lijst

2. Staat het op de planning dat DAO rekening houdt met de binnentemperatuur, met een grens naar boven en naar beneden?
Dan kan DAO op lage prijzen extra verwarmen en de pomp in de dure uren uit laten, zonder dat het te koud wordt. Past dat misschien bij de langere planning waar je aan werkt?

Ja maar waarschijnlijk niet zo gedetailleerd met een warmteverliesberekening.

3. Zo niet: is een simpele tussenstap mogelijk?
Bijvoorbeeld: boven een bepaalde prijs, of in vaste uren in de avondpiek, mag de pomp niet verwarmen (warm water blijft gewoon mogelijk), met een veiligheidsgrens op de binnentemperatuur.

Lijkt mij meer iets voor een automation in HA

4. Een vraag over het verbruik van de warmtepomp. Ik heb de vermogenssensor van de pomp in de DAO-instellingen staan, maar de pompsturing van DAO staat uit. Klopt het dat het pompverbruik dan van de netafname wordt afgetrokken en dus niet in de basislast terechtkomt? Of komt het er juist wel in?

Als het verbruik (niet het vermogen) bij de wp-sensoren hebt staan (onder kopje "reports") dan wordt het wp-verbruik van de basislast afgetrokken.

5. Een vraag over de instelling adjustment factor (de stooklijn die met de prijs meeschuift). In de documentatie staat "K/10%": zoveel graden verschuiving als de prijs 10% van het daggemiddelde afwijkt. In de code (utils.py, calc_adjustment_heatcurve) staat:

code:

adjustment = round(-adjustment_factor * (price_act - price_avg) * 100 / price_avg, 1)

en in het commentaar "0,4 K per 10% = 0.04 K/%".

Dat is graden per procent, dus 10 keer zoveel als de documentatie zegt.
Voorbeeld: met adjustment_factor: 2.0 (gelezen als 2 graden per 10%) geeft de code -20 graden als de prijs 10% boven het gemiddelde zit.

Je stelt in K/%
Dus als je 2 ingeeft dan betekent dat 2 K/% dus 20 K bij 10% afwijking.

Mijn schuifregelaar in Home Assistant gaat maar van -3 tot +3. Welke van de twee is de bedoeling, de documentatie of de code?
En zou een melding in de log kunnen komen als de berekende waarde buiten die schuifregelaar valt?

DAO kan de grenzen van de schuifregelaar (nog) niet uitlezen.
Je kunt deze beter zelf ruim instellen en met een automation in HA deze begrenzen voordat je hem doorzet naar de wp.

Bij mij staat de warmtepompsturing van DAO nog uit, dus er is nog niets mis gegaan.

Wat achtergrondinformatie die ik gevonden heb:
Onderzoek met echte woningen laat zien dat slim sturen van een warmtepomp op stroomprijs (in de literatuur "MPC" genoemd: een regeling die met een rekenmodel van het huis en voorspellingen vooruit plant) ongeveer 2 tot 6% kan besparen, en dat het grootste deel daarvan al komt van het uitzetten van de pomp in de avondpiek.
Een proef van 125 dagen gaf 9%, terwijl een korte proef van een paar dagen 34% liet zien.
Ik verwacht dus geen wonderen, maar de avondpiek-stap lijkt me een mooie eerste stap. Ik denk graag mee en test mee, en meet dan met vergelijkbare dagen, wanneer er eventueel een testversie komt.

Een vergelijkbaar project dat het huis zelf leert kennen uit meetdata (warmteverlies, thermische massa, zon), is NeedForHeat van Windesheim (CC BY 4.0):
https://github.com/energi...orheat-diagnosis-software

Alvast hartelijk dank voor jullie reacties...

[KC27]

hemertje schreef op maandag 5 oktober 2026 @ 22:18:
Beste allemaal,

nog een aantal vragen voor de overgang na 1 januari (wanneer het salderen stopt):

1. Tax refund
In mijn instellingen staat "tax refund": true. Per 1 januari moet dat false. Komt er een datumtabel (zoals bij de tarieven), of moet ik hem op 1 januari met de hand omzetten?

Er komt geen datum/tijd bij "tax refund".
Deze instelling gaat met de eerstvolgende versie na 1-1-2027 vervallen.
Je kunt wel alvast "energy_taxes_production" op 1-1-2027 op "0.00" zetten

2. Strategie
In de code zie ik dat "minimize consumption" eerst de levering aan het net minimaliseert en daarbinnen de kosten.
Klopt dat?
Is "minimize cost" met de tarieven voor 2027 (teruglevering zonder belasting) in de praktijk bijna hetzelfde?
Mijn prioriteit is zelfconsumptie en CO2, minder het handelen.

Ik denk dat in de praktijk die twee elkaar na 1-1-2027 niet veel zullen ontlopen.

3. Balance switch
Ik gebruik "entity balance switch" voor kwartieren waarin DAO nul op de meter wil.
Kan DAO die kwartieren aan elkaar laten vastzitten (minimaal bijvoorbeeld 30 minuten), zodat mijn regelaar niet elk kwartier opnieuw begint?

Dat zou dan een instelling moeten worden.
Staat voorlopig niet op de planning.
De verwachting is dat de meeste perioden van NOM een langere aaneengesloten periode zullen zijn.

4. Nachtlast
Mijn plan houdt de accu 's nachts op 71% terwijl het huis circa 0,5 kW afneemt.
De laagste trap in mijn stages is 500 W met rendement 0,88.
Kan het zijn dat DAO daarom de nachtlast niet uit de accu dekt, en kan ik dat beïnvloeden met de stages?

Ik denk dat het nu nog niet loont om de nachtlast uit de accu te halen.

5. Proefrun
Is er een manier om DAO een plan te laten berekenen met andere opties zonder dat het naar HA schrijft?
Ik wil graag zien wat het plan zonder saldering doet, voordat het zover is.

Je kunt heel eenvoudig tussen de reguliere berekeningen door je instellingen aanpassen en een "Optimaliseringsberekening met debug" doen. Niet vergeten om alles weer goed terug te zetten voor de volgende reguliere berekening.

Wederom bedankt en gegroet,

Hemertje

[Doopy-X-]

Ik wil even van de gelegenheid gebruik maken om de ontwikkelaars van deze geweldige tool wat veren in de achterste te stoppen.

Ik heb vorige week mijn AlphaESS SMILE G3-T10, 18,6 kWh geïnstalleerd gekregen en ik ben de hele week al een beetje aan het spelen met verschillende opties van AlphaESS zelf zoals de pas toegevoegde AI mode en de Price-Based Control mode. Deze laatste werkt aardig maar hiervoor moet je vooraf parameters instellen (hoogte & laagste 10% bijvoorbeeld) wanneer hij mag gaan laden en ontladen. Dit kan per dag heel verschillende uitwerking hebben.

DAO werkt een stuk beter. Ik ben gisteren op kwartierprijzen overgeschakeld en het resultaat van vandaag is verbluffend:


De laadacties per kwartier komen heel mooi uit in deze grafiek en DOA zorgt ervoor dat exact op de goede momenten wordt geladen en ontladen.

voor jullie geweldige model en tool.

Keep up the good work!

P.S. Ik ben nog wel aan het nadenken of ik de limits bijvoorbeeld naar 15/10 wil zetten ipv de 20/15 nu. Dit geeft natuurlijk iets betere opbrengsten maar zorgt er wel voor dat er iets minder speelruimte is qua moment van bijladen?

[ Voor 9% gewijzigd door Doopy-X- op 06-10-2026 00:12 ]

[thomvh]

Sinds dat wij over gaan van Tibber naar Zonneplan loop ik wat te stoeien met de EV's in DAO. De rekentijd wordt namelijk zo lang dat hij of niet tot een oplossing komt of het gewoon echt minuten duurt.

Hierbij heb ik de volgende dingen al gedaan:
- Charge stages verminderd naar 6 / 10 / 16.
- Max gap proberen te verhogen naar 0.05 maar dan krijg ik raar gedrag, waarbij hij besluit uit de accu te gaan laden bijvoorbeeld.

Zolang 1 auto actief staat is er niks aan de hand. Maar ik wilde eigenlijk 3 autos actief in de planning hebben, waarbij de auto's die geen doel hebben constant aan het einde van de horizon geplaatst worden zodat ze wel zo goedkoop mogelijk laden. Eventueel met zonnestroom.

[DikDikkie]

Doopy-X- schreef op dinsdag 6 oktober 2026 @ 00:10:
Ik wil even van de gelegenheid gebruik maken om de ontwikkelaars van deze geweldige tool wat veren in de achterste te stoppen.

Ik heb vorige week mijn AlphaESS SMILE G3-T10, 18,6 kWh geïnstalleerd gekregen en ik ben de hele week al een beetje aan het spelen met verschillende opties van AlphaESS zelf zoals de pas toegevoegde AI mode en de Price-Based Control mode. Deze laatste werkt aardig maar hiervoor moet je vooraf parameters instellen (hoogte & laagste 10% bijvoorbeeld) wanneer hij mag gaan laden en ontladen. Dit kan per dag heel verschillende uitwerking hebben.

DAO werkt een stuk beter. Ik ben gisteren op kwartierprijzen overgeschakeld en het resultaat van vandaag is verbluffend:
[Afbeelding]

De laadacties per kwartier komen heel mooi uit in deze grafiek en DOA zorgt ervoor dat exact op de goede momenten wordt geladen en ontladen.

voor jullie geweldige model en tool.

Keep up the good work!

P.S. Ik ben nog wel aan het nadenken of ik de limits bijvoorbeeld naar 15/10 wil zetten ipv de 20/15 nu. Dit geeft natuurlijk iets betere opbrengsten maar zorgt er wel voor dat er iets minder speelruimte is qua moment van bijladen?

Ziet er goed uit. Ik kom er maar niet aan toe om DAO goed te configureren voor mijn Alpha ESS. Zou je jouw configuratie willen delen? En waar heb je jouw visualisatie in gemaakt? Grafana?

[Dogooder]

thomvh schreef op dinsdag 6 oktober 2026 @ 08:50:
Sinds dat wij over gaan van Tibber naar Zonneplan loop ik wat te stoeien met de EV's in DAO. De rekentijd wordt namelijk zo lang dat hij of niet tot een oplossing komt of het gewoon echt minuten duurt.

Hierbij heb ik de volgende dingen al gedaan:
- Charge stages verminderd naar 6 / 10 / 16.
- Max gap proberen te verhogen naar 0.05 maar dan krijg ik raar gedrag, waarbij hij besluit uit de accu te gaan laden bijvoorbeeld.

Zolang 1 auto actief staat is er niks aan de hand. Maar ik wilde eigenlijk 3 autos actief in de planning hebben, waarbij de auto's die geen doel hebben constant aan het einde van de horizon geplaatst worden zodat ze wel zo goedkoop mogelijk laden. Eventueel met zonnestroom.

Ik vind dit wel een interessante usecase en zou graag onderzoeken waarom de solver hier de weg kwijt raakt. De huidige test suite heeft 24 EV scenario's, maar met 2 EV's max. Maar die scenario's leiden niet tot bovengenoemd gedrag.
Kan jij mij, al dan niet via DM, wat meer uitleg geven over dit specifieke scenario. En hoe goed ben jij met "docker exec -it dao /bin/bash"?

[Wilin]

Hoe moet ik "minimum power" bij de batterijen interpreteren? Ik heb dit voor beide batterijen die ik heb geconfigureerd op 100 staan, maar DAO vraagt nog regelmatig om te ontladen met 35W etc. Ik zou dit willen kunnen uitzetten. mijn batterij kan hier niet echt mee overweg met zulke lage vraag. De batterij blijft in dat geval meestal uit.

[simnet]

DaBit schreef op maandag 5 oktober 2026 @ 14:26:
Ik laat mijn subsystemen ook zoveel mogelijk autonoom hun werk doen, maar dat was met de boiler expliciet niet de bedoeling. Die was en is goedkope overtollige-energie opslag (250 euro voor 6kWh). Maar 'lang genoeg op temperatuur' word gegarandeerd door 'de hele zondag op minstens 60C setpoint'
(in theorie kan iemand nog telkens wat water tappen en zo voorkomen dat het boilervat de temperatuur haalt, maar het is niet realistisch dat dat een heel etmaal lang gebeurt)

Dit is ook precies wat ik bedoel. Er is niets op tegen om je boiler te gebruiken als energieopslag. Dat is ook exact zoals ik het doe. Maar dat is alleen EXTRA energie toevoegen. Ik ga het reguliere legionella programma (wat de boiler zelf bijhoudt en inpland) niet uitzetten of uitstellen alleen maar om een paar centen te besparen.

Ik weet ook eerlijk niet of het regelmatige gebruik van het electrisch element om stroom overschot te dumpen in de boiler invloed heeft op dat legionella programma. Als hij er rekening mee houd; mooi. Zo niet; ach, zoals ik zei, centenwerk. Daar maak ik me niet druk om.

[thomvh]

Dogooder schreef op dinsdag 6 oktober 2026 @ 12:04:
[...]

Ik vind dit wel een interessante usecase en zou graag onderzoeken waarom de solver hier de weg kwijt raakt. De huidige test suite heeft 24 EV scenario's, maar met 2 EV's max. Maar die scenario's leiden niet tot bovengenoemd gedrag.
Kan jij mij, al dan niet via DM, wat meer uitleg geven over dit specifieke scenario. En hoe goed ben jij met "docker exec -it dao /bin/bash"?

Ik denk dat in DM even wat makkelijker is. Ik red me prima met docker. Ik zal je er een sturen!