Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Impossibl3]

wmc schreef op maandag 17 november 2025 @ 14:39:
Hoe makkelijk is het om een thermisch model in DAO te implementeren, waarbij de huidige temperatuur wordt ingelezen, vergeleken wordt met een setpoint en op basis daarvan een inzet van de WP wordt berekend? Ik zie daarbij een aantal inputs:
- WP inzet (Thermisch/electrisch vermogen)
- Zoninstraling (zit al in het model)

Voor zover ik de literatuur ken is het thermisch model prima als combinatie eerste orde modellen te benaderen, waarbij de afkoeling van het huis bepaald wordt door de buitentemperatuur en de opwarming ook. Beide modellen hebben hun eigen tijdsconstanten:
Tin​[k+1]=Tin​[k]+ ts/C (Q​[k]−(Tin​[k]−Tout​[k]​)/R)

Hierbij zijn C en R specifieke tijdsconstanten en Q de hitte die het huis ingestopt wordt (die zit al in het model). Op basis van dit model kunnen grenzen ingesteld worden met hoeveel afwijking van de referentietemperatuur toegestaan is.

Kijk eens naar mijn voorstel: Impossibl3 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

Is dit in lijn met wat jij wil? Ik ben er nog niet aan toe gekomen maar zo iets wilde ik uitwerken.

[DaBit]

KC27 schreef op maandag 17 november 2025 @ 10:21:
Verder heb ik zelf in HA een automation draaien die het laden uitzet zodra de gewenste soc is bereikt (als een soort vangnet).

Ja, ik denk dat ik dat ook maar doe. Maar andersom, dus niet laden als het wel de bedoeling is, los je daarmee niet op. Behalve via een 'if geen oplossing and EV SoC < gewenst then gatochmaarladen' vangnet.

Tenslotte is nog de vraag: waarom is er "geen oplossing"? Heb je voor mij de hele logging?

Bij deze. Wil je ze van latere/eerdere kwartieren ook hebben?
Ik kan ook wel eens debug aanzetten, kijken of dat inzicht bied in die 'geen oplossing' die toch zo'n beetje dagelijks wel een keer voorkomt (en dan het kwartier erop dan meestal niet meer; meerdere kwartieren na elkaar is best uitzonderlijk)






Als je de 'geen data van nordpool' omdat het om bijvoorbeeld 12.55 nog te vroeg is eraf denkt is de rest 'geen oplossing voor minimize cost'

code:

 2025-11-17 06:00:06 info: Day Ahead Optimalisering versie: 2025.11.1.rc2
2025-11-17 06:00:06 info: Day Ahead Optimalisering gestart op: 17-11-2025 06:00:06
2025-11-17 06:00:06 info: Day Ahead Optimalisatie gestart: 17-11-2025 06:00:06 taak: calc_optimum
2025-11-17 06:00:06 info: Debug = False
2025-11-17 06:00:06 info: Zelf berekende baseload
2025-11-17 06:00:06 info: Start waarden: 
      uur                tijd  spot   p_l   p_t  base  pv_ac  pv_dc
0   06:00 2025-11-17 06:00:00 0.072 0.232 0.188 0.084  0.000      0
1   06:15 2025-11-17 06:15:00 0.073 0.233 0.189 0.090  0.000      0
2   06:30 2025-11-17 06:30:00 0.075 0.235 0.191 0.096  0.000      0
3   06:45 2025-11-17 06:45:00 0.075 0.236 0.192 0.116  0.000      0
4   07:00 2025-11-17 07:00:00 0.085 0.247 0.203 0.152  0.000      0
5   07:15 2025-11-17 07:15:00 0.090 0.254 0.210 0.172  0.000      0
6   07:30 2025-11-17 07:30:00 0.097 0.263 0.219 0.192  0.000      0
7   07:45 2025-11-17 07:45:00 0.100 0.266 0.222 0.192  0.009      0
8   08:00 2025-11-17 08:00:00 0.104 0.271 0.227 0.179  0.028      0
9   08:15 2025-11-17 08:15:00 0.106 0.273 0.230 0.179  0.040      0
10  08:30 2025-11-17 08:30:00 0.106 0.273 0.229 0.179  0.052      0
11  08:45 2025-11-17 08:45:00 0.104 0.270 0.227 0.174  0.075      0
12  09:00 2025-11-17 09:00:00 0.112 0.281 0.237 0.165  0.095      0
13  09:15 2025-11-17 09:15:00 0.099 0.265 0.221 0.160  0.118      0
14  09:30 2025-11-17 09:30:00 0.094 0.259 0.215 0.155  0.139      0
15  09:45 2025-11-17 09:45:00 0.085 0.247 0.203 0.149  0.205      0
16  10:00 2025-11-17 10:00:00 0.109 0.277 0.233 0.140  0.308      0
17  10:15 2025-11-17 10:15:00 0.091 0.255 0.212 0.134  0.381      0
18  10:30 2025-11-17 10:30:00 0.077 0.238 0.194 0.128  0.456      0
19  10:45 2025-11-17 10:45:00 0.062 0.219 0.176 0.130  0.547      0
20  11:00 2025-11-17 11:00:00 0.078 0.240 0.196 0.139  0.675      0
21  11:15 2025-11-17 11:15:00 0.073 0.233 0.189 0.141  0.773      0
22  11:30 2025-11-17 11:30:00 0.071 0.231 0.187 0.143  0.876      0
23  11:45 2025-11-17 11:45:00 0.063 0.221 0.177 0.140  0.879      0
24  12:00 2025-11-17 12:00:00 0.077 0.238 0.194 0.134  0.809      0
25  12:15 2025-11-17 12:15:00 0.073 0.233 0.189 0.132  0.814      0
26  12:30 2025-11-17 12:30:00 0.072 0.232 0.188 0.129  0.821      0
27  12:45 2025-11-17 12:45:00 0.070 0.230 0.186 0.125  0.820      0
28  13:00 2025-11-17 13:00:00 0.069 0.229 0.185 0.117  0.821      0
29  13:15 2025-11-17 13:15:00 0.072 0.231 0.188 0.113  0.845      0
30  13:30 2025-11-17 13:30:00 0.073 0.233 0.189 0.109  0.876      0
31  13:45 2025-11-17 13:45:00 0.079 0.240 0.196 0.118  0.823      0
32  14:00 2025-11-17 14:00:00 0.079 0.241 0.197 0.138  0.745      0
33  14:15 2025-11-17 14:15:00 0.080 0.241 0.198 0.147  0.692      0
34  14:30 2025-11-17 14:30:00 0.079 0.241 0.197 0.155  0.638      0
35  14:45 2025-11-17 14:45:00 0.084 0.246 0.203 0.151  0.542      0
36  15:00 2025-11-17 15:00:00 0.079 0.240 0.196 0.133  0.406      0
37  15:15 2025-11-17 15:15:00 0.083 0.245 0.201 0.129  0.241      0
38  15:30 2025-11-17 15:30:00 0.089 0.252 0.209 0.124  0.167      0
39  15:45 2025-11-17 15:45:00 0.093 0.258 0.214 0.133  0.119      0
40  16:00 2025-11-17 16:00:00 0.071 0.231 0.187 0.156  0.081      0
41  16:15 2025-11-17 16:15:00 0.084 0.247 0.203 0.165  0.035      0
42  16:30 2025-11-17 16:30:00 0.088 0.251 0.207 0.174  0.000      0
43  16:45 2025-11-17 16:45:00 0.101 0.267 0.223 0.168  0.000      0
44  17:00 2025-11-17 17:00:00 0.107 0.274 0.231 0.142  0.007      0
45  17:15 2025-11-17 17:15:00 0.114 0.283 0.239 0.136  0.001      0
46  17:30 2025-11-17 17:30:00 0.115 0.284 0.240 0.130  0.000      0
47  17:45 2025-11-17 17:45:00 0.116 0.285 0.241 0.159  0.000      0
48  18:00 2025-11-17 18:00:00 0.118 0.287 0.243 0.227  0.000      0
49  18:15 2025-11-17 18:15:00 0.114 0.283 0.239 0.256  0.000      0
50  18:30 2025-11-17 18:30:00 0.116 0.285 0.241 0.285  0.000      0
51  18:45 2025-11-17 18:45:00 0.116 0.285 0.241 0.263  0.000      0
52  19:00 2025-11-17 19:00:00 0.115 0.283 0.240 0.198  0.000      0
53  19:15 2025-11-17 19:15:00 0.112 0.281 0.237 0.176  0.000      0
54  19:30 2025-11-17 19:30:00 0.109 0.276 0.233 0.154  0.000      0
55  19:45 2025-11-17 19:45:00 0.107 0.274 0.230 0.148  0.000      0
56  20:00 2025-11-17 20:00:00 0.108 0.275 0.232 0.152  0.000      0
57  20:15 2025-11-17 20:15:00 0.107 0.274 0.231 0.146  0.000      0
58  20:30 2025-11-17 20:30:00 0.104 0.271 0.227 0.140  0.000      0
59  20:45 2025-11-17 20:45:00 0.086 0.249 0.206 0.137  0.000      0
60  21:00 2025-11-17 21:00:00 0.095 0.260 0.216 0.137  0.000      0
61  21:15 2025-11-17 21:15:00 0.089 0.252 0.208 0.134  0.000      0
62  21:30 2025-11-17 21:30:00 0.085 0.247 0.203 0.132  0.000      0
63  21:45 2025-11-17 21:45:00 0.080 0.242 0.198 0.129  0.000      0
64  22:00 2025-11-17 22:00:00 0.082 0.244 0.200 0.128  0.000      0
65  22:15 2025-11-17 22:15:00 0.085 0.247 0.203 0.126  0.000      0
66  22:30 2025-11-17 22:30:00 0.088 0.252 0.208 0.123  0.000      0
67  22:45 2025-11-17 22:45:00 0.085 0.247 0.203 0.120  0.000      0
68  23:00 2025-11-17 23:00:00 0.090 0.254 0.210 0.116  0.000      0
69  23:15 2025-11-17 23:15:00 0.084 0.246 0.202 0.112  0.000      0
70  23:30 2025-11-17 23:30:00 0.078 0.240 0.196 0.109  0.000      0
71  23:45 2025-11-17 23:45:00 0.072 0.232 0.188 0.106  0.000      0
2025-11-17 06:00:07 info: No reduced hours applied for Accu schuur
2025-11-17 06:00:07 info: Startwaarde SoC Accu schuur: 43.0%

