• tomvandepoel3
  • Registratie: Januari 2026
  • Laatst online: 20:30
KC27 schreef op vrijdag 6 maart 2026 @ 11:36:
[...]

Ik denk niet dat het een domme user error is.
Als je dit doet:
code:
1
"entity cooling rate": "input_number.dao_yacuzzi_boiler_cooling_rate",
Dan vindt DAO de config regel "cooling rate" niet (dat is de key) en dus valt ie terug op de default-waarde: 0,5 K/uur

Misschien heeft het iets te maken met de eenheden (decimale punt of komma?)
Hoe staat dit bij jou in HA:
[Afbeelding]
OK. Dus geen "entity" toevoegen. Is logisch met deze uitleg.
Mijn HA instelling:
Afbeeldingslocatie: https://tweakers.net/i/jkC6hWG2hlNWjjmVRwEa2_fVziw=/fit-in/4920x3264/filters:max_bytes(3145728):no_upscale():strip_icc():strip_exif()/f/image/eyLgmQ1uW1ZNYngJXeohc0oF.jpg?f=user_large
Ik gebruik overal de decimale punt. Heb een snelle test gedaan door de taal van Engels naar Nederlands te wijzigen (plus HA restart), maar dat heeft geen effect.

Vervolgens zag ik dat ik ook een Unit of measurement had gebruikt voor mijn input number.
Afbeeldingslocatie: https://tweakers.net/i/0lX5-FdPI7JRdxj6Tq7QhFJr324=/fit-in/4920x3264/filters:max_bytes(3145728):no_upscale():strip_icc():strip_exif()/f/image/YnBrrtoNTpKg5SDtX9iwY6Fs.jpg?f=user_large
Ook die heb ik weggehaald maar helaas nog zonder resultaat.

Tenslotte heb ik ook nog "max gap" als flex entity geprobeerd. Daar werkt het prima met een entity met waarde 0.001 en een vaste waarde van 0.005. Dus ik denk niet dat het aan de decimale punt/komma ligt.

Dank voor het meedenken.

[ Voor 6% gewijzigd door tomvandepoel3 op 06-03-2026 14:25 ]


  • Mvdw
  • Registratie: September 2022
  • Nu online
KC27 schreef op vrijdag 6 maart 2026 @ 10:30:
[...]

Ik heb waarschijnlijk de fout gevonden.
DAO verwacht dat je "stages" in oplopende volgorde zijn gesorteerd (staat niet in de documentatie) en bij jou staan ze in aflopende volgorde.
Ik ga dat aanpassen, zodat het niet uitmaakt.
Voorlopig (om de problemen op te lossen) raad ik je aan om ze in oplopende volgorde te zetten.
Helaas toch niet de oplossing lijkt het. Vanaf 13.45 uur geen oplossing mogelijk met strategie minimize cost. Heatpump weer op False gezet en DAO rekent weer.

