Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[KC27]

mightym schreef op zaterdag 21 juni 2025 @ 16:28:
@KC27 Ik maak al ruim een jaar gebruik van jouw addon en ik ben erg tevreden over de werking. Ik loop tegen een configuratie dingetje aan. Mijn accu wordt geladen door 3 multiplussen en via een victron smartsolar wordt er maximaal 6kW via DC direct geladen.
De BMS dicteert de maximale laad en ontlaad stroomsterktes.
Als de Smartsolar al met 6kW aan het laden is, en DAO wil graag met 10kW laden, dan wordt het laadvermogen van de multiplussen begrensd doordat de maximale laadstroom overschreden wordt. De regeling verwacht in totaal 16kWh de accu's in te stoppen, in werkelijkheid is dat dan bijvoorbeeld 12kWh.

Is hier in de configuratie iets aan te doen?

Je kunt met de instellingen bat_to_dc max power en dc_to_bat max power het maximale vermogen van en naar de batterij (de cellen) begrenzen zie DOCS.md. Als je die optionele instellingen opgeeft zal DAO die bij de berekening respecteren.
Ben je hiermee geholpen?

[Impossibl3]

Ik ben vandaag ook gestart met de DOA installatie alleen loop ik bij het begin al tegen twee foutmeldingen aan.

1. mijn HA database is incorrect
2. mijn DOA database is incorrect.

Ik draai op HA MariaDB via add-on. Zo heb ik ook DOA geinstallerd. Ik begreep uit de handleiding dat ik dan niets hoefde aan te passen. Ik heb wat betreft punt 1 nog gecontroleerd of de gegevens uit de MariaDB config overeen komen (databasenaam en gebruikersnaam = homeassistant, password komt overeen met secrets.yaml). Ik begreep uit de handleiding dat ik "mysql" niet hoefde aan te passen als ik mariadb draaide. Is dat correct?

Hieronder de foutmeldingen:

code:

=> directory dao_data made, files copied
=> /root/dao/data doesn't exist, made
=> /root/dao/webserver/app/static/data exist
Setting up watches.
Watches established.
[2025-06-21 16:02:56 +0200] [15] [INFO] Starting gunicorn 23.0.0
[2025-06-21 16:02:56 +0200] [15] [INFO] Listening at: http://0.0.0.0:5000 (15)
[2025-06-21 16:02:56 +0200] [15] [INFO] Using worker: sync
[2025-06-21 16:02:57 +0200] [25] [INFO] Booting worker with pid: 25
[2025-06-21 16:02:57 +0200] [26] [INFO] Booting worker with pid: 26
fout:root:Check your settings for Home Assistant database
fout:root:Check your settings for day_ahead database

En de config:

code:

{
  "homeassistant": { },
  "database ha": {
    "engine": "mysql",
    "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",
  "prices": {
    "source day ahead": "nordpool",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "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
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
   "last invoice": "2022-09-01",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [ ],
  "solar": [ ],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.grid_consumption_low",
      "sensor.grid_consumption_high"
    ],
    "entities grid production": [
      "sensor.grid_production_low",
      "sensor.grid_production_high"
    ],
    "entities solar production ac": [
      "sensor.solaredge_woning_ac_energy_kwh"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.laadpunt_total_energy"],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.ess_grid_consumption"],
    "entities battery production": ["sensor.ess_grid_production"]
  },
  "scheduler": {
    "active": "false",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

De db_da_password heb ik in de DOA secret config aangepast net als de aanpassingen voor db_ha_password.

Als ik meteogegevens ophalen doe onder run krijg ik de volgende foutmeldingen:

code:

Logging van bewerking "Meteoprognoses ophalen":
fout:root:Check your settings for day_ahead database
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3429, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3392, in main
    da_calc = DaCalc("../data/options.json")
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 28, in __init__
    super().__init__(file_name=file_name)
  File "/root/dao/prog/da_base.py", line 202, in __init__
    self.db_da.log_pool_status()
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'log_pool_status'

Nu suggereren de foutmeldingen dat mijn wachtwoord voor de DOA database niet correct zijn. Maar deze heb ik toch echt maar 1x ingesteld en later niet veranderd. Is er ergens een plek waar ik het wachtwoord voor de DOA database toch kan achterhalen of opnieuw kan instellen?

Ik heb DOA al een keer verwijder en HA opnieuw opgestart dat deed niet de truc

[mightym]

KC27 schreef op zaterdag 21 juni 2025 @ 21:31:
[...]

Je kunt met de instellingen bat_to_dc max power en dc_to_bat max power het maximale vermogen van en naar de batterij (de cellen) begrenzen zie DOCS.md. Als je die optionele instellingen opgeeft zal DAO die bij de berekening respecteren.
Ben je hiermee geholpen?

Die had ik nog niet gevonden, ik ga het proberen!

[KC27]

Impossibl3 schreef op zaterdag 21 juni 2025 @ 22:02:
Ik ben vandaag ook gestart met de DOA installatie alleen loop ik bij het begin al tegen twee foutmeldingen aan.

1. mijn HA database is incorrect
2. mijn DOA database is incorrect.

Ik draai op HA MariaDB via add-on. Zo heb ik ook DOA geinstallerd. Ik begreep uit de handleiding dat ik dan niets hoefde aan te passen. Ik heb wat betreft punt 1 nog gecontroleerd of de gegevens uit de MariaDB config overeen komen (databasenaam en gebruikersnaam = homeassistant, password komt overeen met secrets.yaml). Ik begreep uit de handleiding dat ik "mysql" niet hoefde aan te passen als ik mariadb draaide. Is dat correct?

Hieronder de foutmeldingen:

code:

=> directory dao_data made, files copied
=> /root/dao/data doesn't exist, made
=> /root/dao/webserver/app/static/data exist
Setting up watches.
Watches established.
[2025-06-21 16:02:56 +0200] [15] [INFO] Starting gunicorn 23.0.0
[2025-06-21 16:02:56 +0200] [15] [INFO] Listening at: http://0.0.0.0:5000 (15)
[2025-06-21 16:02:56 +0200] [15] [INFO] Using worker: sync
[2025-06-21 16:02:57 +0200] [25] [INFO] Booting worker with pid: 25
[2025-06-21 16:02:57 +0200] [26] [INFO] Booting worker with pid: 26
fout:root:Check your settings for Home Assistant database
fout:root:Check your settings for day_ahead database

En de config:

code:

{
  "homeassistant": { },
  "database ha": {
    "engine": "mysql",
    "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",
  "prices": {
    "source day ahead": "nordpool",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "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
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "vat consumption": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat production": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
   "last invoice": "2022-09-01",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [ ],
  "solar": [ ],
  "electric vehicle": [ ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.grid_consumption_low",
      "sensor.grid_consumption_high"
    ],
    "entities grid production": [
      "sensor.grid_production_low",
      "sensor.grid_production_high"
    ],
    "entities solar production ac": [
      "sensor.solaredge_woning_ac_energy_kwh"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.laadpunt_total_energy"],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.ess_grid_consumption"],
    "entities battery production": ["sensor.ess_grid_production"]
  },
  "scheduler": {
    "active": "false",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

De db_da_password heb ik in de DOA secret config aangepast net als de aanpassingen voor db_ha_password.

Als ik meteogegevens ophalen doe onder run krijg ik de volgende foutmeldingen:

code:

Logging van bewerking "Meteoprognoses ophalen":
fout:root:Check your settings for day_ahead database
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3429, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3392, in main
    da_calc = DaCalc("../data/options.json")
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/webserver/../prog/day_ahead.py", line 28, in __init__
    super().__init__(file_name=file_name)
  File "/root/dao/prog/da_base.py", line 202, in __init__
    self.db_da.log_pool_status()
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'log_pool_status'

Nu suggereren de foutmeldingen dat mijn wachtwoord voor de DOA database niet correct zijn. Maar deze heb ik toch echt maar 1x ingesteld en later niet veranderd. Is er ergens een plek waar ik het wachtwoord voor de DOA database toch kan achterhalen of opnieuw kan instellen?

Ik heb DOA al een keer verwijder en HA opnieuw opgestart dat deed niet de truc

Ik draai ook mariadb als addon.
In mijn dao-addon heb ik de volgende instellingen:

code:

  "database da": {
    "password": "!secret db_da_password"
  },
  "database ha": {
    "password": "!secret db_ha_password"
  },

Omdat alle instellingen (behalve natuurlijk het wachtwoord) zoals ik die heb (exact hetzelfde als de jouwe) default zijn.
Ik heb op mijn laptop een ontwikkelomgeving en daar moet ik wel alles invullen. Bijvoorbeeld:

code:

  "database da": {
    "engine": "mysql",
    "server": "192.168.178.36",
    "port": 3306,
    "database": "day_ahead",
    "username": "day_ahead",
    "password": "!secret db_da_password"
  },

Verder is het belangrijk dat je de rechten van de accounts in mariadb goed hebt staan.
Je kunt dat checken en goed zetten met de phpmyadmin-addon:

[KC27]

Oh ja en ook niet onbelangrijk:
Vul poort 3306 in de config van mariadb-addon in:

[hemertje]

sjampeter schreef op zaterdag 21 juni 2025 @ 10:08:
[...]

jazeker. ik doe 1 run voor mijn boiler per dag. deze laat ik DAO uitrekenen en aansturen. werkt bijna perfect.

zou je @edterbak kunnen helpen met het de manier van Helpers aanmaken ?
Ed (en ik ook niet) heeft geen ervaring met DAO en/of HACS

maar een mooie integratie tussen beide tools DAO en Ed's Node Red zou super gaaf zijn

zie zijn verzoek hier:

edterbak in "Heishamon <> Node Red voor Panasonic warmtepompen"

[Impossibl3]

KC27 schreef op zaterdag 21 juni 2025 @ 22:34:
[...]

Ik draai ook mariadb als addon.
In mijn dao-addon heb ik de volgende instellingen:

code:

  "database da": {
    "password": "!secret db_da_password"
  },
  "database ha": {
    "password": "!secret db_ha_password"
  },

Omdat alle instellingen (behalve natuurlijk het wachtwoord) zoals ik die heb (exact hetzelfde als de jouwe) default zijn.
Ik heb op mijn laptop een ontwikkelomgeving en daar moet ik wel alles invullen. Bijvoorbeeld:

code:

  "database da": {
    "engine": "mysql",
    "server": "192.168.178.36",
    "port": 3306,
    "database": "day_ahead",
    "username": "day_ahead",
    "password": "!secret db_da_password"
  },

Verder is het belangrijk dat je de rechten van de accounts in mariadb goed hebt staan.
Je kunt dat checken en goed zetten met de phpmyadmin-addon:
[Afbeelding]

Super bedankt! Bleek dat mijn homeassistant niet alle rechten had. Daarnaast handmatig maar even een database aangemaakt via phpmyadmin en toen deed die het goed met het ophalen van de weergegevens!

Nu weer verder puzzelen.

[KC27]

Vandaag hebben we een nieuwe productieversie van DAO gepubliceerd.
Dit staat er in de changelog:

2025.6.2

• introduction new buildsystem (thanks @simnet )
• repair vat delivery -> vat consumption, vat redelivery -> vat production

Verder:

Deprecating i386, coming breaking change

In the next coming version (2025.7.0) machines with i386-processor will not be supported anymore.
Some necessary modules (o.a. cryptography) are not available for the i386 architecture.
There are a few users with this processor (5 of ca 200).
Please look out for another machine with an amd64 or aarch64 processor (perhaps a separate Docker-container on your NAS).

[storeman]

KC27 schreef op donderdag 19 juni 2025 @ 13:38:
@storeman
Bij een hybride omvormer heb je twee instellingen waarmee je het laden en ontladen kunt beperken:
De eerste heb je net genoemd
Er is nog een tweede: bat_to_dc max power en dc_to_bat max power, zie DOCS.md.
Ben je hiermee geholpen?

Dat is niet mijn use-case (of ik snap het niet). Ik zal proberen het duidelijker te noteren. Het gaat me hierbij niet om de exacte uitkomst van DAO vandaag, maar hoe een veld soms een gewenste en soms een ongewenste beperking is. Vandaag is een mooi voorbeeld:

Om 9u, iets hogere energieprijs
de accu zou geladen moeten met 1KW (hoger rendement in config), de rest mag terug het net in. Dus 'charge from PV' is dan 1KW.

Om 14 uur is de stroomprijs lager, DAO wil nog niet van AC laden, maar er is ook weinig zon voorspeld. DAO charge from PV is nu ook 1KW, maar dat komt door de verwachte instraling. Mocht de zon ineens doorbreken, dan wil ik alles in de accu stoppen, niet: slechts 1KW laden en de rest het net invoeden.

[sjampeter]

hemertje schreef op zaterdag 21 juni 2025 @ 22:45:
[...]




zou je @edterbak kunnen helpen met het de manier van Helpers aanmaken ?
Ed (en ik ook niet) heeft geen ervaring met DAO en/of HACS

maar een mooie integratie tussen beide tools DAO en Ed's Node Red zou super gaaf zijn

zie zijn verzoek hier:

edterbak in "Heishamon <> Node Red voor Panasonic warmtepompen"

ik ben ook (soort van) actief in dat draadje van edterbak, echter stel je eigen er niet teveel van voor hoor.
zeker niet van mijn programeercapaciteiten haha.
wat ik eigenlijk doe is het volgende.
ik geef in de instellingen van DAO aan, dat een dhw run ongeveer 9 kwartier duurt.
DAO rekent voor mij dan het beste tijdstip voor die run uit.
dit tijdstip komt in de entity "calculated start"

deze entitie lees ik in in Node-red, welke (met waarschijnlijk veel te veel omwegen) enkele external link nodes in "WP input" aciveert.
op manier wordt door DAO de dhw run aangestuurd.
qua verwarming doe ik helemaal niks, aangezien bij mij de wp, als het koud is, toch nagenoeg full-time moet draaien. enkel nachtverlaging pas ik soms toe, maar dat gaat gewoon via heishamon flow.

als je wil kan ik de node-red flow wel prive met je delen. moet wel nog opgepoetst worden eigenlijk. nog niet aan toegekomen. laat maar horen.

[patatman12]

Ik ben sinds gisteren ook over op DAO, en heb DESS uitgezet.
Het was even puzzelen, maar volgens mij heb ik de setup nu werkend.

Even wat over de setup:
1x Victron MultiPlus-II 48/5000/70-48
1x JK BMS 200a i.c.m. 16x Envision ESS 72173207 305Ah - LiFePO4 - 3.2V B-grade (16Kwh)
10x op het Oosten Canadian solar 295wp met een SAJ omvormer
14x op het westen Jinko Solar 375wp met een KOPP omvormer
1x Victron EV charger
Zonneplan met dynamisch contract

Het huis zit op de AC-out van de Victron, alleen de PV west en de EV charger zitten op de non-critical loads.
de 10 panelen van het oosten bewust wel op de AC-out, zodat in island mode ik de accu nog kan laden met solar.

Verbruikers:
1x Tesla model Y standard range (60 kwh)
1x Elektrisch boiler Tesy bellislimo 100 (volgende week aangesloten)
2x Airco's (moeten nog in DAO worden)

Victron is via MQTT aan Home Assistant gekoppeld. En ik gebruik geen Node-red.
Reden voor gebruik DAO is voornamelijk het slimmer aansturen van de verbruikers, zonder zelf 100 automations te hoeven schrijven. DESS kwam hier toch wel te kort, als je ook je verbruikers op slimme momenten kan aanzetten. Nu had ik bij negatieve prijzen dat ik zelf handmatig (lees via de app) dingen ging aanzetten om stroom te verbruiken.

Vannacht zag ik alleen iets interessants, namelijk de GridSetpoint niet niet helemaal logisch in mijn ogen. Deze is s'nachts Negatief, terwijl volgens de strategie deze positief zou moeten zijn toch? Het enige wat ik kan verzinnen, is dat de SOC op 20% stond inplaats van 10%.
Ik had een verschil tussen de min SOC in victron, en DAO. Deze staan nu gelijk op 20% min soc. Zou DAO de accu alsnog naar de 10% willen krijgen?






Mijn DAO Config:

code:

{
  "homeassistant": { },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "entsoe-api-key": "!secret entsoe-api-key",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "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,
      "2025-01-01": 0.01653
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2025-01-01": 0.01653
    },
    "vat delivery": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat redelivery": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat": {
      "2025-01-01": 21
    },
    "last invoice": "2024-09-01",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.35,
    0.35,
    0.35,
    0.35,
    0.35,
    0.38,
    0.45,
    0.65,
    0.70,
    0.40,
    0.38,
    0.40,
    0.50,
    0.40,
    0.38,
    0.40,
    0.55,
    0.70,
    0.85,
    0.80,
    0.90,
    0.75,
    0.50,
    0.40
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 9
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
  {
    "name": "JK Accu",
    "entity actual level": "sensor.battery_percent",
    "capacity": 16,
    "upper limit": 100,
    "lower limit": 10,
    "entity min soc end opt": "input_number.dao_min_soc_limit",
    "entity max soc end opt": "input_number.dao_max_soc_limit",
    "charge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 500,
          "efficiency": 0.785
        },
        {
          "power": 1000,
          "efficiency": 0.872
        },
        {
          "power": 1500,
          "efficiency": 0.897
        },
        {
          "power": 2000,
          "efficiency": 0.899
        },
        {
          "power": 2500,
          "efficiency": 0.898
        },
        {
          "power": 3000,
          "efficiency": 0.892
        },
        {
          "power": 3500,
          "efficiency": 0.882
        },
        {
          "power": 4000,
          "efficiency": 0.865
        }
      ],
    "discharge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 200,
          "efficiency": 0.891
        },
        {
          "power": 500,
          "efficiency": 0.935
        },
        {
          "power": 1000,
          "efficiency": 0.952
        },
        {
          "power": 1250,
          "efficiency": 0.962
        },
        {
          "power": 1500,
          "efficiency": 0.952
        },
        {
          "power": 2000,
          "efficiency": 0.950
        },
        {
          "power": 2500,
          "efficiency": 0.934
        },
        {
          "power": 3000,
          "efficiency": 0.925
        },
        {
          "power": 3500,
          "efficiency": 0.915
        },
        {
          "power": 4000,
          "efficiency": 0.900
        },
        {
          "power": 4350,
          "efficiency": 0.893
        }
      ],
    "minimum power": 100,
    "cycle cost": 0.01,
    "dc_to_bat efficiency": 0.98,
    "bat_to_dc efficiency": 0.99,
    "entity set power feedin": "input_number.dao_setpoint_jk",
    "solar": []
  }
],
  "solar": [
  {
    "name": "pv oost",
    "tilt": 35,
    "orientation": -90,
    "capacity": 2.95,
    "max power": 2.95,
    "yield": 0.0065,
    "entity pv switch": ""
  },
  {
    "name": "pv west",
    "tilt": 35,
    "orientation": 90,
    "capacity": 5.25,
    "max power": 5.25,
    "yield": 0.01116,
    "entity pv switch": ""
  }
],
  "electric vehicle": [],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.zonneplan_p1_electricity_consumption_today"
    ],
    "entities grid production": [
      "sensor.zonneplan_p1_electricity_returned_today"
    ],
    "entities solar production ac": [
      "sensor.energie_productie_oost",
      "sensor.energie_productie_west"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.ev_charger_consumption"],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.ess_grid_consumption"],
    "entities battery production": ["sensor.ess_grid_production"]
  },
  "scheduler": {
    "active": "true",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

[sjampeter]

over SOC gesproken, dit is inderdaad wel een dingetje.
ik heb zelf ook een victron.
SOC haal ik via modbus binnen in hass.
ik heb zelf ook nog wat accu beveiliging lopen via node-red.
feit is wel dat mijn SOC in principe niet lager kan dan 20 % en niet hoger als 95%.
vooral die ondergrens fluctureert wel wat, aangezien dit geen harde calculatie is.
ik houdt dus ook een marge aan betreffende SOC in DAO, wat wil zeggen een paar procent boven de eigenlijke onderste grens.
doe ik dit niet, blijft DAO proberen te ontladen in de berekeningen, waar echter de Victron/node-red dit blokkeert.
op dit moment nog niet mee bezig geweest om dit te fine-tunen.
iemand toevallig zelfde probleem/ oplossing?

[KC27]

patatman12 schreef op zondag 22 juni 2025 @ 11:57:
Ik ben sinds gisteren ook over op DAO, en heb DESS uitgezet.
Het was even puzzelen, maar volgens mij heb ik de setup nu werkend.

Even wat over de setup:
1x Victron MultiPlus-II 48/5000/70-48
1x JK BMS 200a i.c.m. 16x Envision ESS 72173207 305Ah - LiFePO4 - 3.2V B-grade (16Kwh)
10x op het Oosten Canadian solar 295wp met een SAJ omvormer
14x op het westen Jinko Solar 375wp met een KOPP omvormer
1x Victron EV charger
Zonneplan met dynamisch contract

Het huis zit op de AC-out van de Victron, alleen de PV west en de EV charger zitten op de non-critical loads.
de 10 panelen van het oosten bewust wel op de AC-out, zodat in island mode ik de accu nog kan laden met solar.

Verbruikers:
1x Tesla model Y standard range (60 kwh)
1x Elektrisch boiler Tesy bellislimo 100 (volgende week aangesloten)
2x Airco's (moeten nog in DAO worden)

Victron is via MQTT aan Home Assistant gekoppeld. En ik gebruik geen Node-red.
Reden voor gebruik DAO is voornamelijk het slimmer aansturen van de verbruikers, zonder zelf 100 automations te hoeven schrijven. DESS kwam hier toch wel te kort, als je ook je verbruikers op slimme momenten kan aanzetten. Nu had ik bij negatieve prijzen dat ik zelf handmatig (lees via de app) dingen ging aanzetten om stroom te verbruiken.

Vannacht zag ik alleen iets interessants, namelijk de GridSetpoint niet niet helemaal logisch in mijn ogen. Deze is s'nachts Negatief, terwijl volgens de strategie deze positief zou moeten zijn toch? Het enige wat ik kan verzinnen, is dat de SOC op 20% stond inplaats van 10%.
Ik had een verschil tussen de min SOC in victron, en DAO. Deze staan nu gelijk op 20% min soc. Zou DAO de accu alsnog naar de 10% willen krijgen?

[Afbeelding]

[Afbeelding]


Mijn DAO Config:

code:

{
  "homeassistant": { },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "nordpool",
    "entsoe-api-key": "!secret entsoe-api-key",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "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,
      "2025-01-01": 0.01653
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2025-01-01": 0.01653
    },
    "vat delivery": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat redelivery": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "vat": {
      "2025-01-01": 21
    },
    "last invoice": "2024-09-01",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.35,
    0.35,
    0.35,
    0.35,
    0.35,
    0.38,
    0.45,
    0.65,
    0.70,
    0.40,
    0.38,
    0.40,
    0.50,
    0.40,
    0.38,
    0.40,
    0.55,
    0.70,
    0.85,
    0.80,
    0.90,
    0.75,
    0.50,
    0.40
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "battery balance": "True",
    "prices consumption": "True",
    "prices production": "False",
    "prices spot": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
  },
  "grid": {
    "max_power": 9
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
  {
    "name": "JK Accu",
    "entity actual level": "sensor.battery_percent",
    "capacity": 16,
    "upper limit": 100,
    "lower limit": 10,
    "entity min soc end opt": "input_number.dao_min_soc_limit",
    "entity max soc end opt": "input_number.dao_max_soc_limit",
    "charge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 500,
          "efficiency": 0.785
        },
        {
          "power": 1000,
          "efficiency": 0.872
        },
        {
          "power": 1500,
          "efficiency": 0.897
        },
        {
          "power": 2000,
          "efficiency": 0.899
        },
        {
          "power": 2500,
          "efficiency": 0.898
        },
        {
          "power": 3000,
          "efficiency": 0.892
        },
        {
          "power": 3500,
          "efficiency": 0.882
        },
        {
          "power": 4000,
          "efficiency": 0.865
        }
      ],
    "discharge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 200,
          "efficiency": 0.891
        },
        {
          "power": 500,
          "efficiency": 0.935
        },
        {
          "power": 1000,
          "efficiency": 0.952
        },
        {
          "power": 1250,
          "efficiency": 0.962
        },
        {
          "power": 1500,
          "efficiency": 0.952
        },
        {
          "power": 2000,
          "efficiency": 0.950
        },
        {
          "power": 2500,
          "efficiency": 0.934
        },
        {
          "power": 3000,
          "efficiency": 0.925
        },
        {
          "power": 3500,
          "efficiency": 0.915
        },
        {
          "power": 4000,
          "efficiency": 0.900
        },
        {
          "power": 4350,
          "efficiency": 0.893
        }
      ],
    "minimum power": 100,
    "cycle cost": 0.01,
    "dc_to_bat efficiency": 0.98,
    "bat_to_dc efficiency": 0.99,
    "entity set power feedin": "input_number.dao_setpoint_jk",
    "solar": []
  }
],
  "solar": [
  {
    "name": "pv oost",
    "tilt": 35,
    "orientation": -90,
    "capacity": 2.95,
    "max power": 2.95,
    "yield": 0.0065,
    "entity pv switch": ""
  },
  {
    "name": "pv west",
    "tilt": 35,
    "orientation": 90,
    "capacity": 5.25,
    "max power": 5.25,
    "yield": 0.01116,
    "entity pv switch": ""
  }
],
  "electric vehicle": [],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.zonneplan_p1_electricity_consumption_today"
    ],
    "entities grid production": [
      "sensor.zonneplan_p1_electricity_returned_today"
    ],
    "entities solar production ac": [
      "sensor.energie_productie_oost",
      "sensor.energie_productie_west"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.ev_charger_consumption"],
    "entities wp consumption" : [],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.ess_grid_consumption"],
    "entities battery production": ["sensor.ess_grid_production"]
  },
  "scheduler": {
    "active": "true",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

Volgens de berekening van gisteren om 15:34 doet ie vannacht niks negatief met het grid-setpoint: allemaal kleine lichtblauwe (=levering) staafjes.
Heb je voor mij een grafiek van de berekening van vannacht om 4:00 uur dat het grid-setpoint toch negatief was in de nachtelijke uren?

[hemertje]

sjampeter schreef op zondag 22 juni 2025 @ 11:40:
[...]


ik ben ook (soort van) actief in dat draadje van edterbak, echter stel je eigen er niet teveel van voor hoor.
zeker niet van mijn programeercapaciteiten haha.
wat ik eigenlijk doe is het volgende.
ik geef in de instellingen van DAO aan, dat een dhw run ongeveer 9 kwartier duurt.
DAO rekent voor mij dan het beste tijdstip voor die run uit.
dit tijdstip komt in de entity "calculated start"

deze entitie lees ik in in Node-red, welke (met waarschijnlijk veel te veel omwegen) enkele external link nodes in "WP input" aciveert.
op manier wordt door DAO de dhw run aangestuurd.
qua verwarming doe ik helemaal niks, aangezien bij mij de wp, als het koud is, toch nagenoeg full-time moet draaien. enkel nachtverlaging pas ik soms toe, maar dat gaat gewoon via heishamon flow.

als je wil kan ik de node-red flow wel prive met je delen. moet wel nog opgepoetst worden eigenlijk. nog niet aan toegekomen. laat maar horen.

in de regel kan ik programmeertaal lezen en begrijpen
maar on zelf te programmeren gaat me een paar stappen te ver helaas

ben benieuwd naar je NR flow

[patatman12]

KC27 schreef op zondag 22 juni 2025 @ 13:49:
[...]

Volgens de berekening van gisteren om 15:34 doet ie vannacht niks negatief met het grid-setpoint: allemaal kleine lichtblauwe (=levering) staafjes.
Heb je voor mij een grafiek van de berekening van vannacht om 4:00 uur dat het grid-setpoint toch negatief was in de nachtelijke uren?

Ah, hierin zie je inderdaad dat hij probeert die laatste 10% uit de accu te duwen. Hij probeert het ook om 5:00 zie screenshots. En de daarop volgende uren, tot de zon weer gaat schijnen en de accu naar de 20% gaat.
In dit geval dus een PEBKAC

[KC27]

patatman12 schreef op zondag 22 juni 2025 @ 14:47:
[...]


Ah, hierin zie je inderdaad dat hij probeert die laatste 10% uit de accu te duwen. Hij probeert het ook om 5:00 zie screenshots. En de daarop volgende uren, tot de zon weer gaat schijnen en de accu naar de 20% gaat.
In dit geval dus een PEBKAC

[Afbeelding]

[Afbeelding]

Nou volgens de berekening van 15:34 zou de SoC al om 0:00 uur op 10% moeten zitten.
Dus de vraag is: wat was de SoC om 0:00 uur en zijn in de uren daarvoor ook de kWh uit de batterij gehaald zoals berekend/voorspeld door DAO.
De berekening/voorspelling van DAO moet kloppen met de werkelijkheid (mag een procent afwijken).
Als de voorspelling van het verloop van de SoC door DAO niet klopt dan zit er (denk ik) iets fout in je instellingen.
Dat kan op twee vlakken fout zitten:

• de capaciteit is te laag ingesteld
• de efficiency van het ontladen is te laag ingesteld

Als de capaciteit te laag is ingesteld zul je ook problemen hebben tijdens het laden: dat hij ook daar langer over doet dan voorspeld.
Ik denk niet dat de ontlaad-efficiency te laag is ingesteld, omdat hij al "hoog" staat in vergelijking met het laden.

[KC27]

storeman schreef op zondag 22 juni 2025 @ 10:17:
[...]


Dat is niet mijn use-case (of ik snap het niet). Ik zal proberen het duidelijker te noteren. Het gaat me hierbij niet om de exacte uitkomst van DAO vandaag, maar hoe een veld soms een gewenste en soms een ongewenste beperking is. Vandaag is een mooi voorbeeld:

Om 9u, iets hogere energieprijs
de accu zou geladen moeten met 1KW (hoger rendement in config), de rest mag terug het net in. Dus 'charge from PV' is dan 1KW.

Om 14 uur is de stroomprijs lager, DAO wil nog niet van AC laden, maar er is ook weinig zon voorspeld. DAO charge from PV is nu ook 1KW, maar dat komt door de verwachte instraling. Mocht de zon ineens doorbreken, dan wil ik alles in de accu stoppen, niet: slechts 1KW laden en de rest het net invoeden.

Ik geloof dat ik het begin te begrijpen (corrigeer me als ik het mis heb).
Tussen de uurlijkse berekeningen door wil je - afhankelijk van de prijs - schommelingen in je pv-productie anders opvangen:
Bij hoge prijzen (bijv hoger dan gemiddeld):
- als pv productie hoger is dan verwacht: terugleveren
- als pv productie lager is: niks doen
Bij lage prijzen (lager dan gemiddeld):
- als pv productie hoger is dan verwacht: opslaan
- als pv productie lager is dan verwacht: inkopen van het net
Dit kan DAO (nog) niet voor je oplossen.
Maar dit kun je perfect oplossen met een automation of nodered-flow in HA.
Maar voordat ik die hier ga delen, wil ik eerst weten dat dit de weg is die je op wil gaan.

[Torch1969]

@KC27 Zou DAO ook een vorm van "hybride" aansturing aankunnen? Dus niet volledig minimaliseren kosten of volledig maximaliseren eigen verbruik, maar iets daartussen in? Een soort hybride aansturing?

Ik stel me een configuratie instelling voor in een percentage (tientallen), waarmee het algoritme bepaald of het minimaliseren kosten is (0), maximaliseren eigen verbruik (1) of iets ertussenin (b.v. 0.5).

In mijn oude (zelf geautomatiseerde) aansturing ging ik voor maximaliseren eigen verbruik, maar wel binnen de grenzen van minimaliseren kosten. Dus het laden van de accu uitsmeren over de uren waarin de zonopbrengst groter is dan het eigen verbruik, maar de prijs ook laag genoeg om efficiency verliezen en cycle costs goed te maken (en andersom met ontladen).

[diamanten]

Vraagje: met dit warme weer wil ik graag mijn airco's aansturen via DAO. Ik heb nu de volgende machine aangemaakt:

code:

  "machines" : [ 
      { "name": "Airco",
        "programs":[
          {"name": "Uit",
           "power": []},
          {"name": "Auto",
           "power": [1000, 1000, 1000, 1000, 1000, 1000, 1000, 800]
           }
        ],
        "entity start window": "input_datetime.start_window_airco",
        "entity end window": "input_datetime.eind_window_airco",
        "entity selected program": "input_select.airco_programma",
        "entity calculated start": "input_datetime.berekende_start_airco",
        "entity calculated end": "input_datetime.berekende_stop_airco"
      }
  ],

Dit werkt op zich wel, maar is er een betere manier hiervoor?

[ Voor 11% gewijzigd door diamanten op 22-06-2025 20:26 ]

[patatman12]

KC27 schreef op zondag 22 juni 2025 @ 15:42:
[...]

Nou volgens de berekening van 15:34 zou de SoC al om 0:00 uur op 10% moeten zitten.
Dus de vraag is: wat was de SoC om 0:00 uur en zijn in de uren daarvoor ook de kWh uit de batterij gehaald zoals berekend/voorspeld door DAO.
De berekening/voorspelling van DAO moet kloppen met de werkelijkheid (mag een procent afwijken).
Als de voorspelling van het verloop van de SoC door DAO niet klopt dan zit er (denk ik) iets fout in je instellingen.
Dat kan op twee vlakken fout zitten:

• de capaciteit is te laag ingesteld
• de efficiency van het ontladen is te laag ingesteld

Als de capaciteit te laag is ingesteld zul je ook problemen hebben tijdens het laden: dat hij ook daar langer over doet dan voorspeld.
Ik denk niet dat de ontlaad-efficiency te laag is ingesteld, omdat hij al "hoog" staat in vergelijking met het laden.

SoC om 0:00 was 20% i.p.v. de door DAO verwacht 10%.
Dat kwam omdat ik bij DAO 10% had opgegeven, en in de Victron DVCC 20% minimum SoC had aangeven.
In dit geval was DAO tegen de Victron aan het vechten door 2 verschillende parameters.

Ik zal de Setpoint in de gaten houden vanavond, en morgen even een kleine update geven. Maar verwacht dat het door de afwijkende min. SoC kwam.
Bedankt voor je uitgebreide reactie, geeft ook meer inzicht in de werking van DAO!

[balk]

Torch1969 schreef op zondag 22 juni 2025 @ 17:09:
@KC27 Zou DAO ook een vorm van "hybride" aansturing aankunnen? Dus niet volledig minimaliseren kosten of volledig maximaliseren eigen verbruik, maar iets daartussen in? Een soort hybride aansturing?

Ik stel me een configuratie instelling voor in een percentage (tientallen), waarmee het algoritme bepaald of het minimaliseren kosten is (0), maximaliseren eigen verbruik (1) of iets ertussenin (b.v. 0.5).

In mijn oude (zelf geautomatiseerde) aansturing ging ik voor maximaliseren eigen verbruik, maar wel binnen de grenzen van minimaliseren kosten. Dus het laden van de accu uitsmeren over de uren waarin de zonopbrengst groter is dan het eigen verbruik, maar de prijs ook laag genoeg om efficiency verliezen en cycle costs goed te maken (en andersom met ontladen).

Ik heb nu in Home Assistant de logica zitten die bepaalt wat er moet gebeuren indien DAO setpoint 0 is. Onderstaande tabel is nog niet perfect, en ik moet de logica ook nog eens goed doorlopen. Ik heb twee sensoren gemaakt die bepalen of de prijs hoog, medium, laag of negatief is. Simpelweg drie blokken van 33% van de prijs range van vandaag. Stijgend en dalend is met een derivative sensor, een sprong van 3 cent per kWh geeft stijging/daling aan. Anders vlak.

Kolom "Hoog" staat er 2 keer in, duplicaat.

SoC	Prijs hoog	Medium, dalend	Laag	Medium, stijgend	Hoog
100%	XoM, discharge only	XoM, discharge only	idle (wacht op betere prijzen)	idle (wacht op betere prijzen)	XoM, discharge only
> 70%	XoM, discharge only (export zon)	XoM, discharge only (export zon)	XoM, charge only	Idle (betere prijzen komen er aan)	XoM, discharge only
> 40%	XoM, discharge only (export zon)	XoM, discharge only (export zon)	XoM, charge only	XoM, charge only	XoM, discharge only
> 10%	idle	XoM, discharge only	XoM, charge only (?)	XoM, discharge only (?)	Idle
< 10% (noodstroom)	idle	XoM, charge only	XoM, charge only	XoM, charge only	Idle

Dit voelt voor mij beter dan domweg idle wanneer DAO 0 zegt. Misschien niet financieel optimaal maar zeker niet ver er onder.

Ik heb twee Sessy's, en die stuur ik aan met de XoM automation van PimDoos.
+++ edit
nu ik weer zo naar de tabel kijk zie ik toch nog gekke dingen. Er wordt nog aan gewerkt
beetje uitleg toegevoegd aan tabel

[ Voor 3% gewijzigd door balk op 22-06-2025 22:07 ]

[KC27]

patatman12 schreef op zondag 22 juni 2025 @ 20:51:
[...]


SoC om 0:00 was 20% i.p.v. de door DAO verwacht 10%.
Dat kwam omdat ik bij DAO 10% had opgegeven, en in de Victron DVCC 20% minimum SoC had aangeven.
In dit geval was DAO tegen de Victron aan het vechten door 2 verschillende parameters.

Ik zal de Setpoint in de gaten houden vanavond, en morgen even een kleine update geven. Maar verwacht dat het door de afwijkende min. SoC kwam.
Bedankt voor je uitgebreide reactie, geeft ook meer inzicht in de werking van DAO!

Ik zou Victron DVCC en DAO op hetzelfde minimum zetten. Dan kan DAO daarmee de meest optimale inzet van je Victron berekenen.

[KC27]

Torch1969 schreef op zondag 22 juni 2025 @ 17:09:
@KC27 Zou DAO ook een vorm van "hybride" aansturing aankunnen? Dus niet volledig minimaliseren kosten of volledig maximaliseren eigen verbruik, maar iets daartussen in? Een soort hybride aansturing?

Ik stel me een configuratie instelling voor in een percentage (tientallen), waarmee het algoritme bepaald of het minimaliseren kosten is (0), maximaliseren eigen verbruik (1) of iets ertussenin (b.v. 0.5).

In mijn oude (zelf geautomatiseerde) aansturing ging ik voor maximaliseren eigen verbruik, maar wel binnen de grenzen van minimaliseren kosten. Dus het laden van de accu uitsmeren over de uren waarin de zonopbrengst groter is dan het eigen verbruik, maar de prijs ook laag genoeg om efficiency verliezen en cycle costs goed te maken (en andersom met ontladen).

Het is een interessante gedachte en de moeite waard om na te gaan of dit kan.
Jouw vraag is ook een mooie aanleiding om uiteen te zetten hoe DAO nu rekent met "minimize consumption" (is eigenlijk hetzelfde als maximalisering eigen verbruik, toch?).
Als je bij DAO de strategie "minimize consumption" kiest rekent het programma in twee stappen:
stap 1: het programma stuurt de mip optimalisatie aan met de functie:"minimize consumption". Dit levert een uitkomst op waarbij geen rekening is gehouden met de kosten, maar (zeker in de zomer) op zonnige dagen met pv vaak consumption die op nul uitkomt. Maar de teruglevering is dan niet geoptimaliseerd. De zo berekende consumption noem ik consumption_stap_1.
stap 2: ik voer een extra randvoorwaarde in het model: consumption <= maximum(0, consumption_stap_1) en voer wederom een optimaliseringsberekening uit nu met als functie "minimize cost".
Het programma gaat nu de teruglevering sturen naar de uren waar het het meeste oplevert.
De uitkomst die dit oplevert wordt gepresenteerd als het eindresultaat van een bewerking.
Dus eigenlijk doet het programma al een beetje wat jij voorstelt.

Als je die twee strategieën wilt combineren dan zul je - als je mip wilt gebruiken als optimaliseringsalgoritme - die twee eenheden moeten gaan wegen en optellen tot een gecombineerde eenheid en die gaan optimaliseren.
Bijvoorbeeld (dit is een theoretische exercitie) we gaan rekenen met strafpunten (je mag dan zelf de strafpunten instellen in de settings):
1 kWh consumption = 10 strafpunten
1 euro cost = 5 strafpunten
1 euro profit = - 5 strafpunten
Dat stop je als extra randvoorwaarden in het model en je gaat met het model zoeken naar "minimize strafpunten").
Op deze manier zouden we die twee strategieën kunnen combineren.