2025-11-17 06:00:07 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-11-17 06:00:07 info: Instellingen voor laden van EV: Corsa-E
2025-11-17 06:00:07 info: Direct laden is uit
2025-11-17 06:00:07 info:  Ampere  Effic. Grid kW Accu kW
2025-11-17 06:00:07 info:    0.00    1.00    0.00    0.00
2025-11-17 06:00:07 info:    6.00    0.95    1.38    1.31
2025-11-17 06:00:07 info:    7.00    0.95    1.61    1.53
2025-11-17 06:00:07 info:    8.00    0.95    1.84    1.75
2025-11-17 06:00:07 info:   18.00    0.95    4.14    3.93
2025-11-17 06:00:07 info:   21.00    0.95    4.83    4.59
2025-11-17 06:00:07 info:   24.00    0.95    5.52    5.24
2025-11-17 06:00:07 info:   27.00    0.95    6.21    5.90
2025-11-17 06:00:07 info:   30.00    0.95    6.90    6.55
2025-11-17 06:00:07 info:   33.00    0.94    7.59    7.13
2025-11-17 06:00:07 info:   36.00    0.93    8.28    7.70
2025-11-17 06:00:07 info:   39.00    0.92    8.97    8.25
2025-11-17 06:00:07 info:   42.00    0.91    9.66    8.79
2025-11-17 06:00:07 info:   45.00    0.85   10.35    8.80
2025-11-17 06:00:07 info:   48.00    0.80   11.04    8.83
2025-11-17 06:00:07 info: Capaciteit accu: 47.0 kWh
2025-11-17 06:00:07 info: Maximaal laadvermogen: 11.04 kW
2025-11-17 06:00:07 info: Klaar met laden op: 17-11-2025 07:00:00
2025-11-17 06:00:07 info: Huidig laadniveau: 72.0 %
2025-11-17 06:00:07 info: Gewenst laadniveau:70.0 %
2025-11-17 06:00:07 info: Marge voor het laden: 1 %
2025-11-17 06:00:07 info: Locatie: home
2025-11-17 06:00:07 info: Ingeplugged:True
2025-11-17 06:00:07 info: Benodigde netto energie: 0.000 kWh
2025-11-17 06:00:07 info: Tijd nodig om te laden: 0:0 uur
2025-11-17 06:00:07 info: Afgerond naar hele intervallen: 0 kwartier
2025-11-17 06:00:07 info: Stand laden schakelaar: on
2025-11-17 06:00:07 info: Stand aantal ampere laden: 30.0 A
2025-11-17 06:00:07 info: Opladen wordt niet ingepland, omdat werkelijk niveau (72.0%) hoger is of gelijk aan gewenst niveau (70.0% minus de marge 1%).
2025-11-17 06:00:07 info: Instellingen voor laden van EV: boiler
2025-11-17 06:00:07 info: Direct laden is uit
2025-11-17 06:00:07 info:  Ampere  Effic. Grid kW Accu kW
2025-11-17 06:00:07 info:    0.00    1.00    0.00    0.00
2025-11-17 06:00:07 info:    4.00    0.93    0.92    0.86
2025-11-17 06:00:07 info:    5.00    0.93    1.15    1.07
2025-11-17 06:00:07 info:    6.00    0.95    1.38    1.31
2025-11-17 06:00:07 info:    7.00    0.97    1.61    1.56
2025-11-17 06:00:07 info:    8.00    0.99    1.84    1.82
2025-11-17 06:00:07 info:    9.00    0.99    2.07    2.05
2025-11-17 06:00:07 info:   10.00    0.99    2.30    2.28
2025-11-17 06:00:07 info: Capaciteit accu: 13.4 kWh
2025-11-17 06:00:07 info: Maximaal laadvermogen: 2.3 kW
2025-11-17 06:00:07 info: Klaar met laden op: 17-11-2025 08:00:00
2025-11-17 06:00:07 info: Huidig laadniveau: 27.2999992370605 %
2025-11-17 06:00:07 info: Gewenst laadniveau:70.0 %
2025-11-17 06:00:07 info: Marge voor het laden: 1 %
2025-11-17 06:00:07 info: Locatie: home
2025-11-17 06:00:07 info: Ingeplugged:False
2025-11-17 06:00:07 info: Benodigde netto energie: 5.722 kWh
2025-11-17 06:00:07 info: Tijd nodig om te laden: 2:31 uur
2025-11-17 06:00:07 info: Afgerond naar hele intervallen: 11 kwartier
2025-11-17 06:00:07 info: Stand laden schakelaar: on
2025-11-17 06:00:07 info: Stand aantal ampere laden: 10.0 A
2025-11-17 06:00:07 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd.
2025-11-17 06:00:07 info: Gewogen graaddagen: 24.1 K.day
2025-11-17 06:00:07 info: Degree days factor: 3.6 kWh/K.day
2025-11-17 06:00:07 info: Reeds geproduceerde warmte: 4.0 kWh
2025-11-17 06:00:07 info: Nog benodigde warmte: 82.6 kWh
2025-11-17 06:00:07 info: Actuele warmtevraag: Ja
2025-11-17 06:00:07 info: Warmtepomp met power-regeling wordt ingepland

