Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Animal]

Zojuist ook mijn vaatwasser, droger en wasmachine in DAO gezet.
DAO geeft keurig een calculated tijd aan (binnen de door mij gestelde time window, die ik trigger naar een switchbot.

Wat een prachtige software! Complimenten!

Is de log ergens nog terug te kijken. De log die je ziet na een run(zonder debug)?

[KC27]

Animal schreef op woensdag 22 oktober 2025 @ 23:50:
Zojuist ook mijn vaatwasser, droger en wasmachine in DAO gezet.
DAO geeft keurig een calculated tijd aan (binnen de door mij gestelde time window, die ik trigger naar een switchbot.

Wat een prachtige software! Complimenten!

Is de log ergens nog terug te kijken. De log die je ziet na een run(zonder debug)?

Ja, via Home en dan Tabel (naast Grafiek).
Daar kun je ook door bladeren met de "pijltjes".

[CopyCatz]

KC27 schreef op woensdag 22 oktober 2025 @ 22:59:
[...]

Edit:
mappings klinkt leuk, maar is nu even te veel werk. Ik zet het op het to-do lijstje.
Maar als jij tijd over hebt, "be my guest" : maak een fork, pas het aan en dien een Pull Request in.

Done Hoe werkt het eigenlijk met testen? Ik gebruik dan mijn eigen fork om als addon in HA te zetten, blijven de gegevens bewaard als ik overschrijf?

[ Voor 18% gewijzigd door CopyCatz op 23-10-2025 09:19 ]

[Deikke]

Is het trouwens nodig om elk kwartier een nieuw plan te maken? Of geeft DAO de nieuwe instellingen door aan Home Assistant na elk kwartier?

[Animal]

Wasmachine ging om 5 uur aan. Batterij werd geladen. helemaal top!

Nu kwam ik het volgende tegen.

Ik heb vandaag om 11:50 een time window aangegeven voor de droger. Namelijk tussen 12:00 en 17:00.
DAO heeft om 12:00 de calculated time aangepast naar 12:00. Alleen miste home assistant automation deze trigger. Iemand een verklaring? Toen ik de calculated start handmatig aanpaste naar 12:05 werkte de trigger wel

[ Voor 60% gewijzigd door Animal op 23-10-2025 12:40 ]

[storeman]

Deikke schreef op donderdag 23 oktober 2025 @ 12:10:
Is het trouwens nodig om elk kwartier een nieuw plan te maken? Of geeft DAO de nieuwe instellingen door aan Home Assistant na elk kwartier?

Jazeker! DAO probeert de realiteit te modelleren, maar we weten zeker dat de realiteit anders is dan het model. Dus je wil elk kwartier actualiseren. DAO geeft updates alleen door na een run, geplande waardes worden dus niet doorgezet zonder run.

[Animal]

Door een CSV export te maken vanuit Home assistant van mijn energy entity (vannacht tussen 5:00 en 8:00) heb ik Claude dit overzicht laten maken.
Handig om je machines te definiëren in DAO



Dan wordt het dus:

code:

"machines" : [
      { "name": "wasmachine",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "Stand D 40 graden",
           "power": [405, 1782, 398, 158, 142, 123, 104, 253]

[ Voor 20% gewijzigd door Animal op 23-10-2025 12:53 ]

[Deikke]

storeman schreef op donderdag 23 oktober 2025 @ 12:21:
[...]


Jazeker! DAO probeert de realiteit te modelleren, maar we weten zeker dat de realiteit anders is dan het model. Dus je wil elk kwartier actualiseren. DAO geeft updates alleen door na een run, geplande waardes worden dus niet doorgezet zonder run.

Ja, maar die realiteit veranderd toch niet elk kwartier? Hoogstens is de SOC van de batterij een paar procentjes veranderd (naar verwachting). Prijzen veranderen 1x per dag en meteo gegevens worden 4x per dag ververst. Met uurprijzen werd er ook 1x per uur een nieuw plan getrokken.

[RudolfR]

Animal schreef op donderdag 23 oktober 2025 @ 12:11:
Wasmachine ging om 5 uur aan. Batterij werd geladen. helemaal top!

Nu kwam ik het volgende tegen.

Ik heb vandaag om 11:50 een time window aangegeven voor de droger. Namelijk tussen 12:00 en 17:00.
DAO heeft om 12:00 de calculated time aangepast naar 12:00. Alleen miste home assistant automation deze trigger. Iemand een verklaring? Toen ik de calculated start handmatig aanpaste naar 12:05 werkte de trigger wel

Misschien een offset van een minuut toevoegen aan je HA trigger?
Dan kan DOA nooit de huidige minuut missen.

[storeman]

Deikke schreef op donderdag 23 oktober 2025 @ 13:16:
[...]

Ja, maar die realiteit veranderd toch niet elk kwartier? Hoogstens is de SOC van de batterij een paar procentjes veranderd (naar verwachting). Prijzen veranderen 1x per dag en meteo gegevens worden 4x per dag ververst. Met uurprijzen werd er ook 1x per uur een nieuw plan getrokken.

De SoC zal inderdaad de grootste variabele zijn, nu de meeste nog salderen en dus de accu meer als verdien-model hebben dan als netontlasting, zal dat nog meevallen. Als straks het salderen eraf is en er dus veel meer NOM gedraaid wordt, dan is die SoC nog belangrijker. Ook de meteo-gegevens, en dan met name de pv-opbrengsten, wijzigen ook gedurende de dag.

Verder, wat is het probleem van een keertje rekenen?

[Gameboy]

Animal schreef op donderdag 23 oktober 2025 @ 12:11:
Wasmachine ging om 5 uur aan. Batterij werd geladen. helemaal top!

Nu kwam ik het volgende tegen.

Ik heb vandaag om 11:50 een time window aangegeven voor de droger. Namelijk tussen 12:00 en 17:00.
DAO heeft om 12:00 de calculated time aangepast naar 12:00. Alleen miste home assistant automation deze trigger. Iemand een verklaring? Toen ik de calculated start handmatig aanpaste naar 12:05 werkte de trigger wel

HomeAssistant's time-triggers "triggeren" alleen op de exacte opgegeven tijd (de aanvang van de seconde). Dus als een ander proces eerst een trigger-tijd moet instellen (hoe kort ook), dan is die trigger-tijd in HA al voorbij, en zal die flow dus niet worden uitgevoerd.

Als je iets wilt triggeren in HA op een tijd, dan zul je moeten waarborgen dat het proces wat die trigger-tijd instelt, klaar is vòòr die in te stellen trigger-tijd.

[ Voor 8% gewijzigd door Gameboy op 24-10-2025 08:28 ]

[simnet]

Bugje:
Dao lijkt een issue te hebben met de scheduler als HomeAssistant API niet bereikbaar is. Ik kan het niet helemaal beoordelen; maar het volgende zie ik in de logging van de container terug:

code:

Oct 23 05:50:25 hass systemd[1]: Started podman-dao.service.
Oct 23 05:50:25 hass podman-dao-start[467]: e3c8cd35de29fe2d8819b8bdaa6761dde338e0140e1233894da5b01c61167f75
Oct 23 05:50:25 hass dao[562]: => directory dao_data exist
Oct 23 05:50:25 hass dao[562]: => /root/dao/data doesn't exist, made
Oct 23 05:50:25 hass dao[562]: => /root/dao/webserver/app/static/data exist
Oct 23 05:50:28 hass dao[562]: Setting up watches.
Oct 23 05:50:28 hass dao[562]: Watches established.
Oct 23 05:50:29 hass dao[562]: [2025-10-23 05:50:29 +0200] [25] [INFO] Starting gunicorn 23.0.0
Oct 23 05:50:29 hass dao[562]: [2025-10-23 05:50:29 +0200] [25] [INFO] Listening at: http://0.0.0.0:5001 (25)
Oct 23 05:50:29 hass dao[562]: [2025-10-23 05:50:29 +0200] [25] [INFO] Using worker: sync
Oct 23 05:50:29 hass dao[562]: [2025-10-23 05:50:29 +0200] [67] [INFO] Booting worker with pid: 67
Oct 23 05:50:29 hass dao[562]: [2025-10-23 05:50:29 +0200] [68] [INFO] Booting worker with pid: 68
Oct 23 05:50:30 hass dao[562]: Traceback (most recent call last):
Oct 23 05:50:30 hass dao[562]:   File "/root/dao/prog/da_scheduler.py", line 64, in <module>
Oct 23 05:50:30 hass dao[562]:     main()
Oct 23 05:50:30 hass dao[562]:     ~~~~^^
Oct 23 05:50:30 hass dao[562]:   File "/root/dao/prog/da_scheduler.py", line 59, in main
Oct 23 05:50:30 hass dao[562]:     da_sched = DaScheduler("../data/options.json")
Oct 23 05:50:30 hass dao[562]:   File "/root/dao/prog/da_scheduler.py", line 9, in __init__
Oct 23 05:50:30 hass dao[562]:     super().__init__(file_name)
Oct 23 05:50:30 hass dao[562]:     ~~~~~~~~~~~~~~~~^^^^^^^^^^^
Oct 23 05:50:30 hass dao[562]:   File "/root/dao/prog/da_base.py", line 106, in __init__
Oct 23 05:50:30 hass dao[562]:     super().__init__(hassurl=self.hassurl, token=self.hasstoken)
Oct 23 05:50:30 hass dao[562]:     ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 23 05:50:30 hass dao[562]:   File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py", line 36, in __init__
Oct 23 05:50:30 hass dao[562]:     self._assert_api_running()
Oct 23 05:50:30 hass dao[562]:     ~~~~~~~~~~~~~~~~~~~~~~~~^^
Oct 23 05:50:30 hass dao[562]:   File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/hassapi/client/base.py", line 41, in _assert_api>
Oct 23 05:50:30 hass dao[562]:     raise ClientError("Home Assistant API is not running.")
Oct 23 05:50:30 hass dao[562]: hassapi.exceptions.ClientError: Home Assistant API is not running.
Oct 23 14:41:34 hass dao[562]: ../data/options.json MODIFY
Oct 23 14:41:34 hass dao[562]: ./watchdog.sh: line 6: kill: (27) - No such process
Oct 23 14:41:34 hass dao[562]: Setting up watches.
Oct 23 14:41:34 hass dao[562]: Watches established.

Vervolgens lijkt de scheduler te crashen. Sinds 05:45 is er ook geen enkele actie meer geweest vanuit dao.
Het saven van de config zorgt er voor dat de watchdog de scheduler herstart. Daardoor gaat ie ook weer werken.

[Bravo]

Deikke schreef op donderdag 23 oktober 2025 @ 12:10:
Is het trouwens nodig om elk kwartier een nieuw plan te maken? Of geeft DAO de nieuwe instellingen door aan Home Assistant na elk kwartier?

DAO geeft de instellingen door aan HA na het maken van het nieuwe plan. Er is nog geen functie om zonder het maken van een optimalisatie de instellingen van het nieuwe kwartier aan HA te sturen, dus ook voor een wijziging van de parameters in HA is een run nodig.

Zoals anderen al aangeven is het ook handig om regelmatig een nieuwe optimalisatie berekening te doen, om zo de afwijkingen ten opzichte van de planning mee te kunnen nemen.
Je hebt de inputs die een of een paar keer per dag wijzigen (prijs, meteo), maar ook je interne zaken zoals verbruik/huisload (nooit gelijk aan berekende of ingegeven load), pv opwek (is nooit gelijk aan meteo forecast), verwarming (wordt indirect gestuurd, dus afwijking), boiler (douche/bad wordt niet gepland waardoor temperatuur ondergrens eerder bereikt kan worden) en daardoor andere SOC-waarden van de batterij.
Machines heb ik buiten beschouwing gelaten wegens de 'instant start' functie.

[Torch1969]

Gameboy schreef op donderdag 23 oktober 2025 @ 13:32:
[...]


HomeAssistant's time-triggers "triggeren" alleen op de exacte opgegeven tijd (de aanvang dan de seconde). Dus als een ander proces eerst een trigger-tijd moet instellen (hoe kort ook), dan is die trigger-tijd in HA al voorbij, en zal die flow dus niet worden uitgevoerd.

Als je iets wilt triggeren in HA op een tijd, dan zul je moeten waarborgen dat het proces wat die trigger-tijd instelt, klaar is vòòr die in te stellen trigger-tijd.

DAO triggert niet iets in home assistant door middel van een tijd, maar schakelt een gekoppelde helper en via die helper de benodigde actie op een device. Of ik begrijp je niet goed?

[Gameboy]

Torch1969 schreef op donderdag 23 oktober 2025 @ 16:59:
[...]

DAO triggert niet iets in home assistant door middel van een tijd, maar schakelt een gekoppelde helper en via die helper de benodigde actie op een device. Of ik begrijp je niet goed?

Het is goed mogelijk dat ik je opmerking niet correct heb geïnterpreteerd Kun je de code van de HA trigger vermelden? En die van de helper die je gebruikt? En hoe dat door DAO wordt gebruikt?

[Torch1969]

Gameboy schreef op donderdag 23 oktober 2025 @ 17:29:
[...]


Het is goed mogelijk dat ik je opmerking niet correct heb geïnterpreteerd Kun je de code van de HA trigger vermelden? En die van de helper die je gebruikt? En hoe dat door DAO wordt gebruikt?

De opzet is als volgt:
DAO -> configuratie-item -> | -> HA entiteit/helper -> automatisering -> Device

Bijvoorbeeld (zie mijn een stukje terug)
DAO -> entity_set_power_feedin -> | -> input_number.dao_sessy_dllu_set_power_feedin -> automatisering -> number.sessy_dllu_power_setpoint
Waarin de automatisering bij wijziging van input_number.dao_sessy_dllu_set_power_feedin de waarde doorzet naar number.sessy_dllu_power_setpoint. Dat is de daadwerkelijke entiteit die de accu aan het laden of leveren set met het door DAO berekende wattage.

DAO doet uit zichzelf niets. Die moet je eerst een duw geven (via een operatie in de scheduler). Elke keer dat je dat doet, bekijkt DAO hoe de zaken ervoor staan (prijzen, zonvoorspelling, in DAO geplande acties, actuele SOC, baseload etc.) en berekent dan vanuit die actuele situatie de optimale strategie voor de komende kwartieren of uren (tot zover prijzen bekend zijn). Als laatste geeft DAO dan aan alle geconfigureerde gekoppelde HA entiteiten door wat er op dat moment moet gebeuren. Dit blijft dan de status totdat DAO de volgende operatie moet doen, en dan begint dit riedeltje opnieuw.

Daarom is het dus ook belangrijk om, als je kwartierprijzen hebt, elk kwartier deze optimalisatie berekening te doen, want die zorgt ervoor dat de juiste acties voor dat kwartier (voortkomend uit de prijs) worden gestart.

Ikzelf heb nog uurprijzen en doe deze berekening gewoon per uur.

[ Voor 9% gewijzigd door Torch1969 op 23-10-2025 18:30 ]

[Gameboy]

Torch1969 schreef op donderdag 23 oktober 2025 @ 18:25:
[...]

De opzet is als volgt:
DAO -> configuratie-item -> | -> HA entiteit/helper -> automatisering -> Device

Bijvoorbeeld (zie mijn een stukje terug)
DAO -> entity_set_power_feedin -> | -> input_number.dao_sessy_dllu_set_power_feedin -> automatisering -> number.sessy_dllu_power_setpoint
Waarin de automatisering bij wijziging van input_number.dao_sessy_dllu_set_power_feedin de waarde doorzet naar number.sessy_dllu_power_setpoint. Dat is de daadwerkelijke entiteit die de accu aan het laden of leveren set met het door DAO berekende wattage.

DAO doet uit zichzelf niets. Die moet je eerst een duw geven (via een operatie in de scheduler). Elke keer dat je dat doet, bekijkt DAO hoe de zaken ervoor staan (prijzen, zonvoorspelling, in DAO geplande acties, actuele SOC, baseload etc.) en berekent dan vanuit die actuele situatie de optimale strategie voor de komende kwartieren of uren (tot zover prijzen bekend zijn). Als laatste geeft DAO dan aan alle geconfigureerde gekoppelde HA entiteiten door wat er op dat moment moet gebeuren. Dit blijft dan de status totdat DAO de volgende operatie moet doen, en dan begint dit riedeltje opnieuw.

Daarom is het dus ook belangrijk om, als je kwartierprijzen hebt, elk kwartier deze optimalisatie berekening te doen, want die zorgt ervoor dat de juiste acties voor dat kwartier (voortkomend uit de prijs) worden gestart.

Ikzelf heb nog uurprijzen en doe deze berekening gewoon per uur.

Ok, en hoe ziet die automatisering eruit? Wat is daarvan de trigger? Want je zei dat die niet getriggerd was...

[KC27]

CopyCatz schreef op donderdag 23 oktober 2025 @ 01:15:
[...]


Done Hoe werkt het eigenlijk met testen? Ik gebruik dan mijn eigen fork om als addon in HA te zetten, blijven de gegevens bewaard als ik overschrijf?

Ik zal vanavond jouw PR goedkeuren en dan neem ik hem mee (samen met andere verbeteringen) naar een nieuwe testversie. Die kun je dan testen.

[Bravo]

Gameboy schreef op donderdag 23 oktober 2025 @ 18:37:
[...]


Ok, en hoe ziet die automatisering eruit? Wat is daarvan de trigger? Want je zei dat die niet getriggerd was...

In HA kunnen twee soorten entiteiten worden aangestuurd door DAO:
1. Getalwaarden voor entiteiten zoals ontlaadsnelheid etc
2. Tijd/kalenderwaarden voor start/stop momenten, zoals de start van een machine.

Als je een getal stuurt, kan dit als trigger worden gebruikt in een automation, die direct dat getal zal gebruiken. @Torch1969 heeft daar net een mooi voorbeeld voor gegeven.
Als je een kalender/tijd waarde stuurt, is dit vaak niet het moment dat er direct geacteerd moeten worden door een automation. Je bouwt in HA zelf een automation die als het passeren van het genoemde moment gebruikt om te starten.

Nadeel is alleen (en dat is volgens mij de case die door @Gameboy wordt beschreven) is dat als DAO een tijdstip stuurt die nu is, terwijl die daarvoor verder in de toekomst lag. Bijvoorbeeld dat hij om 20.00 uur doorgeeft dat een machine om 20.00 uur moet starten, terwijl deze eerder op 20.30 uur gepland stond.
Tegen de tijd dat die waarde in HA is opgenomen (run van 20.00 + rekentijd DAO + instellen entities in HA), is dat moment (20.00 uur exact, op de seconde nauwkeurig) verstreken en wordt de automation niet getriggerd in HA.

[KC27]

Bravo schreef op donderdag 23 oktober 2025 @ 19:50:
[...]

In HA kunnen twee soorten entiteiten worden aangestuurd door DAO:
1. Getalwaarden voor entiteiten zoals ontlaadsnelheid etc
2. Tijd/kalenderwaarden voor start/stop momenten, zoals de start van een machine.

Als je een getal stuurt, kan dit als trigger worden gebruikt in een automation, die direct dat getal zal gebruiken. @Torch1969 heeft daar net een mooi voorbeeld voor gegeven.
Als je een kalender/tijd waarde stuurt, is dit vaak niet het moment dat er direct geacteerd moeten worden door een automation. Je bouwt in HA zelf een automation die als het passeren van het genoemde moment gebruikt om te starten.

Nadeel is alleen (en dat is volgens mij de case die door @Gameboy wordt beschreven) is dat als DAO een tijdstip stuurt die nu is, terwijl die daarvoor verder in de toekomst lag. Bijvoorbeeld dat hij om 20.00 uur doorgeeft dat een machine om 20.00 uur moet starten, terwijl deze eerder op 20.30 uur gepland stond.
Tegen de tijd dat die waarde in HA is opgenomen (run van 20.00 + rekentijd DAO + instellen entities in HA), is dat moment (20.00 uur exact, op de seconde nauwkeurig) verstreken en wordt de automation niet getriggerd in HA.

Dat klinkt heel aannemelijk. Ik vermoed dat het alleen voorkomt bij het starten van machines en de boiler.
In dat geval zou daar door DAO niet 20:00 uur gecommuniceerd moeten worden, maar 20:00 uur plus de verstreken tijd plus nog ca 5 seconden extra verwerking en trigger tijd.
Klinkt dat werkbaar?

[Impossibl3]

Ik vroeg mij af hoe wordt door DAO nu de hysterese bepaald bij het plannen van de warmtepomp? In bijgevoegd figuur zie je de hysterese op en neer gaan en de prijs volgens DAO. De flinke daling in hysterese bij een prijs van €0,25 cent (ex belastingen etc) snap ik. Maar dezelfde wisselingen zie ik als de prijs veel minder scheelt tov de goedkoopste momenten. Zeker op dinsdag had ik de schommeling minder verwacht. Kan mij nog voorstellen dat op de andere dagen er een buffer wordt "opgebouwd" waarna die "leeg loopt" bij het €0,25+ moment en vervolgens weer "aangevuld" wordt.

Het gedrag zal aan de adjustment factor liggen maar ik snap niet helemaal de logica daarvan. Ook niet met de uitleg in de DOCS.

adjustment factor: float K/10% Het aantal graden voor de verschuiving van de stooklijn als de actuele da prijs 10% afwijkt van het daggemiddelde (niet voor on/off warmtepomp).

code:

  "heating": {
    "heater present": "True",
    "degree days factor": 4.1,
    "entity adjust heating curve": "input_number.dao_thermostaat_hysterese",
    "adjustment factor": 0.2,
    "stages": [
      { "max_power": 1566, "cop": 3.80 },
      { "max_power": 1387, "cop": 4.05 },
      { "max_power": 1283, "cop": 4.34 },
      { "max_power": 988,  "cop": 4.69 },
      { "max_power": 865,  "cop": 5.05 },
      { "max_power": 748,  "cop": 5.50 },
      { "max_power": 563,  "cop": 5.87 },
      { "max_power": 436,  "cop": 6.84 }
    ]
  },

Jaargegevens waarop de betreffende variabele heb bepaald.

[KC27]

Zojuist is testversie 2025.10.6.rc1 gepubliceerd.
Dit staat er in de changelog:

• Added extra check missing price-data, error-logging and stop calculation (idea from @balk )
• Extra check op "plugged in" and "home" for warning "te weinig tijd"
• Correct wrong pv->dc calculation
• Added mapping for "Aan" and "Uit" for "entity set operating mode" (thanks @CopyCatz )
• Moved remote resources for webpages to local (thanks @simnet )
• Updated several used python-modules

[eleet]

Hallo, hoe verhoudt DAO zich tot EMHASS in aanpak en features aub?

https://community.home-as...for-home-assistant/338126

[Animal]

Heeft iemand al de zonnebonus van Zonneplan kunnen integreren?
Mijn DAO werkt sinds gisteren super goed. Wat een mooie software.

Verder gebruik ik machines in DAO. Dit werkt goed alleen maakt de time window me niet zoveel uit. Ik wil het liefst alleen de helper veranderen van off naar stand 'eco' bijvoorbeeld.
De Start window stel ik in op 0:00 en de end window op 23:59. Dus de hele dag mag DAO de calculated start en end helper instellen.

Alleen de log zegt nu dit
2025-10-24 03:00:03 info: Machine wasmachine wordt niet ingepland, want het planning-window ligt voorbij einde optimalisering
Hoe kan ik dit het beste aanpakken zonder telkens mijn time window te hoeven aanpassen?

Verder krijg ik reports vaak:

code:

Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

[ Voor 82% gewijzigd door Animal op 24-10-2025 03:21 ]

[Torch1969]

Animal schreef op vrijdag 24 oktober 2025 @ 02:26:
Heeft iemand al de zonnebonus van Zonneplan kunnen integreren?
Mijn DAO werkt sinds gisteren super goed. Wat een mooie software.

Verder gebruik ik machines in DAO. Dit werkt goed alleen maakt de time window me niet zoveel uit. Ik wil het liefst alleen de helper veranderen van off naar stand 'eco' bijvoorbeeld.
De Start window stel ik in op 0:00 en de end window op 23:59. Dus de hele dag mag DAO de calculated start en end helper instellen.

Alleen de log zegt nu dit
2025-10-24 03:00:03 info: Machine wasmachine wordt niet ingepland, want het planning-window ligt voorbij einde optimalisering
Hoe kan ik dit het beste aanpakken zonder telkens mijn time window te hoeven aanpassen?

Verder krijg ik reports vaak:

code:

Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

Fijn dat het goed werkt en je enthousiast bent. De zonnebonus is in dit topic al een paar keer voorbij gekomen, als je even een zoekactie doet, vindt je een paar keer deze vraag en antwoord

Die machine instelling die je doet klinkt logisch, wat er denk ik gebeurd is dat DAO steeds het volgende hele tijdblok zoekt, en dat is steeds één dag verder dan dat de prijzen bekend zijn. Denk dat @KC27 hier het beste op kan antwoorden, net als de server error.

[Torch1969]

eleet schreef op donderdag 23 oktober 2025 @ 23:49:
Hallo, hoe verhoudt DAO zich tot EMHASS in aanpak en features aub?

https://community.home-as...for-home-assistant/338126

Toen ik me een jaar geleden op een EMS in home assistant oriënteerde was mijn beeld dat EMHASS meer internationaal gericht is, meer geconfigureerd kan worden, maar daardoor ook een stuk complexer. DAO is op Nederland gericht en wat eenvoudiger (maar voor de beginner nog steeds niet makkelijk) en voldeed aan mijn wensen. Als instap voor een EMS dus mijn keuze. Tot nu toe doet het nog steeds uitstekend wat ik wil.

[Impossibl3]

eleet schreef op donderdag 23 oktober 2025 @ 23:49:
Hallo, hoe verhoudt DAO zich tot EMHASS in aanpak en features aub?

https://community.home-as...for-home-assistant/338126

Wat ik begrijp heeft EMHASS niet een optie om een warmtepomp slim in te zetten op basis van cop curves bijvoorbeeld. De boiler zit er ook wat suffer in op basis van een elektrisch element. Dat zit in DAO beter in elkaar.