[Torch1969]

balk schreef op zondag 22 juni 2025 @ 21:49:
[...]

Ik heb nu in Home Assistant de logica zitten die bepaalt wat er moet gebeuren indien DAO setpoint 0 is. Onderstaande tabel is nog niet perfect, en ik moet de logica ook nog eens goed doorlopen. Ik heb twee sensoren gemaakt die bepalen of de prijs hoog, medium, laag of negatief is. Simpelweg drie blokken van 33% van de prijs range van vandaag. Stijgend en dalend is met een derivative sensor, een sprong van 3 cent per kWh geeft stijging/daling aan. Anders vlak.

Kolom "Hoog" staat er 2 keer in, duplicaat.

SoC	Prijs hoog	Medium, dalend	Laag	Medium, stijgend	Hoog
100%	XoM, discharge only	XoM, discharge only	idle (wacht op betere prijzen)	idle (wacht op betere prijzen)	XoM, discharge only
> 70%	XoM, discharge only (export zon)	XoM, discharge only (export zon)	XoM, charge only	Idle (betere prijzen komen er aan)	XoM, discharge only
> 40%	XoM, discharge only (export zon)	XoM, discharge only (export zon)	XoM, charge only	XoM, charge only	XoM, discharge only
> 10%	idle	XoM, discharge only	XoM, charge only (?)	XoM, discharge only (?)	Idle
< 10% (noodstroom)	idle	XoM, charge only	XoM, charge only	XoM, charge only	Idle

Dit voelt voor mij beter dan domweg idle wanneer DAO 0 zegt. Misschien niet financieel optimaal maar zeker niet ver er onder.

Ik heb twee Sessy's, en die stuur ik aan met de XoM automation van PimDoos.
+++ edit
nu ik weer zo naar de tabel kijk zie ik toch nog gekke dingen. Er wordt nog aan gewerkt
beetje uitleg toegevoegd aan tabel

Super interessant en ik zal het nog eens goed doornemen,
Nadeel is wel dat je buiten DAO om de accu gaat gebruiken. Denk dat het mooier is dat DAO dit bedenkt zodat die weet wat er gaat gebeuren en daar ook rekening mee houdt.
De XOM blueprint van Pimdoos heb ik op mijn todo staan om te integreren om ook NOM te kunnen draaien voor de balanceer optie van DAO (eventueel 2 varianten waar de ene alleen kan laden en de andere alleen kan ontladen).

[ Voor 4% gewijzigd door Torch1969 op 23-06-2025 08:18 ]

[Torch1969]

KC27 schreef op zondag 22 juni 2025 @ 22:59:
[...]

Het is een interessante gedachte en de moeite waard om na te gaan of dit kan.
Jouw vraag is ook een mooie aanleiding om uiteen te zetten hoe DAO nu rekent met "minimize consumption" (is eigenlijk hetzelfde als maximalisering eigen verbruik, toch?).
Als je bij DAO de strategie "minimize consumption" kiest rekent het programma in twee stappen:
stap 1: het programma stuurt de mip optimalisatie aan met de functie:"minimize consumption". Dit levert een uitkomst op waarbij geen rekening is gehouden met de kosten, maar (zeker in de zomer) op zonnige dagen met pv vaak consumption die op nul uitkomt. Maar de teruglevering is dan niet geoptimaliseerd. De zo berekende consumption noem ik consumption_stap_1.
stap 2: ik voer een extra randvoorwaarde in het model: consumption <= maximum(0, consumption_stap_1) en voer wederom een optimaliseringsberekening uit nu met als functie "minimize cost".
Het programma gaat nu de teruglevering sturen naar de uren waar het het meeste oplevert.
De uitkomst die dit oplevert wordt gepresenteerd als het eindresultaat van een bewerking.
Dus eigenlijk doet het programma al een beetje wat jij voorstelt.

Als je die twee strategieën wilt combineren dan zul je - als je mip wilt gebruiken als optimaliseringsalgoritme - die twee eenheden moeten gaan wegen en optellen tot een gecombineerde eenheid en die gaan optimaliseren.
Bijvoorbeeld (dit is een theoretische exercitie) we gaan rekenen met strafpunten (je mag dan zelf de strafpunten instellen in de settings):
1 kWh consumption = 10 strafpunten
1 euro cost = 5 strafpunten
1 euro profit = - 5 strafpunten
Dat stop je als extra randvoorwaarden in het model en je gaat met het model zoeken naar "minimize strafpunten").
Op deze manier zouden we die twee strategieën kunnen combineren.

Ja, met maximaliseer eigen verbruik bedoelde ik inderdaad “minimize consumption”. Dank voor de uitleg (zal die ook toevoegen in de wiki 😀). Goed te lezen dat die eigenlijk al een soort van hybride vorm is. Ik zal in mijn testomgeving eens schaduwdraaien met die instelling. Klinkt inderdaad alsof dat eigenlijk al is wat ik wil. Werkt dit ook zo bij ontladen? Dus sturen naar uren met minste zon opbrengst en daarbinnen naar duurste uren?

De werking met strafpunten zou een alternatief kunnen zijn, maar die moeten we nog maar eens goed doorgronden.

[Torch1969]

diamanten schreef op zondag 22 juni 2025 @ 20:20:
Vraagje: met dit warme weer wil ik graag mijn airco's aansturen via DAO. Ik heb nu de volgende machine aangemaakt:

code:

  "machines" : [ 
      { "name": "Airco",
        "programs":[
          {"name": "Uit",
           "power": []},
          {"name": "Auto",
           "power": [1000, 1000, 1000, 1000, 1000, 1000, 1000, 800]
           }
        ],
        "entity start window": "input_datetime.start_window_airco",
        "entity end window": "input_datetime.eind_window_airco",
        "entity selected program": "input_select.airco_programma",
        "entity calculated start": "input_datetime.berekende_start_airco",
        "entity calculated end": "input_datetime.berekende_stop_airco"
      }
  ],

[Afbeelding]
Dit werkt op zich wel, maar is er een betere manier hiervoor?

Ik heb eigenlijk een soortgelijke vraag. Ik heb de airco nu voor de reports als WP (is het eigenlijk ook) geconfigureerd, maar dus alleen voor vastleggen energieverbruik ( om die uit de baseload te halen). Voor de aansturing ben ik er ook nog niet uit. Voelt vreemd om de airco als “heating” te configureren, afgezien van het feit dat ik de benodigde gegevens lastig kan achterhalen.

[balk]

Torch1969 schreef op maandag 23 juni 2025 @ 07:56:
[...]


Super interessant en ik zal het nog eens goed doornemen,
Nadeel is wel dat je buiten DAO om de accu gaat gebruiken. Denk dat het mooier is dat DAO dit bedenkt zodat die weet wat er gaat gebeuren en daar ook rekening mee houdt.
De XOM blueprint van Pimdoos heb ik op mijn todo staan om te integreren om ook NOM te kunnen draaien voor de balanceer optie van DAO (eventueel 2 varianten waar de ene alleen kan laden en de andere alleen kan ontladen).

Zolang je zonnestroom hebt zal DAO nooit precies kunnen voorspellen wat er gaat gebeuren. Ook eigen gebruik is niet foutloos te voorspellen. Ik zie DAO als de strateeg die zich niet bemoeit met de directe uitvoering. Het is heel goed met het uitzetten van de grote lijnen maar kan niet op de seconde regelen. Home Assistant juist omgekeerd en daarom werkt het ook zo lekker samen.

[patatman12]

KC27 schreef op zondag 22 juni 2025 @ 22:59:
[...]

Het is een interessante gedachte en de moeite waard om na te gaan of dit kan.
Jouw vraag is ook een mooie aanleiding om uiteen te zetten hoe DAO nu rekent met "minimize consumption" (is eigenlijk hetzelfde als maximalisering eigen verbruik, toch?).
Als je bij DAO de strategie "minimize consumption" kiest rekent het programma in twee stappen:
stap 1: het programma stuurt de mip optimalisatie aan met de functie:"minimize consumption". Dit levert een uitkomst op waarbij geen rekening is gehouden met de kosten, maar (zeker in de zomer) op zonnige dagen met pv vaak consumption die op nul uitkomt. Maar de teruglevering is dan niet geoptimaliseerd. De zo berekende consumption noem ik consumption_stap_1.
stap 2: ik voer een extra randvoorwaarde in het model: consumption <= maximum(0, consumption_stap_1) en voer wederom een optimaliseringsberekening uit nu met als functie "minimize cost".
Het programma gaat nu de teruglevering sturen naar de uren waar het het meeste oplevert.
De uitkomst die dit oplevert wordt gepresenteerd als het eindresultaat van een bewerking.
Dus eigenlijk doet het programma al een beetje wat jij voorstelt.

Als je die twee strategieën wilt combineren dan zul je - als je mip wilt gebruiken als optimaliseringsalgoritme - die twee eenheden moeten gaan wegen en optellen tot een gecombineerde eenheid en die gaan optimaliseren.
Bijvoorbeeld (dit is een theoretische exercitie) we gaan rekenen met strafpunten (je mag dan zelf de strafpunten instellen in de settings):
1 kWh consumption = 10 strafpunten
1 euro cost = 5 strafpunten
1 euro profit = - 5 strafpunten
Dat stop je als extra randvoorwaarden in het model en je gaat met het model zoeken naar "minimize strafpunten").
Op deze manier zouden we die twee strategieën kunnen combineren.

Dit is eigenlijk vergelijkbaar hoe DESS werkt met "Green Mode".
https://communityarchive....namic-ess-green-mode.html

Optimized Self-Consumption: With this mode enabled, your system first directs solar energy towards meeting your immediate consumption needs.
Battery Charging Priority: Once your consumption needs are met, any excess solar power is utilized to charge your batteries, ensuring they are charged sufficiently for hours without solar.
Grid trading: Only after your consumption and battery charging needs are fulfilled does the system consider selling surplus solar energy back to the grid.

Alleen met DAO zou je dan die laatste ook nog optimaliseren, dus alleen verkopen op de duurste momenten.

[DaBit]

balk schreef op zondag 22 juni 2025 @ 21:49:
Ik heb nu in Home Assistant de logica zitten die bepaalt wat er moet gebeuren indien DAO setpoint 0 is.

Het mag dan misschien beter voelen, maar als DAO 0 als setpoint aanhoud is er kwa efficiency en kosten voor gebruik accu geen eer te behalen aan gebruik van die accu. Dan ben je volgens mij net zo goed of beter af door de laad/ontlaad efficiencies kunstmatig hoog te zetten en kosten voor gebruik accu kunstmatig laag.

Overigens: als DAO vind dat 0-op-meter de beste strategie is dan kiest-ie daar zelf ook voor. Sinds ik DAO (op de juiste manier) verteld heb dat ik 2 cent moet betalen voor het terugleveren van een kWh kiest-ie daar bij mij vrij vaak voor als de zon schijnt.

Een beetje lastig grafiekje als je 'm niet zelf ingesteld hebt, maar:



Waar de gele lijn (netbalans, vermogen op de P1 meter) redelijk strak op 0 zit is DAO aan het balanceren en aan het proberen de 'waardeloze' zonne-energie in de accu te krijgen.

Overigens is er ook goed te zien dat het niet handig is als DAO ergens niet vanaf weet. Om ca. 13.15 moet de auto nog even bijgeladen worden en wordt dat geforceerd door een van de familieleden (ze kiezen voor 'nu laden'). DAO weet daar niet van, en kiest vrolijk voor 'balanceren' met als gevolg dat veel van die autolaadenergie uit de accu komt.

(misschien moet ik 'nu laden' implementeren door de EV-moet-vol-zijn tijd aan te passen en DAO een schop te geven)

balk schreef op maandag 23 juni 2025 @ 08:32:
Ik zie DAO als de strateeg die zich niet bemoeit met de directe uitvoering. Het is heel goed met het uitzetten van de grote lijnen maar kan niet op de seconde regelen. Home Assistant juist omgekeerd en daarom werkt het ook zo lekker samen.

Ik ook, daarom laat ik 'm vaker draaien dan eens per uur zodat de strateeg de strategie bij kan werken als de praktijk wat afwijkt van de theorie. Zeker zinvol als HA buiten DAO om nog dingen met de 'door DAO beheerde apparatuur' doet.
DAO gaat er voorlopig nog wel vanuit dat zaken binnen het uur klaar moeten zijn en houd geen rekening met verkorte tijden tussen de runs.