Dit is de output van de debug run:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
2026-03-06 16:56:42 info: Gewogen graaddagen vandaag: 6.0 K.day
2026-03-06 16:56:42 info: Gewogen graaddagen morgen: 8.3 K.day
2026-03-06 16:56:42 info: Gewogen graaddagen totaal: 14.4 K.day
2026-03-06 16:56:42 info: Degree days factor: 1.1 kWh/K.day
2026-03-06 16:56:42 info: Totaal benodigde warmte: 16.5 kWh
2026-03-06 16:56:42 info: Reeds geproduceerde warmte: 6.9 kWh
2026-03-06 16:56:42 info: Nog benodigde warmte: 9.7 kWh
2026-03-06 16:56:42 info: Regeling warmtepomp: heating curve
2026-03-06 16:56:42 info: Actuele warmtevraag: Nee
2026-03-06 16:56:42 info: Minimale runlengte 1 uur
2026-03-06 16:56:42 info: Warmtepomp met power-regeling/stooklijnverschuiving wordt ingepland.
2026-03-06 16:56:42 info: Maximaal warmteproducerend vermogen: 4.56 kW
2026-03-06 16:56:42 info: Minimaal warmteproducerend vermogen: 3.42 kW
2026-03-06 16:56:42 info: Aantal beschikbare uren: 30.00
2026-03-06 16:56:42 info: Maximaal te produceren hoeveelheid warmte: 132.5 kWh
2026-03-06 16:56:42 info: Minimaal te produceren hoeveelheid warmte: 99.4 kWh
2026-03-06 16:56:42 info: Aantal in te plannen uren: 2.0
2026-03-06 16:56:42 info: Warmtepomp staat stil
2026-03-06 16:56:42 info: Eerste blok van 1 uur
2026-03-06 16:56:42 info: Tussenin 0 blokken van 15 uur
2026-03-06 16:56:42 info: Laatste blok van 1.0 uur
2026-03-06 16:56:42 info: Totaal aantal blokken: 2
Het wijzigen van de degree days factor naar bijv 0.5 laat DAO wel rekenen:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2026-03-06 16:58:52 info: Gewogen graaddagen vandaag: 6.0 K.day
2026-03-06 16:58:52 info: Gewogen graaddagen morgen: 8.3 K.day
2026-03-06 16:58:52 info: Gewogen graaddagen totaal: 14.4 K.day
2026-03-06 16:58:52 info: Degree days factor: 0.5 kWh/K.day
2026-03-06 16:58:52 info: Totaal benodigde warmte: 7.2 kWh
2026-03-06 16:58:52 info: Reeds geproduceerde warmte: 6.9 kWh
2026-03-06 16:58:52 info: Nog benodigde warmte: 0.3 kWh
2026-03-06 16:58:52 info: Regeling warmtepomp: heating curve
2026-03-06 16:58:52 info: Actuele warmtevraag: Nee
2026-03-06 16:58:52 info: Minimale runlengte 1 uur
2026-03-06 16:58:52 info: Warmtepomp met power-regeling/stooklijnverschuiving wordt ingepland.
2026-03-06 16:58:52 info: Maximaal warmteproducerend vermogen: 4.56 kW
2026-03-06 16:58:52 info: Minimaal warmteproducerend vermogen: 3.42 kW
2026-03-06 16:58:52 info: Aantal beschikbare uren: 30.00
2026-03-06 16:58:52 info: Maximaal te produceren hoeveelheid warmte: 132.3 kWh
2026-03-06 16:58:52 info: Minimaal te produceren hoeveelheid warmte: 99.2 kWh
2026-03-06 16:58:52 info: Aantal in te plannen uren: 0.0
2026-03-06 16:58:52 info: Warmtepomp staat stil
2026-03-06 16:58:52 info: Omdat de wp meer dan 75% van de uren draait wordt de wp zonder "min_run_length"=1 ingepland.
Dankzij de zon is de woning opgewarmd tot 20.7 graden, setpoint thermstaat is 20.1. Geen idee of het relevant is maar meld het voor de zekerheid.

  • simnet
  • Registratie: Januari 2020
  • Laatst online: 18:05
Ik had vandaag weer een rare strategie met mijn battery. Om 16:45 besloot DAO om met volle vermogen te ontladen tot 16:47. Waarom gebeurt dit? Ik heb al eens eerder zulk gedrag gezien, maar dat is pas sinds recent.

Ik heb namelijk geen helper geconfigureerd om de eindtijd in te stoppen (die is volgens de documentatie optioneel) en dus de automation die al bijna een jaar perfect werkt klopt niet met dit gedrag.
Mijn DAO scheduler draait om de 15m, dus ik begrijp de keuze niet niet.
Wat moet mijn batterij na die 2 minuten doen? Wat is de strategie voor die overige 13minuten? blijven ontladen, of juist opladen? Uit gaan of NoM houden?

Is er een manier om het oude gedrag terug te krijgen? Die vond ik persoonlijk beter dan dit (enigszins onvoorspelbaar) gedrag. Ik kan me ook voorstellen dat het voor een omvormer misschien niet de levensduur bevorderd om dit soort bursting te doen. Maar daar heb ik te weinig verstand van.
Het komt in ieder geval de stabiliteit van de grid niet ten goede.

[ Voor 3% gewijzigd door simnet op 06-03-2026 18:05 ]


  • jeroenribbink
  • Registratie: November 2003
  • Nu online
thewhi schreef op donderdag 5 maart 2026 @ 09:26:
[...]


Het lijkt inderdaad inderdaad het gevolg van een timeout.
Ik heb even lopen zoeken, maar weet jij waar ik deze gunicorn.config kan lokaliseren?


[...]
Ik zie dat je al geholpen bent, maar om antwoord te geven op je vraag.
Ik verbind via Portainer met de docker in HA OS (agent zelf geïnstalleerd) en maak een console verbinding naar de DAO container.

Daar begin hij op /dao/prog maar gunicorn.config bevindt zich in /dao/webserver
Pagina: 1 ... 31 32 Laatste