2025-11-17 06:00:07 info: Strategie: minimale kosten
2025-11-17 06:00:07 info: Maximale fout (maximal gap): 0.005000 euro
2025-11-17 06:00:14 info: Rekentijd: 7.26  sec
2025-11-17 06:00:14 waarschuwing: Geen oplossing voor: minimize cost

Config:

code:

{
  "homeassistant": { 
     "protocol api": "http",
     "host": "192.168.100.18",
     "ip port": 8123,
     "token": "!secret ha_api_token"
  },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "meteoserver-model": "harmonie",
  "meteoserver-attemps": 2,
  "interval": "15min",
  "prices": {
    "source day ahead": "nordpool",
    "entsoe-api-key": "!secret entsoe-api-key",
    "energy taxes consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": 0.0181
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2025-01-01": -0.0181
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2025-02-27",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.40,
    0.40,
    0.40,
    0.40,
    0.65,
    0.65,
    0.65,
    0.65,
    0.90,
    1.30,
    2.00,
    1.80,
    1.70,
    1.30,
    1.10,
    1.30,
    1.60,
    1.60,
    0.90,
    0.90,
    0.90,
    0.70,
    0.70,
    0.50
  ],
  "graphical backend": "",
  "graphics": {
    "style": "dark_background",
    "show" : "true",
    "battery balance": "True",
    "prices delivery": "False",
    "prices redelivery": "True",
    "average delivery": "False",
    "prices consumption": "True",
    "prices production": "True",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
        "notification entity": "input_text.dao_notification"
  },
  "grid": {
    "max_power": 18
  },
  "history": {
    "save days": 14
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_boiler_temperature",
    "entity setpoint": "input_number.boiler_desiredtemperature",
    "cop": 1.0,
    "cooling rate": 0.4,
    "volume": 100,
    "heating allowed below": 70,
    "elec. power": 2100,
    "entity hysterese": "input_number.boiler_hysterese",
    "activate service": "turn_on",
    "activate entity": "input_boolean.dao_boiler_activate"
  },
  "heating": {
    "heater present": "True",
    "entity hp enabled": "input_boolean.always_true",
    "entity hp heat produced": "sensor.heatpump_daily_energy_production",
    "adjustment": "heating curve",
    "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.hp_lwt_adjust",
    "adjustment factor": 0.05
  },
  "battery": [ 
          {
        "name": "Accu schuur",
        "entity actual level": "sensor.victron_battery_state_of_charge_system",
        "capacity": 31,
        "upper limit": 100,
        "lower limit": 25,
        "optimal lower level": 30,
        "entity min soc end opt": "input_number.bat_min_soc_einde_opt",
        "entity max soc end opt": "input_number.bat_max_soc_einde_opt",
      "charge stages": [
            {
              "power": 0,
              "efficiency": 1
            },
            {
              "power": 180,
              "efficiency": 0.711
            },
            {
              "power": 495,
              "efficiency": 0.806
            },
            {
              "power": 591,
              "efficiency": 0.838
            },
            {
              "power": 651,
              "efficiency": 0.848
            },
            {
              "power": 798,
              "efficiency": 0.865
            },
            {
              "power": 1140,
              "efficiency": 0.895
            },
            {
              "power": 1446,
              "efficiency": 0.913
            },
            {
              "power": 2274,
              "efficiency": 0.920
            },
            {
              "power": 2456,
              "efficiency": 0.920
            },
        {
              "power": 3009,
              "efficiency": 0.922
        },
        {
              "power": 4170,
              "efficiency": 0.921
            },
        {
              "power": 5298,
              "efficiency": 0.916
            },
        {
              "power": 6200,
              "efficiency": 0.910
            },
            {
              "power": 7116,
              "efficiency": 0.906
            },
            {
              "power": 8100,
              "efficiency": 0.885
            },
        {
              "power": 9000,
              "efficiency": 0.80
            },
        {
              "power": 10500,
              "efficiency": 0.75
            }
   ],
   "discharge stages": [
            {
              "power": 0,
              "efficiency": 1
            },
            {
              "power": 117,
              "efficiency": 0.661
            },
            {
              "power": 192,
              "efficiency": 0.762
            },
            {
              "power": 315,
              "efficiency": 0.835
            },
            {
              "power": 579,
              "efficiency": 0.902
            },
            {
              "power": 837,
              "efficiency": 0.927
            },
            {
              "power": 1206,
              "efficiency": 0.941
            },
            {
              "power": 1467,
              "efficiency": 0.95
            },
            {
              "power": 1866,
              "efficiency": 0.957
            },
            {
              "power": 2262,
              "efficiency": 0.956
            },
            {
              "power": 3300,
              "efficiency": 0.956
            },
        {
              "power": 4398,
              "efficiency": 0.950
            },
        {
              "power": 5430,
              "efficiency": 0.944
            },
        {
              "power": 6564,
              "efficiency": 0.935
            },
            {
              "power": 7230,
              "efficiency": 0.929
            },
        {
              "power": 8235,
              "efficiency": 0.919
            },
            {
              "power": 9360,
              "efficiency": 0.909
            },
        {
              "power": 10312,
              "efficiency": 0.80
            },
            {
              "power": 11265,
              "efficiency": 0.75
            },
            {
              "power": 12378,
              "efficiency": 0.70
            }
          ],
          "minimum power": 300,
          "dc_to_bat efficiency": 0.98,
          "bat_to_dc efficiency": 0.98,
          "cycle cost": 0.005,
          "entity set power feedin": "input_number.batt_power_feedin",
          "entity set operating mode": "input_select.batt_operating_mode",
          "entity stop inverter": "input_datetime.batt_inverter_stop",
          "entity balance switch": "input_boolean.batt_balance_switch",
          "solar": [ ]
      }
  ],
  "solar": [ 
    {
      "name": "Growatt oostkant",
      "tilt": 35,
      "orientation": 270,
      "capacity": 4.4,
      "yield": 0.008,
      "entity pv switch": "input_boolean.pv_huis_onoff"
    },
    {
      "name": "Growatt westkant",
      "tilt": 35,
      "orientation": 90,
      "capacity": 4.4,
      "yield": 0.008,
      "entity pv switch": "input_boolean.pv_huis_onoff"
    },
    {
      "name": "schuur zuid",
      "tilt": 35,
      "orientation": 0,
      "capacity": 0.88,
      "yield": 0.0026,
      "entity pv switch": "input_boolean.pv_schuur_onoff"
    },
    {
      "name": "schuur midden",
      "tilt": 35,
      "orientation": 0,
      "capacity": 0.88,
      "yield": 0.0026,
      "entity pv switch": "input_boolean.pv_schuur_onoff"
    },
    {
      "name": "schuur noord",
      "tilt": 35,
      "orientation": 0,
      "capacity": 0.88,
      "yield": 0.0026,
      "entity pv switch": "input_boolean.pv_schuur_onoff"
    },
    {
      "name": "schuur platnoord",
      "tilt": 10,
      "orientation": 180,
      "capacity": 1.1,
      "yield": 0.0021,
      "entity pv switch": "input_boolean.pv_schuur_onoff"
    },
    {
      "name": "erker",
      "tilt": 10,
      "orientation": 270,
      "capacity": 0.55,
      "yield": 0.0006,
      "entity pv switch": "input_boolean.pv_huis_onoff"
    },
    {
      "name": "aanbouw",
      "tilt": 10,
      "orientation": 90,
      "capacity": 1.1,
      "yield": 0.0016,
      "entity pv switch": "input_boolean.pv_huis_onoff"
    }
  ],
  "electric vehicle": [ 
    {
      "name": "Corsa-E",
      "capacity": 47.0,
      "entity max amperage": "input_number.ev_max_charge_amps",
      "entity position": "input_select.corsae_location",
      "entity instant start": "input_boolean.dao_nu_laden",
      "entity instant level": "input_number.dao_nu_laden_soc",
      "charge three phase": "False",
      "charge stages" : [
      {"ampere":  0, "efficiency" :  1},
            {"ampere":  6, "efficiency": 0.95},
            {"ampere":  7, "efficiency": 0.95},
            {"ampere":  8, "efficiency": 0.95},
            {"ampere": 18, "efficiency": 0.95},
            {"ampere": 21, "efficiency": 0.95},
            {"ampere": 24, "efficiency": 0.95},
            {"ampere": 27, "efficiency": 0.95},
      {"ampere": 30, "efficiency": 0.95},
            {"ampere": 33, "efficiency": 0.94},
            {"ampere": 36, "efficiency": 0.93},
            {"ampere": 39, "efficiency": 0.92},
            {"ampere": 42, "efficiency": 0.91},
            {"ampere": 45, "efficiency": 0.85},
            {"ampere": 48, "efficiency": 0.80}
      ],
      "entity actual level": "sensor.corsa_e_battery_percent",
      "entity plugged in": "binary_sensor.charger_pluggedin",
      "charge scheduler": {
        "entity set level": "input_number.ev_desired_chargelevel",
        "level margin": 1,
        "entity ready datetime": "input_datetime.charge_ready_datetime"
      },
      "charge switch": "input_boolean.corsae_charge_switch",
      "entity set charging ampere": "input_number.dao_laadpaal_amp"
    },
    {
      "name": "boiler",
      "capacity": 13.4,
      "entity max amperage": "input_number.ev_max_charge_amps",
      "entity position": "input_select.corsae_location",
      "charge three phase": "False",
      "charge stages" : [
        {"ampere":  0,  "efficiency":  1},
        {"ampere":  4,  "efficiency": 0.93 },
        {"ampere":  5,  "efficiency": 0.93 },
        {"ampere":  6,  "efficiency": 0.95 },
        {"ampere":  7,  "efficiency": 0.97 },
        {"ampere":  8,  "efficiency": 0.99 },
        {"ampere":  9,  "efficiency": 0.99 },
        {"ampere":  10,  "efficiency": 0.99 }
      ],
      "entity actual level": "sensor.boiler_boiler_temperature",
      "entity plugged in": "binary_sensor.electricity_cheaperthangas",
      "charge scheduler": {
        "entity set level": "input_number.boiler_desiredtemperature",
        "level margin": 1,
        "entity ready datetime": "input_datetime.dao_boiler_ready_datetime"
      },
      "charge switch": "input_boolean.dao_boiler_activate",
      "entity set charging ampere": "input_number.dao_boiler_ampsetpoint"
    }
  ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.energy_consumption_tarif_1",
      "sensor.energy_consumption_tarif_2"
    ],
    "entities grid production": [
      "sensor.energy_production_tarif_1",
      "sensor.energy_production_tarif_2"
    ],
    "entities solar production ac": [
      "sensor.pv_opbrengst_huisdak",
      "sensor.noordkant_yieldtotal",
      "sensor.midden_schuur_yieldtotal",
      "sensor.zuidkant_yieldtotal",
      "sensor.schuur_opnoorden_yieldtotal",
      "sensor.aanbouw_yieldtotal",
      "sensor.erker_yieldtotal"
    ],
   "entities solar production dc": [],
    "entities ev consumption" : ["sensor.laadpaal_energieverbruik_kwh", "sensor.boiler_boiler_daily_energy"],
    "entities wp consumption" : ["sensor.warmtepomp_energieverbruik"],
    "entities machine consumption": [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.victron_energy_into_battery"],
    "entities battery production": ["sensor.victron_energy_from_battery"]  },
  "scheduler": {
    "active": "true",
    "0433": "get_meteo_data",
    "0930": "calc_baseloads",
    "1033": "get_meteo_data",
    "1633": "get_meteo_data",
    "2233": "get_meteo_data",
    "2235": "calc_baseloads",
    "xx55": "get_day_ahead_prices",
    "2359": "clean_data"
  }
}