@KC27: zo'n cost-gebaseerde optimalisatie, of strafpunten zo je wil, is wel wat als je het mij vraagt.

[ Voor 9% gewijzigd door DaBit op 23-06-2025 09:14 ]

[storeman]

KC27 schreef op zondag 22 juni 2025 @ 16:40:
[...]

Ik geloof dat ik het begin te begrijpen (corrigeer me als ik het mis heb).
Tussen de uurlijkse berekeningen door wil je - afhankelijk van de prijs - schommelingen in je pv-productie anders ...
Maar voordat ik die hier ga delen, wil ik eerst weten dat dit de weg is die je op wil gaan.

Dank voor je reactie KC27! Waar het bij mij schuurt is dat die entiteit dus eigenlijk twee functies heeft: begrenzing en planning.

Maar altijd goed om even te sparren. Ik heb nu bedacht dat als de `entity from ac` 0 is en `entity from pv` is dat niet, dat er onbeperkt geladen mag worden, volgens mij is dat de juiste logica.

[balk]

DaBit schreef op maandag 23 juni 2025 @ 09:06:
[...]

Overigens: als DAO vind dat 0-op-meter de beste strategie is dan kiest-ie daar zelf ook voor. Sinds ik DAO (op de juiste manier) verteld heb dat ik 2 cent moet betalen voor het terugleveren van een kWh kiest-ie daar bij mij vrij vaak voor als de zon schijnt.

Mee eens, ik ben dat ook nog aan het inrichten. Mijn logica is een aanvulling daarop. Stel DAO kiest voor NoM midden op de dag en dan gaat hier de wasmachine/Quooker/oid aan , dan wil ik niet dat het tekort uit de batterij komt maar vanaf het net. Op die momenten is het dus XoM met alleen laden. Omgekeerd zijn er ook scenarios waarbij je niet wil laden, en alleen ontladen.
+++
Aanvulling: mijn PV vermogen is kleiner dan accu laad vermogen

[ Voor 4% gewijzigd door balk op 23-06-2025 13:42 ]

[simnet]

DaBit schreef op maandag 23 juni 2025 @ 09:06:
[...]

Overigens is er ook goed te zien dat het niet handig is als DAO ergens niet vanaf weet. Om ca. 13.15 moet de auto nog even bijgeladen worden en wordt dat geforceerd door een van de familieleden (ze kiezen voor 'nu laden'). DAO weet daar niet van, en kiest vrolijk voor 'balanceren' met als gevolg dat veel van die autolaadenergie uit de accu komt.

(misschien moet ik 'nu laden' implementeren door de EV-moet-vol-zijn tijd aan te passen en DAO een schop

Ik zit met een vergelijkbare uitdaging, in dat ik graag mijn vaatwasser wil meenemen in DOA als machine, maar hij is alleen niet slim te sturen (en de vrouw wil hem ook gewoon zelf kunnen starten wanner zij wil). Ik weet (aan de hand van een energysocket) wel wanneer hij start en heb zitten proberen om vergelijkbaar met jou DAO daar van op de hoogte te stellen. Ik heb nog niet een echt betrouwbare methode gevonden.

Dit is overigens ook een feature request aan @KC27 die ik nog aan het formulieren was...
Dus eigenlijk een endpoint binnen DAO om direct een machine te starten en een hercalculatie te doen. Mede omdat op dit soort momenten de batterij strategie flink kan wijzigen.

[DaBit]

balk schreef op maandag 23 juni 2025 @ 13:30:
Mee eens, ik ben dat ook nog aan het inrichten. Mijn logica is een aanvulling daarop.

Ik liet precies zo'n moment liet zien in mijn grafiekje (en ook nog eens eentje waarvoor de accu relatief flink aan de bak moest want zo'n EV-met-voorrang lust meteen 11kW), maar heel erg is het niet:

- Normaal heb ik ruim >3kW aan zon als DAO gaat balanceren. Als er dan een vaatwasser oid aan gaat laad de accu tijdelijk even wat minder vlot. Dat wordt in de uren erna wel weer rechtgetrokken; je hebt al gauw meer opbrengst op een dag dan kWh-en aan accucapaciteit om te vullen.
- Die paar kWh die deze special case uit de accu komen zijn hoogstwaarschijnlijk goedkoop verkregen kWh-en, je 'betaalt' er alleen een procent of 15 aan laad/ontlaadverliezen voor en een paar cent aan apparatuurslijtage als je dat wil verrekenen. Eigenlijk niet of amper meer dan de inkoopvergoeding die je zou moeten betalen als het van het net af komt, dus accu of net is best wel lood om oud ijzer eigenlijk....
- Het is over tijdsspannes van maanden gemeten zo'n klein deel van de tijd dat dit euvel zich voordoet. Over het aantal kWh-en aan energiestromen gemeten ook.

De ene kant van het muntje is dat er winst te behalen is door de special case af te handelen, maar al met al is de winst die ik ermee kan halen door het aan te pakken erg klein.
De andere kant van het muntje is een hoop extra bitjes aan automaties toevoegen. En al die bitjes die je toevoegt kunnen omvallen en hebben onderhoud nodig om te voorkomen dat er bitrot ontstaat.

Mijn persoonlijke keuze: ik vind kosten vs baten te ongunstig uitvallen en pak mijn 'verlies' wel. Simpel, rechttoerechtaan en robuust heeft zo z'n charmes.

Dus of ik DAO in ga lichten dat de EV aan het laden is? Ik krijg net zoals jullie weer van die jeukende vingers om een automatie in elkaar te draaien die de auto-klaar tijd even aanpast, het gewenste percentage op 100 zet en DAO een schop geeft. Maar in werkelijkheid denk ik dat ik het lekker zo hou. KISS.

[ Voor 7% gewijzigd door DaBit op 23-06-2025 15:30 ]

[DaBit]

Hier eenje van vandaag overdag. Een 'rotdag' voor de digitale kaboutertjes die het allemaal maar moeten zien te rooien met die sterk varierende zon en kinderen die thuis rondhangen:



Ik vind de schade wel meevallen. Meer dan 100% krijg ik toch niet in die accu en dat haalt-ie met gemak. En wat er in die dipjes uit de accu gehaald wordt is eerder opgeslagen zonne-energie. Daar heb ik geen belasting over betaald en geen 2 cent vergoeding voor aan de leverancier betaald dus dat is netzogoed goedkope stroom.

[ Voor 15% gewijzigd door DaBit op 23-06-2025 16:10 ]

[Torch1969]

DaBit schreef op maandag 23 juni 2025 @ 16:07:
Hier eenje van vandaag overdag. Een 'rotdag' voor de digitale kaboutertjes die het allemaal maar moeten zien te rooien met die sterk varierende zon en kinderen die thuis rondhangen:

[Afbeelding]

Ik vind de schade wel meevallen. Meer dan 100% krijg ik toch niet in die accu en dat haalt-ie met gemak. En wat er in die dipjes uit de accu gehaald wordt is eerder opgeslagen zonne-energie. Daar heb ik geen belasting over betaald en geen 2 cent vergoeding voor aan de leverancier betaald dus dat is netzogoed goedkope stroom.

@DaBit en @balk dank voor jullie relativerende bespiegelingen en andere kijk op de zaak. Goed om eens in de overwegingen van aansturing mee te nemen. KISS is voor mij ook een belangrijk uitgangspunt, dat mag best ten koste van die paar laatste cent winst op een dag gaan. Kortom DAO bepaald de grote lijnen en in HA doe je de finetuning (op een zo eenvoudig mogelijke manier). DAO corrigeert de afwijkingen wel weer in het volgende uur (en moppert daar gelukkig niet over )

[DaBit]

Wat dat betreft zit ik toch 'met smart' te wachten op de kwartiers-variant van DAO
(je kunt 'm wel elk kwartier draaien, maar de berekeningresultaten zijn voor het komende uur)

[KC27]

@DaBit @simnet en anderen:
Als je een sensor hebt in HA waarvan de waarde verandert (state change) omdat iemand de auto gaat laden, de vaatwasser aanzet of anderszins dan kun je al vanuit HA een berekening van DAO initiëren (RTFM ):

Maak in configuration.yaml van HA een restcommando aan (bijvoorbeeld)

YAML:

rest_command:
  start_dao_calc:
    url: http://192.168.178.36:5000/api/run/calc_zonder_debug
    verify_ssl: false

Maak een automation in HA die wordt getriggerd door de genoemde state-change(s) (hier door een input_button):

YAML:

alias: Start berekening DAO via rest
description: Start berekening DAO
mode: single
triggers:
  - entity_id:
      - input_button.start_day_ahead_berekening
    trigger: state
conditions: []
actions:
  - data: {}
    action: rest_command.start_dao_calc

Bij mij werkt ie.

[DaBit]

@KC27 : Ja, dat ik at kan weet ik. Haal ik ook aan ergens in de posts.

Maar stel, plingpling op de app 'Wij kunnen niet naar het toernooi van de kinderen rijden want ziek. Kun jij het overnemen?' Ja, opzich wel, maar dan moet ik wel even rap de auto bijladen. Voor die gevallen heb ik een knopje 'Nu laden'. Die zet simpelweg de laadpaal op '3x16A gewenst'. Auto gaat laden, en als iemand de laadstekker eruit trekt gaat de boel weer terug naar normaal, oftewel DAO gestuurd.

Zou ik dat via DAO willen repliceren dan moet ik in een automatie:
- De gewenste lading op 100% zetten.
- De helper die aangeeft wanneer DAO klaar moet zijn met EV laden op een zinnige tijd zetten, die ook nog eens afhankelijk is van de SoC van de accu. Want als ik DAO meer tijd geef dan nodig dan zou-ie voor een lager vermogen kunnen kiezen
- een berekening zonder debug starten via REST.
- Als de auto losgekoppeld word het ladingspercentage en tijd-klaar weer herstellen.

Voordat dat feilloos werkt... 'Nu laden' is nu knap betrouwbaar. Of de communicatie naar de paal werkt en ik kan 3x16A, of de boel ligt op z'n gat en de paal doet 3x10A als fallback.
Hoe het bij jullie thuis zit weet ik niet, maar hier is de oepsmomentjes-tolerantie van de rondborstige directie exact 0.

[mgroen81]

DaBit schreef op maandag 23 juni 2025 @ 22:55:
@KC27 : Ja, dat ik at kan weet ik. Haal ik ook aan ergens in de posts.

Maar stel, plingpling op de app 'Wij kunnen niet naar het toernooi van de kinderen rijden want ziek. Kun jij het overnemen?' Ja, opzich wel, maar dan moet ik wel even rap de auto bijladen. Voor die gevallen heb ik een knopje 'Nu laden'. Die zet simpelweg de laadpaal op '3x16A gewenst'. Auto gaat laden, en als iemand de laadstekker eruit trekt gaat de boel weer terug naar normaal, oftewel DAO gestuurd.

Zou ik dat via DAO willen repliceren dan moet ik in een automatie:
- De gewenste lading op 100% zetten.
- De helper die aangeeft wanneer DAO klaar moet zijn met EV laden op een zinnige tijd zetten, die ook nog eens afhankelijk is van de SoC van de accu. Want als ik DAO meer tijd geef dan nodig dan zou-ie voor een lager vermogen kunnen kiezen
- een berekening zonder debug starten via REST.
- Als de auto losgekoppeld word het ladingspercentage en tijd-klaar weer herstellen.

Voordat dat feilloos werkt... 'Nu laden' is nu knap betrouwbaar. Of de communicatie naar de paal werkt en ik kan 3x16A, of de boel ligt op z'n gat en de paal doet 3x10A als fallback.
Hoe het bij jullie thuis zit weet ik niet, maar hier is de oepsmomentjes-tolerantie van de rondborstige directie exact 0.

Ik had ook zo'n nu laden functie gemaakt. Maar als je 10 minuten voor het hele uur start wordt het laden vaak gestopt door DAO.
Om dat te voorkomen heb ik idd gemaakt wat je beschrijft. En dat werkt perfect.
Ik heb de volgende 2 sensoren gemaakt. De sensoren berekenen de vertrek tijd op basis van de huidige SOC. Een automatisering zet de berekende vertrektijd in de DAO helper.

code:

- platform: template
  sensors:    
    ev_charge_time:
      friendly_name: "Estimated Charging Time"
      unit_of_measurement: "hours"
      value_template: >-
        {% set soc_remaining = 100 - states('sensor.zoe_state_of_charge') | int %}
        {% set energy_needed_kWh = soc_remaining * 4 / 10 %}
        {% set charging_power = 10 %}
        {{ (energy_needed_kWh / charging_power) | round(2) }}
    zoe_charge_now_time:
      friendly_name: "Zoe charge now time"
      value_template: >-
        {% set charge_time = states('sensor.ev_charge_time') | float %}
        {{ (now() + timedelta(hours=charge_time) + timedelta(hours=1)).strftime('%H:%M') }}

[simnet]

@KC27
Ik heb die rest call inderdaad al geimplementeerd, echter moet ik de vaatwasser nogal omslacht inplannen:

code:

alias: "DAO: trigger run by dishwasher"
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_select.dishwasher_status
    to: Running
    from: Idle
conditions: []
actions:
  - action: input_select.select_option
    metadata: {}
    data:
      option: eco
    target:
      entity_id: input_select.dao_program_vaatwasser
    enabled: true
  - data_template:
      entity_id: input_datetime.dao_calculated_start_vaatwasser
      date: >
        {% set date_time = as_timestamp(now()) | int %} {{ date_time |
        timestamp_custom("%Y-%m-%d", true) }}
      time: "00:00:00"
    action: input_datetime.set_datetime
    enabled: true
  - data_template:
      entity_id: input_datetime.dao_calculated_stop_vaatwasser
      date: >
        {% set date_time = as_timestamp(now()) | int %} {{ date_time |
        timestamp_custom("%Y-%m-%d", true) }}
      time: "23:59:00"
    action: input_datetime.set_datetime
    enabled: true
  - data_template:
      entity_id: input_datetime.dao_start_window_vaatwasser
      time: >
        {% set date_time = as_timestamp(now()) | int - 60 %} {{ date_time |
        timestamp_custom("%H:%M:00", true) }}
    action: input_datetime.set_datetime
  - data_template:
      entity_id: input_datetime.dao_end_window_vaatwasser
      time: >
        {% set date_time = as_timestamp(now()) | int + 3600 + 900 %} {{
        date_time | timestamp_custom("%H:%M:00", true) }}
    action: input_datetime.set_datetime
  - action: rest_command.dao_start_calc
    metadata: {}
    data: {}
    enabled: true
mode: single

Ik zou het fijner vinden om het hele rekenen met datums achterwege te laten en tegen DAO te zeggen, 'start vaatwasser nu'. (dito voor andere machines)

[KC27]

Ik heb jullie signalen begrepen en ben nu aan het puzzelen omdat te implementeren in DAO.
Als ik het goed begrijp zou het zoiets moeten worden (corrigeer me als ik het verkeerd zie of iets ben vergeten)
Je drukt in HA op een knop, daaronder zit een rest_commando met de volgende url en payload:

code:

http://<host>:<port>/api/start/?device=<device>&<param1>=<value1>&<param2>=<value2>

<host>: de dns-naam of het ip-adres van de machine waar DAO op draait
<port>: het poortnummer waar dao naar luistert (meestal 5000)
<device> de naam van je auto of van een van je machines (namen moeten uniek zijn) deze parameter is verplicht
als het een ev is:
<param1>="ampere", <value1>= het aantal ampère waarmee geladen moet gaan worden, default het hoogste aantal ampere uit je settings
<param2>="soc", <value2> = het gewenste eindniveau van de soc, default 100%

als het een machine:
<param1>="program", value1=de naam van het programma zoals genoemd in je settings voorbeeld program=eco, deze parameter is verplicht

Een paar voorbeelden:
Stel je wilt je Tesla direct "volgooien":

code:

url = http://192.168.178.xx:5000/api/start?device=tesla&ampere=16&soc=90

Of je wilt snel een wasje doen:

code:

url = http://192.168.178.xx:5000/api/start?device=wasmachine&program=eco

Wat er dan gebeurt als zo'n ev/machine op deze wijze via DAO wordt gestart:

• het betreffende device wordt direct ingepland met eindtijdstip voor de noodzakelijke duur van het gebruik/laden van het device
• er wordt een dao-berekening met de gewijzigde situatie uitgevoerd zodat eventueel meer/minder wordt geladen in de batterij, pv eventueel (tijdelijk) wordt aangezet enz
• de helpers in HA worden met de juiste data geladen zodat de gevraagde actie ook daadwerkelijk wordt uitgevoerd.

Denken jullie dat dit zo kan werken?
Nogmaals kijk er kritisch naar en laat het me weten.

[jvs1]

ik krijg in de log iedere keer een KeyError: 'vat'

zie bijvoorbeeld hier:

Logging van bewerking "Meteoprognoses ophalen":

Traceback (most recent call last):
File "/root/dao/webserver/../prog/day_ahead.py", line 3429, in <module>
main()
File "/root/dao/webserver/../prog/day_ahead.py", line 3392, in main
da_calc = DaCalc("../data/options.json")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/webserver/../prog/day_ahead.py", line 28, in __init__
super().__init__(file_name=file_name)
File "/root/dao/prog/da_base.py", line 161, in __init__
self.btw_l_def = self.prices_options["vat"]
~~~~~~~~~~~~~~~~~~~^^^^^^^
KeyError: 'vat'

wat is hieraan te doen?

[Torch1969]

jvs1 schreef op woensdag 25 juni 2025 @ 07:05:
ik krijg in de log iedere keer een KeyError: 'vat'

zie bijvoorbeeld hier:

Logging van bewerking "Meteoprognoses ophalen":

Traceback (most recent call last):
File "/root/dao/webserver/../prog/day_ahead.py", line 3429, in <module>
main()
File "/root/dao/webserver/../prog/day_ahead.py", line 3392, in main
da_calc = DaCalc("../data/options.json")
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/root/dao/webserver/../prog/day_ahead.py", line 28, in __init__
super().__init__(file_name=file_name)
File "/root/dao/prog/da_base.py", line 161, in __init__
self.btw_l_def = self.prices_options["vat"]
~~~~~~~~~~~~~~~~~~~^^^^^^^
KeyError: 'vat'

wat is hieraan te doen?

Zie https://github.com/corneel27/day-ahead/issues/288

[simnet]

KC27 schreef op dinsdag 24 juni 2025 @ 23:07:
Denken jullie dat dit zo kan werken?
Nogmaals kijk er kritisch naar en laat het me weten.

Exact zoals ik het voor ogen had!

[KC27]

Torch1969 schreef op woensdag 25 juni 2025 @ 07:53:
[...]

Zie https://github.com/corneel27/day-ahead/issues/288

@jvs1
Of verander het in je settings naar:

code:

    "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
    },

