Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[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.