Start DAO calc is bij mij uit de scheduler en vervangen door een HA automatie:

code:

alias: Trigger DAO calc
description: ""
triggers:
  - trigger: time_pattern
    minutes: /15
    seconds: "2"
    hours: "*"
conditions: []
actions:
  - action: rest_command.start_dao_calc
    metadata: {}
    data: {}
mode: single

[Ferrox1]

wmc schreef op maandag 17 november 2025 @ 14:39:
Hoe makkelijk is het om een thermisch model in DAO te implementeren, waarbij de huidige temperatuur wordt ingelezen, vergeleken wordt met een setpoint en op basis daarvan een inzet van de WP wordt berekend? Ik zie daarbij een aantal inputs:
- WP inzet (Thermisch/electrisch vermogen)
- Zoninstraling (zit al in het model)

Voor zover ik de literatuur ken is het thermisch model prima als combinatie eerste orde modellen te benaderen, waarbij de afkoeling van het huis bepaald wordt door de buitentemperatuur en de opwarming ook. Beide modellen hebben hun eigen tijdsconstanten:
Tin​[k+1]=Tin​[k]+ ts/C (Q​[k]−(Tin​[k]−Tout​[k]​)/R)

Hierbij zijn C en R specifieke tijdsconstanten en Q de hitte die het huis ingestopt wordt (die zit al in het model). Op basis van dit model kunnen grenzen ingesteld worden met hoeveel afwijking van de referentietemperatuur toegestaan is.