[DaBit]

Denken jullie dat dit zo kan werken?
Nogmaals kijk er kritisch naar en laat het me weten.

Jazeker, dat klinkt heel goed!

Misschien nog een kleine additie: het is ook handig om aan te kunnen geven dat een apparaat al iets aan het doen is zodat DAO zijn strategie aan kan passen.

Fictief voorbeeld: een boiler zou een minimum-temperatuur aan kunnen houden om bevriezing in de winter te voorkomen of een legionella-run. Dat die boiler zelfstandig besluit om te gaan verwarmen kunnen we wel meten omdat het via een energysocket aangesloten zit, maar niet beinvloeden. We zouden dan aan DAO door kunnen geven dat die boiler met X ampere/watt bezig is.

Geen hoge prioriteit feature wat mij betreft overigens, maar ze lijken mischien voldoende op elkaar.

[ Voor 69% gewijzigd door DaBit op 26-06-2025 08:16 ]

[Asclepius8]

Dat is gek, hij runt geen optimalisatie sinds vandaag (terwijl er morgen een mooie spread ligt van bijna 25c). Als ik hem handmatig run zie ik weinig spannende dingen..

[sjampeter]

hmm. na 23 uur is je accu leeg, en na middernacht wordt ik niet echt warm of koud van de prijsverschillen. laat ik die accu niet voor draaien hoor.

[Asclepius8]

Verkeerd gekeken idd, morgen te kleine spread om te werken, vandaag is juist de mooie spread..

Not a bug, feature..

[DaBit]

Hier is het ook enkel wat overtollige zonne-energie opslaan:


Prima beslissing van DAO als je het mij vraagt.

Ik vind dat jij je accu wel erg ver leeg laat staan voor de langere periode. Zou je dat niet beter richting de 20% brengen?

[diamanten]

Helaas deze foutmelding (ondermeer Perhaps out of memory), nadat ik de dao addon een dag had gestopt en toen weer heb aangezet.
Wat kan ik hieraan doen?

code:

Watches established.
[2025-06-25 20:37:49 +0200] [12] [INFO] Starting gunicorn 23.0.0
[2025-06-25 20:37:49 +0200] [12] [INFO] Listening at: http://0.0.0.0:5000 (12)
[2025-06-25 20:37:49 +0200] [12] [INFO] Using worker: sync
[2025-06-25 20:37:49 +0200] [22] [INFO] Booting worker with pid: 22
[2025-06-25 20:37:49 +0200] [23] [INFO] Booting worker with pid: 23
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
[2025-06-25 20:46:01 +0200] [12] [CRITICAL] WORKER TIMEOUT (pid:23)
[2025-06-25 20:46:01 +0200] [23] [ERROR] Error handling request /
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/gunicorn/workers/sync.py", line 134, in handle
    self.handle_request(listener, req, client, addr)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/gunicorn/workers/sync.py", line 177, in handle_request
    respiter = self.wsgi(environ, resp.start_response)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1498, in __call__
    return self.wsgi_app(environ, start_response)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, 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 213, in menu
    return run_process()
           ^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 342, in run_process
    proc = run(cmd, stdout=PIPE, stderr=PIPE)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 550, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 1207, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 2059, in _communicate
    ready = selector.select(timeout)
            ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/selectors.py", line 415, in select
    fd_event_list = self._selector.poll(timeout)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/gunicorn/workers/base.py", line 204, in handle_abort
    sys.exit(1)
SystemExit: 1
[2025-06-25 20:46:01 +0200] [23] [INFO] Worker exiting (pid: 23)
[2025-06-25 20:46:02 +0200] [12] [ERROR] Worker (pid:23) was sent SIGKILL! Perhaps out of memory?
[2025-06-25 20:46:02 +0200] [627] [INFO] Booting worker with pid: 627

[KC27]

diamanten schreef op woensdag 25 juni 2025 @ 20:53:
Helaas deze foutmelding (ondermeer Perhaps out of memory), nadat ik de dao addon een dag had gestopt en toen weer heb aangezet.
Wat kan ik hieraan doen?

code:

Watches established.
[2025-06-25 20:37:49 +0200] [12] [INFO] Starting gunicorn 23.0.0
[2025-06-25 20:37:49 +0200] [12] [INFO] Listening at: http://0.0.0.0:5000 (12)
[2025-06-25 20:37:49 +0200] [12] [INFO] Using worker: sync
[2025-06-25 20:37:49 +0200] [22] [INFO] Booting worker with pid: 22
[2025-06-25 20:37:49 +0200] [23] [INFO] Booting worker with pid: 23
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.
[2025-06-25 20:46:01 +0200] [12] [CRITICAL] WORKER TIMEOUT (pid:23)
[2025-06-25 20:46:01 +0200] [23] [ERROR] Error handling request /
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/gunicorn/workers/sync.py", line 134, in handle
    self.handle_request(listener, req, client, addr)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/gunicorn/workers/sync.py", line 177, in handle_request
    respiter = self.wsgi(environ, resp.start_response)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1498, in __call__
    return self.wsgi_app(environ, start_response)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 1473, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 880, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/flask/app.py", line 865, 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 213, in menu
    return run_process()
           ^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 342, in run_process
    proc = run(cmd, stdout=PIPE, stderr=PIPE)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 550, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 1207, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/subprocess.py", line 2059, in _communicate
    ready = selector.select(timeout)
            ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/selectors.py", line 415, in select
    fd_event_list = self._selector.poll(timeout)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/gunicorn/workers/base.py", line 204, in handle_abort
    sys.exit(1)
SystemExit: 1
[2025-06-25 20:46:01 +0200] [23] [INFO] Worker exiting (pid: 23)
[2025-06-25 20:46:02 +0200] [12] [ERROR] Worker (pid:23) was sent SIGKILL! Perhaps out of memory?
[2025-06-25 20:46:02 +0200] [627] [INFO] Booting worker with pid: 627

Dit vind ik een een interessante foutmelding.
Ik ben benieuwd hoeveel geheugen je aan HA en zijn add-ons hebt toebedeeld en hoeveel daarvan in gebruik is. Bij mij (ik draai sinds een paar maanden op een RPi5) staat het geheugengebruik en het vrije geheugen hierop:

Je kunt dit plaatje (en de informatie daarop) krijgen door in HA de integratie "System monitor" te installeren.

[diamanten]

KC27 schreef op woensdag 25 juni 2025 @ 23:33:
[...]

Dit vind ik een een interessante foutmelding.
Ik ben benieuwd hoeveel geheugen je aan HA en zijn add-ons hebt toebedeeld en hoeveel daarvan in gebruik is. Bij mij (ik draai sinds een paar maanden op een RPi5) staat het geheugengebruik en het vrije geheugen hierop:
[Afbeelding]
Je kunt dit plaatje (en de informatie daarop) krijgen door in HA de integratie "System monitor" te installeren.

Memory houdt niet over (ik draai op een oude laptop - Generic x86-64).
Nu krijg ik trouwens deze foutmelding met een simpelere config:

code:

2025-06-26 07:29:17 info: Day Ahead Optimalisering versie: 2025.6.2
2025-06-26 07:29:17 info: Day Ahead Optimalisering gestart op: 26-06-2025 07:29:17
2025-06-26 07:29:17 info: Day Ahead Optimalisatie gestart: 26-06-2025 07:29:17 taak: calc_optimum_met_debug
2025-06-26 07:29:18 info: Debug = True
2025-06-26 07:29:18 info: Baseload uit instellingen
2025-06-26 07:29:18 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 539, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 469, in calc_optimum_met_debug
    dacalc.calc_optimum()
  File "/root/dao/prog/day_ahead.py", line 154, in calc_optimum
    solar_num = len(self.solar)
                ^^^^^^^^^^^^^^^
TypeError: object of type 'NoneType' has no len()
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3429, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3403, in main
    da_calc.run_task_function("calc_optimum_met_debug")
  File "/root/dao/prog/da_base.py", line 539, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 469, in calc_optimum_met_debug
    dacalc.calc_optimum()
  File "/root/dao/prog/day_ahead.py", line 154, in calc_optimum
    solar_num = len(self.solar)
                ^^^^^^^^^^^^^^^
TypeError: object of type 'NoneType' has no len()

code:

{
  "homeassistant": { },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "entsoe",
    "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
    },
    "cost supplier production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "vat consumption": {
      "2022-01-01": 21,
      "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-04-01",
    "tax refund": "True"
  },
  "logging level" : "info",
  "use_calc_baseload": "False",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "true",
    "prices consumption": "True",
    "prices production": "True",
    "average consumption": "True"
  },
  "strategy": "minimize cost",
  "notifications": {
    "notification entity": "input_text.dao_notificatie",
    "opstarten": "True",
    "berekening": "True",
    "last activity entity": "input_datetime.dao_laatste_activiteit"
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },

 
  "battery": [],
 

  "electric vehicle": [
    {
      "name": "Kia Niro EV",
      "capacity": 55,
      "entity position": "input_select.kia_locatie_dao",
      "entity max amperage": "input_number.niro_ac_max_ampere",
      "charge three phase": "True",
      "charge stages": [
        { "ampere": 0, "efficiency": 1.00 },
        { "ampere": 16, "efficiency": 0.95 }
      ],
      "entity actual level": "input_number.dummy_kia_soc",
      "entity plugged in": "input_boolean.kia_ingeplugd_dao",
      "entity stop charging": "input_datetime.stop_laden_ev",
      "charge scheduler": {
        "entity set level": "number.ev_smart_charging_minimum_ev_soc",
        "level margin": 2,
        "entity ready datetime": "input_datetime.kia_niro_ready_time"
      },
      "charge switch": "input_boolean.kia_niro_charge_enable",
      "entity set charging ampere": "input_number.kia_niro_set_charging_ampere"
    }
  ],


  "machines" : [ 
      { "name": "Airco",
        "programs":[
          {"name": "Uit",
           "power": []},
          {"name": "Auto",
           "power": [1000, 1000, 1000, 1000, 1000, 1000, 1000, 800]
           }
        ],
        "entity start window": "input_datetime.start_window_airco",
        "entity end window": "input_datetime.eind_window_airco",
        "entity selected program": "input_select.airco_programma",
        "entity calculated start": "input_datetime.berekende_start_airco",
        "entity calculated end": "input_datetime.berekende_stop_airco"
      }
  ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.energy_consumed_tariff_1",
      "sensor.energy_consumed_tariff_2"
    ],
    "entities grid production": [
      "sensor.energy_produced_tariff_1",
      "sensor.energy_produced_tariff_2"
    ],
    "entities solar production ac": [
      "sensor.envoy_current_energy_production_kwh"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.ev_laadsessie_simulatie_kwh"],
    "entities wp consumption" : ["sensor.airco_e8165626d04f_energy_usage_cycle"],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.totaal_batterij_consumption_dao"],
    "entities battery production": ["sensor.totaal_batterij_production_dao"]
  },
  "scheduler": {
    "active": "false",
    "0430": "get_meteo_data",
    "1030": "get_meteo_data",
    "1630": "get_meteo_data",
    "2230": "get_meteo_data",
    "1255": "get_day_ahead_prices",
    "1355": "get_day_ahead_prices",
    "1455": "get_day_ahead_prices",
    "1554": "get_day_ahead_prices",
    "1655": "get_day_ahead_prices",
    "xx00": "calc_optimum",
    "2359": "clean_data"
  }
}

[ Voor 102% gewijzigd door diamanten op 26-06-2025 07:37 ]

[RudolfR]

@diamanten

Iets teveel weggehaald?

Zoiets is wel vereist.

JSON:

"solar": [],

[ Voor 13% gewijzigd door RudolfR op 26-06-2025 08:55 ]

[diamanten]

RudolfR schreef op donderdag 26 juni 2025 @ 08:49:
@diamanten

Iets teveel weggehaald?

Zoiets is wel vereist.

JSON:

"solar": [],

Dank, de simpele versie werkt weer.
Deze steeds verder uitgebreid en nu werkt de complete versie ook weer!
Weet niet wat er aan de hand was.

[patatman12]

bladebla schreef op vrijdag 6 juni 2025 @ 17:35:
Wat een fantastisch project, @KC27 – dank daarvoor. Het is duidelijk dat hier veel denkwerk en uitwerking in zit. Sinds ik je oplossing toepas, zijn mijn Multiplussen ook merkbaar stiller geworden. Ze draaien nu efficiënter bij een bepaald vermogen, in plaats van continu op vol vermogen zoals bij DESS.

Ik ben me de afgelopen dagen aan het verdiepen in de werking, maar loop nog tegen een punt aan:
Wat doe je in een Victron-systeem precies met de entity set power feedin (battery setpoint)? Deze bepaalt het laad-/ontlaadvermogen van de accu’s, terwijl Victron je toelaat om het grid setpoint van Victron ESS in te stellen.

In dit topic zag ik dat @tonvanboven, @thys en @georgeboot hier ook mee bezig zijn, maar ik kon nergens terugvinden hoe ze dit precies aanpakken.

Wat ik nu gebouwd heb:
Ik gebruik de set power feedin uit DAO als basis en corrigeer de grid setpoint continu zodat er een kloppende energiebalans ontstaat:

code:

Grid setpoint = (DAO power feedin + house load) – PV production

Mijn pv installatie bestaat uit een DC Victron MPPT charger en een AC Fronius inverter. Ik heb mijn gehele huis achter AC-out1 hangen.

Ik doe het volgende via Node-RED naar MQTT-server van de Cerbo en HA:

[Afbeelding]

DAO power feedin = homeassistant/dao/set_power_feedin

House load L1 = N/#####/system/0/Ac/Consumption/L1/Power
House load L2 = N/#####/system/0/Ac/Consumption/L2/Power
House load L3 = N/#####/system/0/Ac/Consumption/L3/Power

Fronius inverter = N/#####/pvinverter/20/Ac/Power
Victron charger = N/#####/solarcharger/279/Yield/Power

De resulterende Grit setpoint schrijf ik dan naar:
Grid setpoint = W/#####/settings/0/Settings/CGwacs/AcPowerSetPoint

De berekening wordt continu herhaald bij elke nieuwe input van een van de componenten.

Mijn volledige woning hangt achter AC-out1. 's Nachts, wanneer er geen PV is en de accu’s in rust zijn, zie ik dat het verschil tussen house load en grid zichtbaar wordt: bijvoorbeeld 400W load tegenover 433W uit het net. Dus ~33W eigen verbruik door de drie Multiplussen.

Is deze aanpak logisch volgens jullie?
En is het zinvol (en haalbaar) om die ~33W eigen verbruik van de Multiplussen ook mee te nemen in de berekening?

Dank voor jou post trouwens! Ik heb nu DAO een week draaien, en door middel van een template sensor in Hass heb ik hetzelfde resultaat.
Mijn Helper template:

code:

{{ (states('input_number.dao_setpoint_jk') | float(0) + states('sensor.cerbo_gx_total_consumption_l1') | float(0)) - states('sensor.total_solar') | float(0) }}

Werkt perfect. Je ziet in de data dat hij netjes bij een onverwacht overschot aan zonne energie gaat terug leveren. Iets wat ik eigenlijk nog wilt optimaliseren, want dat is natuurlijk sonde. Heeft iemand daar nog een tip voor? Ik zit eraan te denken om DAO ieder kwartier te laten draaien, zoals iemand anders in dit topic ook doet. Dan kan hij sneller optimaliseren.




P.S. Ik was bang dat mijn automation die de setpoint zetten iets oververhit raakte (de sensor update meerdere keren per seconden). Heb dus een kleine condition toegevoegd dat het berekende setpoint wel 50 watt moet schelen met de vorige:

code:

{# Sla de nieuwe en huidige waarde op in variabelen voor leesbaarheid #}
        {% set new_setpoint = trigger.to_state.state | float(0) %}
        {% set current_setpoint = states('number.cerbo_gx_grid_setpoint') | float(0) %}
        
        {# Bereken het absolute verschil en kijk of het groter is dan 10 Watt #}
        {{ (new_setpoint - current_setpoint) | abs > 50 }}

Waarschijnlijk overkill, en kan HASS het makkelijk aan. Maar puur vanuit mijn eigen perspectief sloeg het nergens op om de Cerbo mqtt zo te bombarderen met berichten.

[patatman12]

Vanavond ben ik er toch mee bezig geweest, en heb ik een mogelijk oplossing voor de onverwachte momenten dat het bewolkt is, of zonniger dan verwacht.
Heb Gemini als rubber ducky gebruikt, dus ik copy paste even zijn antwoord (sorry als dit niet word gewaardeerd)

We moeten de logica aanpassen zodat de "agressieve begrenzing" alleen wordt toegepast wanneer DAO daadwerkelijk een handelsactie opgeeft (dus als DAO_setpoint niet nul is).

Als DAO_setpoint > 0 (Actief kopen): Voorkom terugleveren. De ondergrens is 0. (max functie)

Als DAO_setpoint < 0 (Actief verkopen): Voorkom afname. De bovengrens is 0. (min functie)

Als DAO_setpoint == 0 (Neutraal / Geen handel): Laat de berekening ongemoeid. Het grid-setpoint wordt dan simpelweg huisverbruik - zonneproductie. Hierdoor zal het systeem stroom van het net afnemen als dat nodig is om de basislast te dekken, precies zoals de DAO-grafiek het bedoelt.

De template sensor word dan:

code:

          {% set dao_setpoint = states('input_number.dao_setpoint_jk') | float(0) %}
          {% set house_load = states('sensor.cerbo_gx_total_consumption_l1') | float(0) %}
          {% set pv_production = states('sensor.total_solar') | float(0) %}
          
          {% set calculated_setpoint = dao_setpoint + house_load - pv_production %}
          
          {% if dao_setpoint > 0 %}
            {# INTENTIE: Actief kopen (bv. batterij laden).
               Voorkom ongewenst terugleveren. Setpoint mag niet negatief worden. #}
            {{ max(0, calculated_setpoint) }}

          {% elif dao_setpoint < 0 %}
            {# INTENTIE: Actief verkopen (bv. batterij ontladen naar net).
               Voorkom ongewenste afname. Setpoint mag niet positief worden. #}
            {{ min(0, calculated_setpoint) }}

          {% else %}
            {# INTENTIE: Neutraal (DAO setpoint is 0).
               Geen actieve handel. Volg de basislast.
               Setpoint wordt wat nodig is: positief bij verbruik, negatief bij overschot. #}
            {{ calculated_setpoint }}
          {% endif %}

Heb een test sensor aangemaakt die ik morgen in de gaten houd, en het gewenste gedrag vertoond. Op basis daarvan kan ik hem uiteindelijk volledig omzetten.

[bladebla]

patatman12 schreef op donderdag 26 juni 2025 @ 20:52:
[...]


Dank voor jou post trouwens! Ik heb nu DAO een week draaien, en door middel van een template sensor in Hass heb ik hetzelfde resultaat.
Mijn Helper template:

code:

{{ (states('input_number.dao_setpoint_jk') | float(0) + states('sensor.cerbo_gx_total_consumption_l1') | float(0)) - states('sensor.total_solar') | float(0) }}

Heel mooi dat je dat met native Hass is gelukt. Ik dacht dat de standaard Hass Victron intergratie niet zo vaak waardes ververst, of komen de waardes uit MQTT?

Ik update het setpoint op de Cerbo meerdere keren per seconde. Ik heb in Victron OS gemonitord wat de load is maar dat is geen probleem. Ook geen onnodige schrijfacties naar de opslag met beperkte levensduur. (Mijn energiemeter op de hoofdaansluiting wordt standaard niet in Victron OS ondersteund loopt daarom via een MQTT-driver en gooit ook zo vaak als hij kan, meerdere keren per seconden, het huisverbruik naar de MQTT server van de Cerbo en ook dat brengt hem echt niet op zijn knieën.)

Werkt perfect. Je ziet in de data dat hij netjes bij een onverwacht overschot aan zonne energie gaat terug leveren. Iets wat ik eigenlijk nog wilt optimaliseren, want dat is natuurlijk sonde. Heeft iemand daar nog een tip voor? Ik zit eraan te denken om DAO ieder kwartier te laten draaien, zoals iemand anders in dit topic ook doet. Dan kan hij sneller optimaliseren.

Draai je dan strategy = minimize consumption"? Ik draai minimize costs en dan is PV-opbrengst iets wat je gewoon op het net wil zetten.

Ik herbereken overigens ieder kwartier. Daar gaan we toch naar toe en de balanceeract loopt toch altijd een beetje anders dan gepland en dan stel je daar gewoon ieder kwartier op bij. Het script is sinds een van de laatste versies toch een stuk sneller geworden.

[patatman12]

bladebla schreef op donderdag 26 juni 2025 @ 22:54:
[...]

Heel mooi dat je dat met native Hass is gelukt. Ik dacht dat de standaard Hass Victron intergratie niet zo vaak waardes ververst, of komen de waardes uit MQTT?

Ik update het setpoint op de Cerbo meerdere keren per seconde. Ik heb in Victron OS gemonitord wat de load is maar dat is geen probleem. Ook geen onnodige schrijfacties naar de opslag met beperkte levensduur. (Mijn energiemeter op de hoofdaansluiting wordt standaard niet in Victron OS ondersteund loopt daarom via een MQTT-driver en gooit ook zo vaak als hij kan, meerdere keren per seconden, het huisverbruik naar de MQTT server van de Cerbo en ook dat brengt hem echt niet op zijn knieën.)

Ik doe het via een MQTT verbinding met de Victron. Een mqtt relay (https://gist.github.com/K...b340cf3ad513f9415b20ed5fa) Deze update super snel.

Toevallig kreeg ik een ping van iemand vanochtend, die een custom integratie heeft gebouwd naar de Victron MQTT: https://github.com/tomer-w/ha-victron-mqtt
Die zal ik straks even proberen, en kan interessant zijn voor de mensen in dit topic. Het grote voordeel van de MQTT integratie is de snelheid.

bladebla schreef op donderdag 26 juni 2025 @ 22:54:

[...]


Draai je dan strategy = minimize consumption"? Ik draai minimize costs en dan is PV-opbrengst iets wat je gewoon op het net wil zetten.

Ik herbereken overigens ieder kwartier. Daar gaan we toch naar toe en de balanceeract loopt toch altijd een beetje anders dan gepland en dan stel je daar gewoon ieder kwartier op bij. Het script is sinds een van de laatste versies toch een stuk sneller geworden.

Nee ik draai ook Minimize costs. PV opbrengst mag ook wel het net op, alleen niet op de momenten dat DAO actief aan het inkopen is.
Als DAO berekend dat energie ingekocht moet worden, dan zal de prijs wel dusdanig laag zijn (of zelfs negatief) dat je ook overtollig PV niet wilt terug leveren, en dus zelf in je accu stopt of andere verbruikers. In de praktijk zal het wel meevallen hoeveel impact dit heeft, gezien dit korte momenten zijn, en gespreid over een uur het totaal wel mee valt. Maar toch een kleine optimalisatie in mijn ogen.

[patatman12]

Na vandaag ben ik overtuig van de nieuwe template, en dit zie je netjes terug in de grafieken.


Hier zie je dat de eerdere sensor netjes negatief (dus gaat terugleveren) terwijl DAO duidelijk de status inkopen heeft. De nieuwe Sensor heeft een hard limiet van 0, dus de overtollige energie zou in de accu zijn gegaan in plaats van terug geleverd.
Als mijn boiler aanspringt, en ik dus meer energie nodig hebt, gaat de nieuwe sensor netjes mee naar het positieve om actief in te kopen.

Onderstaand in meer detail.

[Asclepius8]

DaBit schreef op woensdag 25 juni 2025 @ 16:55:
Hier is het ook enkel wat overtollige zonne-energie opslaan:
[Afbeelding]

Prima beslissing van DAO als je het mij vraagt.

Ik vind dat jij je accu wel erg ver leeg laat staan voor de langere periode. Zou je dat niet beter richting de 20% brengen?

Dit mis ik dan wel, ik zou verwachten dat hij de overtollige stroom zou opslaan?

Waarom zou ik die low % niet zo houden?

[DaBit]

Asclepius8 schreef op zaterdag 28 juni 2025 @ 14:49:
Dit mis ik dan wel, ik zou verwachten dat hij de overtollige stroom zou opslaan?

Als jij DAO vertelt dat terugleveren van stroom geld kost (bij mij/Nextenergy dus ~2ct/kWh) dan is-ie al sneller geneigd om overtollige zonnestroom in de accu te stoppen.

Waarom zou ik die low % niet zo houden?

Eerste probleem: Li-ion batterijen degraderen relatief vlot als ze langdurig op hele lage SoC gehouden worden. Dat geld voor alle kathodematerialen, dus ook voor LFP. Langdurig 100% vol en hogere temperaturen is ook zo'n situatie die je wil vermijden als je daar geen verdere nadelen van ondervind.
Ik laat de wellesnietes-discussie of je daar tijdens de levensduur van je batterij last van hebt even in het midden; google wat rond en maak je eigen keus.

Tweede probleem met lage SOC is dat je makkelijk onder de 0% grens schiet. Stel, je ontlaad naar 0% en laad alleen bij als er overschot aan zon is. Dat kan ooit weken duren, en in die tijd sippen de verbruikers op die batterij (BMS, omvormer, bla) de cellen onder de 0%. Dat geeft onmiddelijke en onomkeerbare schade. Dit effect is doodsoorzaak nummer 1 van Li-ion cellen.
Dat heb je bij 3-5% ook nog wel; vroeg of laat slijt 1 cel iets harder dan z'n broertjes dus als het hele pack dan nog op 5% zit kan het best zijn dat er 1 cel tegen 0 zit. Bij LFP kun je dat aan de celspanning niet zo goed zien.

Derde probleem: als je een keer stroomuitval krijgt en je batterij is zo ketsleeg dat je nog geen lampje kunt laten branden dan ga je dat de komende 30 jaar op elk familiefeestje te horen krijgen


Persoonlijk laad ik wel naar 100% want daar blijft het pack toch nooit heel lang op staan en alles naar 100% is een reset van alle tellertjes en eventuele onbalans. Maar aan de onderkant van de SoC vind ik persoonlijk 20% kortdurend / 25% langdurend wel een mooie grens. Geen risico dat er cellen diepontladen worden, worstcase nog zo'n 6kWh over om een lampje te kunnen laten branden, telefoon te laden en eten te koken.
Iets lager kan imho ook nog wel, zeg 10%/15%. Maar daaronder ben je te gulzig als je het mij vraagt.

[simnet]

eea hangt denk ik enorm af van de batterij die je hebt.
Ik heb een relatief kleine (5kWh) batterij die vanuit zichzelf al stopt met ontladen bij 11% soc. Ik heb mijn minimum dus ook op 11% gezet.

[mgroen81]

De Sessy kan je ook prima op 0% laten staan. 0% is niet helemaal leeg en de Sessy BMS zal de batterij ook bijladen als dat nodig is om hem op de juiste spanning te houden.

[firecaps30]

Sinds gisteren DAO op de HA-pi geïnstalleerd en druk bezig om alles te configureren. Wellicht een simpele vraag, als ik in de run zie:

2025-06-30 13:33:56 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -10.22
2025-06-30 13:33:56 info: Geoptimaliseerd, kosten met day ahead tarieven: -12.45

En de grafiek toont de winst bij strategie minimale kosten 2.23, dan interpreteer ik dat als: Bij ‘niks doen’ verdien ik morgen 10.22, maar als ik de DAO strategie overneem dan haal ik er nog 2.23 extra uit.

Klopt dat?

EDIT: nog een vraag over de accu cycle kosten:

2025-06-30 14:15:46 info: Cycle cost Accu1: 1.49 euro

Deze moeten er nog van afgetrokken worden?

[ Voor 12% gewijzigd door firecaps30 op 30-06-2025 14:18 ]

[KC27]

firecaps30 schreef op maandag 30 juni 2025 @ 13:48:
Sinds gisteren DAO op de HA-pi geïnstalleerd en druk bezig om alles te configureren. Wellicht een simpele vraag, als ik in de run zie:

2025-06-30 13:33:56 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -10.22
2025-06-30 13:33:56 info: Geoptimaliseerd, kosten met day ahead tarieven: -12.45

En de grafiek toont de winst bij strategie minimale kosten 2.23, dan interpreteer ik dat als: Bij ‘niks doen’ verdien ik morgen 10.22, maar als ik de DAO strategie overneem dan haal ik er nog 2.23 extra uit.

Klopt dat?

EDIT: nog een vraag over de accu cycle kosten:

2025-06-30 14:15:46 info: Cycle cost Accu1: 1.49 euro

Deze moeten er nog van afgetrokken worden?

Ja .die 2,23 is het verschil tussen 12,45 en 10,22.
Dat is de netto winst en daar zijn cycle costs al vanaf.
Dus je bruto winst is 2,23 + 1,49 = 3,72.

[Torch1969]

Ik ben de strategy “minimise consumption” eens aan het proberen. Vorige week bij weinig zonopbrengst gaf dat niet het gewenste resultaat (tussendoor bijladen bij hogere prijs en later weer ontladen bij lagere prijs).
Deze week bij hoge zonopbrengst lijkt het beter, maar 2 dingen vallen mij op.
1. De thuisbatterij wordt gedurende een aantal uren ontladen met lager vermogen (360W) dan ik als minimum hebt ingesteld (440W).
2. De PHEV wordt geladen met lagere vermogens (en dus vele uren) dan ik heb ingesteld (0 of 15A) (dit kan ook niet anders met mijn laadpaal en PHEV, gewoon 1 fase vol vermogen)

Mis ik iets qua instellingen?

Configuratie thuisbatterij:

code:

 "battery": [
    {
      "name": "Sessy_dllu",
      "entity actual level": "sensor.sessy_dllu_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "entity min soc end opt": "input_number.dao_sessy_dllu_min_soc_end",
      "entity max soc end opt": "input_number.dao_sessy_dllu_max_soc_end",
      "charge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 110.0,
         "efficiency": 0.758},
        {"power": 220.0,
         "efficiency": 0.850},
        {"power": 330.0,
         "efficiency": 0.892},
        {"power": 440.0,
         "efficiency": 0.912},
        {"power": 660.0,
         "efficiency": 0.933},
        {"power": 880.0,
         "efficiency": 0.942},
        {"power": 1100.0,
         "efficiency": 0.946},
        {"power": 1320.0,
         "efficiency": 0.942},
        {"power": 1540.0,
         "efficiency": 0.938},
        {"power": 1760.0,
         "efficiency": 0.929},
        {"power": 1980.0,
         "efficiency": 0.921},
        {"power": 2200.0,
         "efficiency": 0.908}
      ],
      "discharge stages": [
        {"power": 0.0,
         "efficiency": 1},
        {"power": 60.0,
         "efficiency": 0.7},
        {"power": 85.0,
         "efficiency": 0.735},
        {"power": 170.0,
         "efficiency": 0.829},
        {"power": 255.0,
         "efficiency": 0.882},
        {"power": 340.0,
         "efficiency": 0.921},
        {"power": 510.0,
         "efficiency": 0.943},
        {"power": 680.0,
         "efficiency": 0.957},
        {"power": 850.0,
         "efficiency": 0.957},
        {"power": 1020.0,
         "efficiency": 0.953},
        {"power": 1190.0,
         "efficiency": 0.943},
        {"power": 1360.0,
         "efficiency": 0.936},
        {"power": 1530.0,
         "efficiency": 0.929},
        {"power": 1700.0,
         "efficiency": 0.925}
      ],
      "reduced hours":
       {  "1": 2200,
          "2": 2200,
         "18": 2200,
         "19": 2200
       },
      "minimum power": 440,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.01,
      "entity set power feedin": "input_number.dao_sessy_dllu_set_power_feedin",
      "entity set operating mode": "input_select.dao_sessy_dllu_set_operating_mode",
      "entity stop inverter": "input_datetime.dao_sessy_dllu_stop_inverter",
      "entity balance switch": "input_boolean.dao_sessy_dllu_balance_switch",
      "entity calculated soc": "input_number.dao_sessy_dllu_calculated_soc",
      "solar": []
    }

Configuratie EV:

code:

 "electric vehicle": [
    {
      "name": "Kia",
      "capacity": 11.1,
      "entity position": "input_select.dao_ev_position",
      "charge three phase": "False",
      "charge stages" : [
        {"ampere": 0, "efficiency": 0.00},
        {"ampere": 15, "efficiency": 0.89}
      ],      
      "entity actual level": "sensor.dao_ev_actual_level",
      "entity plugged in": "input_boolean.dao_ev_plugged_in",
      "entity stop charging": "input_datetime.dao_stop_laden_ev",
      "charge scheduler": {
        "entity set level": "input_number.dao_ev_set_level",
        "level margin": 2,
        "entity ready datetime": "input_datetime.dao_ev_ready_time"
      },
      "charge switch": "input_boolean.dao_ev_charge_switch",
      "entity set charging ampere": "input_number.dao_ev_set_charging_ampere"
    }
  ],

[KC27]

Torch1969 schreef op maandag 30 juni 2025 @ 19:16:

De thuisbatterij wordt gedurende een aantal uren ontladen met lager vermogen (360W) dan ik als minimum hebt ingesteld (440W).

Zou het niet zo kunnen zijn dat DAO wel ging ontladen met 440W, maar dat er een eindtijd is gecommuniceerd zodat er uiteindelijk 0,36 kWh is ontladen?
Dat kun je terugvinden in de logging van de berekening en de historie van de entity "stop inverter"

De PHEV wordt geladen met lagere vermogens (en dus vele uren) dan ik heb ingesteld (0 of 15A) (dit kan ook niet anders met mijn laadpaal en PHEV, gewoon 1 fase vol vermogen)

Hier misschien hetzelfde verhaal: laden met 15A maar slechts een deel van het uur en tussentijds stoppen met laden (zie logging berekening en historie van entity "stop laden ev").

Ik hoor het graag.
Als mijn veronderstellingen niet kloppen dan zie ik graag de logging van de berekening.

[KC27]

Vandaag is er een nieuwe test-versie van DAO gepubliceerd: 2025.7.0.rc1.
Belangrijkste nieuws:

• BREAKING : geen ondersteuning meer voor i386-processors
• cryptography-package is toegevoegd, zodat gebruikers met mysql-database (niet te verwarren met mariadb) kunnen inloggen met encrypted wachtwoord
• een heleboel packages zijn geupdate dankzij het toevoegen van een dependabot-workflow die dat dagelijks checkt (met veel dank aan @simnet )
• bij gebruikers met een postgresql-database wordt de timezone gezet naar de lokale timezone (reported by @balk )

[balk]

KC27 schreef op dinsdag 1 juli 2025 @ 16:35:

• bij gebruikers met een postgresql-database wordt de timezone gezet naar de lokale timezone (reported by @balk )

Getest, lijkt niet te werken helaas. Volgens ChatGPT kan je deze bewerking niet uitvoeren wanneer je verbonden bent met de database. Of dat waar is weet ik niet maar het werkt niet in ieder geval. En ik krijg ook niet de melding in de addon log van "logging.info(f'Database "day_ahead" timezone gezet naar {timezone}')", maar ik weet niet of die daar terecht moet komen. Ik ga wat testen.
++edit++
hij komt niet bij de code dankzij 'if l_version < 20250700:' ; l_version is namelijk 20250700
++edit2++
en dan werkt de ALTER niet, wellicht door bovenstaande beperking.
++edit3++
Ik stel voor om tot we een programmatische oplossing hebben, iets in de documentatie op te nemen zodat die enkele postgres gebruiker dit handmatig kan doen

[ Voor 21% gewijzigd door balk op 01-07-2025 22:07 ]

[Torch1969]

KC27 schreef op maandag 30 juni 2025 @ 23:00:
[...]


[...]

Zou het niet zo kunnen zijn dat DAO wel ging ontladen met 440W, maar dat er een eindtijd is gecommuniceerd zodat er uiteindelijk 0,36 kWh is ontladen?
Dat kun je terugvinden in de logging van de berekening en de historie van de entity "stop inverter"


[...]

Hier misschien hetzelfde verhaal: laden met 15A maar slechts een deel van het uur en tussentijds stoppen met laden (zie logging berekening en historie van entity "stop laden ev").

Ik hoor het graag.
Als mijn veronderstellingen niet kloppen dan zie ik graag de logging van de berekening.

Vwb de accu:
De daadwerkelijke aansturing is met het (te) lage vermogen. Het attribuut "stop inverter" is niet gewijzigd (ongewijzigd waarde 2000-01-01).

Ik heb een GitHub issue aangemaakt om alle logging met je te delen: https://github.com/corneel27/day-ahead/issues/316

Voor de laadpaal kan ik het niet goed achterhalen. De entiteit "stop laden ev" heb ik niet aangemaakt. Maar ik begrijp niet zo goed waarom het slimmer is om gedurende een uur b.v. 1 kwartier te laden. Zolang we salderen hebben kun je daarmee binnen een uur de opgewekte zonne energie wegstrepen tegen de laadstroom, maar als salderen weg is, dan gaat die vlieger niet meer op.

[DaBit]

Torch1969 schreef op woensdag 2 juli 2025 @ 20:40:
Maar ik begrijp niet zo goed waarom het slimmer is om gedurende een uur b.v. 1 kwartier te laden.

Stel, je hebt ingesteld dat je met 0kW of 4kW kunt laden. En dat er op een gegeven moment nog 1kWh bij moet om op het ingestelde percentage +/- de marge uit te komen.

Dan heb je drie opties voor dat uur:
- Niet laden. Dan haal je het gewenste percentage niet
- Een uur laden met 4kW. Dan schiet je er overheen.
- Die stop entity gebruiken om 1/4 van een uur te laden. Dan kom je precies goed uit.

Persoonlijk vind ik die stop entiteiten een hoop extra logica voor weinig winst. Ik doe liever de botte-bijl methode en draai de DAO optimalisatie wat vaker. Maar ik vind het ook niet zo erg dat een ingestelde 80% uitkomt op bijvoorbeeld 83%, en ik heb al vaker aangegeven dat ik terughoudend ben met logica implementeren omdat de tijd voor testen/optimalisatie exponentieel toeneemt met de hoeveelheid logica en minder logica betrouwbaardere systemen oplevert. Jouw mening hierover kan en mag best afwijken.

[mgroen81]

Ik heb in de config verschillende laadstromen voor de EV ingesteld met allemaal dezelfde efficiency. Ik had nog nooit gezien dat DAO een ander amperage kiest. edit: Na wat aanpassingen werkt dit.

Ik laad de auto met een SmartEVSE en kan iedere amperage instellen om te laden.
Is een betere methode dan tijdens het laden te stoppen.

[ Voor 15% gewijzigd door mgroen81 op 03-07-2025 10:39 ]

[DaBit]

mgroen81 schreef op maandag 30 juni 2025 @ 12:42:
De Sessy kan je ook prima op 0% laten staan. 0% is niet helemaal leeg en de Sessy BMS zal de batterij ook bijladen als dat nodig is om hem op de juiste spanning te houden.

Sessy geeft inderdaad aan dat je dat mag doen en ze hebben er ook geen uitzondering voor in hun 10 jaar/6000 cycli garantie. Die zullen dus intern wel wat marge aanhouden, net zoals EV-fabrikanten ook doen.
Deye/Victron zelfbouwers moeten wat meer opletten.

Wat dat betreft is het geweldig dat je bij DAO op kunt geven wat de tijdelijke minimale SoC en langdurigere minimale SoC mag zijn. Dat heeft @KC27 mooi verzonnen.

[DaBit]

mgroen81 schreef op donderdag 3 juli 2025 @ 09:23:
Ik heb in de config verschillende laadstromen voor de EV ingesteld met allemaal dezelfde efficiency. Ik heb nog nooit gezien dat DAO een ander amperage kiest. Hoe krijg ik dit werkend?

Ik heb een aardig aantal laadstromen ingesteld:

code:

"electric vehicle": [ 
    {
      "name": "Corsa-E",
      "capacity": 47.0,
      "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":  6, "efficiency": 0.95},
            {"ampere":  7, "efficiency": 0.95},
            {"ampere":  8, "efficiency": 0.95},
            {"ampere":  9, "efficiency": 0.95},
            {"ampere": 10, "efficiency": 0.95},
            {"ampere": 11, "efficiency": 0.95},
      {"ampere": 12, "efficiency": 0.95},
            {"ampere": 13, "efficiency": 0.95},
            {"ampere": 14, "efficiency": 0.95},
            {"ampere": 15, "efficiency": 0.95},
            {"ampere": 16, "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.80},
            {"ampere": 48, "efficiency": 0.70}

Verder draai ik DAO per kwartier. Het werkt bij mij. 90% wordt ooit 92% of 89%, maar dat komt ook omdat ik de SoC zelf moet interpoleren; die auto communiceert die maar zelden. Eigenlijk alleen als je de stekker erin stopt, eruit haalt of na enkele uren.
De lage efficiency bij 45+ ampere is niet echt maar gefoezel van mijn kant; ik heb liever niet dat DAO die kiest tenzij het echt goed uitkomt.

[ Voor 3% gewijzigd door DaBit op 03-07-2025 09:50 ]

[Dogooder]

Ik ben gisteren begonnen met DAO in een eigen docker, so far so good.
Ik heb thuis een warmtepomp die ook warm water maakt met een boiler. Dit is alleen niet regelbaar. Ik weet dat de boiler wordt verwarmd tussen 12 en 14 's middags. De warmtepomp doet vloerkoeling of verwarming wanneer nodig.

Aangezien dit apparaat dus niet te sturen valt. Moet ik dat dan meenemen in de baseload? Of kan DAO het verbruik van de warmtepomp wel meenemen om er voor te zorgen dat de SOC van de accu wel geschikt is om 0 op de meter te blijven draaien?

[hemertje]

DaBit schreef op maandag 30 juni 2025 @ 11:48:
[...]


Als jij DAO vertelt dat terugleveren van stroom geld kost (bij mij/Nextenergy dus ~2ct/kWh) dan is-ie al sneller geneigd om overtollige zonnestroom in de accu te stoppen.


[...]


Eerste probleem: Li-ion batterijen degraderen relatief vlot als ze langdurig op hele lage SoC gehouden worden. Dat geld voor alle kathodematerialen, dus ook voor LFP. Langdurig 100% vol en hogere temperaturen is ook zo'n situatie die je wil vermijden als je daar geen verdere nadelen van ondervind.
Ik laat de wellesnietes-discussie of je daar tijdens de levensduur van je batterij last van hebt even in het midden; google wat rond en maak je eigen keus.

Tweede probleem met lage SOC is dat je makkelijk onder de 0% grens schiet. Stel, je ontlaad naar 0% en laad alleen bij als er overschot aan zon is. Dat kan ooit weken duren, en in die tijd sippen de verbruikers op die batterij (BMS, omvormer, bla) de cellen onder de 0%. Dat geeft onmiddelijke en onomkeerbare schade. Dit effect is doodsoorzaak nummer 1 van Li-ion cellen.
Dat heb je bij 3-5% ook nog wel; vroeg of laat slijt 1 cel iets harder dan z'n broertjes dus als het hele pack dan nog op 5% zit kan het best zijn dat er 1 cel tegen 0 zit. Bij LFP kun je dat aan de celspanning niet zo goed zien.

Derde probleem: als je een keer stroomuitval krijgt en je batterij is zo ketsleeg dat je nog geen lampje kunt laten branden dan ga je dat de komende 30 jaar op elk familiefeestje te horen krijgen


Persoonlijk laad ik wel naar 100% want daar blijft het pack toch nooit heel lang op staan en alles naar 100% is een reset van alle tellertjes en eventuele onbalans. Maar aan de onderkant van de SoC vind ik persoonlijk 20% kortdurend / 25% langdurend wel een mooie grens. Geen risico dat er cellen diepontladen worden, worstcase nog zo'n 6kWh over om een lampje te kunnen laten branden, telefoon te laden en eten te koken.
Iets lager kan imho ook nog wel, zeg 10%/15%. Maar daaronder ben je te gulzig als je het mij vraagt.

hoe zit dit bij zogenaamde loodgel accu's die bv Qurmit gebruikt?

https://qurmit.com/

[DaBit]

hemertje schreef op donderdag 3 juli 2025 @ 20:52:
hoe zit dit bij zogenaamde loodgel accu's die bv Qurmit gebruikt?

Bedoel je kwa SoC limieten? Volgens mij gebruiken ze loodaccu's, dus dan zou ik zeggen 100% bovengrens, 50% ondergrens, 60-80% landurigere ondergrens. Loodaccu's vinden regelmatig diep ontladen worden niet leuk, en daar kun je met gel, glasmatten, calcium, etcetera maar deels wat aan doen.
Maar ik zou het even bij die mensen zelf navragen, want als ze vinden dat een thuisaccu op basis van lood-zuur anno 2025 levensvatbaar is dan hebben ze vast wat bijzonders. Een heel goed marketingbureau in de arm genomen ofzo.

Kwa DAO-gedrag: DAO weet niks van chemie. Het gedrag van DAO verandert hooguit omdat je 75% laad/ontlaad efficientie en vrij hoge kosten per cyclus in gaat voeren. Qurmit is op basis van Victron, dus samenwerken met HA/DAO zou geen probleem moeten zijn.

[Torch1969]

DaBit schreef op donderdag 3 juli 2025 @ 09:12:
[...]


Stel, je hebt ingesteld dat je met 0kW of 4kW kunt laden. En dat er op een gegeven moment nog 1kWh bij moet om op het ingestelde percentage +/- de marge uit te komen.

Dan heb je drie opties voor dat uur:
- Niet laden. Dan haal je het gewenste percentage niet
- Een uur laden met 4kW. Dan schiet je er overheen.
- Die stop entity gebruiken om 1/4 van een uur te laden. Dan kom je precies goed uit.

Persoonlijk vind ik die stop entiteiten een hoop extra logica voor weinig winst. Ik doe liever de botte-bijl methode en draai de DAO optimalisatie wat vaker. Maar ik vind het ook niet zo erg dat een ingestelde 80% uitkomt op bijvoorbeeld 83%, en ik heb al vaker aangegeven dat ik terughoudend ben met logica implementeren omdat de tijd voor testen/optimalisatie exponentieel toeneemt met de hoeveelheid logica en minder logica betrouwbaardere systemen oplevert. Jouw mening hierover kan en mag best afwijken.

Ja ik begrijp dat je op deze manier 1kWh kunt laden met vol vermogen (omdat die niet is terug te regelen), maar wat ik zag dat dit in de strategie voor komende nacht stond gepland voor meerdere uren. Dus er moet b.v. nog 4kWh geladen worden en dit stond als 4 x een kwartier gepland. Ik zou verwachten dat dit gewoon in één uur (het goedkoopste) gepland zou worden. Zal wel komen omdat dao in het minimize consumption algoritme probeert het laden uit te smeren over een langere periode en daarna kijkt hoe dit aan te sturen is en dan erachter komt dat er maar met één vermogen geladen kan worden en het dus over een deel van het uur plant…. En dat is dan niet logisch volgens mij, want per saldo ben je dan dus duurder uit (afgezien van het meerdere keren aan/uitschakelen van de laadpaal)

Edit: heb de grafiek en report er nog even bij gezocht (gaat mij dus om dat lang uitgesmeerde EV laden, terwijl ik alleen met 15A kan laden…):

code:

 2025-06-30 18:02:46 info: Inzet-factor laden Kia per stap
uur   0.0A  15.0A 
18    0.46   0.54   
19    0.66   0.34   
20    0.90   0.10   
21    0.84   0.16   
22    0.87   0.13   
23    0.91   0.09   
 0    0.96   0.04   
 1    0.91   0.09   
 2    0.91   0.09   
 3    0.31   0.69   
 4    0.96   0.04   
 5    0.93   0.07   
 6    0.96   0.04   
 7    0.79   0.21   
 8    0.51   0.49   
2025-06-30 18:02:46 info: Berekeningsuitkomst voor opladen van Kia:
2025-06-30 18:02:46 info: - aantal ampere 15A (was 0.0A)
2025-06-30 18:02:46 info: - stand schakelaar 'on' (was 'off')
2025-06-30 18:02:46 info: - stop laden op 2025-06-30 18:35
2025-06-30 18:02:46 info: - positie: home
2025-06-30 18:02:46 info: - ingeplugd: True
2025-06-30 18:02:46 info: Laden van Kia aangezet met 15 ampere via 'input_number.dao_ev_set_charging_ampere'
2025-06-30 18:02:46 info: Evaluatie status laden Kia op 2025-06-30 18:02
2025-06-30 18:02:46 info: - schakelaar laden: on
2025-06-30 18:02:46 info: - aantal ampere: 15.0
2025-06-30 18:02:46 info: Grid set point: 0.0 W

[ Voor 29% gewijzigd door Torch1969 op 04-07-2025 12:55 ]

[DaBit]

Torch1969 schreef op vrijdag 4 juli 2025 @ 11:59:
Dus er moet b.v. nog 4kWh geladen worden en dit stond als 4 x een kwartier gepland. Ik zou verwachten dat dit gewoon in één uur (het goedkoopste) gepland zou worden.

Ik zie dat soort dingen ook gebeuren inderdaad:



Het ene kwartier is DAO de accu aan het bijladen (03.45-04.00 vannacht) om daarna nul-op-meter te vragen (04.00-04.30). Enzovoorts.
DAO is er toch nog niet helemaal voor gemaakt om elk kwartier een optimalisatie te draaien met uitkomsten die voor het komende uur bedoeld zijn lijkt het.

@KC27 : heb je toevallig al een kwartiers-testversie?

[Impossibl3]

Ik heb een gebruikersvraag mbt het onderdeel warmtepomp.

Onze warmtepomp kan zowel verwarmen als koelen. Hoe kan ik deze het beste invoeren? Ik kan dit doen als 1 warmtepomp met een lijst van COP's onder heating maar de COP's (of eigenslijk EER's) zijn anders bij koelen dan verwarmen. Kan ik twee warmtepompen toevoegen? Of hoe moet ik dit invullen?

Ik ben namelijk ook een aantal kWh sensoren aan het maken die het verbruik van mijn WP totaal splits in WP - DHW, WP - Verwarmen/Koelen of dus WP - Verwarmen, WP - Koelen. De warmtepomp stuurt naar HA in welke status die staat (verwarmen, koelen, tapwater, rust). Zeker als verwarmen/koelen losgaat moet ik bedenken waar het verbruik van rust bij geteld moet worden om een correct beeld te krijgen.

Ik hoor graag jullie ideeën.

[KC27]

Torch1969 schreef op vrijdag 4 juli 2025 @ 11:59:
[...]


Ja ik begrijp dat je op deze manier 1kWh kunt laden met vol vermogen (omdat die niet is terug te regelen), maar wat ik zag dat dit in de strategie voor komende nacht stond gepland voor meerdere uren. Dus er moet b.v. nog 4kWh geladen worden en dit stond als 4 x een kwartier gepland. Ik zou verwachten dat dit gewoon in één uur (het goedkoopste) gepland zou worden. Zal wel komen omdat dao in het minimize consumption algoritme probeert het laden uit te smeren over een langere periode en daarna kijkt hoe dit aan te sturen is en dan erachter komt dat er maar met één vermogen geladen kan worden en het dus over een deel van het uur plant…. En dat is dan niet logisch volgens mij, want per saldo ben je dan dus duurder uit (afgezien van het meerdere keren aan/uitschakelen van de laadpaal)

Edit: heb de grafiek en report er nog even bij gezocht (gaat mij dus om dat lang uitgesmeerde EV laden, terwijl ik alleen met 15A kan laden…):
[Afbeelding]

code:

 2025-06-30 18:02:46 info: Inzet-factor laden Kia per stap
uur   0.0A  15.0A 
18    0.46   0.54   
19    0.66   0.34   
20    0.90   0.10   
21    0.84   0.16   
22    0.87   0.13   
23    0.91   0.09   
 0    0.96   0.04   
 1    0.91   0.09   
 2    0.91   0.09   
 3    0.31   0.69   
 4    0.96   0.04   
 5    0.93   0.07   
 6    0.96   0.04   
 7    0.79   0.21   
 8    0.51   0.49   
2025-06-30 18:02:46 info: Berekeningsuitkomst voor opladen van Kia:
2025-06-30 18:02:46 info: - aantal ampere 15A (was 0.0A)
2025-06-30 18:02:46 info: - stand   2025-06-30 18:35
2025-06-30 18:02:46 info: - positie: home
2025-06-30 18:02:46 info: - ingeplugd: True
2025-06-30 18:02:46 info: Laden van Kia aangezet met 15 ampere via 'input_number.dao_ev_set_charging_ampere'
2025-06-30 18:02:46 info: Evaluatie status laden Kia op 2025-06-30 18:02
2025-06-30 18:02:46 info: - schakelaar laden: on
2025-06-30 18:02:46 info: - aantal ampere: 15.0
2025-06-30 18:02:46 info: Grid set point: 0.0 W

Er is een dilemma in deze situatie:
- enerzijds wil jij "minimize consumption", want dat is je gekozen strategie
- anderzijds wil je in het goedkoopste uur laden, maar dan moet er ingekocht worden
De situatie wordt nog meer op scherp gezet omdat je alleen maar met 16A kunt laden.
Ik weet dat het heel vreemd klinkt, maar zou je een proef-berekening (calc met debug) willen doen waarbij je of salderen op "false" of je zet "energy taxes production" op nul (bijna hetzelfde).
Waarschijnlijk rekent ie dan precies zoals jij zou willen (nl zoveel mogelijk eigen gebruik).
Ik wil ook wel iets aan de instellingen toevoegen/veranderen om aan je wens tegemoet te komen, maar hoe zou je het dan willen?

[KC27]

DaBit schreef op vrijdag 4 juli 2025 @ 18:53:
[...]


Ik zie dat soort dingen ook gebeuren inderdaad:

[Afbeelding]

Het ene kwartier is DAO de accu aan het bijladen (03.45-04.00 vannacht) om daarna nul-op-meter te vragen (04.00-04.30). Enzovoorts.
DAO is er toch nog niet helemaal voor gemaakt om elk kwartier een optimalisatie te draaien met uitkomsten die voor het komende uur bedoeld zijn lijkt het.

@KC27 : heb je toevallig al een kwartiers-testversie?

Ik stuur een je dm.

[KC27]

Impossibl3 schreef op vrijdag 4 juli 2025 @ 23:07:
Ik heb een gebruikersvraag mbt het onderdeel warmtepomp.

Onze warmtepomp kan zowel verwarmen als koelen. Hoe kan ik deze het beste invoeren? Ik kan dit doen als 1 warmtepomp met een lijst van COP's onder heating maar de COP's (of eigenslijk EER's) zijn anders bij koelen dan verwarmen. Kan ik twee warmtepompen toevoegen? Of hoe moet ik dit invullen?
.....

Voor koeling heeft DAO helemaal nog geen mogelijkheid.
Als daar veel behoefte naar is wil ik daar graag met jullie naar kijken hoe dat is te implementeren.
Want koelen met een wp of met een of meer airco's werkt waarschijnlijk vergelijkbaar.
Ik heb zelf een grondgebonden wp en die koelt "passief" met 50W, dus voor mijzelf is het niet interessant. maar gebruikers met een lucht/water wp of met airco('s) (lucht/lucht) kan het interessant zijn.
Ik hoor graag hoe jullie hier over denken en ik hoor ook graag ideeën en suggesties hoe we dat kunnen implementeren.

[Impossibl3]

KC27 schreef op vrijdag 4 juli 2025 @ 23:52:
[...]

Voor koeling heeft DAO helemaal nog geen mogelijkheid.
Als daar veel behoefte naar is wil ik daar graag met jullie naar kijken hoe dat is te implementeren.
Want koelen met een wp of met een of meer airco's werkt waarschijnlijk vergelijkbaar.
Ik heb zelf een grondgebonden wp en die koelt "passief" met 50W, dus voor mijzelf is het niet interessant. maar gebruikers met een lucht/water wp of met airco('s) (lucht/lucht) kan het interessant zijn.
Ik hoor graag hoe jullie hier over denken en ik hoor ook graag ideeën en suggesties hoe we dat kunnen implementeren.

Ik heb een lucht/water WP en waarschijnlijk nog ergens dit jaar een airco voor het verwarmen/koelen van de zolder(werk)kamer.

Een optie om dit in te bouwen zou super zijn. Volgens mij kan dit op de zelfde manier gaan als de WP er nu in zit maar dan onder de naam "airco". Meerdere "airco" apparaten zouden dan ook wenselijk zijn zodat die los aangestuurd kunnen worden. In mijn geval dus een WP en een airco.

De "airco" krijgt dan net als de WP een EER en dat die actief is of niet. Volgens mij is die niet heel anders dan de WP nu in DAO zit.

Brengt mij gelijk bij het tapwater (boiler). Ik kan nog niet bedenken hoe ik doe moet invullen met diverse COP's op basis van de buiten temperatuur en gewenste doeltemperatuur. Nu kan ik maar 1 waarde invullen terwijl dat ook variabel is net als bij het verwarmen.

[KC27]

Ik ben namelijk ook een aantal kWh sensoren aan het maken die het verbruik van mijn WP totaal splits in WP - DHW, WP - Verwarmen/Koelen of dus WP - Verwarmen, WP - Koelen. De warmtepomp stuurt naar HA in welke status die staat (verwarmen, koelen, tapwater, rust). Zeker als verwarmen/koelen losgaat moet ik bedenken waar het verbruik van rust bij geteld moet worden om een correct beeld te krijgen.

Ik hoor graag jullie ideeën.

Wel een beetje off-topic (beter in het HA topic):
Ik splits het verbruik van mijn warmtepomp ook uit over vier categorieën.
Dat doe ik in HA met een utility-meter in combinatie met een automation.
Ik heb voor het dagelijks verbruik deze utiliy_meter aangemaakt (in configuration.yaml):

YAML:

  daily_wp_consumption:
    source: sensor.youless_meterstand
    name: daily_wp_consumption
    cycle: daily
    tariffs:
      - norequest
      - heating
      - hot_water
      - cooling

En met een automation wordt afhankelijk van de status het goede tarief gezet:

YAML:

alias: split wp consumption
description: ""
mode: single
triggers:
  - entity_id: sensor.status_wp
    trigger: state
conditions: []
actions:
  - target:
      entity_id: select.daily_wp_consumption
    data:
      option: >-
        {% if (states('sensor.status_wp') == 'no request') %} norequest {%
        elif (states('sensor.status_wp') == 'heating') %} heating {% elif
        (states('sensor.status_wp') == 'hot water') %} hot_water {% else %}
        cooling {% endif %}
    action: select.select_option

[Impossibl3]

Bedenk mij nu net voor de momenten dat het er nog niet in zit. Kan ik de WP-Koelen dan toevoegen als machine die niet te sturen is? Hierdoor gaat DOA niets met de WP doen onder heating (waar nu dus ook koeling onder valt)

[Torch1969]

KC27 schreef op vrijdag 4 juli 2025 @ 23:30:
[...]

Er is een dilemma in deze situatie:
- enerzijds wil jij "minimize consumption", want dat is je gekozen strategie
- anderzijds wil je in het goedkoopste uur laden, maar dan moet er ingekocht worden
De situatie wordt nog meer op scherp gezet omdat je alleen maar met 16A kunt laden.
Ik weet dat het heel vreemd klinkt, maar zou je een proef-berekening (calc met debug) willen doen waarbij je of salderen op "false" of je zet "energy taxes production" op nul (bijna hetzelfde).
Waarschijnlijk rekent ie dan precies zoals jij zou willen (nl zoveel mogelijk eigen gebruik).
Ik wil ook wel iets aan de instellingen toevoegen/veranderen om aan je wens tegemoet te komen, maar hoe zou je het dan willen?

Je begrijpt inmiddels al dat ik inderdaad op zoek ben naar een optimale situatie tussen minimize consumption en minimize cost. Ik had ook al bedacht dat als saldering weg is, de optie saldering op “false” moet en dan, icm minimize cost, de werking (bijna) is zoals ik zou willen. Ik ga daar eens verder mee testen. Om nu nog van alles in te bouwen voor 1,5 jaar lijkt me niet zinvol. Anders gewoon nog maar even 1,5 jaar euro’s stampen met de accu.

[Torch1969]

KC27 schreef op vrijdag 4 juli 2025 @ 23:52:
[...]

Voor koeling heeft DAO helemaal nog geen mogelijkheid.
Als daar veel behoefte naar is wil ik daar graag met jullie naar kijken hoe dat is te implementeren.
Want koelen met een wp of met een of meer airco's werkt waarschijnlijk vergelijkbaar.
Ik heb zelf een grondgebonden wp en die koelt "passief" met 50W, dus voor mijzelf is het niet interessant. maar gebruikers met een lucht/water wp of met airco('s) (lucht/lucht) kan het interessant zijn.
Ik hoor graag hoe jullie hier over denken en ik hoor ook graag ideeën en suggesties hoe we dat kunnen implementeren.

Ik heb ook interesse in aansturing airco. Hoe het precies moet vindt ik lastig aangeven. Ik begin in ieder geval met situatiebeschrijving:
Ik heb een multisplit airco. Oftewel één buiten unit en 3 binnen units in 3 kamers. Ik gebruik deze voor koelen én verwarmen (‘s winters in 2 kamers). De temperatuurinstelling is per kamer. Het energieverbruik rapportage voor de totale installatie. Ik heb wel gezien dat het energieverbruik hoger is als het verschil in temperatuur tussen binnen, buiten en setpoint hoger is, maar heb hier geen efficiency curves/gegevens voor. Ik zet nu de airco op de slaapkamer aan rond 12 ‘s middags om de kamer koel te houden gedurende de periode met lage temperatuur. ‘s avond laat ik hem draaien of zet ik hem uit in de uren met hoge prijs. Bij het naar bed gaan nog even laten draaien tot temperatuur buiten laag genoeg is. De andere 2 kamers koel of verwarm ik alleen bij gebruik (thuiswerken).

Geen idee hoe dit met instellingen goed te configureren is en hoe je dan de aansturing vanuit HA doet….

[diamanten]

Een vraag over de port:
Ik wil dao draaien op port 5001.
Dit is mijn config:

In de dao log zie ik dit:

code:

[2025-07-05 19:17:05 +0200] [12] [INFO] Starting gunicorn 23.0.0
[2025-07-05 19:17:05 +0200] [12] [INFO] Listening at: http://0.0.0.0:5000 (12)

Waarom staat daar nog steeds 5000?

Nb. http://192.168.x.yyy:5001/ geeft wel het dao interface, dus ik neem aan dat de configuratie wel goed is gegaan.

[RudolfR]

@diamanten

Dat is hoe docker werkt; poorten van de host worden gemapt naar de applicatie in docker.
Het voordeel hiervan is dat je alleen configuratie van de docker add-on hoeft te wijzigen, zodat de poort op de host veranderd. Voor DAO blijft alles hetzelfde, die werkt nog steeds op 5000.

[diamanten]

RudolfR schreef op zaterdag 5 juli 2025 @ 20:15:
@diamanten

Dat is hoe docker werkt; poorten van de host worden gemapt naar de applicatie in docker.
Het voordeel hiervan is dat je alleen configuratie van de docker add-on hoeft te wijzigen, zodat de poort op de host veranderd. Voor DAO blijft alles hetzelfde, die werkt nog steeds op 5000.

OK, dank voor je uitleg!

Trouwens ik ben ook geinteresseerd in het toevoegen van een airco-optie in dao.
Ik maak gebruik van de mitsubishi addon:
https://github.com/jeatheak/Mitsubishi-WF-RAC-Integration/
met ondermeer deze sensor.airco_xxxxx_energy_usage_cycle: energie in kWh.
Momenteel heb ik een quick&dirty oplossing gemaakt door een machine aan te maken (zie ook mijn eerdere posts):

code:

  "machines" : [ 
      { "name": "Airco",
        "programs":[
          {"name": "Uit",
           "power": []},
          {"name": "Auto",
           "power": [1000, 1000, 1000, 1000, 1000, 1000, 1000, 800, 600]
           }
        ],
        "entity start window": "input_datetime.start_window_airco",
        "entity end window": "input_datetime.eind_window_airco",
        "entity selected program": "input_select.airco_programma",
        "entity calculated start": "input_datetime.berekende_start_airco",
        "entity calculated end": "input_datetime.berekende_stop_airco"
      }
  ],

[KC27]

Vanavond is versie 2025.7.0 van DAO gepubliceerd.
Belangrijkste nieuws:

• BREAKING : geen ondersteuning meer voor i386-processors
• cryptography-package is toegevoegd, zodat gebruikers met mysql-database (niet te verwarren met mariadb) kunnen inloggen met encrypted wachtwoord
• een heleboel packages zijn geupdate dankzij het toevoegen van een dependabot-workflow die dat dagelijks checkt (met veel dank aan @simnet )
• bij gebruikers met een postgresql-database wordt gechecked of de timezone staat op de lokale timezone (reported by @balk )

[firecaps30]

Sinds een paar dagen beweegt de accu SoC lijn niet meer mee. Al een restart gedaan maar niet geholpen, er is niets aan de config veranderd.

[sMoKeFiSh]

firecaps30 schreef op dinsdag 8 juli 2025 @ 08:57:
Sinds een paar dagen beweegt de accu SoC lijn niet meer mee. Al een restart gedaan maar niet geholpen, er is niets aan de config veranderd.

[Afbeelding]

Hoe ziet de history van de SoC entity in Homeassistant eruit? Vera derd die wel?

[firecaps30]

sMoKeFiSh schreef op dinsdag 8 juli 2025 @ 12:21:
[...]

Hoe ziet de history van de SoC entity in Homeassistant eruit? Vera derd die wel?

Ja, de lijn van de grafiek verandert ook mee zoals hieronder te zien in, maar SoC fluctueert niet:

[itavero]

firecaps30 schreef op dinsdag 8 juli 2025 @ 15:21:
[...]

Ja, de lijn van de grafiek verandert ook mee zoals hieronder te zien in, maar SoC fluctueert niet:

Ik geloof dat @sMoKeFiSh bedoelde hoe de SoC er in de geschiedenis in Home Assistant zelf uitziet. Dat kan ik uit dit plaatje niet opmaken.

[ Voor 5% gewijzigd door itavero op 08-07-2025 15:47 ]

[KC27]

firecaps30 schreef op dinsdag 8 juli 2025 @ 15:21:
[...]

Ja, de lijn van de grafiek verandert ook mee zoals hieronder te zien in, maar SoC fluctueert niet:

[Afbeelding]

Je ziet dat alle zonne-energie niet naar de accu maar naar je huis en het net gaat.
Ikzelf heb de laatste tijd ook veel gebruik van mijn accu, omdat de "spread" tussen hoge en lage prijzen de laatste dagen minder is (we tikken de "nul" niet meer aan).
Hoe hoog staat jouw "cycle cost"? Als die hoog staat zorgt dat ervoor dat bij een lage spread er niet wordt geladen/ontladen. Bij mij staat die op 0,01 euro/kWh.
Ook de efficiency van het laden en ontladen tussen DC en BAT speelt een rol. Staat bij mij op 0,97.

[firecaps30]

KC27 schreef op dinsdag 8 juli 2025 @ 17:56:
[...]

Je ziet dat alle zonne-energie niet naar de accu maar naar je huis en het net gaat.
Ikzelf heb de laatste tijd ook veel gebruik van mijn accu, omdat de "spread" tussen hoge en lage prijzen de laatste dagen minder is (we tikken de "nul" niet meer aan).
Hoe hoog staat jouw "cycle cost"? Als die hoog staat zorgt dat ervoor dat bij een lage spread er niet wordt geladen/ontladen. Bij mij staat die op 0,01 euro/kWh.
Ook de efficiency van het laden en ontladen tussen DC en BAT speelt een rol. Staat bij mij op 0,97.

Ah ja, die verandert mee;

sensor.growattzoldermodbus_bms_1_soc is dat in HA.

uit de config file:
"entity actual level": "sensor.growattzoldermodbus_bms_1_soc"

Cycle cost staat op 0.1;

"minimum power": 250,
"dc_to_bat efficiency": 0.93,
"dc_to_bat max power" : 5000.0,
"bat_to_dc efficiency": 0.93,
"bat_to_dc max power" : 5000.0,
"cycle cost": 0.10

Het zal dan inderdaad wel met de lage spreads te maken hebben.

[KC27]

firecaps30 schreef op dinsdag 8 juli 2025 @ 18:18:
[...]


Ah ja, die verandert mee;

sensor.growattzoldermodbus_bms_1_soc is dat in HA.

uit de config file:
"entity actual level": "sensor.growattzoldermodbus_bms_1_soc"

Cycle cost staat op 0.1;

"minimum power": 250,
"dc_to_bat efficiency": 0.93,
"dc_to_bat max power" : 5000.0,
"bat_to_dc efficiency": 0.93,
"bat_to_dc max power" : 5000.0,
"cycle cost": 0.10

Het zal dan inderdaad wel met de lage spreads te maken hebben.

Maar je cyclecost staat wel hoog: 10cts/kWh. De waardevermindering van je batterijen gaat waarschijnlijk veel sneller door veroudering (jaren) en technische/economische veroudering dan door slijtage ten gevolge van laden/ontladen.
Ook je efficiency (0,93) vind ik laag. Als je LiFePO4 cellen hebt en je blijft met de (ont)laadsnelheid onder de 0,2 C zijn die verliezen veel minder.