Ik heb zoiets al draaien, maar zou fijner zijn als DAO deze constanten afleid inderdaad. Voor mij ook boven mijn pet om dit daarin te implementeren. maar komt op hetzelfde neer. Ik bereken de opwarmtijd naar de gewenste temperatuur. Zie mijn post hier

[KC27]

wmc schreef op maandag 17 november 2025 @ 14:39:
Hoe makkelijk is het om een thermisch model in DAO te implementeren, waarbij de huidige temperatuur wordt ingelezen, vergeleken wordt met een setpoint en op basis daarvan een inzet van de WP wordt berekend? Ik zie daarbij een aantal inputs:
- WP inzet (Thermisch/electrisch vermogen)
- Zoninstraling (zit al in het model)

Voor zover ik de literatuur ken is het thermisch model prima als combinatie eerste orde modellen te benaderen, waarbij de afkoeling van het huis bepaald wordt door de buitentemperatuur en de opwarming ook. Beide modellen hebben hun eigen tijdsconstanten:
Tin​[k+1]=Tin​[k]+ ts/C (Q​[k]−(Tin​[k]−Tout​[k]​)/R)

Hierbij zijn C en R specifieke tijdsconstanten en Q de hitte die het huis ingestopt wordt (die zit al in het model). Op basis van dit model kunnen grenzen ingesteld worden met hoeveel afwijking van de referentietemperatuur toegestaan is.

Dit klinkt interessant, net als het uitgewerkte model van @Impossibl3 .
Ik ga eens kijken of ik een en/of ander in DAO kan implementeren, maar kan helaas niet op de korte termijn.
Nog even een paar vragen:
Waar staat ts voor?
Wat is de dimensie van C en R en waar staan ze voor?
Kan ik het ook zo schrijven (voor de duidelijkheid):
T_{i, k+1} = T_{i, k} + (ts/C) x (Q_k - (T_{i, k} -T_{u, k})/R)
waarbij zijn:
T_{i, k} : de binnentemperatuur aan het begin van interval k in °C
T_{u, k} : de buitemperatuur aan het begin van interval k, in °C
ts ?
C ?
Q_k de hoeveelheid warmte die gedurende interval k wordt toegevoerd in kWh?
R ?

[wmc]

De symbolen zijn gedefinieerd als:
ts: sampletijd, voor een thermisch systeem kan dit prima de 15 minuten zijn van DAO
C: Thermische capaciteit van het huis (J/K)
R: Thermische weerstand van het huis (K/W)
Q: Thermisch vermogen (W)
T_k: Is de temperatuur op de vorige tijdstap (K)

[wmc]

Impossibl3 schreef op maandag 17 november 2025 @ 15:47:
[...]


Kijk eens naar mijn voorstel: Impossibl3 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

Is dit in lijn met wat jij wil? Ik ben er nog niet aan toe gekomen maar zo iets wilde ik uitwerken.

Dit lijkt er wel veel op, ik moet het in detail nog bekijken.
Zoals ik de uitleg nu lees, nog niet helemaal. Het doel is de temperatuur te voorspellen op basis van de inputs die gegeven worden. Het doel is te bepalen wanneer het optimaal is om de warmtepomp in te zetten gegeven de gewenste temperatuur, met constraints op de minimum en maximum temperatuur. Aan het einde van de horizon moet de gewenste temperatuur gehaald zijn.

[ Voor 30% gewijzigd door wmc op 17-11-2025 17:53 ]

[KC27]

DaBit schreef op maandag 17 november 2025 @ 15:51:
[...]


Ja, ik denk dat ik dat ook maar doe. Maar andersom, dus niet laden als het wel de bedoeling is, los je daarmee niet op. Behalve via een 'if geen oplossing and EV SoC < gewenst then gatochmaarladen' vangnet.


[...]


Bij deze. Wil je ze van latere/eerdere kwartieren ook hebben?
Ik kan ook wel eens debug aanzetten, kijken of dat inzicht bied in die 'geen oplossing' die toch zo'n beetje dagelijks wel een keer voorkomt (en dan het kwartier erop dan meestal niet meer; meerdere kwartieren na elkaar is best uitzonderlijk)

[Afbeelding]

[Afbeelding]


Als je de 'geen data van nordpool' omdat het om bijvoorbeeld 12.55 nog te vroeg is eraf denkt is de rest 'geen oplossing voor minimize cost'


[...]


Config:


[...]


Start DAO calc is bij mij uit de scheduler en vervangen door een HA automatie:


[...]

Ik heb gevonden waarom het bij jou fout gaat (= geen oplossing). De benodigde warmte van je wp is meer dan hij kan leveren in de periode van de berekening. Deze fout gaat ik vandaag of morgen herstellen zie:
KC27 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

[DaBit]

KC27 schreef op maandag 17 november 2025 @ 19:52:
Ik heb gevonden waarom het bij jou fout gaat (= geen oplossing). De benodigde warmte van je wp is meer dan hij kan leveren in de periode van de berekening. Deze fout gaat ik vandaag of morgen herstellen zie:
KC27 in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"

Aha...
Ik gebruik "adjustment": "heating curve". Ik dacht dat die enkel op basis van afwijking van gemiddelde prijs verschoof? Of houd dat wel rekening met het aantal kWh dat er nog in het huis moet? Want dan moet ik dat eens serieus instellen.

[Impossibl3]

DaBit schreef op maandag 17 november 2025 @ 21:30:
[...]


Aha...
Ik gebruik "adjustment": "heating curve". Ik dacht dat die enkel op basis van afwijking van gemiddelde prijs verschoof? Of houd dat wel rekening met het aantal kWh dat er nog in het huis moet? Want dan moet ik dat eens serieus instellen.

Ja die maakt gebruikt van de verwachte totale warmtevraag van je woning op basis van gewogen graaddagen. Vandaar dat je "degree days factor" ook zo belangrijk is. Probleem is wel het systeem gaat uit van X kW nodig voor je woning. Het houdt geen rekening met zon instraling, open deuren etc.

Als je dus opeens extra kW's nodig hebt (omdat je de deur open had staan voor een langere tijd) dan stopt die omdat de benodigde theoretische kW's geleverd zijn. Of als er juist veel zon instraling is dan blijft die door gaan omdat de benodigde kW's nog niet geleverd zijn. De graaddagen houden enigszins rekening met het tweede. Het eerste is natuurlijk niet op te plannen.

Op basis van je parameters gaat die wel je stooklijn (of thermostaat) verschuiven aan de hand van de buiten temperatuur en de kosten van dat tijdsblok.

[ Voor 28% gewijzigd door Impossibl3 op 17-11-2025 22:16 ]

[DaBit]

Ik meende ergens gelezen te hebben dat die "adjustment": "heating curve" simpelweg de afwijking van de gemiddelde prijs in procenten nam en "adjustment factor" uitspuugt per 10% afwijking. Daar kun je dan de LWT en kamertemperatuur setpoint wat mee verstellen om zo de produktie van de WP wat te beinvloeden. Het lijkt zo te werken trouwens, al heb ik de getallen nog niet nagerekend.

Dat is overigens ook wat ik wil. Het bereikt het doel van 'betonbuffer' vullen met extra warmte als de stroom relatief goedkoop is en het verbruik reduceren tijdens de duurdere uren. De betonbuffer is te klein / warmtelek te groot om langdurig niet te verwarmen dus het is door DAO toch niet lang vooruit te plannen. En als klap op de vuurpijl kan ik niet zoveel met mijn warmtepomp (Daikin Altherma 3) als ik zou willen; LWT-offset veranderen gaat per hele graad en dat apparaat heeft sowieso een aardig eigen willetje.

[KC27]

DaBit schreef op dinsdag 18 november 2025 @ 08:27:
Ik meende ergens gelezen te hebben dat die "adjustment": "heating curve" simpelweg de afwijking van de gemiddelde prijs in procenten nam en "adjustment factor" uitspuugt per 10% afwijking. Daar kun je dan de LWT en kamertemperatuur setpoint wat mee verstellen om zo de produktie van de WP wat te beinvloeden. Het lijkt zo te werken trouwens, al heb ik de getallen nog niet nagerekend.

Dat is overigens ook wat ik wil. Het bereikt het doel van 'betonbuffer' vullen met extra warmte als de stroom relatief goedkoop is en het verbruik reduceren tijdens de duurdere uren. De betonbuffer is te klein / warmtelek te groot om langdurig niet te verwarmen dus het is door DAO toch niet lang vooruit te plannen. En als klap op de vuurpijl kan ik niet zoveel met mijn warmtepomp (Daikin Altherma 3) als ik zou willen; LWT-offset veranderen gaat per hele graad en dat apparaat heeft sowieso een aardig eigen willetje.

@Impossibl3 Het is precies zoals Dabit het zegt, maar jij hebt gedeeltelijk ook gelijk:
Om toch een goede indruk te krijgen van het verbruik per interval door de warmtepomp (o.a. ivm overschrijding van grid maximum, maar ook als je "nul op de meter" wil) wordt ook bij "adjustment": "heating curve" dezelfde verbruiksberekening uitgevoerd als bij "adjustment": "power" met alle voor- en nadelen vandien.

[thewhi]

wmc schreef op maandag 17 november 2025 @ 14:39:
Hoe makkelijk is het om een thermisch model in DAO te implementeren, waarbij de huidige temperatuur wordt ingelezen, vergeleken wordt met een setpoint en op basis daarvan een inzet van de WP wordt berekend? Ik zie daarbij een aantal inputs:
- WP inzet (Thermisch/electrisch vermogen)
- Zoninstraling (zit al in het model)

Voor zover ik de literatuur ken is het thermisch model prima als combinatie eerste orde modellen te benaderen, waarbij de afkoeling van het huis bepaald wordt door de buitentemperatuur en de opwarming ook. Beide modellen hebben hun eigen tijdsconstanten:
Tin​[k+1]=Tin​[k]+ ts/C (Q​[k]−(Tin​[k]−Tout​[k]​)/R)

Hierbij zijn C en R specifieke tijdsconstanten en Q de hitte die het huis ingestopt wordt (die zit al in het model). Op basis van dit model kunnen grenzen ingesteld worden met hoeveel afwijking van de referentietemperatuur toegestaan is.

Wind, zoninstraling en type afgifte (vloer/radiator/lucht) zijn (afhankelijk van de bouw) niet te onderschatten variabelen ;-)

[wmc]

thewhi schreef op dinsdag 18 november 2025 @ 11:21:
[...]


Wind, zoninstraling en type afgifte (vloer/radiator/lucht) zijn (afhankelijk van de bouw) niet te onderschatten variabelen ;-)

Oh absoluut. Het model dat ik voorstel is het simpelste mogelijk, waarbij afkoeling en ingaand vermogen gedefinieerd zijn. Mijn insteek met modelleren van het systeem is het simpelste model opschrijven dat de situatie juist beschrijft.

Afhankelijk van de ambitie kan er meer worden toegevoegd. Het grootste probleem is een parameter te bepalen die dit juist klassificeert. Hoe meer graden van vrijheid, hoe lastiger identificatie van het systeem is, bijvoorbeeld:
- De windrichting kan, naast de snelheid) opwarming en afkoeling anders beinvloeden, omdat het huis mogelijk beschut staat voor wind uit het noorden.
- De hoek van de zon kan invloed hebben op hoe het huis opwarmt. Voorbeeld voor mijn eigen huis: De zomerzon straalt zo goed als niet binnen omdat ik grote overhangen heb buiten het huis, in de herfst staan de bomen voor het huis nog in blad, waardoor de zon niet binnenkomt en in de winter staat hij wel laag genoeg om binnen te schijnen. Dat betekent dus een seizoensafhankelijke parameter (als het er al 1 is en het niet tijd van de dag afhankelijk is).

[KC27]

Testversie 2025.11.1.rc4 is gepubliceerd.
Ik hoop hiermee de fouten met "geen oplossing" door de warmtepomp te voorkomen.
Dit staat in de changelog:
Changes in "heatpump":
- maximization of the total heat to produce to prevent "no solution"
- extra logging heatpump

[Psycho_Mantis]

Ik gebruik sinds 2 weken DAO en ben zeer tevreden over de eenvoud en de duidelijke documentatie. Deze op het spoor gekomen nadat ik eerst verzopen ben geraakt in EMHASS.

Het werkt top voor de vaatwasser en de thuisaccu. Nu heb ik ook nog lucht/lucht warmtepompen (oftewel airco units), is dat de moeite waard om deze met DAO te schakelen?
Ik betwijfel of ik hiermee überhaupt iets zou kunnen besparen in energiekosten.

[DaBit]

KC27 schreef op dinsdag 18 november 2025 @ 11:57:
Testversie 2025.11.1.rc4 is gepubliceerd.

En geinstalleerd...

[Hedzie]

Waarschijnlijk draaien de meeste hier DAO met strategie ‘minimale kosten”.
Maar zijn er ook mensen welke “minimale levering” draaien?

Ik vind het vreemd dat er tussen 17.00 en 19.00 geen levering uit de accu plaats vind.
Maar wel om 23.00 als de prijs lager is.

[KC27]

Hedzie schreef op woensdag 19 november 2025 @ 18:03:
Waarschijnlijk draaien de meeste hier DAO met strategie ‘minimale kosten”.
Maar zijn er ook mensen welke “minimale levering” draaien?

Ik vind het vreemd dat er tussen 17.00 en 19.00 geen levering uit de accu plaats vind.
Maar wel om 23.00 als de prijs lager is.

[Afbeelding]

Wat zijn je instellingen van Sessy1?

[Hedzie]

KC27 schreef op woensdag 19 november 2025 @ 19:58:
[...]

Wat zijn je instellingen van Sessy1?

code:

battery": [ 
    {
      "name": "Sessy1",
      "entity actual level": "sensor.SoC",
      "capacity": 11.0,
      "upper limit": 100,
      "lower limit": 5,
      "optimal lower level": 5,
      "entity min soc end opt": "input_number.min_soc_end_opt",
      "entity max soc end opt": "input_number.max_soc_end_opt",
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 120.0,
          "efficiency": 0.7
        },
        {
          "power": 220.0,
          "efficiency": 0.758
        },
        {
          "power": 440.0,
          "efficiency": 0.850
        },
        {
          "power": 660.0,
          "efficiency": 0.892
        },
        {
          "power": 880.0,
          "efficiency": 0.912
        },
        {
          "power": 1320.0,
          "efficiency": 0.933
        },
        {
          "power": 1740.0,
          "efficiency": 0.942
        },
        {
          "power": 2200.0,
          "efficiency": 0.946
        },
        {
          "power": 2640.0,
          "efficiency": 0.942
        },
        {
          "power": 3080.0,
          "efficiency": 0.938
        },
        {
          "power": 3520.0,
          "efficiency": 0.929
        },
        {
          "power": 3960.0,
          "efficiency": 0.9211
        },
        {
          "power": 4400.0,
          "efficiency": 0.908
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 120.0,
          "efficiency": 0.7
        },
        {
          "power": 170.0,
          "efficiency": 0.735
        },
        {
          "power": 330.0,
          "efficiency": 0.829
        },
        {
          "power": 510.0,
          "efficiency": 0.882
        },
        {
          "power": 680.0,
          "efficiency": 0.921
        },
        {
          "power": 1020.0,
          "efficiency": 0.943
        },
        {
          "power": 1360.0,
          "efficiency": 0.957
        },
        {
          "power": 1700.0,
          "efficiency": 0.957
        },
        {
          "power": 2040.0,
          "efficiency": 0.953
        },
        {
          "power": 2380.0,
          "efficiency": 0.943
        },
        {
          "power": 2720.0,
          "efficiency": 0.936
        },
        {
          "power": 3060.0,
          "efficiency": 0.929
        },
        {
          "power": 3400.0,
          "efficiency": 0.925
        }
      ],
      "reduced hours":{ 
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.00,
      "entity stop inverter": "input_datetime.stop_sessy1",
      "entity set power feedin": "input_number.sessy1_power_setpoint",
      "entity set operating mode": "input_select.sessy1",
      "entity balance switch": "input_boolean.balanceer_sessy1_grid",
      "entity calculated soc": "input_number.sessy1_calculated_soc",
      "solar": []
    }
  ],

[DaBit]

KC27 schreef op dinsdag 18 november 2025 @ 11:57:
Testversie 2025.11.1.rc4 is gepubliceerd.
Ik hoop hiermee de fouten met "geen oplossing" door de warmtepomp te voorkomen.

Tot nu toe alleen de 12u55 'Geen data van Nordpool' meldingen, verder niks.

[wmc]

Klopt de weergave van de warmtepomp energie? Ik krijg de indruk dat er vermogen wordt weergegeven, terwijl er voor de zonnepanelen kWh/15 min in de grafiek lijkt te staan?

[KC27]

Hedzie schreef op woensdag 19 november 2025 @ 20:24:
[...]


[...]

Het is een afweging die DAO maakt tussen:
terugleveren met een kleiner vermogen en dus een slechter rendement
of
terugleveren een paar uur later met een hoger vermogen en een beter rendement
Hij probeert tegen zo laag mogelijke kosten zoveel mogelijk levering te voorkomen.

[KC27]

DaBit schreef op woensdag 19 november 2025 @ 20:30:
[...]


Tot nu toe alleen de 12u55 'Geen data van Nordpool' meldingen, verder niks.

Die van 12:55 had ik ook, de data waren nog niet beschikbaar. Gelukkig wel om 13:10.

[KC27]

wmc schreef op woensdag 19 november 2025 @ 20:41:
Klopt de weergave van de warmtepomp energie? Ik krijg de indruk dat er vermogen wordt weergegeven, terwijl er voor de zonnepanelen kWh/15 min in de grafiek lijkt te staan?

[Afbeelding]

Bij mij klopt het wel.
Kijk eens in de logging:

code:

2025-11-19 22:00:06 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 22:00    0.00     0.00   0.26   0.00   0.04   0.00   0.08   0.14   0.00   0.07   -0.00  47.88   0.00
 22:15    0.00     0.00   0.12   0.00   0.04   0.00   0.08   0.00   0.00   0.03   -0.00  47.75   0.00
 22:30    0.00     0.00   0.11   0.00   0.04   0.00   0.08   0.00   0.00   0.03   -0.00  47.62   0.00
 22:45    0.00     0.00   0.11   0.00   0.04   0.00   0.08   0.00   0.00   0.03   -0.00  47.50   0.00
 23:00    0.00     0.00   0.11   0.00   0.04   0.00   0.08   0.00   0.00   0.03   -0.00  47.37   0.00
 23:15    0.00     0.00   0.14   0.00   0.04   0.00   0.10   0.00   0.00   0.04   -0.00  47.25   0.00

In de kolom wp staan echt kWh.
Kloppen die bij jou met de grafiek?
Hoe heb je de vermogens ingesteld van je wp en met welke regeling stuur je hem aan?

[KC27]

Er is een nieuwe test- en productieversie gepubliceerd 2025.11.1.rc5 (test) en 2025.11.1 (productie)
De versies zijn identiek.
Dit staat in de changelog van de productieversie (daarin zijn alle rc's van 2025.11.1 opgenomen):

- upgrade python numpy-module
- upgrade debian-base

Changes in "heatpump":
- maximization of the total heat to produce to prevent "no solution"
- extra logging heatpump
- Fixed error with heatpump and heatpump-boiler with on/off adjustment
- Fixed error with on/off adjustement and not configured power-entity

- Fixed apparmor.txt for network-access
- Fixed report errors
- Respect minimal run length heatpump in hours with 15min-interva
- Suppress resource warning "unclosed database in sqlite3.Connection"
- Fix sorting-error mysql prices
- Fix error loading ev with too much power and exceeding grid-maximum (reported by @sMoKeFiSh)
- Update errors in DOCS.md

[balk]

@KC27 een tijdje terug hebben we gepraat over twee dingen:

• Het opslaan van kwartier-kosten en opbrengsten in de DB
• Het toevoegen van de config editor van @simnet

Beiden vergen een behoorlijke verbouwing. Heb je hier al verder over nagedacht?

[ Voor 17% gewijzigd door balk op 20-11-2025 08:11 ]

[wmc]

KC27 schreef op woensdag 19 november 2025 @ 22:21:
[...]

Bij mij klopt het wel.
Kijk eens in de logging:

code:

2025-11-19 22:00:06 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 22:00    0.00     0.00   0.26   0.00   0.04   0.00   0.08   0.14   0.00   0.07   -0.00  47.88   0.00
 22:15    0.00     0.00   0.12   0.00   0.04   0.00   0.08   0.00   0.00   0.03   -0.00  47.75   0.00
 22:30    0.00     0.00   0.11   0.00   0.04   0.00   0.08   0.00   0.00   0.03   -0.00  47.62   0.00
 22:45    0.00     0.00   0.11   0.00   0.04   0.00   0.08   0.00   0.00   0.03   -0.00  47.50   0.00
 23:00    0.00     0.00   0.11   0.00   0.04   0.00   0.08   0.00   0.00   0.03   -0.00  47.37   0.00
 23:15    0.00     0.00   0.14   0.00   0.04   0.00   0.10   0.00   0.00   0.04   -0.00  47.25   0.00

In de kolom wp staan echt kWh.
Kloppen die bij jou met de grafiek?
Hoe heb je de vermogens ingesteld van je wp en met welke regeling stuur je hem aan?

In de kolom staat een waarde die overeenkomt met het vermogen van de warmtepomp bij de gegeven temperatuur.

code:

2025-11-20 07:15:01 info: Reeds geproduceerde warmte: 67.6 kWh
2025-11-20 07:15:01 info: Nog benodigde warmte: 8.4 kWh
2025-11-20 07:15:01 info: Actuele warmtevraag: Ja
2025-11-20 07:15:01 info: On/off warmtepomp wordt ingepland
2025-11-20 07:15:01 info: Elektriciteit benodigd:4.3 kWh, cop: 5.0, vermogen:2.2 kW, warmtepomp draait: 2 uren

2025-11-20 07:15:02 info: 22:30 0.2749   2.17
2025-11-20 07:15:02 info: 22:45 0.2688   2.17
2025-11-20 07:15:02 info: 23:00 0.2751   2.17
2025-11-20 07:15:02 info: 23:15 0.2608   2.17
2025-11-20 07:15:02 info: 23:30 0.2566   2.17
2025-11-20 07:15:02 info: 23:45 0.2514   2.17

Als ik dit vergelijk met de benodigde warmte die berekend wordt klopt dat ook niet. De inzet van de warmtepomp is vervolgens wel juist en het huis blijft voldoende op temperatuur. Dit lijkt ook wel gekoppeld aan de minimale inzet tijd van de warmtepomp (die niet altijd wordt gerespecteerd zoals eerder aangegeven in dit topic).

[wmc]

Het lijkt met de nieuwste update (vanmorgen geinstalleerd) wel juist te zijn:

code:

2025-11-20 08:30:07 info: 10:15 0.3122   0.00
2025-11-20 08:30:07 info: 10:30 0.3043   0.54
2025-11-20 08:30:07 info: 10:45 0.2890   0.54
2025-11-20 08:30:07 info: 11:00 0.3038   0.54
2025-11-20 08:30:07 info: 11:15 0.2987   0.54
2025-11-20 08:30:07 info: 11:30 0.2981   0.54
2025-11-20 08:30:07 info: 11:45 0.2919   0.00

[KC27]

balk schreef op donderdag 20 november 2025 @ 05:42:
@KC27 een tijdje terug hebben we gepraat over twee dingen:

• Het opslaan van kwartier-kosten en opbrengsten in de DB
• Het toevoegen van de config editor van @simnet

Beiden vergen een behoorlijke verbouwing. Heb je hier al verder over nagedacht?

Ik ben afgelopen week bezig geweest met het verbeteren van de warmtepomp module en ik ben begonnen met de implementatie van de solar-voorspeller van @simnet. Dat heeft nu even mijn prioriteit.

Wat betreft het opslaan van kwartierkosten: daar zie ik nog een paar beren op de weg. Het belangrijkste is dat wanneer er iets aan de prijsconfiguratie verandert de prijzen en daarmee de berekende kosten niet kloppen. Ik zoek nog naar een oplossing hoe ik dat kan oplossen omdat ik meer dan tien dagen terug geen kwartierwaarden meer kan ophalen uit HA.

Wat betreft de config-editor van @simnet en jou: ik zie wel de meerwaarde daarvan maar de huidige versie op github is meer een proof of concept dan een goed werkende versie. Ik ben zelf niet goed genoeg in het ontwerpen en bouwen van een goede en goed werkende front-end voor dit doel. Dus ik heb een of twee personen nodig met de nodige skills die daar tijd in willen steken. Wie meldt zich?

[balk]

KC27 schreef op donderdag 20 november 2025 @ 09:41:
[...]

Ik ben afgelopen week bezig geweest met het verbeteren van de warmtepomp module en ik ben begonnen met de implementatie van de solar-voorspeller van @simnet. Dat heeft nu even mijn prioriteit.

Wat betreft het opslaan van kwartierkosten: daar zie ik nog een paar beren op de weg. Het belangrijkste is dat wanneer er iets aan de prijsconfiguratie verandert de prijzen en daarmee de berekende kosten niet kloppen. Ik zoek nog naar een oplossing hoe ik dat kan oplossen omdat ik meer dan tien dagen terug geen kwartierwaarden meer kan ophalen uit HA.

Wat betreft de config-editor van @simnet en jou: ik zie wel de meerwaarde daarvan maar de huidige versie op github is meer een proof of concept dan een goed werkende versie. Ik ben zelf niet goed genoeg in het ontwerpen en bouwen van een goede en goed werkende front-end voor dit doel. Dus ik heb een of twee personen nodig met de nodige skills die daar tijd in willen steken. Wie meldt zich?

Ik begrijp uiteraard dat je je aandacht wil verdelen tussen acute issues en grote veranderingen ik help graag mee. Programmeren is niet echt mijn ding maar meedenken moet wel lukken. Op GitHub loopt een draadje waarin door verschillende mensen nagedacht is over die kosten. Misschien kunnen we dat daar verder uitgewerken? En vanuit daar hulp zoeken voor de implementatie?

[Update94]

Hallo DAO-ers,

Ik heb al een tijdje een Panasonic 9J warmtepomp met fancoils voor verwarming en een 480 liter SWW vat, welke ik aanstuur met de Heishamon, Zonnepanelen met Enphase omvormers, een elektrische auto en 3*25A met Tibber als energieleverancier.

Dit alles hangt bij mij aan HA en ik wil de DAO al een tijdje graag proberen, echter draai ik alles in Docker, ook HA, waardoor Add-ons "niet bestaan". Het is me met behulp van de Readme gelukt om DAO in een aparte docker container op te starten en de HA database uit te laten lezen zoals omschreven in de uitleg.

Ik vraag me alleen nog af hoe de besturing van bijvoorbeeld het maken van warm water nu precies kan gaan lopen via DAO. Gaat deze gewoon dingen aanpassen/wijzigen in de HA-db om warm water te laten maken? Of werkt dit anders (en alleen als je de add-on gebruikt?) Home Assistant is zich nu niet bewust van het bestaan van DAO omdat die in een aparte docker container zit en "stiekem" de HA db uit doet lezen.

Is het ook een idee om helpers aan te maken in Home Assistant en die dan te laten omzetten door DAO om daar vervolgens automations of iets dergelijks aan te koppelen? Zijn er andere mensen die een soortegelijke docker setup hebben en hoe doen jullie dit?

Alvast bedankt.

[Torch1969]

Update94 schreef op donderdag 20 november 2025 @ 19:54:
….
Ik vraag me alleen nog af hoe de besturing van bijvoorbeeld het maken van warm water nu precies kan gaan lopen via DAO. Gaat deze gewoon dingen aanpassen/wijzigen in de HA-db om warm water te laten maken? Of werkt dit anders (en alleen als je de add-on gebruikt?) Home Assistant is zich nu niet bewust van het bestaan van DAO omdat die in een aparte docker container zit en "stiekem" de HA db uit doet lezen.

Is het ook een idee om helpers aan te maken in Home Assistant en die dan te laten omzetten door DAO om daar vervolgens automations of iets dergelijks aan te koppelen? Zijn er andere mensen die een soortegelijke docker setup hebben en hoe doen jullie dit?

Alvast bedankt.

Welkom bij de DAO community. Fijn dat je al zover bent gekomen. Heb je de Wiki op GitHub ook al gevonden? Daar staat ook uitleg over je vraag en idee
De koppeling verloopt inderdaad via home assistant entiteiten (bij voorkeur helpers).

[Update94]

Dit is precies de tip die ik nodig had, dankjewel!