Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[DaBit]

RudolfR schreef op maandag 28 april 2025 @ 12:05:
Misschien wel een bug.
Zou kunnen dat er per abuis naar de settings van de 1e EV wordt gekeken.

Klinkt aannemelijk ja!
KC27 zal er vanzelf wel op reageren, geen haast.

arro3038 schreef op maandag 28 april 2025 @ 12:13:
Geen oplossing van je error, maar waarom gebruik je de boiler in DAO niet? DAO geeft aan wanneer je boiler zou moeten gaan verwarmen (op elektra), dan kun je zelf op dat moment in HA of Node red beslissen of je dat op gas of op elektra wilt doen.

Nou, die boiler probeert de hele tijd te verwarmen. Ik zie in de documentatie (https://github.com/cornee.../dao/DOCS.md#configuratie) ook geen verwijzing meer staan naar wanneer die boiler klaar moet zijn (dat was er wel ooit meen ik?).
Verder is het (zeker als de panelen uitgaan) best handig als DAO de vermogens kan plannen. Een 3x25A aansluiting is nogal krap voor auto, thuisaccu, boiler, etc.
Dat vermogens plannen lukt minder goed als ik extern blokkeer. Al is dat geen ultiem drama, ook al niet omdat ik DAO om het kwartier laat rekenen, juist om om te gaan met DAO-krijgt-niet-wat-ie-vraagt.
DAO kent voor de boiler ook alleen alles of niks, maar niet deelvermogen (ik kan de boiler traploos regelen).
Eigenlijk kan met dat boilerdeel net niks, of ik snap nog niet goed genoeg hoe het werkt.

Beschouw ik de boiler als 'elektrische auto', dan doet het in potentie eigenlijk precies wat ik wil. Als die boiler 'ingeplugd' wordt omdat de randcondities goed zijn dan weet DAO hoeveel energie erin moet (namelijk 4.18kJ/kg.K maal 100 liter/kilo = ~0.13kWh/graad opwarming. Pakken we de graden als 'procent SoC' dan moeten we de capaciteit van de 100L boiler instellen op 13.4kWh) om op het gewenste tijdstip de temperatuur te halen.
Vervolgens kan dat net zoals bij een EV ingeschaald worden op het meest gunstige moment, en DAO weet van het boilervermogen af.

Dan kan het zijn dat DAO dat inschaalt op een moment waarop de elektra niet meer goedkoper is, maar ik vermoed dat dat wel mee gaat vallen. Met een EV heb je hetzelfde trouwens; die word ook uitgeplugd.

Het is een experiment waard in ieder geval. Mag het eerst droog draaien naast het bestaande spul.

Huidig stukje codekoeterwaals wat dan door DAO vervangen zou worden is dit:
(jaja, kan een stuk netter. Doet de truuk echter best aardig)

code:

..
const eCheaper_temps = [70,60,55,50,45,40,40];   // cheapest hours vs boiler setpoint map
..
// Is electricity cheaper than gas?
let electricityIsCheaper = global.get("electricityIsCheaper");
if (electricityIsCheaper) {
    // Even though electricity is cheaper, only heat in the 6 cheapest hours
    // Note for GoT: priceArray is today's prices sorted from most expensive hour to cheapest hour
    if (priceArray.length >= 21) {
        let n=0;
        for (let i = (priceArray.length - 1); i >= (priceArray.length-7); i--) {
            if (priceArray[i][0] == hour) {
                // Set limit to the maximum
                desiredBoilerTemp = eCheaper_temps[n];
                energyQuotum = absoluteMaxEnergyQuotum;
            }
            n = n+1;
        }
    }
}

[KC27]

DaBit schreef op maandag 28 april 2025 @ 11:34:
Ik heb een 100L COP=1 elektrische boiler als voorverwarmer voor mijn tapwater. Die boiler moet gebruikt worden als het uitkan, dus als warmwater breiden met elektriciteit goedkoper is dan gas. Die boiler draait nu buiten DAO om met een stukje nodered dat kijkt of electriciteit goedkoper is dan gas, sorteert op goedkoopste uren en het setpoint aanpast (70C in het goedkoopste uur aflopend naar 45C).

Ideaal is dat niet op dagen zoals gisteren; de stroom was al veel eerder goedkoper dan gas voor-ie negatief ging. Dan is de boiler al een aardig eind op temperatuur. Verder weet DAO niks van de consumptie van die boiler wat de totale oplossing minder optimaal maakt.

Ik probeerde nu dus om die boiler als 2e elektrische auto in de voeren. Dat doet wat ik wil denk ik; de goedkoper-dan-gas boolean kan dienst doen als 'is plugged in', gemeten/gewenste temperatuur is niet anders dan procenten SoC, ik kan opgeven wanneer het klaar moet zijn, en DAO kan het optimaal inplannen.

De nep-auto in de configuratiefile. Daar zitten nog een paar dingetjes in van de echte EV bij de boiler maar die worden toch niet gebruikt (corsae_location is altijd 'home' bijvoorbeeld)

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}
      ],
      "entity actual level": "sensor.corsa_e_battery_percent",
      "entity plugged in": "binary_sensor.charger_pluggedin",
      "charge scheduler": {
        "entity set level": "input_number.ev_desired_chargelevel",
        "level margin": 1,
        "entity ready datetime": "input_datetime.charge_ready_datetime"
      },
      "charge switch": "input_boolean.corsae_charge_switch",
      "entity set charging ampere": "input_number.dao_laadpaal_amp"
    },
    {
      "name": "boiler",
      "capacity": 11.4,
      "entity max amperage": "input_number.ev_max_charge_amps",
      "entity position": "input_select.corsae_location",
      "charge three phase": "False",
      "charge stages" : [
      {"ampere":  0,  "efficiency":  1},
      {"ampere":  3,  "efficiency": 0.99 },
            {"ampere":  5,  "efficiency": 0.99 },
      {"ampere":  8,  "efficiency": 0.98 },
            {"ampere":  10, "efficiency": 0.98 }
      ],
      "entity actual level": "sensor.boiler_boiler_temperature",
      "entity plugged in": "binary_sensor.electricity_cheaperthangas",
      "charge scheduler": {
        "entity set level": "input_number.boiler_desiredtemperature",
        "level margin": 1,
        "entity ready datetime": "input_datetime.dao_boiler_ready_datetime"
      },
      "charge switch": "input_boolean.dao_boiler_activate",
      "entity set charging ampere": "input_number.dao_boiler_ampsetpoint"
    }
  ],
..
..

Na draaien optimalisatie krijg ik deze foutmeldingen:

code:

..
..
2025-04-28 11:15:07 info: Berekeningsuitkomst voor opladen van Corsa-E:
2025-04-28 11:15:07 info: - aantal ampere 0A (was 0.0A)
2025-04-28 11:15:07 info: - stand schakelaar 'off' (was 'off')
2025-04-28 11:15:07 info: - positie: home
2025-04-28 11:15:07 info: - ingeplugd: True
2025-04-28 11:15:07 info: Evaluatie status laden Corsa-E op 2025-04-28 11:15
2025-04-28 11:15:07 info: - schakelaar laden: off
2025-04-28 11:15:07 info: - aantal ampere: 0.0
2025-04-28 11:15:07 info: Inzet-factor laden boiler per stap
uur   0.0A   3.0A   5.0A   8.0A  10.0A 2025-04-28 11:15:07 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3452, in <module>
2025-04-28 11:15:07 fout: File: /root/dao/webserver/../prog/day_ahead.py, line 3426, in main
2025-04-28 11:15:07 fout: File: /root/dao/prog/da_base.py, line 479, in run_task_function
2025-04-28 11:15:07 fout: File: /root/dao/prog/da_base.py, line 410, in calc_optimum_met_debug
2025-04-28 11:15:07 fout: File: /root/dao/prog/day_ahead.py, line 2866, in calc_optimum
2025-04-28 11:15:07 fout: Onverwachte fout: list index out of range
Traceback (most recent call last):
  File "/root/dao/prog/day_ahead.py", line 2441, in calc_optimum
    print(f" {charge_stages[e][cs]['ampere']:4.1f}A", end=" ")
              ~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range

Vast stupid user error, maar waar?

Nee geen stupid user user!
Stomme programmeer fout die alleen optreedt bij meer dan 1 auto.
Door deze fout in de uitvoer naar de logging "springt ie eruit" en worden de settings niet naar de "auto" gestuurd.
Inmiddels staat rc3 in de test-branche, maar ik neem het herstel van deze fout mee naar rc4 die vanavond naar de testbranche gaat..
Zou jij hem dan willen testen?
Je kunt nu al testen of je oplossing goed gaat door "de gewone auto" tijdelijk uit je settings te halen.

Dank voor het melden!

[arro3038]

DaBit schreef op maandag 28 april 2025 @ 14:05:
[...]
Nou, die boiler probeert de hele tijd te verwarmen. Ik zie in de documentatie

Aha op die manier. Leuk experiment . En meteen een bug gevonden die ook alweer wordt opgelost

[DaBit]

KC27 schreef op maandag 28 april 2025 @ 14:41:
Inmiddels staat rc3 in de test-branche, maar ik neem het herstel van deze fout mee naar rc4 die vanavond naar de testbranche gaat..
Zou jij hem dan willen testen?

Ja hoor, dat wil ik wel doen.

Je kunt nu al testen of je oplossing goed gaat door "de gewone auto" tijdelijk uit je settings te halen.

Ik wacht wel even op die RC4 of desnoods een RC5. Geen bloedspoed.
De huidige oplossing functioneert ook vrij optimaal zolang er niet teveel elektra-goedkoper-dan-gas uren in een etmaal zitten.

arro3038 schreef op maandag 28 april 2025 @ 14:46:
Aha op die manier. Leuk experiment .

Ik zal wel terugmelden of het ook doet wat ik ervan verwacht. Want opzich is een relatief kleine elektrische boiler in serie voor de gasketel best een prima optie voor mensen die de benodigde buffervaten voor vol-elektrisch-warmtepomp niet kunnen plaatsen. Zo'n boilertje is toch 6+ kWh aan energie-opslag voor kostprijs 250 euro ofzo.

[martinisoft]

Hoi Allemaal,

Ik ben sinds afgelopen weekend met DAO gaan spelen en ik ben tot nu toe erg onder de indruk.
Inmiddels heb ik 3 Sessy batterijen, twee sets aan zonnepanelen en een boiler toegevoegd.
Ik laat de helpers in HA vooralsnog niets schakelen en kijk nu nog vooral mee wat DAO gedaan zou hebben.
Inmiddels heb ik een paar vraagjes over de "Boiler".
Vul ik in het geval van een warmtepomp bij "elec. power" het maximale elektrische vermogen in? of is het beter om rond het gemiddelde daadwerkelijk opgenomen vermogen te gaan zitten?

En op dit moment heb ik in Node-Red een Flow lopen die het moment bepaald waarop de WP de boiler kan/moet gaan verwarmen. Omdat niet alleen de elektriciteitsprijs maar ook de Buitentemperatuur hier een factor in kan zijn heb ik een tabel in die flow gestopt waarbij ik bij iedere hele graad tussen de -16 en +31 de COP heb ingevuld om deze mee te kunnen wegen bij de bepaling van het gunstigste uur:

var COP = '';
var tmpround = Math.round(temperature);
if (tmpround <= -16) {COP = 1}
if (tmpround == -15) {COP = 1.67}
if (tmpround == -14) {COP = 1.682}
if (tmpround == -13) {COP = 1.694}
if (tmpround == -12) {COP = 1.706}
if (tmpround == -11) {COP = 1.718}
if (tmpround == -10) {COP = 1.73}
if (tmpround == -9) {COP = 1.747}
if (tmpround == -8) {COP = 1.764}
if (tmpround == -7) {COP = 1.78}
if (tmpround == -6) {COP = 1.841}
if (tmpround == -5) {COP = 1.901}
if (tmpround == -4) {COP = 1.962}
if (tmpround == -3) {COP = 2.023}
if (tmpround == -2) {COP = 2.084}
if (tmpround == -1) {COP = 2.145}
if (tmpround == 0) {COP = 2.206}
if (tmpround == 1) {COP = 2.267}
if (tmpround == 2) {COP = 2.33}
if (tmpround == 3) {COP = 2.418}
if (tmpround == 4) {COP = 2.506}
if (tmpround == 5) {COP = 2.594}
if (tmpround == 6) {COP = 2.682}
if (tmpround == 7) {COP = 2.77}
if (tmpround == {COP = 2.888}
if (tmpround == 9) {COP = 3.006}
if (tmpround == 10) {COP = 3.124}
if (tmpround == 11) {COP = 3.242}
if (tmpround == 12) {COP = 3.36}
if (tmpround == 13) { COP = 3.463}
if (tmpround == 14) { COP = 3.566}
if (tmpround == 15) {COP = 3.67}
if (tmpround == 16) { COP = 3.772}
if (tmpround == 17) { COP = 3.874}
if (tmpround == 18) { COP = 3.976}
if (tmpround == 19) { COP = 4.078}
if (tmpround == 20) { COP = 4.18}
if (tmpround == 21) { COP = 4.232}
if (tmpround == 22) { COP = 4.284}
if (tmpround == 23) { COP = 4.335}
if (tmpround == 24) { COP = 4.387}
if (tmpround == 25) { COP = 4.44}
if (tmpround == 26) { COP = 4.491}
if (tmpround == 27) { COP = 4.543}
if (tmpround == 28) { COP = 4.595}
if (tmpround == 29) { COP = 4.647}
if (tmpround == 30) { COP = 4.699}
if (tmpround >= 31) { COP = 4.8}

Iets vergelijkbaars doet DAO ook al bij de "battery" (vermogen vs efficientie) en ook bij "heating" via een HA entity (entity hp cop). Is het een idee om dit ook voor "boiler" als optie toe te voegen? Of desnoods een switch waarmee je kunt bepalen dat de "entity hp cop" setting zoals ingesteld onder "heating" moet worden meegenomen? Idealiter wil ik natuurlijk van mijn eigen Node-Red flow af en gewoon alles door DAO laten regelen in de toekomst.

Ik ga intussen nog even verder puzzelen en finetunen.. DAO is echt super cool!

mvg

Martijn.

[KC27]

martinisoft schreef op maandag 28 april 2025 @ 16:36:
Hoi Allemaal,

Ik ben sinds afgelopen weekend met DAO gaan spelen en ik ben tot nu toe erg onder de indruk.
Inmiddels heb ik 3 Sessy batterijen, twee sets aan zonnepanelen en een boiler toegevoegd.
Ik laat de helpers in HA vooralsnog niets schakelen en kijk nu nog vooral mee wat DAO gedaan zou hebben.
Inmiddels heb ik een paar vraagjes over de "Boiler".
Vul ik in het geval van een warmtepomp bij "elec. power" het maximale elektrische vermogen in? of is het beter om rond het gemiddelde daadwerkelijk opgenomen vermogen te gaan zitten?

En op dit moment heb ik in Node-Red een Flow lopen die het moment bepaald waarop de WP de boiler kan/moet gaan verwarmen. Omdat niet alleen de elektriciteitsprijs maar ook de Buitentemperatuur hier een factor in kan zijn heb ik een tabel in die flow gestopt waarbij ik bij iedere hele graad tussen de -16 en +31 de COP heb ingevuld om deze mee te kunnen wegen bij de bepaling van het gunstigste uur:

var COP = '';
var tmpround = Math.round(temperature);
if (tmpround <= -16) {COP = 1}
if (tmpround == -15) {COP = 1.67}
if (tmpround == -14) {COP = 1.682}
if (tmpround == -13) {COP = 1.694}
if (tmpround == -12) {COP = 1.706}
if (tmpround == -11) {COP = 1.718}
if (tmpround == -10) {COP = 1.73}
if (tmpround == -9) {COP = 1.747}
if (tmpround == -8) {COP = 1.764}
if (tmpround == -7) {COP = 1.78}
if (tmpround == -6) {COP = 1.841}
if (tmpround == -5) {COP = 1.901}
if (tmpround == -4) {COP = 1.962}
if (tmpround == -3) {COP = 2.023}
if (tmpround == -2) {COP = 2.084}
if (tmpround == -1) {COP = 2.145}
if (tmpround == 0) {COP = 2.206}
if (tmpround == 1) {COP = 2.267}
if (tmpround == 2) {COP = 2.33}
if (tmpround == 3) {COP = 2.418}
if (tmpround == 4) {COP = 2.506}
if (tmpround == 5) {COP = 2.594}
if (tmpround == 6) {COP = 2.682}
if (tmpround == 7) {COP = 2.77}
if (tmpround == {COP = 2.888}
if (tmpround == 9) {COP = 3.006}
if (tmpround == 10) {COP = 3.124}
if (tmpround == 11) {COP = 3.242}
if (tmpround == 12) {COP = 3.36}
if (tmpround == 13) { COP = 3.463}
if (tmpround == 14) { COP = 3.566}
if (tmpround == 15) {COP = 3.67}
if (tmpround == 16) { COP = 3.772}
if (tmpround == 17) { COP = 3.874}
if (tmpround == 18) { COP = 3.976}
if (tmpround == 19) { COP = 4.078}
if (tmpround == 20) { COP = 4.18}
if (tmpround == 21) { COP = 4.232}
if (tmpround == 22) { COP = 4.284}
if (tmpround == 23) { COP = 4.335}
if (tmpround == 24) { COP = 4.387}
if (tmpround == 25) { COP = 4.44}
if (tmpround == 26) { COP = 4.491}
if (tmpround == 27) { COP = 4.543}
if (tmpround == 28) { COP = 4.595}
if (tmpround == 29) { COP = 4.647}
if (tmpround == 30) { COP = 4.699}
if (tmpround >= 31) { COP = 4.8}

Iets vergelijkbaars doet DAO ook al bij de "battery" (vermogen vs efficientie) en ook bij "heating" via een HA entity (entity hp cop). Is het een idee om dit ook voor "boiler" als optie toe te voegen? Of desnoods een switch waarmee je kunt bepalen dat de "entity hp cop" setting zoals ingesteld onder "heating" moet worden meegenomen? Idealiter wil ik natuurlijk van mijn eigen Node-Red flow af en gewoon alles door DAO laten regelen in de toekomst.

Ik ga intussen nog even verder puzzelen en finetunen.. DAO is echt super cool!

mvg

Martijn.

Martijn, ben je ermee geholpen als je de cop van de boiler kunt instellen via een entity en dat jij die dan in Home Assistant berekent op basis van de gemiddelde buitentemperatuur?

[Torch1969]

KC27 schreef op maandag 28 april 2025 @ 17:38:
[...]

Martijn, ben je ermee geholpen als je de cop van de boiler kunt instellen via een entity en dat jij die dan in Home Assistant berekent op basis van de gemiddelde buitentemperatuur?

Als ik me ook even mee mag bemoeien… nadeel daarvan is dat je alleen de huidige temperatuur en daarmee COP kunt gebruiken. Het mooiste is dat DAO de voorspelling van weer (en daarmee temperatuur) gebruikt om het meest gunstige moment te berekenen waarop de boiler kan draaien.

[martinisoft]

Torch1969 schreef op maandag 28 april 2025 @ 18:22:
[...]

Als ik me ook even mee mag bemoeien… nadeel daarvan is dat je alleen de huidige temperatuur en daarmee COP kunt gebruiken. Het mooiste is dat DAO de voorspelling van weer (en daarmee temperatuur) gebruikt om het meest gunstige moment te berekenen waarop de boiler kan draaien.

Dat is inderdaad de truuk, door in de DAO Boiler config de mogelijkheid te hebben om een tabel in te voeren (vergelijkbaar met "efficientie vs vermogen" bij battery) zou DAO het optimale moment kunnen berekenen op basis van stroomprijs en de COP. Ik moet wel eerlijk bekennen dat de toegevoegde waarde relatief beperkt is. Dit komt omdat ik in mijn eigen Node-Red flow zie dat het relatief weinig voorkomt dat deze berekening een ander tijdslot oplevert dan simpelweg het goedkoopste uur. Dit hangt natuurlijk af van de schommelingen van beide parameters binnen de periode van 24 uur. Maar het zou wel gaaf zijn als DAO (op termijn) in staat is om op deze manier het echte optimale moment te bepalen.

[Torch1969]

KC27 schreef op zaterdag 26 april 2025 @ 15:33:
Voor gebruikers die de nieuwe release (voor hij wordt gepubliceerd) willen testen.
In de addon-branche staat versie 2025.4.2.rc1 (edit: inmiddels rc2) daarvoor klaar.
Dit staat er in de changelog:
- Fixed futurewarning dataframe (reported by @Torch1969 )
- Fixed error when deleting an image/log and deny or cancel confirmation (the item was deleted) (reported by @Bravo )
- Fixed error when calling api with data for base (=baseload) (reported by @Torch1969 )
- Adjusted documentation of the api-call

Ik hoor graag jullie bevindingen.

@KC27 Ik heb een testversie geïnstalleerd in aparte container en e.e.a nagelopen. Ziet er op het eerste gezicht goed uit. De base variabele bij de api werkt nu. Ik zie nog wat "expected" waarden op 0 staan, maar dat kan ook liggen aan het feit dat ik nog een redelijk verse/lege install heb.

Ik krijg nog wel een foutmelding bij "Reports"/"Balans", daar heb ik een issue voor aangemaakt op GitHub.

De eerste fix (Futurewarning dataframe) kan ik zo niet meer herinneren (en terugvinden) wat daar mis ging en hoe ik die kan controleren. Kun je mijn geheugen nog even opfrissen?

[KC27]

Torch1969 schreef op maandag 28 april 2025 @ 21:23:
[...]


@KC27 Ik heb een testversie geïnstalleerd in aparte container en e.e.a nagelopen. Ziet er op het eerste gezicht goed uit. De base variabele bij de api werkt nu. Ik zie nog wat "expected" waarden op 0 staan, maar dat kan ook liggen aan het feit dat ik nog een redelijk verse/lege install heb.

Ik krijg nog wel een foutmelding bij "Reports"/"Balans", daar heb ik een issue voor aangemaakt op GitHub.

De eerste fix (Futurewarning dataframe) kan ik zo niet meer herinneren (en terugvinden) wat daar mis ging en hoe ik die kan controleren. Kun je mijn geheugen nog even opfrissen?

Fout van mij
Ik moet mijn unit-testen niet alleen uitbreiden maar ook draaien voordat ik een nieuwe rc of versie naar github push. Ik prijs me gelukkig met de nieuwe consciëntieuze testers in dit topic .
Pas ik iets aan voor de api gaat het fout bij het genereren van het rapport.
Vanavond komt (een geteste ) rc4 op github.
Dank voor het melden!
Edit:
Die "Futurewarning" was dus geen fout, maar een waarschuwing dat dingen in de door mij gebruikte module pandas gaan veranderen en dat mijn code dan niet meer werkt. Dat heb ik aangepast. Weet alleen niet meer exact waar en heb nu geen tijd om dat op te zoeken.

[ Voor 11% gewijzigd door KC27 op 28-04-2025 22:39 ]

[DaBit]

Ik ben er klaar voor, rc3 draait al

[KC27]

[@Torch1969 @DaBit
Release Candidate no 4 staat op Github (addon branche)
Dit staat in de changelog:

code:

RC4: 
- Fixed error when more than one EV is configured (reported by [~DaBit] )
- Fixed error when generating \Reports\Balans (reported by [~Torch1969] )

Ik hoor graag jullie bevindingen.

[ Voor 9% gewijzigd door KC27 op 28-04-2025 22:56 ]

[DaBit]

Hij draait in ieder geval. Morgen die tweede 'EV' weer eens toevoegen en kijken wat het doet.

[Torch1969]

KC27 schreef op maandag 28 april 2025 @ 22:54:
[@Torch1969 @DaBit
Release Candidate no 4 staat op Github (addon branche)
Dit staat in de changelog:

code:

RC4: 
- Fixed error when more than one EV is configured (reported by [~DaBit] )
- Fixed error when generating \Reports\Balans (reported by [~Torch1969] )

Ik hoor graag jullie bevindingen.

Test-containertje even opnieuw opgebouwd en gedraaid. Werkt nu prima.
Fijn dat we op deze manier kunnen bijdragen @KC27 . Kleine moeite

Ik draai nu een weekje dao (aansturing thuisbatterij, uitschakelen zonnepanelen en binnenkort ook aansturing laden phev (nu aan het schaduw draaien)) en er beginnen wel wat “feature-requests” in mijn hoofd te borrelen. Op welke plek wil je die het liefst ontvangen? Hier op tweakers (tussen de andere berichten), of als discussie of issue op GitHub (voordeel is dat je de discussie over zo’n request bij elkaar hebt)?

En dan als laatste, ik zou je graag willen trakteren op een kop koffie, een biertje of andere virtuele blijk van waardering voor al het werk dat je in dao stopt. Heb je er al eens over nagedacht om daarvoor een mogelijkheid aan te bieden op b.v. GitHub ?

[DaBit]

Berekening met 2 EV's gaat goed, of althans, het ontploft niet. Als ik met de gasprijs sjoemel dan word de boiler iets langduriger met lager vermogen ingeschaald. Dat klinkt goed.

Ik heb DAO maar gelijk de controle gegeven over die boiler zodat het goed getest wordt. Bloed of bloemen
Zo tegen een uur of 16.00 weet ik wat-ie precies gedaan heeft.

[ Voor 9% gewijzigd door DaBit op 29-04-2025 08:43 ]

[sMoKeFiSh]

Torch1969 schreef op dinsdag 29 april 2025 @ 07:50:
[...]
En dan als laatste, ik zou je graag willen trakteren op een kop koffie, een biertje of andere virtuele blijk van waardering voor al het werk dat je in dao stopt. Heb je er al eens over nagedacht om daarvoor een mogelijkheid aan te bieden op b.v. GitHub ?

Same! DAO werkt bij mij sinds de installatie erg goed en ben tot nu toe erg tevreden over de features, support en besparingen/winstoptimalisering. Naast de geschreven waardering doe ik ook graag een donatie om je werk te supporten.

[KC27]

Voor mij is het een leuke hobby, waarin ik drie vakgebieden uit mijn 7 jaar geleden afgesloten werkzame leven kan combineren:

1. programmeren (doe ik al vanaf 1976),
2. wiskunde (was het leukste bijvak tijdens mijn studie)
3. en - last but not least - energiemanagement.

Mijn voldoening zit erin dat - o.a. door dit topic - het aantal tevreden gebruikers toeneemt en dat ik zo een kleine bijdrage kan leveren aan een wereld met minder milieuvervuiling en een beter klimaat.
Dus als jullie mij willen steunen: "spread the word", maak hier of elders reclame voor dit gratis product.

[ErnstH]

KC27 schreef op dinsdag 29 april 2025 @ 09:26:
Voor mij is het een leuke hobby, waarin ik drie vakgebieden uit mijn 7 jaar geleden afgesloten werkzame leven kan combineren:

1. programmeren (doe ik al vanaf 1976),
2. wiskunde (was het leukste bijvak tijdens mijn studie)
3. en - last but not least - energiemanagement.

Mijn voldoening zit erin dat - o.a. door dit topic - het aantal tevreden gebruikers toeneemt en dat ik zo een kleine bijdrage kan leveren aan een wereld met minder milieuvervuiling en een beter klimaat.
Dus als jullie mij willen steunen: "spread the word", maak hier of elders reclame voor dit gratis product.

Krijgen we dan ook ooit nog een ponskaart modus voor DAO?

[Bravo]

KC27 schreef op zaterdag 26 april 2025 @ 15:33:
Voor gebruikers die de nieuwe release (voor hij wordt gepubliceerd) willen testen.
In de addon-branche staat versie 2025.4.2.rc1 (edit: inmiddels rc2) daarvoor klaar.
Dit staat er in de changelog:
- Fixed futurewarning dataframe (reported by @Torch1969 )
- Fixed error when deleting an image/log and deny or cancel confirmation (the item was deleted) (reported by @Bravo )
- Fixed error when calling api with data for base (=baseload) (reported by @Torch1969 )
- Adjusted documentation of the api-call

Ik hoor graag jullie bevindingen.

Het lukt mij niet om de tweede (rc) versie draaiend te krijgen zonder foutmeldingen Zou iemand anders met de rc-versie kunnen testen of het annuleren bij het verwijderen van een run nu niet de gegevens verwijderd?

[Torch1969]

Bravo schreef op dinsdag 29 april 2025 @ 11:05:
[...]

Het lukt mij niet om de tweede (rc) versie draaiend te krijgen zonder foutmeldingen Zou iemand anders met de rc-versie kunnen testen of het annuleren bij het verwijderen van een run nu niet de gegevens verwijderd?

Getest en het werkt nu goed.👍🏻

[llevering]

Ga ook proberen om dit te gebruiken, ben nu EMHASS gebruiker, maar dit ziet er goed uit.

Wel gelijk twee drie feature requests ingediend op Github. Maar eerste indruk is heel goed, wel wat technisch om in te stellen, voor mij geen probleem maar zal veel nieuwe gebruikers wel tegenhouden. Ook bij EMHASS is dat het geval, dus dat maakt verder niet uit.

[mgroen81]

KC27 schreef op vrijdag 11 april 2025 @ 23:24:
[...]


Er is in principe niks fout aan je settings.
Maar met drie batterijen maak je het DAO niet makkelijk.
In jouw situatie met drie batterijen en een ev zijn er heel veel variabelen.
De rekentijd neemt toe met het ongeveer het kwadraat van de variabelen.
In jouw situatie heb je drie identieke batterijen die je - als ik het goed zie - ook identiek inzet.
Je zou het DAO waarschijnlijk veel makkelijker kunnen maken door van die drie één virtuele batterij te maken.

Dat zou je eerst even kunnen testen door tijdelijk twee batterijen weg te halen en dan een "run met debug" doen.
Als dat veel scheelt kun je alsnog (als je dat wilt) een virtuele batterij maken:

• je definieert één batterij
• de capaciteit vermenigvuldig je met drie, evenals het vermogen in alle "stages" en de andere vermogens
• voor de start soc neem je een template sensor die het gemiddelde van de drie echte soc's berekend
• voor de door DAO berekende inzet/het vermogen maak je een input_number aan en daar hang je een automation aan die een derde doorzet naar de drie afzonderlijke sessy's.

Ik ben benieuwd naar je bevindingen.

Ik heb de 3 Accus samengevoegd tot 1 en dat draait nu al weer een tijdje zo.
De berekenings tijd is van 78 sec verlaagd naar 50 sec. Ik vind dat nog steeds lang duren of is dit gebruikelijk? Wat me opvalt is dat iets in het begin van de log de meeste tijd kost (48 sec). Lijkt me dat er ergens op gewacht wordt? Of wordt hier de berekening al gedaan?

code:

 2025-04-29 12:00:00 info: Day Ahead Optimalisering versie: 2025.4.1
2025-04-29 12:00:00 info: Day Ahead Optimalisering gestart op: 29-04-2025 12:00:00
2025-04-29 12:00:00 info: Day Ahead Optimalisatie gestart: 29-04-2025 12:00:00 taak: calc_optimum
2025-04-29 12:00:00 info: Debug = False
2025-04-29 12:00:00 info: Zelf berekende baseload
2025-04-29 12:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    12 2025-04-29 12:00:00   0.17   0.17  -3.67   4.94      0
1    13 2025-04-29 13:00:00   0.17   0.17  -4.01   5.08      0
2    14 2025-04-29 14:00:00   0.17   0.17  -3.43   4.85      0
3    15 2025-04-29 15:00:00   0.17   0.17  -2.73   4.51      0
4    16 2025-04-29 16:00:00   0.19   0.19  -1.69   3.80      0
5    17 2025-04-29 17:00:00   0.26   0.26  -0.91   2.84      0
6    18 2025-04-29 18:00:00   0.29   0.29   0.17   2.09      0
7    19 2025-04-29 19:00:00   0.32   0.32   0.23   1.11      0
8    20 2025-04-29 20:00:00   0.36   0.36   0.46   0.29      0
9    21 2025-04-29 21:00:00   0.33   0.33   0.51   0.00      0
10   22 2025-04-29 22:00:00   0.30   0.30   0.45   0.00      0
11   23 2025-04-29 23:00:00   0.29   0.29   0.48   0.00      0
2025-04-29 12:00:48 info: Verbruik dit contractjaar: 6377.013 kWh
2025-04-29 12:00:48 info: Productie dit contractjaar: 2660.366 kWh

Ik heb ook nog een ander probleem wat waarschijnlijk gerelateerd is aan het feit dat ik op HomeAssistant DuckDNS heb draaien en NGINX om HomeAssistant lokaal (http) weer beschikbaar te maken.
DAO doet zijn berekeningen zoals gepland.
Maar als ik een berekening start met onderstaand rest command lukt dat niet.
edit: Rest command komt wel door maar krijg steeds de melding van time-out in HomeAssistant. Het lijkt er wel op dat de berekening niet wordt afgemaakt als ik de rest_command gebruik.

code:

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

[ Voor 6% gewijzigd door mgroen81 op 29-04-2025 13:29 ]

[Torch1969]

mgroen81 schreef op dinsdag 29 april 2025 @ 12:38:
[...]

Ik heb de 3 Accus samengevoegd tot 1 en dat draait nu al weer een tijdje zo.
De berekenings tijd is van 78 sec verlaagd naar 50 sec. Ik vind dat nog steeds lang duren of is dit gebruikelijk? Wat me opvalt is dat iets in het begin van de log de meeste tijd kost (48 sec). Lijkt me dat er ergens op gewacht wordt? Of wordt hier de berekening al gedaan?

code:

 2025-04-29 12:00:00 info: Day Ahead Optimalisering versie: 2025.4.1
2025-04-29 12:00:00 info: Day Ahead Optimalisering gestart op: 29-04-2025 12:00:00
2025-04-29 12:00:00 info: Day Ahead Optimalisatie gestart: 29-04-2025 12:00:00 taak: calc_optimum
2025-04-29 12:00:00 info: Debug = False
2025-04-29 12:00:00 info: Zelf berekende baseload
2025-04-29 12:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    12 2025-04-29 12:00:00   0.17   0.17  -3.67   4.94      0
1    13 2025-04-29 13:00:00   0.17   0.17  -4.01   5.08      0
2    14 2025-04-29 14:00:00   0.17   0.17  -3.43   4.85      0
3    15 2025-04-29 15:00:00   0.17   0.17  -2.73   4.51      0
4    16 2025-04-29 16:00:00   0.19   0.19  -1.69   3.80      0
5    17 2025-04-29 17:00:00   0.26   0.26  -0.91   2.84      0
6    18 2025-04-29 18:00:00   0.29   0.29   0.17   2.09      0
7    19 2025-04-29 19:00:00   0.32   0.32   0.23   1.11      0
8    20 2025-04-29 20:00:00   0.36   0.36   0.46   0.29      0
9    21 2025-04-29 21:00:00   0.33   0.33   0.51   0.00      0
10   22 2025-04-29 22:00:00   0.30   0.30   0.45   0.00      0
11   23 2025-04-29 23:00:00   0.29   0.29   0.48   0.00      0
2025-04-29 12:00:48 info: Verbruik dit contractjaar: 6377.013 kWh
2025-04-29 12:00:48 info: Productie dit contractjaar: 2660.366 kWh

Ik heb ook nog een ander probleem wat waarschijnlijk gerelateerd is aan het feit dat ik op HomeAssistant DuckDNS heb draaien en NGINX om HomeAssistant lokaal (http) weer beschikbaar te maken.
DAO doet zijn berekeningen zoals gepland.
Maar als ik een berekening start met onderstaand rest command lukt dat niet.

code:

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

Ik heb lokaal toegang op poort 8123 dus dan zou de API op poort 5000 ook moeten werken lijkt me?

Als je bij de instellingen "logging level" : "info" wijzigt in "logging level" : "debug", dan krijg je veel uitgebreidere logging en kun je wellicht zien waar dao die 48 seconden mee bezig is. Ik hoop dat je log file niet klapt…

[KC27]

mgroen81 schreef op dinsdag 29 april 2025 @ 12:38:
[...]

Ik heb de 3 Accus samengevoegd tot 1 en dat draait nu al weer een tijdje zo.
De berekenings tijd is van 78 sec verlaagd naar 50 sec. Ik vind dat nog steeds lang duren of is dit gebruikelijk? Wat me opvalt is dat iets in het begin van de log de meeste tijd kost (48 sec). Lijkt me dat er ergens op gewacht wordt? Of wordt hier de berekening al gedaan?

code:

 2025-04-29 12:00:00 info: Day Ahead Optimalisering versie: 2025.4.1
2025-04-29 12:00:00 info: Day Ahead Optimalisering gestart op: 29-04-2025 12:00:00
2025-04-29 12:00:00 info: Day Ahead Optimalisatie gestart: 29-04-2025 12:00:00 taak: calc_optimum
2025-04-29 12:00:00 info: Debug = False
2025-04-29 12:00:00 info: Zelf berekende baseload
2025-04-29 12:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    12 2025-04-29 12:00:00   0.17   0.17  -3.67   4.94      0
1    13 2025-04-29 13:00:00   0.17   0.17  -4.01   5.08      0
2    14 2025-04-29 14:00:00   0.17   0.17  -3.43   4.85      0
3    15 2025-04-29 15:00:00   0.17   0.17  -2.73   4.51      0
4    16 2025-04-29 16:00:00   0.19   0.19  -1.69   3.80      0
5    17 2025-04-29 17:00:00   0.26   0.26  -0.91   2.84      0
6    18 2025-04-29 18:00:00   0.29   0.29   0.17   2.09      0
7    19 2025-04-29 19:00:00   0.32   0.32   0.23   1.11      0
8    20 2025-04-29 20:00:00   0.36   0.36   0.46   0.29      0
9    21 2025-04-29 21:00:00   0.33   0.33   0.51   0.00      0
10   22 2025-04-29 22:00:00   0.30   0.30   0.45   0.00      0
11   23 2025-04-29 23:00:00   0.29   0.29   0.48   0.00      0
2025-04-29 12:00:48 info: Verbruik dit contractjaar: 6377.013 kWh
2025-04-29 12:00:48 info: Productie dit contractjaar: 2660.366 kWh

Ik heb ook nog een ander probleem wat waarschijnlijk gerelateerd is aan het feit dat ik op HomeAssistant DuckDNS heb draaien en NGINX om HomeAssistant lokaal (http) weer beschikbaar te maken.
DAO doet zijn berekeningen zoals gepland.
Maar als ik een berekening start met onderstaand rest command lukt dat niet.

code:

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

Ik heb lokaal toegang op poort 8123 dus dan zou de API op poort 5000 ook moeten werken lijkt me?

Dat hij 48 seconden doet om die verbruik- en productiegegevens op te halen uit HA is veel te lang.
Bij mij doet ie dat nog in dezelfde seconde als de berekening wordt gestart:

code:

2025-04-29 13:00:00 info: Verbruik dit contractjaar: 4851.175 kWh
2025-04-29 13:00:00 info: Productie dit contractjaar: 3225.834 kWh

Hoe lang doet ie bij jou over het produceren van een \Report\Grid met als periode "dit contractjaar".
Dat moet ook binnen een seconde op het scherm staan.
Gezien het niet kunnen runnen van een rest-command doet mij vermoeden dat er iets verkeerd geconfigureerd is in je netwerk. Maar daar ben ik niet deskundig in.
Kun je wel pingen naar je HA machine?
Heb je homeassisant.local al geprobeerd als ip-adres.

Een tijdje terug hadden we "out of the blue" problemen met het niet kunnen bereiken van HA als je niets configureerde.
Daar was toen een snelle fix voor gevonden, maar geen oplossing.
Inmiddels lijkt dat probleem ook weer voorbij (ik zou niet weten waarom).
Je kunt dat eenvoudig testen door je configuratie als volgt te wijzigen:

code:

{ "homeassistant": { },
  "//homeassistant": {
    "protocol api": "http",
    "ip adress": "homeassistant.local",
    "ip port": 8123,
    "token": "!secret ha_api_token"
  },

Dus de fix voorzien van een of meer willekeurig letters en de oude definitie daarboven.
Dan kun je via \Run\Optimaliseringsberekening met debug testen of het bij jou weer werkt.
Als het niet werkt zet je alles weer terug.

Misschien lost dat jouw probleem ook (gedeeltelijk) op?
Anderen?

[mgroen81]

@KC27 Het opvragen van \Report\Grid met als periode "dit contractjaar" duurt inderdaad ongeveer 40 sec.
Is er iets wat ik kan proberen om dit te fixen? De hardware is snel genoeg. OdroidN2+

De api call lijkt toch wel te werken alleen krijg ik een time-out melding. En de berekening wordt niet helemaal afgemaakt lijkt het.

edit: http://192.168.178.156 werkt wel homeassistant.local werkt niet.
DNS resolve op local netwerk werkt niet doordat ik NGINX en DuckDNS heb draaien.
fritz.box werkt bijvoorbeeld ook niet.

[ Voor 23% gewijzigd door mgroen81 op 29-04-2025 14:17 ]

[mgroen81]

Torch1969 schreef op dinsdag 29 april 2025 @ 13:00:
[...]


Als je bij de instellingen "logging level" : "info" wijzigt in "logging level" : "debug", dan krijg je veel uitgebreidere logging en kun je wellicht zien waar dao die 48 seconden mee bezig is. Ik hoop dat je log file niet klapt…

@KC27
Dit is het ingekorte debug log:

code:

2025-04-29 13:21:04 debug: python pad:['/root/dao/prog', '/root', '/root/dao', '/root/dao/prog', '/usr/lib/python311.zip', '/usr/lib/python3.11', '/usr/lib/python3.11/lib-dynload', '/root/dao/venv/day_ahead/lib/python3.11/site-packages']
2025-04-29 13:21:04 info: Day Ahead Optimalisering versie: 2025.4.1
2025-04-29 13:21:04 info: Day Ahead Optimalisering gestart op: 29-04-2025 13:21:04
2025-04-29 13:21:04 debug: Locatie: latitude 51.9122405552573 longitude: 4.168463945388795
2025-04-29 13:21:04 info: Day Ahead Optimalisatie gestart: 29-04-2025 13:21:04 taak: calc_optimum
2025-04-29 13:21:04 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 478 in /root/dao/prog/da_base.py
2025-04-29 13:21:04 info: Debug = False
2025-04-29 13:21:05 debug: Prognose data:
          time                tijd  temp  glob_rad      pv_rad  da_price
0   1745924400 2025-04-29 13:00:00  21.0     292.0  123.568951  -0.00190
gewiste gegevens
34  1746046800 2025-04-30 23:00:00  19.0       0.0    0.000000   0.09753
2025-04-29 13:21:05 info: Zelf berekende baseload
2025-04-29 13:21:05 debug: Query: 
 SELECT strftime(?, datetime(t1.time, ?, ?)) AS maand, min(datetime(t1.time, ?, ?)) AS vanaf, max(datetime(t1.time, ?, ?)) AS tot, sum(t1.value) AS consumption 
FROM "values" AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = ? AND t1.time >= strftime(?, ?, ?) AND t1.time < strftime(?, ?, ?) GROUP BY maand
2025-04-29 13:21:05 debug: Query: 
 SELECT strftime(?, datetime(t1.time, ?, ?)) AS maand, min(datetime(t1.time, ?, ?)) AS vanaf, max(datetime(t1.time, ?, ?)) AS tot, sum(t1.value) AS production 
FROM "values" AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = ? AND t1.time >= strftime(?, ?, ?) AND t1.time < strftime(?, ?, ?) GROUP BY maand
2025-04-29 13:21:05 debug: Query: 
 SELECT strftime(?, datetime(t1.time, ?, ?)) AS maand, min(datetime(t1.time, ?, ?)) AS vanaf, max(datetime(t1.time, ?, ?)) AS tot, sum(t1.value) AS cost 
FROM "values" AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = ? AND t1.time >= strftime(?, ?, ?) AND t1.time < strftime(?, ?, ?) GROUP BY maand
2025-04-29 13:21:05 debug: Query: 
 SELECT strftime(?, datetime(t1.time, ?, ?)) AS maand, min(datetime(t1.time, ?, ?)) AS vanaf, max(datetime(t1.time, ?, ?)) AS tot, sum(t1.value) AS profit 
FROM "values" AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = ? AND t1.time >= strftime(?, ?, ?) AND t1.time < strftime(?, ?, ?) GROUP BY maand
2025-04-29 13:21:17 debug: query get sensor data:
 SELECT strftime(?, datetime(t2.start_ts, ?, ?)) AS uur, datetime(t2.start_ts, ?, ?) AS tijd, datetime(t2.start_ts, ?, ?) AS tot, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE ? END AS consumption 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + ? JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = ? AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= strftime(?, ?, ?) - ? AND t1.start_ts < strftime(?, ?, ?) - ?
2025-04-29 13:21:18 debug: sensordata raw, sensor sensor.sessy_p6eh_tariff_1_consumed_energy,
                        uur                tijd                 tot  consumption
tijd                                                                           
2024-10-01 00:00:00  00:00 2024-10-01 00:00:00 2024-10-01 00:00:00        0.391
gewiste gegevens
2025-04-29 12:00:00  12:00 2025-04-29 12:00:00 2025-04-29 12:00:00        0.000

2025-04-29 13:21:18 debug: query get sensor data:
 SELECT strftime(?, datetime(t2.start_ts, ?, ?)) AS uur, datetime(t2.start_ts, ?, ?) AS tijd, datetime(t2.start_ts, ?, ?) AS tot, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE ? END AS consumption 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + ? JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = ? AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= strftime(?, ?, ?) - ? AND t1.start_ts < strftime(?, ?, ?) - ?
2025-04-29 13:21:18 debug: sensordata raw, sensor sensor.sessy_p6eh_tariff_2_consumed_energy,
                        uur                tijd                 tot  consumption
tijd                                                                           
2024-10-01 00:00:00  00:00 2024-10-01 00:00:00 2024-10-01 00:00:00        0.000
gewiste gegevens
2025-04-29 12:00:00  12:00 2025-04-29 12:00:00 2025-04-29 12:00:00        0.000

2025-04-29 13:21:21 debug: query get sensor data:
 SELECT strftime(?, datetime(t2.start_ts, ?, ?)) AS uur, datetime(t2.start_ts, ?, ?) AS tijd, datetime(t2.start_ts, ?, ?) AS tot, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE ? END AS production 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + ? JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = ? AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= strftime(?, ?, ?) - ? AND t1.start_ts < strftime(?, ?, ?) - ?
2025-04-29 13:21:22 debug: sensordata raw, sensor sensor.sessy_p6eh_tariff_1_produced_energy,
                        uur                tijd                 tot  production
tijd                                                                          
2024-10-01 00:00:00  00:00 2024-10-01 00:00:00 2024-10-01 00:00:00       0.000
gewiste gegevens
2025-04-29 12:00:00  12:00 2025-04-29 12:00:00 2025-04-29 12:00:00       0.000

2025-04-29 13:21:25 debug: query get sensor data:
 SELECT strftime(?, datetime(t2.start_ts, ?, ?)) AS uur, datetime(t2.start_ts, ?, ?) AS tijd, datetime(t2.start_ts, ?, ?) AS tot, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE ? END AS production 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + ? JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = ? AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= strftime(?, ?, ?) - ? AND t1.start_ts < strftime(?, ?, ?) - ?
2025-04-29 13:21:26 debug: sensordata raw, sensor sensor.sessy_p6eh_tariff_2_produced_energy,
                        uur                tijd                 tot  production
tijd                                                                          
2024-10-01 00:00:00  00:00 2024-10-01 00:00:00 2024-10-01 00:00:00       0.000
gewiste gegevens
2025-04-29 12:00:00  12:00 2025-04-29 12:00:00 2025-04-29 12:00:00       2.479

2025-04-29 13:21:29 debug: query get prognose data:
 SELECT datetime(p1.time, ?, ?) AS tijd, p1.value AS consumption, p2.value AS production, ? AS datasoort 
FROM prognoses AS p1, prognoses AS p2, variabel AS v1, variabel AS v2 
WHERE p1.time = p2.time AND p1.variabel = v1.id AND v1.code = ? AND p2.variabel = v2.id AND v2.code = ? AND p1.time >= strftime(?, ?, ?) AND p1.time < strftime(?, ?, ?)
2025-04-29 13:21:54 info: Verbruik dit contractjaar: 6383.567 kWh
2025-04-29 13:21:54 info: Productie dit contractjaar: 2662.845 kWh
2025-04-29 13:21:54 info: All taxes refund (alles wordt gesaldeerd)
2025-04-29 13:21:56 debug: Reduced hours for Sessy
2025-04-29 13:21:56 debug: cycle cost: 0.03 eur/kWh
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/sensor.sessy_state_of_charge_avg HTTP/1.1" 200 430
2025-04-29 13:21:56 info: Startwaarde SoC Sessy: 44.67%
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_min_soc_einde_opt HTTP/1.1" 200 472
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_max_soc_einde_opt HTTP/1.1" 200 474
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/sensor.ecodan_heatpump_dhw_current_temp HTTP/1.1" 200 474
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/sensor.ecodan_heatpump_dhw_setpoint_value HTTP/1.1" 200 478
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_hysterese_dhw HTTP/1.1" 200 418
2025-04-29 13:21:56 info: Boiler opwarmen wordt ingepland tussen: 13 en 13 uur
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_boolean.dao_zoe_external_power_connected HTTP/1.1" 200 411
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/device_tracker.smartevse_6697 HTTP/1.1" 200 592
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.zoe_accu HTTP/1.1" 200 403
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_zoe_gewenst_laad_niveau HTTP/1.1" 200 465
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_datetime.dao_zoetijdstip_klaar_met_laden HTTP/1.1" 200 471
2025-04-29 13:21:56 info: Instellingen voor laden van EV: Zoe
2025-04-29 13:21:56 info:  Ampere  Effic. Grid kW Accu kW
2025-04-29 13:21:56 info:    0.00    1.00    0.00    0.00
2025-04-29 13:21:56 info:   15.00    1.00   10.35   10.35
2025-04-29 13:21:56 info: Capaciteit accu: 40 kWh
2025-04-29 13:21:56 info: Maximaal laadvermogen: 10.35 kW
2025-04-29 13:21:56 info: Klaar met laden op: 30-04-2025 06:00:00
2025-04-29 13:21:56 info: Huidig laadniveau: 25.0 %
2025-04-29 13:21:56 info: Gewenst laadniveau:100.0 %
2025-04-29 13:21:56 info: Marge voor het laden: 1 %
2025-04-29 13:21:56 info: Locatie: home
2025-04-29 13:21:56 info: Ingeplugged:False
2025-04-29 13:21:56 info: Benodigde energie: 30.0 kWh
2025-04-29 13:21:56 info: Tijd nodig om te laden: 2.90 uur
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_boolean.dao_zoe_charging HTTP/1.1" 200 384
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_zoe_set_car_charging_ampere HTTP/1.1" 200 501
2025-04-29 13:21:56 info: Afgerond naar hele uren: 3
2025-04-29 13:21:56 info: Stand laden schakelaar: on
2025-04-29 13:21:56 info: Stand aantal ampere laden: 15.0 A
2025-04-29 13:21:56 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd.

[f.welvering]

mgroen81 schreef op dinsdag 29 april 2025 @ 13:49:
@KC27 Het opvragen van \Report\Grid met als periode "dit contractjaar" duurt inderdaad ongeveer 40 sec.
Is er iets wat ik kan proberen om dit te fixen? De hardware is snel genoeg. OdroidN2+

De api call lijkt toch wel te werken alleen krijg ik een time-out melding. En de berekening wordt niet helemaal afgemaakt lijkt het.

edit: http://192.168.178.156 werkt wel homeassistant.local werkt niet.
DNS resolve op local netwerk werkt niet doordat ik NGINX en DuckDNS heb draaien.
fritz.box werkt bijvoorbeeld ook niet.

Wat voor database engine gebruik je voor Home Assistant?
Mijn ervaring op de OdroidN2+ was dat de sqllite db erg traag werd na verloop van tijd.
Ik heb alles daarom overgezet naar Mysql wat de snelheid terug haalde.
Let ook even op je memory gebruik van de Odroid, ervanuitgaande dat je de 4GB versie hebt kan dit wel eens krap zijn. Ik had geregeld vastlopers met dit ding en ben overgestapt op wat zwaardere hardware.

[balk]

De rekensnelheid gaat binnenkort een nog grotere rol spelen vanwege de 15minuten tarieven. Dat geeft nog veel meer mogelijkheden en dus meer rekentijd.
Misschien is het goed om in de documentatie wat woorden te besteden aan hoe de configuratie de rekentijd beïnvloed. Ik kan binnenkort daar wel wat tijd in steken.
Vooruitlopend daarop: ik heb mijn zes panelen individueel in de config staan, want ze liggen niet allemaal het zelfde. Zou de berekening sneller gaan wanneer ik ze als 1 paneel zou gaan instellen?

[DaBit]

@KC27 : volgens mij is dat 2-auto probleem nog niet 100% opgelost.

code:

2025-04-29 17:01:30 info: Berekeningsuitkomst voor opladen van Corsa-E:
2025-04-29 17:01:30 info: - aantal ampere 0A (was 0.0A)
2025-04-29 17:01:30 info: - stand schakelaar 'off' (was 'off')
2025-04-29 17:01:30 info: - positie: home
2025-04-29 17:01:30 info: - ingeplugd: False
2025-04-29 17:01:30 info: Corsa-E is niet thuis of niet ingeplugd
2025-04-29 17:01:30 info: Evaluatie status laden Corsa-E op 2025-04-29 17:01
2025-04-29 17:01:30 info: - schakelaar laden: off
2025-04-29 17:01:30 info: - aantal ampere: 0.0
2025-04-29 17:01:30 info: Berekeningsuitkomst voor opladen van boiler:
2025-04-29 17:01:30 info: - aantal ampere 0A (was 10.0A)
2025-04-29 17:01:30 info: - stand schakelaar 'off' (was 'on')
2025-04-29 17:01:30 info: - positie: home
2025-04-29 17:01:30 info: - ingeplugd: False
2025-04-29 17:01:30 info: boiler is niet thuis of niet ingeplugd
2025-04-29 17:01:30 info: Evaluatie status laden boiler op 2025-04-29 17:01
2025-04-29 17:01:30 info: - schakelaar laden: on
2025-04-29 17:01:30 info: - aantal ampere: 10.0

Zie redelijk op het eind: 'boiler' is niet thuis of niet ingeplugd maar toch blijft de laad-schakelaar aanstaan, evenals de laadstroom op 10A terwijl de uitkomst van de berekening off/0A was.

Voor de rest lijkt het prima gefunctioneerd te hebben. DAO plande de boiler in om 11.00 toen volgens mijn regels de elektriciteit goedkoper werd dan gas:

code:

2025-04-29 11:01:28 info: Instellingen voor laden van EV: boiler
2025-04-29 11:01:28 info:  Ampere  Effic. Grid kW Accu kW
2025-04-29 11:01:28 info:    0.00    1.00    0.00    0.00
2025-04-29 11:01:28 info:    2.00    0.99    0.46    0.46
2025-04-29 11:01:28 info:    3.00    0.99    0.69    0.68
2025-04-29 11:01:28 info:    4.00    0.99    0.92    0.91
2025-04-29 11:01:28 info:    5.00    0.99    1.15    1.14
2025-04-29 11:01:28 info:    6.00    0.98    1.38    1.35
2025-04-29 11:01:28 info:    7.00    0.98    1.61    1.58
2025-04-29 11:01:28 info:    8.00    0.98    1.84    1.80
2025-04-29 11:01:28 info:    9.00    0.97    2.07    2.01
2025-04-29 11:01:28 info:   10.00    0.97    2.30    2.23
2025-04-29 11:01:28 info: Capaciteit accu: 13.4 kWh
2025-04-29 11:01:28 info: Maximaal laadvermogen: 2.3 kW
2025-04-29 11:01:28 info: Klaar met laden op: 29-04-2025 18:00:00
2025-04-29 11:01:28 info: Huidig laadniveau: 15.9 %
2025-04-29 11:01:28 info: Gewenst laadniveau:70.0 %
2025-04-29 11:01:28 info: Marge voor het laden: 1 %
2025-04-29 11:01:28 info: Locatie: home
2025-04-29 11:01:28 info: Ingeplugged:True
2025-04-29 11:01:28 info: Benodigde energie: 7.2494000000000005 kWh
2025-04-29 11:01:28 info: Tijd nodig om te laden: 3.25 uur
2025-04-29 11:01:28 info: Afgerond naar hele uren: 4
2025-04-29 11:01:28 info: Stand laden schakelaar: off
2025-04-29 11:01:28 info: Stand aantal ampere laden: 0.0 A
2025-04-29 11:01:28 info: Opladen wordt ingepland.

Procenten zijn graden.

Met als resultaat:



In het eerste stukje nog geen opwarming vanwege een bugje aan mijn kant van het hele verhaal, daarna gestaag.
DAO heeft hier niet gekregen wat-ie wilde; boilervermogen is geknepen vanwege bovengrens temperatuur elektronica. Meh, SSR kan zijn warmte niet kwijt, daar moet ik echt eens naar kijken.

DAO vond het verder schijnbaar ook nodig om redelijk richting 0 op de meter te regelen, bewust of onbewust:



(gele lijn is de netbalans afkomstig van de P1-meter, negatief is energie de straat op, positief is energie het huis binnen)

Het stukje configuratie van de boiler:

code:

{
      "name": "boiler",
      "capacity": 13.4,
      "entity max amperage": "input_number.ev_max_charge_amps",
      "entity position": "input_select.corsae_location",
      "charge three phase": "False",
      "charge stages" : [
        {"ampere":  0,  "efficiency":  1},
        {"ampere":  6,  "efficiency": 0.98 },
        {"ampere":  7,  "efficiency": 0.98 },
        {"ampere":  8,  "efficiency": 0.98 },
        {"ampere":  9,  "efficiency": 0.97 },
        {"ampere":  10, "efficiency": 0.97 }
      ],
      "entity actual level": "sensor.boiler_boiler_temperature",
      "entity plugged in": "binary_sensor.electricity_cheaperthangas",
      "charge scheduler": {
        "entity set level": "input_number.boiler_desiredtemperature",
        "level margin": 1,
        "entity ready datetime": "input_datetime.dao_boiler_ready_datetime"
      },
      "charge switch": "input_boolean.dao_boiler_activate",
      "entity set charging ampere": "input_number.dao_boiler_ampsetpoint"
    }

[ Voor 69% gewijzigd door DaBit op 29-04-2025 17:27 ]

[KC27]

mgroen81 schreef op dinsdag 29 april 2025 @ 14:34:
[...]

@KC27
Dit is het ingekorte debug log:

code:

2025-04-29 13:21:04 debug: python pad:['/root/dao/prog', '/root', '/root/dao', '/root/dao/prog', '/usr/lib/python311.zip', '/usr/lib/python3.11', '/usr/lib/python3.11/lib-dynload', '/root/dao/venv/day_ahead/lib/python3.11/site-packages']
2025-04-29 13:21:04 info: Day Ahead Optimalisering versie: 2025.4.1
2025-04-29 13:21:04 info: Day Ahead Optimalisering gestart op: 29-04-2025 13:21:04
2025-04-29 13:21:04 debug: Locatie: latitude 51.9122405552573 longitude: 4.168463945388795
2025-04-29 13:21:04 info: Day Ahead Optimalisatie gestart: 29-04-2025 13:21:04 taak: calc_optimum
2025-04-29 13:21:04 debug: Connection status Pool size: 5  Connections in pool: 0 Current Overflow: -5 Current Checked out connections: 0 at line 478 in /root/dao/prog/da_base.py
2025-04-29 13:21:04 info: Debug = False
2025-04-29 13:21:05 debug: Prognose data:
          time                tijd  temp  glob_rad      pv_rad  da_price
0   1745924400 2025-04-29 13:00:00  21.0     292.0  123.568951  -0.00190
gewiste gegevens
34  1746046800 2025-04-30 23:00:00  19.0       0.0    0.000000   0.09753
2025-04-29 13:21:05 info: Zelf berekende baseload
2025-04-29 13:21:05 debug: Query: 
 SELECT strftime(?, datetime(t1.time, ?, ?)) AS maand, min(datetime(t1.time, ?, ?)) AS vanaf, max(datetime(t1.time, ?, ?)) AS tot, sum(t1.value) AS consumption 
FROM "values" AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = ? AND t1.time >= strftime(?, ?, ?) AND t1.time < strftime(?, ?, ?) GROUP BY maand
2025-04-29 13:21:05 debug: Query: 
 SELECT strftime(?, datetime(t1.time, ?, ?)) AS maand, min(datetime(t1.time, ?, ?)) AS vanaf, max(datetime(t1.time, ?, ?)) AS tot, sum(t1.value) AS production 
FROM "values" AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = ? AND t1.time >= strftime(?, ?, ?) AND t1.time < strftime(?, ?, ?) GROUP BY maand
2025-04-29 13:21:05 debug: Query: 
 SELECT strftime(?, datetime(t1.time, ?, ?)) AS maand, min(datetime(t1.time, ?, ?)) AS vanaf, max(datetime(t1.time, ?, ?)) AS tot, sum(t1.value) AS cost 
FROM "values" AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = ? AND t1.time >= strftime(?, ?, ?) AND t1.time < strftime(?, ?, ?) GROUP BY maand
2025-04-29 13:21:05 debug: Query: 
 SELECT strftime(?, datetime(t1.time, ?, ?)) AS maand, min(datetime(t1.time, ?, ?)) AS vanaf, max(datetime(t1.time, ?, ?)) AS tot, sum(t1.value) AS profit 
FROM "values" AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = ? AND t1.time >= strftime(?, ?, ?) AND t1.time < strftime(?, ?, ?) GROUP BY maand
2025-04-29 13:21:17 debug: query get sensor data:
 SELECT strftime(?, datetime(t2.start_ts, ?, ?)) AS uur, datetime(t2.start_ts, ?, ?) AS tijd, datetime(t2.start_ts, ?, ?) AS tot, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE ? END AS consumption 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + ? JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = ? AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= strftime(?, ?, ?) - ? AND t1.start_ts < strftime(?, ?, ?) - ?
2025-04-29 13:21:18 debug: sensordata raw, sensor sensor.sessy_p6eh_tariff_1_consumed_energy,
                        uur                tijd                 tot  consumption
tijd                                                                           
2024-10-01 00:00:00  00:00 2024-10-01 00:00:00 2024-10-01 00:00:00        0.391
gewiste gegevens
2025-04-29 12:00:00  12:00 2025-04-29 12:00:00 2025-04-29 12:00:00        0.000

2025-04-29 13:21:18 debug: query get sensor data:
 SELECT strftime(?, datetime(t2.start_ts, ?, ?)) AS uur, datetime(t2.start_ts, ?, ?) AS tijd, datetime(t2.start_ts, ?, ?) AS tot, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE ? END AS consumption 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + ? JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = ? AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= strftime(?, ?, ?) - ? AND t1.start_ts < strftime(?, ?, ?) - ?
2025-04-29 13:21:18 debug: sensordata raw, sensor sensor.sessy_p6eh_tariff_2_consumed_energy,
                        uur                tijd                 tot  consumption
tijd                                                                           
2024-10-01 00:00:00  00:00 2024-10-01 00:00:00 2024-10-01 00:00:00        0.000
gewiste gegevens
2025-04-29 12:00:00  12:00 2025-04-29 12:00:00 2025-04-29 12:00:00        0.000

2025-04-29 13:21:21 debug: query get sensor data:
 SELECT strftime(?, datetime(t2.start_ts, ?, ?)) AS uur, datetime(t2.start_ts, ?, ?) AS tijd, datetime(t2.start_ts, ?, ?) AS tot, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE ? END AS production 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + ? JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = ? AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= strftime(?, ?, ?) - ? AND t1.start_ts < strftime(?, ?, ?) - ?
2025-04-29 13:21:22 debug: sensordata raw, sensor sensor.sessy_p6eh_tariff_1_produced_energy,
                        uur                tijd                 tot  production
tijd                                                                          
2024-10-01 00:00:00  00:00 2024-10-01 00:00:00 2024-10-01 00:00:00       0.000
gewiste gegevens
2025-04-29 12:00:00  12:00 2025-04-29 12:00:00 2025-04-29 12:00:00       0.000

2025-04-29 13:21:25 debug: query get sensor data:
 SELECT strftime(?, datetime(t2.start_ts, ?, ?)) AS uur, datetime(t2.start_ts, ?, ?) AS tijd, datetime(t2.start_ts, ?, ?) AS tot, CASE WHEN (t2.state > t1.state) THEN t2.state - t1.state ELSE ? END AS production 
FROM statistics AS t1 JOIN statistics AS t2 ON t2.start_ts = t1.start_ts + ? JOIN statistics_meta AS v1 ON v1.id = t1.metadata_id AND v1.id = t2.metadata_id 
WHERE v1.statistic_id = ? AND t1.state IS NOT NULL AND t2.state IS NOT NULL AND t1.start_ts >= strftime(?, ?, ?) - ? AND t1.start_ts < strftime(?, ?, ?) - ?
2025-04-29 13:21:26 debug: sensordata raw, sensor sensor.sessy_p6eh_tariff_2_produced_energy,
                        uur                tijd                 tot  production
tijd                                                                          
2024-10-01 00:00:00  00:00 2024-10-01 00:00:00 2024-10-01 00:00:00       0.000
gewiste gegevens
2025-04-29 12:00:00  12:00 2025-04-29 12:00:00 2025-04-29 12:00:00       2.479

2025-04-29 13:21:29 debug: query get prognose data:
 SELECT datetime(p1.time, ?, ?) AS tijd, p1.value AS consumption, p2.value AS production, ? AS datasoort 
FROM prognoses AS p1, prognoses AS p2, variabel AS v1, variabel AS v2 
WHERE p1.time = p2.time AND p1.variabel = v1.id AND v1.code = ? AND p2.variabel = v2.id AND v2.code = ? AND p1.time >= strftime(?, ?, ?) AND p1.time < strftime(?, ?, ?)
2025-04-29 13:21:54 info: Verbruik dit contractjaar: 6383.567 kWh
2025-04-29 13:21:54 info: Productie dit contractjaar: 2662.845 kWh
2025-04-29 13:21:54 info: All taxes refund (alles wordt gesaldeerd)
2025-04-29 13:21:56 debug: Reduced hours for Sessy
2025-04-29 13:21:56 debug: cycle cost: 0.03 eur/kWh
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/sensor.sessy_state_of_charge_avg HTTP/1.1" 200 430
2025-04-29 13:21:56 info: Startwaarde SoC Sessy: 44.67%
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_min_soc_einde_opt HTTP/1.1" 200 472
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_max_soc_einde_opt HTTP/1.1" 200 474
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/sensor.ecodan_heatpump_dhw_current_temp HTTP/1.1" 200 474
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/sensor.ecodan_heatpump_dhw_setpoint_value HTTP/1.1" 200 478
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_hysterese_dhw HTTP/1.1" 200 418
2025-04-29 13:21:56 info: Boiler opwarmen wordt ingepland tussen: 13 en 13 uur
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_boolean.dao_zoe_external_power_connected HTTP/1.1" 200 411
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/device_tracker.smartevse_6697 HTTP/1.1" 200 592
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.zoe_accu HTTP/1.1" 200 403
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_zoe_gewenst_laad_niveau HTTP/1.1" 200 465
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_datetime.dao_zoetijdstip_klaar_met_laden HTTP/1.1" 200 471
2025-04-29 13:21:56 info: Instellingen voor laden van EV: Zoe
2025-04-29 13:21:56 info:  Ampere  Effic. Grid kW Accu kW
2025-04-29 13:21:56 info:    0.00    1.00    0.00    0.00
2025-04-29 13:21:56 info:   15.00    1.00   10.35   10.35
2025-04-29 13:21:56 info: Capaciteit accu: 40 kWh
2025-04-29 13:21:56 info: Maximaal laadvermogen: 10.35 kW
2025-04-29 13:21:56 info: Klaar met laden op: 30-04-2025 06:00:00
2025-04-29 13:21:56 info: Huidig laadniveau: 25.0 %
2025-04-29 13:21:56 info: Gewenst laadniveau:100.0 %
2025-04-29 13:21:56 info: Marge voor het laden: 1 %
2025-04-29 13:21:56 info: Locatie: home
2025-04-29 13:21:56 info: Ingeplugged:False
2025-04-29 13:21:56 info: Benodigde energie: 30.0 kWh
2025-04-29 13:21:56 info: Tijd nodig om te laden: 2.90 uur
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_boolean.dao_zoe_charging HTTP/1.1" 200 384
2025-04-29 13:21:56 debug: Starting new HTTP connection (1): 192.168.178.156:8123
2025-04-29 13:21:56 debug: http://192.168.178.156:8123 "GET /api/states/input_number.dao_zoe_set_car_charging_ampere HTTP/1.1" 200 501
2025-04-29 13:21:56 info: Afgerond naar hele uren: 3
2025-04-29 13:21:56 info: Stand laden schakelaar: on
2025-04-29 13:21:56 info: Stand aantal ampere laden: 15.0 A
2025-04-29 13:21:56 info: Opladen wordt niet ingepland, omdat auto is niet ingeplugd.

Als ik naar de logging kijk zie ik dat hij veel tijd kwijt is met het ophalen van data uit de day_ahead database.
Met name die laatste query duurt 25 seconden.
Misschien kun je nog eens naar de day_ahead database kijken.
En - zoals @f.welvering ook zei - kijk nog even naar je hardware.
Ik heb zelf de "system monitor" integratie geinstalleerd:
https://www.home-assistant.io/integrations/systemmonitor/
Ik had eerst een RPi4 en die liep tegen zijn grenzen aan (af en toe te heet).
Ik draai nu met een RPi 5 met 16 GB en een ssd en die loopt prima (eigenlijk te goed):

[KC27]

balk schreef op dinsdag 29 april 2025 @ 16:06:
De rekensnelheid gaat binnenkort een nog grotere rol spelen vanwege de 15minuten tarieven. Dat geeft nog veel meer mogelijkheden en dus meer rekentijd.
Misschien is het goed om in de documentatie wat woorden te besteden aan hoe de configuratie de rekentijd beïnvloed. Ik kan binnenkort daar wel wat tijd in steken.
Vooruitlopend daarop: ik heb mijn zes panelen individueel in de config staan, want ze liggen niet allemaal het zelfde. Zou de berekening sneller gaan wanneer ik ze als 1 paneel zou gaan instellen?

De datum van invoer van het 15min interval voor day-ahead prijzen (oorspronkelijke planning 11 juni a.s.) staat weer op losse schroeven.
Zie: https://www.epexspot.com/...e-day-ahead-go-live-light.
Eind mei wordt er over gestemd....

Maar het gaat hoe dan ook dit jaar (waarschijnlijk) gebeuren.
Dat betekent dat het aantal variabelen in de optimaliserings-berekening grofweg met een factor 4 toeneemt en de rekentijd - schat ik - met een factor 16.
Ik heb al een aantal testen gedraaid en met name 's middags om 13:00 uur als de nieuwe prijzen binnen zijn heeft DAO het zwaar. Er zijn diverse oplossingsrichtingen denkbaar:

• snellere hardware
• probeer het aantal variabelen te reduceren
• de nauwkeurig van het gewenste eindresultaat ("de winst") verminderen, scheelt een aantal iteraties
• de berekening een instelbaar aantal seconden voor het begin van het kwartier starten, zodat de data direct aan het begin van het kwartier beschikbaar zijn
• een combinatie van twee of meer van bovengenoemde richtingen.

Hebben jullie nog ideeën?

[KC27]

DaBit schreef op dinsdag 29 april 2025 @ 17:09:
@KC27 : volgens mij is dat 2-auto probleem nog niet 100% opgelost.

code:

2025-04-29 17:01:30 info: Berekeningsuitkomst voor opladen van Corsa-E:
2025-04-29 17:01:30 info: - aantal ampere 0A (was 0.0A)
2025-04-29 17:01:30 info: - stand schakelaar 'off' (was 'off')
2025-04-29 17:01:30 info: - positie: home
2025-04-29 17:01:30 info: - ingeplugd: False
2025-04-29 17:01:30 info: Corsa-E is niet thuis of niet ingeplugd
2025-04-29 17:01:30 info: Evaluatie status laden Corsa-E op 2025-04-29 17:01
2025-04-29 17:01:30 info: - schakelaar laden: off
2025-04-29 17:01:30 info: - aantal ampere: 0.0
2025-04-29 17:01:30 info: Berekeningsuitkomst voor opladen van boiler:
2025-04-29 17:01:30 info: - aantal ampere 0A (was 10.0A)
2025-04-29 17:01:30 info: - stand schakelaar 'off' (was 'on')
2025-04-29 17:01:30 info: - positie: home
2025-04-29 17:01:30 info: - ingeplugd: False
2025-04-29 17:01:30 info: boiler is niet thuis of niet ingeplugd
2025-04-29 17:01:30 info: Evaluatie status laden boiler op 2025-04-29 17:01
2025-04-29 17:01:30 info: - schakelaar laden: on
2025-04-29 17:01:30 info: - aantal ampere: 10.0

Zie redelijk op het eind: 'boiler' is niet thuis of niet ingeplugd maar toch blijft de laad-schakelaar aanstaan, evenals de laadstroom op 10A terwijl de uitkomst van de berekening off/0A was.

Voor de rest lijkt het prima gefunctioneerd te hebben. DAO plande de boiler in om 11.00 toen volgens mijn regels de elektriciteit goedkoper werd dan gas:

code:

2025-04-29 11:01:28 info: Instellingen voor laden van EV: boiler
2025-04-29 11:01:28 info:  Ampere  Effic. Grid kW Accu kW
2025-04-29 11:01:28 info:    0.00    1.00    0.00    0.00
2025-04-29 11:01:28 info:    2.00    0.99    0.46    0.46
2025-04-29 11:01:28 info:    3.00    0.99    0.69    0.68
2025-04-29 11:01:28 info:    4.00    0.99    0.92    0.91
2025-04-29 11:01:28 info:    5.00    0.99    1.15    1.14
2025-04-29 11:01:28 info:    6.00    0.98    1.38    1.35
2025-04-29 11:01:28 info:    7.00    0.98    1.61    1.58
2025-04-29 11:01:28 info:    8.00    0.98    1.84    1.80
2025-04-29 11:01:28 info:    9.00    0.97    2.07    2.01
2025-04-29 11:01:28 info:   10.00    0.97    2.30    2.23
2025-04-29 11:01:28 info: Capaciteit accu: 13.4 kWh
2025-04-29 11:01:28 info: Maximaal laadvermogen: 2.3 kW
2025-04-29 11:01:28 info: Klaar met laden op: 29-04-2025 18:00:00
2025-04-29 11:01:28 info: Huidig laadniveau: 15.9 %
2025-04-29 11:01:28 info: Gewenst laadniveau:70.0 %
2025-04-29 11:01:28 info: Marge voor het laden: 1 %
2025-04-29 11:01:28 info: Locatie: home
2025-04-29 11:01:28 info: Ingeplugged:True
2025-04-29 11:01:28 info: Benodigde energie: 7.2494000000000005 kWh
2025-04-29 11:01:28 info: Tijd nodig om te laden: 3.25 uur
2025-04-29 11:01:28 info: Afgerond naar hele uren: 4
2025-04-29 11:01:28 info: Stand laden schakelaar: off
2025-04-29 11:01:28 info: Stand aantal ampere laden: 0.0 A
2025-04-29 11:01:28 info: Opladen wordt ingepland.

Procenten zijn graden.

Met als resultaat:

[Afbeelding]

In het eerste stukje nog geen opwarming vanwege een bugje aan mijn kant van het hele verhaal, daarna gestaag.
DAO heeft hier niet gekregen wat-ie wilde; boilervermogen is geknepen vanwege bovengrens temperatuur elektronica. Meh, SSR kan zijn warmte niet kwijt, daar moet ik echt eens naar kijken.

DAO vond het verder schijnbaar ook nodig om redelijk richting 0 op de meter te regelen, bewust of onbewust:

[Afbeelding]

(gele lijn is de netbalans afkomstig van de P1-meter, negatief is energie de straat op, positief is energie het huis binnen)

Het stukje configuratie van de boiler:

code:

{
      "name": "boiler",
      "capacity": 13.4,
      "entity max amperage": "input_number.ev_max_charge_amps",
      "entity position": "input_select.corsae_location",
      "charge three phase": "False",
      "charge stages" : [
        {"ampere":  0,  "efficiency":  1},
        {"ampere":  6,  "efficiency": 0.98 },
        {"ampere":  7,  "efficiency": 0.98 },
        {"ampere":  8,  "efficiency": 0.98 },
        {"ampere":  9,  "efficiency": 0.97 },
        {"ampere":  10, "efficiency": 0.97 }
      ],
      "entity actual level": "sensor.boiler_boiler_temperature",
      "entity plugged in": "binary_sensor.electricity_cheaperthangas",
      "charge scheduler": {
        "entity set level": "input_number.boiler_desiredtemperature",
        "level margin": 1,
        "entity ready datetime": "input_datetime.dao_boiler_ready_datetime"
      },
      "charge switch": "input_boolean.dao_boiler_activate",
      "entity set charging ampere": "input_number.dao_boiler_ampsetpoint"
    }

Tot nu toe is het uitgangspunt bij een ev altijd geweest dat de aan/uit schakelaar alleen wordt bediend als én de auto thuis is én deze is ingeplugd. Als niet aan beide condities wordt voldaan blijft DAO van de schakelaar af (bijv. auto kan buiten de deur aan een lader hangen).
Dit is tot nu toe altijd goed gegaan, alleen nu niet met een virtuele auto.
Ik ben huiverig om dit om te gooien en daarmee problemen bij anderen te creëren.
Kun jij het zelf met een automation oplossen?

[Impossibl3]

KC27 schreef op dinsdag 29 april 2025 @ 23:40:
[...]


Tot nu toe is het uitgangspunt bij een ev altijd geweest dat de aan/uit schakelaar alleen wordt bediend als én de auto thuis is én deze is ingeplugd. Als niet aan beide condities wordt voldaan blijft DAO van de schakelaar af (bijv. auto kan buiten de deur aan een lader hangen).
Dit is tot nu toe altijd goed gegaan, alleen nu niet met een virtuele auto.
Ik ben huiverig om dit om te gooien en daarmee problemen bij anderen te creëren.
Kun jij het zelf met een automation oplossen?

Hoe wordt de positie home bepaald? Haalt die dat uit de auto of via een andere weg? Als ik kijk naar mijn PHEV dan moet ik een abbo afsluiten om dat te krijgen a €100+ piek per jaar. Mijn laadpaal is wel slim en die stuur ik nu dan ook aan op dynamisch laad amperage (PV-overschot en goedkoopste uren). Hoe gaat DAO daar mee om? De SOC weet ik dus niet maar 9 van de 10 keer is de accu leeg als die ingeplugt wordt dus ik weet wel hoeveel kWh erin moet gaan.

[Impossibl3]

KC27 schreef op dinsdag 29 april 2025 @ 23:27:
[...]
Er zijn diverse oplossingsrichtingen denkbaar:

• snellere hardware
• probeer het aantal variabelen te reduceren
• de nauwkeurig van het gewenste eindresultaat ("de winst") verminderen, scheelt een aantal iteraties
• de berekening een instelbaar aantal seconden voor het begin van het kwartier starten, zodat de data direct aan het begin van het kwartier beschikbaar zijn
• een combinatie van twee of meer van bovengenoemde richtingen.

Hebben jullie nog ideeën?

Snellere hardware altijd +1 .

Maar zonder gekheid ik zou de nauwkeurigheid omlaag schroeven. Liever iets minder "winst" draaien dan veel CPU kracht nodig hebben.

Het voordeel van een paar seconden voor het kwartier starten heb je alleen bij nieuwe prijzen (1x per etmaal dus). Als de prijzen bekend zijn dan is het eerder draaien van de berekening net zo nuttig als bij de uurprijzen in mijn optiek.

[ErnstH]

KC27 schreef op dinsdag 29 april 2025 @ 23:27:
[...]

De datum van invoer van het 15min interval voor day-ahead prijzen (oorspronkelijke planning 11 juni a.s.) staat weer op losse schroeven.
Zie: https://www.epexspot.com/...e-day-ahead-go-live-light.
Eind mei wordt er over gestemd....

Maar het gaat hoe dan ook dit jaar (waarschijnlijk) gebeuren.
Dat betekent dat het aantal variabelen in de optimaliserings-berekening grofweg met een factor 4 toeneemt en de rekentijd - schat ik - met een factor 16.
Ik heb al een aantal testen gedraaid en met name 's middags om 13:00 uur als de nieuwe prijzen binnen zijn heeft DAO het zwaar. Er zijn diverse oplossingsrichtingen denkbaar:

• snellere hardware
• probeer het aantal variabelen te reduceren
• de nauwkeurig van het gewenste eindresultaat ("de winst") verminderen, scheelt een aantal iteraties
• de berekening een instelbaar aantal seconden voor het begin van het kwartier starten, zodat de data direct aan het begin van het kwartier beschikbaar zijn
• een combinatie van twee of meer van bovengenoemde richtingen.

Hebben jullie nog ideeën?

Je zou iets met de "resolutie" van de tijdsintervallen kunnen doen. De dure en goedkope uren zijn waarop gestuurd wordt, dus die wil je op 15min lengte houden, maar de 50% tijd aan "middenprijzen" zou je op een 1 uur of zelfs langer tijdsinterval kunnen houden. Dus een dynamisch tijdsinterval gebaseerd op de relevantie van de onderliggende prijs.

[balk]

ErnstH schreef op woensdag 30 april 2025 @ 06:48:
[...]

Je zou iets met de "resolutie" van de tijdsintervallen kunnen doen. De dure en goedkope uren zijn waarop gestuurd wordt, dus die wil je op 15min lengte houden, maar de 50% tijd aan "middenprijzen" zou je op een 1 uur of zelfs langer tijdsinterval kunnen houden. Dus een dynamisch tijdsinterval gebaseerd op de relevantie van de onderliggende prijs.

Precies mijn gedachte. Wanneer de prijzen niet significant* veranderen, en de andere variabelen ook niet, dan zal de uitkomst hetzelfde zijn. Daarmee kan je het aantal tijdvakken flink reduceren en dus de snelheid verhogen.
* Instelbaar

[DaBit]

KC27 schreef op dinsdag 29 april 2025 @ 23:27:
Er zijn diverse oplossingsrichtingen denkbaar:

• snellere hardware
• probeer het aantal variabelen te reduceren
• de nauwkeurig van het gewenste eindresultaat ("de winst") verminderen, scheelt een aantal iteraties
• de berekening een instelbaar aantal seconden voor het begin van het kwartier starten, zodat de data direct aan het begin van het kwartier beschikbaar zijn
• een combinatie van twee of meer van bovengenoemde richtingen.

Hebben jullie nog ideeën?

Hmm, ik zou eerst eens aankijken hoe erg het 'probleem' nou werkelijk gaat worden. Als de inzet voor kwartier N 10% verschilt van de inzet van kwartier N+1 en de rekentijd 10% van een kwartier is, dan verliezen we heel erg kort door de bocht 1%. Dat is ruis. En dat is al pessimistisch gerekend.
Maar ik weet niet of mijn aanname dat de inzet van kwartier N+1 heel veel lijkt op kwartier N klopt.

Is die fictieve 1% dan een probleem voor een gebruiker, dan kun je best eisen dat het aantal variabelen of iteraties gereduceerd wordt, of de hardware sneller. Met FE-analyses, games, ecetera is het immers ook niet anders. Grotere meshes, dikkere hardware of langer wachten.

Maargoed, mijn mening.

KC27 schreef op dinsdag 29 april 2025 @ 23:40:
Dit is tot nu toe altijd goed gegaan, alleen nu niet met een virtuele auto.
Ik ben huiverig om dit om te gooien en daarmee problemen bij anderen te creëren.
Kun jij het zelf met een automation oplossen?

Ah, geen bug maar een feature dus!
Natuurlijk kan ik dat met een automatie oplossen. Dat was al zo zelfs; je ziet dat de boiler stopt als de elektra weer duurder word dan gas.

[mgroen81]

KC27 schreef op dinsdag 29 april 2025 @ 23:04:
[...]

Als ik naar de logging kijk zie ik dat hij veel tijd kwijt is met het ophalen van data uit de day_ahead database.
Met name die laatste query duurt 25 seconden.
Misschien kun je nog eens naar de day_ahead database kijken.
En - zoals @f.welvering ook zei - kijk nog even naar je hardware.
Ik heb zelf de "system monitor" integratie geinstalleerd:
https://www.home-assistant.io/integrations/systemmonitor/
Ik had eerst een RPi4 en die liep tegen zijn grenzen aan (af en toe te heet).
Ik draai nu met een RPi 5 met 16 GB en een ssd en die loopt prima (eigenlijk te goed):
[Afbeelding]

Ik heb MariaDB geinstalleerd en alleen de DAO database overgezet naar MySQL.
Resultaat. van 50 sec naar 37 sec gegaan.
Dit heeft geholpen, bedankt!

[KC27]

Impossibl3 schreef op dinsdag 29 april 2025 @ 23:45:
[...]


Hoe wordt de positie home bepaald? Haalt die dat uit de auto of via een andere weg? Als ik kijk naar mijn PHEV dan moet ik een abbo afsluiten om dat te krijgen a €100+ piek per jaar. Mijn laadpaal is wel slim en die stuur ik nu dan ook aan op dynamisch laad amperage (PV-overschot en goedkoopste uren). Hoe gaat DAO daar mee om? De SOC weet ik dus niet maar 9 van de 10 keer is de accu leeg als die ingeplugt wordt dus ik weet wel hoeveel kWh erin moet gaan.

Jij bepaalt hoe de positie home wordt doorgegeven aan DAO. Je kunt daarvoor de position-tracker van de auto gebruiken (met alle door jou genoemde nadelen van dien). Maar je kunt ook een helper aanmaken. Bijvoorbeeld een input_select met twee opties: "home" en "away", die je zelf instelt als je thuiskomt of weggaat samen met het tijdstip dat ie tot een bepaald niveau geladen moet zijn.
Meestal staat er iets op het dashboard van je auto hoe groot je elektrisch bereik is. Je zou een input_number kunnen maken waarin je dat invult en dat je een template of automation maakt die dat omrekent naar een start_soc. Je kunt ook nog (voor tijdens het laden) een "berekende" soc maken die de start_soc ophoogt met het omgerekende verbruik van je laadpaal. Is allemaal iets meer invullen maar werkt wel.

[ebbz]

Ik meld mij ook even in dit topic.
DAO ziet er uit als een gave oplossing.
Ga me de komende tijd eens mee bezig houden om het aan de praat te krijgen.
Ik ziet hier ook met een EV, PV, warmtepomp en boiler + dynamisch contract.

Ik heb al het een en ander in elkaar gezet in home assistant om te sturen op lage prijzen. Dit werkt allemaal prima. Maar met deze oplossing wordt het waarschijnlijk een stuk makkelijker om alles 2027 proof te krijgen.

@KC27 Ik heb op github een issue aangemaakt, hier liep ik tegen aan bij het configureren
--Wellicht kan ik daar t.z.t. ook nog een PR voor inschieten met een verbeter voorstel.

[ Voor 7% gewijzigd door ebbz op 30-04-2025 10:43 ]

[KC27]

Voor diegenen die het gemist hebben (verstopt in een bericht aan @mgroen81 ):

Een tijdje terug hadden we "out of the blue" problemen met het niet kunnen bereiken van HA als je niets voor homeassistant configureerde: dus "homeassistant": { },
Daar was toen een snelle fix voor gevonden, maar geen oplossing.
Inmiddels lijkt dat probleem ook weer voorbij (ik zou niet weten waarom (dus ook weer "out of the blue").
Je kunt dat eenvoudig testen door je configuratie als volgt te wijzigen:

code:

{ "homeassistant": { },
  "//homeassistant": {
    "protocol api": "http",
    "ip adress": "homeassistant.local",
    "ip port": 8123,
    "token": "!secret ha_api_token"
  },

Dus de fix voorzien van een of meer willekeurig letters en de oude definitie daarboven.
Dan kun je via \Run\Optimaliseringsberekening met debug testen of het bij jou weer werkt.
Als het niet werkt zet je alles weer terug.

[WTH_70]

Ik volg dit topic ook al een tijdje, en ben aardig onder de indruk van het knap staaltje werk @KC27

Ik heb een EV, PV, warmtepomp + boiler en thuisbatterij in gebruik en ben nu op zoek naar een oplossing om dit allemaal (beter) aan te sturen via Home Assistant. Maar dan in België...

@KC27 Staat dit op de roadmap?

[KC27]

WTH_70 schreef op woensdag 30 april 2025 @ 11:45:
Ik volg dit topic ook al een tijdje, en ben aardig onder de indruk van het knap staaltje werk @KC27

Ik heb een EV, PV, warmtepomp + boiler en thuisbatterij in gebruik en ben nu op zoek naar een oplossing om dit allemaal (beter) aan te sturen via Home Assistant. Maar dan in België...

@KC27 Staat dit op de roadmap?

Ja dat staat zeker in de planning.
Mede op verzoek van je landgenoot @Undertilted (zoek en zie zijn bijdragen in dit topic).
Je kunt nu al je maximaal afgenomen vermogen instellen (In verband met het capaciteitstarief):

code:

  "grid": {
    "max_power": 17

Ik ben bezig om de formules voor de berekening van het inkoop- en teruglevertarief flexibel (dwz zelf invulbaar) te maken. Daarmee kun je het helemaal op jouw situatie toesnijden.
Of zijn er nog meer specifieke situaties in België?

[llevering]

Het lukt niet om een optimalisatie te berekenen, zie het volgende in de log:

[2025-04-30 13:57:30 +0200] [2443] [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 246, in menu
return run_process()
^^^^^^^^^^^^^
File "/root/dao/webserver/app/routes.py", line 371, 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

Dynamische prijzen zijn opgehaald via ENTSOE. Geen enkele dynamisch load geconfigureerd (allemaal uitgezet om het uit te sluiten). Misschien vanwege negatieve prijs morgen? Iemand anders er ook last van?

[KC27]

Bij mij werkt ie prima.
Hij moet juist wel minimaal een dynamische load hebben om te kunnen schuiven.
Het lijkt op een timeout error.
Kun je de log van de berekening (via Home en dan tabel ipv grafiek) hier delen?

[Torch1969]

KC27 schreef op woensdag 30 april 2025 @ 09:49:
[...]

Jij bepaalt hoe de positie home wordt doorgegeven aan DAO. Je kunt daarvoor de position-tracker van de auto gebruiken (met alle door jou genoemde nadelen van dien). Maar je kunt ook een helper aanmaken. Bijvoorbeeld een input_select met twee opties: "home" en "away", die je zelf instelt als je thuiskomt of weggaat samen met het tijdstip dat ie tot een bepaald niveau geladen moet zijn.
Meestal staat er iets op het dashboard van je auto hoe groot je elektrisch bereik is. Je zou een input_number kunnen maken waarin je dat invult en dat je een template of automation maakt die dat omrekent naar een start_soc. Je kunt ook nog (voor tijdens het laden) een "berekende" soc maken die de start_soc ophoogt met het omgerekende verbruik van je laadpaal. Is allemaal iets meer invullen maar werkt wel.

@Impossibl3 ik heb(wil) ook geen directe connectie met een "slimme" auto, maar deze post op GitHub heeft mij goed geholpen om de juiste helpers aan te maken en die zelf handmatig in te stellen.

[itavero]

verguldebarman schreef op vrijdag 18 april 2025 @ 07:00:
Is het een idee om de Docker images te publiceren, zodat je in compose er gewoon naar kunt verwijzen? Dat scheelt voor iedereen een build een maakt het een stuk toegankelijker 💪

Dit lijkt mij ook een goed idee. Als ik een keer tijd vind ga ik hier mee aan de gang.

Ik heb eerder iets soortgelijks gedaan voor mijn (inmiddels deprecated) Peblar2MQTT projectje.
Het is vrij eenvoudig om dit te automatiseren en de images naar ghcr.io te laten publiceren.

Mocht iemand anders er mee aan de slag willen gaan dan kan deze GitHub workflow wellicht ter inspiratie dienen:
https://github.com/itaver...kflows/docker-publish.yml

De matrix kan dan gebruikt worden voor de architecture die voor zowel BUILD_ARCH en BUILD_FROM nodig is.
De versie kan wellicht ingevuld worden met een van de outputs van de Docker meta action.

De test stap kan uiteraard geheel verwijderd worden.

[ Voor 3% gewijzigd door itavero op 30-04-2025 20:27 ]

[KC27]

itavero schreef op woensdag 30 april 2025 @ 20:25:
[...]


Dit lijkt mij ook een goed idee. Als ik een keer tijd vind ga ik hier mee aan de gang.

Ik heb eerder iets soortgelijks gedaan voor mijn (inmiddels deprecated) Peblar2MQTT projectje.
Het is vrij eenvoudig om dit te automatiseren en de images naar ghcr.io te laten publiceren.

Mocht iemand anders er mee aan de slag willen gaan dan kan deze GitHub workflow wellicht ter inspiratie dienen:
https://github.com/itaver...kflows/docker-publish.yml

De matrix kan dan gebruikt worden voor de architecture die voor zowel BUILD_ARCH en BUILD_FROM nodig is.
De versie kan wellicht ingevuld worden met een van de outputs van de Docker meta action.

De test stap kan uiteraard geheel verwijderd worden.

@verguldebarman@itavero
Inmiddels heeft @bvw een workflow in GitHub gemaakt die als een nieuwe release wordt gepubliceerd een build (eigenlijk 3 voor iedere ondersteunde architectuur) maakt en publiceert van die nieuwe release.
We gaan dit binnenkort testen en als het werkt wordt de installatie een stuk sneller en eenvoudiger.

Als jullie willen checken, meekijken graag: in de map
.github/workflows staat publish.yml.

[ebbz]

Voor wie home assistant publiek benaderbaar hebben en op een makkelijke (en veilige manier) DAO ook publiek benaderbaar willen hebben.

Ik draai home assistant via een reverse proxy. DAO heeft geen eigen authenticatie. Maar via deze manier kun je DAO toch benaderbaar maken en meeliften op de authenticatie van home assistant

Kijk eens naar dit

[DaBit]

Dat werkt toch mooi, een nep-EV inzetten voor de boiler:



Momenteel is de elektra al goedkoper dan gas, maar die boiler moet nog even wachten op de laagste dagprijzen vandaag voordat die mag beginnen met verwarmen. Dat gaat netjes zo.

[DaBit]

@KC27 : heb jij toevallig ook al een testversie beschikbaar die met tijdspannes van een kwartier werkt? DAO elk kwartier laten optimaliseren doet wel iets als de uitgangspunten voor de optimalisatie veranderen buiten DAO om, maar als apparaat X nu Y kW nodig heeft wordt dat verdeeld over hele uren (met eventueel nog wat 'gefoezel' bij bijvoorbeeld de EV om het laden ergens in het uur uit te zetten).

Mijn onderbuik zegt dat ik die resolutie toch graag hoger zou willen hebben, en aangezien jij daar toch al mee bezig bent zou ik dat graag eens proberen als dat mogelijk is.

Tweede vraag: kan de scheduler ook secondes? Ik heb aan het begin van het uur een klein beetje tijd nodig om data te prepareren die DAO nodig heeft om z'n werk te doen. Om racecondities te voorkomen start ik DAO nu 1 minuut later. Geen ramp, ook niet vervelend genoeg om de REST API te gebruiken ipv de scheduler van DAO zelf, maar eigenlijk is 5 seconden ook al genoeg.

[ Voor 24% gewijzigd door DaBit op 01-05-2025 12:31 ]

[itavero]

KC27 schreef op woensdag 30 april 2025 @ 20:55:
[...]

@verguldebarman@itavero
Inmiddels heeft @bvw een workflow in GitHub gemaakt die als een nieuwe release wordt gepubliceerd een build (eigenlijk 3 voor iedere ondersteunde architectuur) maakt en publiceert van die nieuwe release.
We gaan dit binnenkort testen en als het werkt wordt de installatie een stuk sneller en eenvoudiger.

Als jullie willen checken, meekijken graag: in de map
.github/workflows staat publish.yml.

Die had ik zien staan, maar blijkbaar over die home-assistant/builder@master actie heen gekeken.
Ik zie bij andere workflows die dit ook gebruiken soms nog wel een losse stap om de versie van de add-on goed te zetten, maar dat zal wellicht liggen aan hoe het project is opgezet.

Mocht je het liever naar GitHub pushen i.p.v. Docker Hub, zag ik daar hier nog een voorbeeld van staan: https://github.com/joBr99...ows/builder.yaml#L93-L111

Verder zou ik zelf altijd een gedefinieerde versie van een GitHub Action proberen te gebruiken (bijv. 2025.03.0), i.p.v. simpelweg latest/greatest, aangezien wijzigingen daar niet altijd backwards compatible zijn).

[KC27]

Gisteravond is een nieuwe versie (2025.4.2) gepubliceerd op github.
Zie changelog voor alle doorgevoerde wijzigingen.

[itavero]

KC27 schreef op vrijdag 2 mei 2025 @ 08:39:
Gisteravond is een nieuwe versie (2025.4.2) gepubliceerd op github.

Voor hen die het interesseert: het publiceren van de Docker images gaat helaas nog niet goed. Nog even geduld denk ik dus.

[llevering]

KC27 schreef op woensdag 30 april 2025 @ 14:21:
Bij mij werkt ie prima.
Hij moet juist wel minimaal een dynamische load hebben om te kunnen schuiven.
Het lijkt op een timeout error.
Kun je de log van de berekening (via Home en dan tabel ipv grafiek) hier delen?

Inmiddels op de nieuwste versie, zelfde resultaat nog.

code:

 2025-05-02 09:50:16 info: Day Ahead Optimalisering versie: 2025.4.2
2025-05-02 09:50:16 info: Day Ahead Optimalisering gestart op: 02-05-2025 09:50:16
2025-05-02 09:50:16 info: Day Ahead Optimalisatie gestart: 02-05-2025 09:50:16 taak: calc_optimum_met_debug
2025-05-02 09:50:16 info: Debug = True
2025-05-02 09:50:16 info: Baseload uit instellingen
2025-05-02 09:50:16 info: Start waarden: 
    uur                tijd      p_l      p_t  base     pv_ac  pv_dc
0     9 2025-05-02 09:00:00  0.24010  0.24010  0.40  0.227112      0
1    10 2025-05-02 10:00:00  0.14869  0.14869  0.40  1.856006      0
2    11 2025-05-02 11:00:00  0.14765  0.14765  0.40  2.206829      0
3    12 2025-05-02 12:00:00  0.14670  0.14670  0.40  2.469246      0
4    13 2025-05-02 13:00:00  0.14403  0.14403  0.40  3.543512      0
5    14 2025-05-02 14:00:00  0.14282  0.14282  0.40  3.385790      0
6    15 2025-05-02 15:00:00  0.14757  0.14757  0.40  3.225595      0
7    16 2025-05-02 16:00:00  0.14803  0.14803  0.40  2.971139      0
8    17 2025-05-02 17:00:00  0.22201  0.22201  0.90  2.660100      0
9    18 2025-05-02 18:00:00  0.26283  0.26283  0.25  2.189647      0
10   19 2025-05-02 19:00:00  0.27832  0.27832  0.25  0.138771      0
11   20 2025-05-02 20:00:00  0.31749  0.31749  0.25  0.058860      0
12   21 2025-05-02 21:00:00  0.29012  0.29012  0.20  0.053750      0
13   22 2025-05-02 22:00:00  0.27261  0.27261  0.17  0.043000      0
14   23 2025-05-02 23:00:00  0.25995  0.25995  0.17  0.032250      0

In de add-on log:

code:

[2025-05-02 09:49:54 +0200] [14] [INFO] Starting gunicorn 23.0.0
[2025-05-02 09:49:54 +0200] [14] [INFO] Listening at: http://0.0.0.0:5000 (14)
[2025-05-02 09:49:54 +0200] [14] [INFO] Using worker: sync
[2025-05-02 09:49:54 +0200] [28] [INFO] Booting worker with pid: 28
[2025-05-02 09:49:54 +0200] [29] [INFO] Booting worker with pid: 29
[2025-05-02 09:51:07 +0200] [14] [CRITICAL] WORKER TIMEOUT (pid:29)
[2025-05-02 09:51:07 +0200] [29] [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 246, in menu
    return run_process()
           ^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 375, 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-05-02 09:51:07 +0200] [29] [INFO] Worker exiting (pid: 29)
[2025-05-02 09:51:08 +0200] [38] [INFO] Booting worker with pid: 38

Heel soms zie ik ook meldingen over out-of-memory, dus ik heb alle andere add-ons gesloten, dan krijg ik geen out-of-memory melding maar ook geen berekening. Ik vrees dat de add-on te zwaar is voor mijn Odroid N2 (4gb), alhoewel de grafiek van geheugengebruik niet boven de 75% komt. Ik zou alleen niet weten waar het anders te zoeken.

[DaBit]

HomeAssistant als VM op Proxmox met meerdere addons waaronder DAO:



Het is geen odroid, maar dan nog lijkt die 4GB me wel voldoende.

(zo aan de CPU-pieken te zien doet DAO niks met meerdere CPU-cores. Misschien zit daar nog winst voor het geval dat de rekentijden te lang worden?)

[KC27]

llevering schreef op vrijdag 2 mei 2025 @ 10:23:
[...]


Inmiddels op de nieuwste versie, zelfde resultaat nog.

code:

 2025-05-02 09:50:16 info: Day Ahead Optimalisering versie: 2025.4.2
2025-05-02 09:50:16 info: Day Ahead Optimalisering gestart op: 02-05-2025 09:50:16
2025-05-02 09:50:16 info: Day Ahead Optimalisatie gestart: 02-05-2025 09:50:16 taak: calc_optimum_met_debug
2025-05-02 09:50:16 info: Debug = True
2025-05-02 09:50:16 info: Baseload uit instellingen
2025-05-02 09:50:16 info: Start waarden: 
    uur                tijd      p_l      p_t  base     pv_ac  pv_dc
0     9 2025-05-02 09:00:00  0.24010  0.24010  0.40  0.227112      0
1    10 2025-05-02 10:00:00  0.14869  0.14869  0.40  1.856006      0
2    11 2025-05-02 11:00:00  0.14765  0.14765  0.40  2.206829      0
3    12 2025-05-02 12:00:00  0.14670  0.14670  0.40  2.469246      0
4    13 2025-05-02 13:00:00  0.14403  0.14403  0.40  3.543512      0
5    14 2025-05-02 14:00:00  0.14282  0.14282  0.40  3.385790      0
6    15 2025-05-02 15:00:00  0.14757  0.14757  0.40  3.225595      0
7    16 2025-05-02 16:00:00  0.14803  0.14803  0.40  2.971139      0
8    17 2025-05-02 17:00:00  0.22201  0.22201  0.90  2.660100      0
9    18 2025-05-02 18:00:00  0.26283  0.26283  0.25  2.189647      0
10   19 2025-05-02 19:00:00  0.27832  0.27832  0.25  0.138771      0
11   20 2025-05-02 20:00:00  0.31749  0.31749  0.25  0.058860      0
12   21 2025-05-02 21:00:00  0.29012  0.29012  0.20  0.053750      0
13   22 2025-05-02 22:00:00  0.27261  0.27261  0.17  0.043000      0
14   23 2025-05-02 23:00:00  0.25995  0.25995  0.17  0.032250      0

In de add-on log:

code:

[2025-05-02 09:49:54 +0200] [14] [INFO] Starting gunicorn 23.0.0
[2025-05-02 09:49:54 +0200] [14] [INFO] Listening at: http://0.0.0.0:5000 (14)
[2025-05-02 09:49:54 +0200] [14] [INFO] Using worker: sync
[2025-05-02 09:49:54 +0200] [28] [INFO] Booting worker with pid: 28
[2025-05-02 09:49:54 +0200] [29] [INFO] Booting worker with pid: 29
[2025-05-02 09:51:07 +0200] [14] [CRITICAL] WORKER TIMEOUT (pid:29)
[2025-05-02 09:51:07 +0200] [29] [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 246, in menu
    return run_process()
           ^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 375, 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-05-02 09:51:07 +0200] [29] [INFO] Worker exiting (pid: 29)
[2025-05-02 09:51:08 +0200] [38] [INFO] Booting worker with pid: 38

Heel soms zie ik ook meldingen over out-of-memory, dus ik heb alle andere add-ons gesloten, dan krijg ik geen out-of-memory melding maar ook geen berekening. Ik vrees dat de add-on te zwaar is voor mijn Odroid N2 (4gb), alhoewel de grafiek van geheugengebruik niet boven de 75% komt. Ik zou alleen niet weten waar het anders te zoeken.

Een kennis van @tonvanboven had precies dezelfde foutmelding op een Intel NUC. Na een halve dag liep ie weer. Hij werkt met een MySQL db.
Hoe zit dat bij jou?

[llevering]

KC27 schreef op vrijdag 2 mei 2025 @ 21:55:
[...]

Een kennis van @tonvanboven had precies dezelfde foutmelding op een Intel NUC. Na een halve dag liep ie weer. Hij werkt met een MySQL db.
Hoe zit dat bij jou?

Nou ik denk dat ik het gevonden heb... En het feit dat het op een niet zo krachtige NUC voorkwam duidt op dezelfde richting. Ik gebruik trouwens de standaard sqlite database van HA. De last invoice date setting stond heel ver terug, daar had ik eigenlijk niet al te veel naar gekeken. Nu die goed staat lijkt het consequent goed te gaan. Heb het alleen nog maar een paar keer gedraaid sindsdien. Want stiekem mis ik toch de goede aansturing voor 2 boilers. Dat heb ik al helemaal goed ingericht voor EMHASS (daar is er standaard ook niks voor) en dat werkt goed. Maar daar geef ik gewoon aan hoeveel uur die moet lopen, dat kan in DAO ook wel met de machines en hun programs, maar dan moet ik heel veel programs gaan aanmaken en ik moet nog even door die zure appel heen bijten .

Ik hou DAO wel goed in de gaten, want de manier waarop de warmtepomp aansturing standaard gaat sluit weer beter op hoe ik het wel hebben (op basis van warmteverlies huis) dan hoe het in EMHASS geregeld is. Alleen het is nu niet echt warmtepomp weer, dus voor nu heb ik alleen de lasten van de overstap en niet de lusten. Dus als de winter komt ben ik snel meer gemotiveerd denk ik

[ Voor 5% gewijzigd door llevering op 02-05-2025 22:24 ]

[KC27]

llevering schreef op vrijdag 2 mei 2025 @ 22:23:
[...]


Nou ik denk dat ik het gevonden heb... En het feit dat het op een niet zo krachtige NUC voorkwam duidt op dezelfde richting. Ik gebruik trouwens de standaard sqlite database van HA. De last invoice date setting stond heel ver terug, daar had ik eigenlijk niet al te veel naar gekeken. Nu die goed staat lijkt het consequent goed te gaan. Heb het alleen nog maar een paar keer gedraaid sindsdien. Want stiekem mis ik toch de goede aansturing voor 2 boilers. Dat heb ik al helemaal goed ingericht voor EMHASS (daar is er standaard ook niks voor) en dat werkt goed. Maar daar geef ik gewoon aan hoeveel uur die moet lopen, dat kan in DAO ook wel met de machines en hun programs, maar dan moet ik heel veel programs gaan aanmaken en ik moet nog even door die zure appel heen bijten .

Ik hou DAO wel goed in de gaten, want de manier waarop de warmtepomp aansturing standaard gaat sluit weer beter op hoe ik het wel hebben (op basis van warmteverlies huis) dan hoe het in EMHASS geregeld is. Alleen het is nu niet echt warmtepomp weer, dus voor nu heb ik alleen de lasten van de overstap en niet de lusten. Dus als de winter komt ben ik snel meer gemotiveerd denk ik

Dat met die "last invoice" speelde daar ook. Dus ik zal een warning generen als die datum meer dan een jaar terug is.
Ik zal het kunnen configureren van meer dan een boiler opnemen op het wensenlijstje, maar dat 15min interval dat er aankomt heeft iets meer prio.

[llevering]

KC27 schreef op vrijdag 2 mei 2025 @ 22:33:
[...]

Dat met die "last invoice" speelde daar ook. Dus ik zal een warning generen als die datum meer dan een jaar terug is.
Ik zal het kunnen configureren van meer dan een boiler opnemen op het wensenlijstje, maar dat 15min interval dat er aankomt heeft iets meer prio.

Dat snap ik. Wat misschien een eenvoudigere tussenweg is... Dat je een machine zou kunnen hebben die naar een input number (in minuten denk ik) kijkt voor hoe lang het apparaat moet lopen. Is minder optimaal dan het verloop van het verschillende programma's maar wel heel flexibel. Maar sowieso geen haast

[storeman]

Ik heb het idee dat er iets niet helemaal goed gaat. Ik heb een accu, PV en boiler geconfigureerd. De optimalisatieslag geeft momenteel echter een negatieve opbrengst. Het grootste ding lijkt hoe de PV-opwek wordt weergegeven. Die macht niet tussen de verschillende grafieken.

[KC27]

storeman schreef op zaterdag 3 mei 2025 @ 08:26:
Ik heb het idee dat er iets niet helemaal goed gaat. Ik heb een accu, PV en boiler geconfigureerd. De optimalisatieslag geeft momenteel echter een negatieve opbrengst. Het grootste ding lijkt hoe de PV-opwek wordt weergegeven. Die macht niet tussen de verschillende grafieken.

[Afbeelding]

Kun je je battery instelling(en) en de log van de berekening (via Home\tabel) delen?

[storeman]

KC27 schreef op zaterdag 3 mei 2025 @ 10:12:
[...]

Kun je je battery instelling(en) en de log van de berekening (via Home\tabel) delen?

Jazeker. Het draait al een tijdje wel goed hoor, van de week de accu aangestuurd vanuit DAO, maar dat betreft een automation in HA.

code:

"battery": [{
      "name": "Dyness T7",
      "entity actual level": "sensor.growatt_stateofcharge",
      "capacity": 17,
      "lower limit": 32,
      "upper limit": 100,
      "optimal lower level": 32,
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 30.0,
          "efficiency": 0.95
        },
        {
          "power": 10000.0,
          "efficiency": 0.87
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 30.0,
          "efficiency": 0.95
        },
        {
          "power": 10000.0,
          "efficiency": 0.885
        }
      ],
      "minimum power": 0,
      "dc_to_bat efficiency": 0.95,
      "dc_to_bat max power": 10000.0,
      "bat_to_dc efficiency": 0.95,
      "bat_to_dc max power": 10000.0,
      "cycle cost": 0.04,
      "entity set power feedin": "input_number.dao_battery_discharge",
      "entity set operating mode": "input_select.dao_ess_operating_mode",
      "entity stop inverter": "input_datetime.dao_battery_inverter_stop",
      "entity balance switch": "input_boolean.dao_battery_balancing",
      "entity from battery": "input_number.dao_battery_discharge",
      "entity from pv": "input_number.dao_battery_charge_from_pv",
      "entity from ac": "input_number.dao_battery_charge_from_ac",
      "entity calculated soc": "input_number.dao_battery_end_of_hour_soc",
      "solar": [
        {
          "name": "Growatt PV1",
          "tilt": 35,
          "orientation": 55,
          "capacity": 9600,
          "yield": 0.024,
          "entity pv switch": "input_boolean.pv_enabled"
        }
      ]
    }

code:

 2025-05-03 12:00:00 info: Day Ahead Optimalisering versie: 2025.4.2
2025-05-03 12:00:00 info: Day Ahead Optimalisering gestart op: 03-05-2025 12:00:00
2025-05-03 12:00:00 info: Day Ahead Optimalisatie gestart: 03-05-2025 12:00:00 taak: calc_optimum
2025-05-03 12:00:00 info: Debug = False
2025-05-03 12:00:00 info: Zelf berekende baseload
2025-05-03 12:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    12 2025-05-03 12:00:00   0.15   0.15  -2.81      0   5.68
1    13 2025-05-03 13:00:00   0.14   0.14  -2.28      0   6.82
2    14 2025-05-03 14:00:00   0.14   0.14  -3.70      0   7.52
3    15 2025-05-03 15:00:00   0.15   0.15  -3.99      0   7.58
4    16 2025-05-03 16:00:00   0.15   0.15  -4.20      0   6.73
5    17 2025-05-03 17:00:00   0.18   0.18  -2.54      0   5.72
6    18 2025-05-03 18:00:00   0.22   0.22  -1.68      0   2.01
7    19 2025-05-03 19:00:00   0.24   0.24  -0.67      0   1.18
8    20 2025-05-03 20:00:00   0.25   0.25   0.43      0   0.55
9    21 2025-05-03 21:00:00   0.25   0.25   0.79      0   0.00
10   22 2025-05-03 22:00:00   0.26   0.26   0.73      0   0.00
11   23 2025-05-03 23:00:00   0.25   0.25   0.70      0   0.00
2025-05-03 12:00:00 info: Verbruik dit contractjaar: 435.782 kWh
2025-05-03 12:00:00 info: Productie dit contractjaar: 1296.512 kWh
2025-05-03 12:00:00 info: All taxes refund (alles wordt gesaldeerd)
2025-05-03 12:00:00 info: No reduced hours applied for Dyness T7
2025-05-03 12:00:00 info: Startwaarde SoC Dyness T7: 40.0%
2025-05-03 12:00:00 info: Boiler opwarmen wordt ingepland tussen: 12 en 12 uur
2025-05-03 12:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-05-03 12:00:00 info: Strategie: minimale kosten
2025-05-03 12:00:00 info: Het programma heeft een optimale oplossing gevonden.
2025-05-03 12:00:00 info: Geen saldeer correctie
2025-05-03 12:00:00 info: Niet geoptimaliseerd, kosten met reguliere tarieven: -26.25
2025-05-03 12:00:00 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -8.33 
2025-05-03 12:00:00 info: Geoptimaliseerd, kosten met day ahead tarieven: -8.45 
2025-05-03 12:00:00 info: Levering: 2.17   (kWh)
2025-05-03 12:00:00 info: Waarde boiler om 23 uur: 0.81 kWh
2025-05-03 12:00:00 info: In- en uitgaande energie per uur batterij Dyness T7
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
    12  -5.03  88.50  -5.68   5.68   0.00     --   0.00     --  40.00
    13  -0.03  95.00  -0.03   6.82   6.78  95.00   6.45     --  77.92
    14  -3.16  88.50  -3.57   7.52   3.95  95.00   3.75     -- 100.00
    15  -6.71  88.50  -7.58   7.58   0.00     --   0.00     -- 100.00
    16  -5.95  88.50  -6.73   6.73   0.00  95.00   0.00     -- 100.00
    17  -5.06  88.50  -5.72   5.72   0.00     --   0.00     -- 100.00
    18  -1.78  88.50  -2.01   2.01   0.00     --   0.00     -- 100.00
    19  -1.04  88.50  -1.18   1.18   0.00     --   0.00     -- 100.00
    20  -0.49  88.50  -0.55   0.55   0.00     --   0.00     -- 100.00
    21   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    22  -0.03  95.00  -0.03   0.00  -0.03  95.00  -0.03  90.25  99.80
    23  -0.03  95.00  -0.03   0.00  -0.03  95.00  -0.03  90.25  99.61
Totaal -29.31     -- -33.11  43.79  10.67     --  10.13     --       
2025-05-03 12:00:00 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 12.00    0.00     5.03   0.00   3.91  -2.81   3.93   0.00   0.00   0.00   0.00   -0.57  56.75
 13.00    0.00     0.03   0.00   2.31  -2.28   0.00   0.00   0.00   0.00   0.00   -0.33  56.50
 14.00    0.00     3.16   0.00   6.86  -3.70   0.00   0.00   0.00   0.00   0.00   -0.99  56.25
 15.00    0.00     6.71   0.00  10.70  -3.99   0.00   0.00   0.00   0.00   0.00   -1.58  56.00
 16.00    0.00     5.95   0.00  10.15  -4.20   0.00   0.00   0.00   0.00   0.00   -1.50  55.75
 17.00    0.00     5.06   0.00   7.60  -2.54   0.00   0.00   0.00   0.00   0.00   -1.37  55.50
 18.00    0.00     1.78   0.00   3.45  -1.68   0.00   0.00   0.00   0.00   0.00   -0.76  55.25
 19.00    0.00     1.04   0.00   1.71  -0.67   0.00   0.00   0.00   0.00   0.00   -0.41  55.00
 20.00    0.00     0.49   0.00   0.06   0.43   0.00   0.00   0.00   0.00   0.00   -0.02  54.75
 21.00    0.00     0.00   0.79   0.00   0.79   0.00   0.00   0.00   0.00   0.20   -0.00  54.50
 22.00    0.00     0.03   0.70   0.00   0.73   0.00   0.00   0.00   0.00   0.18   -0.00  54.25
 23.00    0.00     0.03   0.67   0.00   0.70   0.00   0.00   0.00   0.00   0.17   -0.00  54.00
Totaal    0.00    29.31   2.17  46.76 -19.21   3.93   0.00   0.00   0.00   0.55   -7.53       
2025-05-03 12:00:00 info: Winst: € 0.12
2025-05-03 12:00:00 info: Doorzetten van alle settings naar HA
2025-05-03 12:00:00 info: Boiler opwarmen geactiveerd
2025-05-03 12:00:00 info: Grid set point: -3913.0 W
2025-05-03 12:00:00 info: Cycle cost Dyness T7: 0.43 euro
2025-05-03 12:00:00 info: Netto vermogen naar(+)/uit(-) omvormer Dyness T7: -5029 W
2025-05-03 12:00:00 info: Balanceren: False
2025-05-03 12:00:00 info: Vermogen uit batterij: 0W
2025-05-03 12:00:00 info: Vermogen dat binnenkomt van pv: 5683W
2025-05-03 12:00:00 info: Vermogen dat binnenkomt van ac: -5683W
2025-05-03 12:00:00 info: Waarde SoC na eerste uur: 40.0%

[tonvanboven]

llevering schreef op vrijdag 2 mei 2025 @ 10:23:
[...]


Inmiddels op de nieuwste versie, zelfde resultaat nog.

code:

 2025-05-02 09:50:16 info: Day Ahead Optimalisering versie: 2025.4.2
2025-05-02 09:50:16 info: Day Ahead Optimalisering gestart op: 02-05-2025 09:50:16
2025-05-02 09:50:16 info: Day Ahead Optimalisatie gestart: 02-05-2025 09:50:16 taak: calc_optimum_met_debug
2025-05-02 09:50:16 info: Debug = True
2025-05-02 09:50:16 info: Baseload uit instellingen
2025-05-02 09:50:16 info: Start waarden: 
    uur                tijd      p_l      p_t  base     pv_ac  pv_dc
0     9 2025-05-02 09:00:00  0.24010  0.24010  0.40  0.227112      0
1    10 2025-05-02 10:00:00  0.14869  0.14869  0.40  1.856006      0
2    11 2025-05-02 11:00:00  0.14765  0.14765  0.40  2.206829      0
3    12 2025-05-02 12:00:00  0.14670  0.14670  0.40  2.469246      0
4    13 2025-05-02 13:00:00  0.14403  0.14403  0.40  3.543512      0
5    14 2025-05-02 14:00:00  0.14282  0.14282  0.40  3.385790      0
6    15 2025-05-02 15:00:00  0.14757  0.14757  0.40  3.225595      0
7    16 2025-05-02 16:00:00  0.14803  0.14803  0.40  2.971139      0
8    17 2025-05-02 17:00:00  0.22201  0.22201  0.90  2.660100      0
9    18 2025-05-02 18:00:00  0.26283  0.26283  0.25  2.189647      0
10   19 2025-05-02 19:00:00  0.27832  0.27832  0.25  0.138771      0
11   20 2025-05-02 20:00:00  0.31749  0.31749  0.25  0.058860      0
12   21 2025-05-02 21:00:00  0.29012  0.29012  0.20  0.053750      0
13   22 2025-05-02 22:00:00  0.27261  0.27261  0.17  0.043000      0
14   23 2025-05-02 23:00:00  0.25995  0.25995  0.17  0.032250      0

In de add-on log:

code:

[2025-05-02 09:49:54 +0200] [14] [INFO] Starting gunicorn 23.0.0
[2025-05-02 09:49:54 +0200] [14] [INFO] Listening at: http://0.0.0.0:5000 (14)
[2025-05-02 09:49:54 +0200] [14] [INFO] Using worker: sync
[2025-05-02 09:49:54 +0200] [28] [INFO] Booting worker with pid: 28
[2025-05-02 09:49:54 +0200] [29] [INFO] Booting worker with pid: 29
[2025-05-02 09:51:07 +0200] [14] [CRITICAL] WORKER TIMEOUT (pid:29)
[2025-05-02 09:51:07 +0200] [29] [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 246, in menu
    return run_process()
           ^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 375, 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-05-02 09:51:07 +0200] [29] [INFO] Worker exiting (pid: 29)
[2025-05-02 09:51:08 +0200] [38] [INFO] Booting worker with pid: 38

Heel soms zie ik ook meldingen over out-of-memory, dus ik heb alle andere add-ons gesloten, dan krijg ik geen out-of-memory melding maar ook geen berekening. Ik vrees dat de add-on te zwaar is voor mijn Odroid N2 (4gb), alhoewel de grafiek van geheugengebruik niet boven de 75% komt. Ik zou alleen niet weten waar het anders te zoeken.

Ik heb een HA Blue, dat is ook een odroid N2 met 4GB en heb de swapfile uit moeten breiden, zie de Increase Swap Add-on for Home Assistant Operating System (HAOS)

[Asclepius8]

Is het bezwaarlijk als DAO elk uur runt? Ik ben sinds een paar dagen hiermee aan de slag (PV 6,6+3,8 kWp en Deye 12kW/20kWh). Hij heeft met de standaard instellingen gerund om 14u en 15u.

[KC27]

Asclepius8 schreef op maandag 5 mei 2025 @ 15:54:
Is het bezwaarlijk als DAO elk uur runt? Ik ben sinds een paar dagen hiermee aan de slag (PV 6,6+3,8 kWp en Deye 12kW/20kWh). Hij heeft met de standaard instellingen gerund om 14u en 15u.

Het is juist de bedoeling om ieder uur te runnen.
Als er iets in de "omstandigheden" verandert worden die verwerkt in een nieuwe planning en er worden nieuwe settings doorgezet via Home Assistant naar de apparaten zoals je Deye.

[Asclepius8]

My bad, ik zie die xx00 calc optimum in de scheduler staan.

Hoe moet ik die savings interpreteren? Is dat voor de komende calculatie ? Hij verschilt nl. per uur nu..

[KC27]

Asclepius8 schreef op maandag 5 mei 2025 @ 16:10:
My bad, ik zie die xx00 calc optimum in de scheduler staan.

Hoe moet ik die savings interpreteren? Is dat voor de komende calculatie ? Hij verschilt nl. per uur nu..

Die savings van vandaag (met prognose) veranderen inderdaad ieder uur omdat hij een prognose maakt voor de uren die nog komen en de werkelijkheid is altijd anders dan de prognose. Maar natuurlijk liefst zo weinig mogelijk. Daarom is het belangrijk om de voorspelling van je pv, de inzet van je thuisbatterij, je baseload enz zo goed mogelijk te finetunen.
De savings van "gisteren" of "vorige week" mogen niet meer veranderen.

[storeman]

Hi KC27, als eerste nog eens dank voor al het werk dat je erin stopt. Echt een gave tool om een complex probleem benaderbaar te maken. Ik ben steeds meer bekend met verschillende onderdelen, maar loop ook nog tegen twee dingen/vragen aan.

Als eerste: de boiler. Vanuit de documentatie krijg ik niet helemaal helder hoe ik deze precies in moet regelen. Vannacht ging de WP (voor warm water) bijvoorbeeld aan, wat niet erg logisch was voor mij, dus waarschijnlijk heb ik verkeerde zaken ingesteld:
- doeltemp: 53
- hysterese: 3
- inschakelen onder: 45

Van mij mag de boiler afkoelen tot ca 40, maar vannacht ging hij dus aan omdat ie onder de 45 graden dook. Moet ik die hysterese dan op 13 zetten? (het zoekt lastig in dit topic met al die configs)

Ten tweede: stel, een 'machine' gaat aan met een programma van 4 uur. Weet DAO in het tweede uur van het draaiende programma dan dat dit programma draait? Als ik naar de inputs en outputs kijk, dan lijkt dat me niet zo waarschijnlijk en zal DAO in alle uren opnieuw proberen deze in te plannen, zolang binnen het gewenste time window?

[KC27]

storeman schreef op maandag 5 mei 2025 @ 20:46:
Hi KC27, als eerste nog eens dank voor al het werk dat je erin stopt. Echt een gave tool om een complex probleem benaderbaar te maken. Ik ben steeds meer bekend met verschillende onderdelen, maar loop ook nog tegen twee dingen/vragen aan.

Als eerste: de boiler. Vanuit de documentatie krijg ik niet helemaal helder hoe ik deze precies in moet regelen. Vannacht ging de WP (voor warm water) bijvoorbeeld aan, wat niet erg logisch was voor mij, dus waarschijnlijk heb ik verkeerde zaken ingesteld:
- doeltemp: 53
- hysterese: 3
- inschakelen onder: 45

Van mij mag de boiler afkoelen tot ca 40, maar vannacht ging hij dus aan omdat ie onder de 45 graden dook. Moet ik die hysterese dan op 13 zetten? (het zoekt lastig in dit topic met al die configs)

Ten tweede: stel, een 'machine' gaat aan met een programma van 4 uur. Weet DAO in het tweede uur van het draaiende programma dan dat dit programma draait? Als ik naar de inputs en outputs kijk, dan lijkt dat me niet zo waarschijnlijk en zal DAO in alle uren opnieuw proberen deze in te plannen, zolang binnen het gewenste time window?

Boiler
Als je doeltemperatuur 53 °C en je wilt het niet kouder laten worden dan 40 °C, dan zet je inderdaad de hysterese op 13 K. Als hij mag gaan verwarmen als de boiler onder de 45 °C is moet je kijken of er genoeg afkoeltijd is (ca 12 uur) tussen die 45 en 40 °C zodat je een periode hebt met lage prijzen. Anders zou ik daar meer tijd tussen maken door of die 45 hoger en/of die 40 lager te maken.
Bij mij zijn mijn settings:
- doeltemp: 55
- hysterese: 17
- inschakelen onder: 46
En ik krijg nu de melding in de logging: "Boiler opwarmen wordt ingepland tussen: 12 en 23 uur".
Dat is ruim voldoende om morgenmiddag tijdens de prijsdip op te warmen.

Machine
DAO leest de entities calculated start en calculated end en zal tijdens een berekeningrun in deze periode (als het goed is) geen nieuwe planning berekenen. Mocht dat wel zo zijn dan wil ik dat graag corrigeren, maar dan wel graag documenteren met settings, schermkopie van alle betrokken entities en eem kopie van de info-logging van de berekening.

[sailor_dg]

Was een tijdje geleden gestart met DAO, maar nooit doorgepakt omdat de EV en WP boiler ook prima met Nodered en eigen flow werkte. Nu komt er echter een batterij aan en wil ik de boel wat beter inrichten. Mooi om te zien hoe actief KC27 hiermee is.

Is het verwacht dat DAO geen oplossing vindt bij strategie minimize costs wanneer het boiler setpoint lager is dan de actuele temperatuur? Ik speel via automations met mijn setpoint, maar lijkt binnen DAO niet zo te werken.

[KC27]

sailor_dg schreef op maandag 5 mei 2025 @ 22:49:
Was een tijdje geleden gestart met DAO, maar nooit doorgepakt omdat de EV en WP boiler ook prima met Nodered en eigen flow werkte. Nu komt er echter een batterij aan en wil ik de boel wat beter inrichten. Mooi om te zien hoe actief KC27 hiermee is.

Is het verwacht dat DAO geen oplossing vindt bij strategie minimize costs wanneer het boiler setpoint lager is dan de actuele temperatuur? Ik speel via automations met mijn setpoint, maar lijkt binnen DAO niet zo te werken.

Als je zelf speelt met het setpoint dan speel je voor wat betreft de boiler zelf voor optimaliseringsberekening.
Ook als de boilertemperatuur boven het setpoint is zal DAO uitrekenen wanneer de "opwarmtemperatuur" wordt bereikt met jouw afkoelingssnelheid (cooling rate).
Maar ik zou een keuze maken:

• of je laat je boiler buiten DAO en regelt het zelf
• of je laat DAO de boiler beheren en blijft verder van de settings af met automations

[storeman]

@KC27 wat betreft de boiler, helder, dank! Ik heb een flink vat, dus dat komt wel goed. Eerder altijd aangestuurd met 'cheapest energy hours' script, en dat ging al best prima.

Wat betreft de machines: Die logica had ik niet bedacht, klinkt goed. Ik zal eea observeren.

[llevering]

Ben aardig te pakken genomen de afgelopen dagen doordat er in de documentatie onder 'Machines' '(optioneel)' staat achter 'entity calculated start' en 'entity calculated end'. Als je die twee weglaat krijg je een dikke foutmelding om je oren en is onduidelijk waar het vandaan komt.

code:

2025-05-06 09:16:42 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 480, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 411, in calc_optimum_met_debug
    dacalc.calc_optimum()
  File "/root/dao/prog/day_ahead.py", line 1713, in calc_optimum
    planned_end_str = self.get_state(ma_entity_plan_end[m]).state
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/states.py", line 15, in get_state
    return State(**self._get(f"states/{entity_id}"))  # type: ignore
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 54, in _get
    return self._process_response(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 90, in _process_response
    self._raise_error(response.status_code, response.url)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 95, in _raise_error
    raise error(f"{status_code} status code returned from {url}",)  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hassapi.exceptions.NotFound: 404 status code returned from http://supervisor/core/api/states/None
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3453, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3427, in main
    da_calc.run_task_function("calc_optimum_met_debug")
  File "/root/dao/prog/da_base.py", line 480, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 411, in calc_optimum_met_debug
    dacalc.calc_optimum()
  File "/root/dao/prog/day_ahead.py", line 1713, in calc_optimum
    planned_end_str = self.get_state(ma_entity_plan_end[m]).state
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/states.py", line 15, in get_state
    return State(**self._get(f"states/{entity_id}"))  # type: ignore
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 54, in _get
    return self._process_response(
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 90, in _process_response
    self._raise_error(response.status_code, response.url)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 95, in _raise_error
    raise error(f"{status_code} status code returned from {url}",)  # type: ignore
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hassapi.exceptions.NotFound: 404 status code returned from http://supervisor/core/api/states/None

Nu vraag je je misschien af waarom zou je die weglaten? Ik dacht begin simpel om te kijken of het werkt en bouw het dan uit dan is het makkelijker om fouten te vinden. In dit geval niet

[KC27]

Goed dat je me daarop wijst.
Die twee entities zijn inderdaad optioneel, MAAR een van de twee moet er wel zijn.
Ik zal het aanpassen in de code en de documentatie.

[storeman]

KC27 schreef op zaterdag 3 mei 2025 @ 10:12:
[...]

Kun je je battery instelling(en) en de log van de berekening (via Home\tabel) delen?

Ik geloof dat ik zie wat er speelt. Ik heb de baseloads op automatisch berekenen staan. Hierbij werden een aantal loads meegenomen die al wel geoptimaliseerd worden gebruikt. Bijvoorbeeld de vaatwasser wasmachine en wasdroger zetten we handmatig al ongeveer op het juiste moment aan. De WP werd ook extern ongeveer op het juiste moment gepland.

Ik heb nu weer handmatig een setje baseloads ingevoerd en de grafiekjes zien er weer vertrouwd uit.

[martinisoft]

Even een vraagje over de "entity balance switch".
Ik heb drie Sessy's in de DAO configuratie zitten en wil deze in NOM gaan sturen zodra deze switch is ingeschakeld.
Wat opvalt is dat er verschillen zitten in momenten waarop DAO de indivuele entity balance switches van de verschillende batterijen aan/uit zet.
Gevoelsmatig is er geen scenario waarbij het efficient is om de ene batterij in NOM te schakelen terwijl de ander aan het laden/ontladen is of zie ik dat verkeerd?
Ik weet dat ik één virtuele batterij kan maken maar ik probeer eerst even te begrijpen wat hier gebeurd en of ik zelf een denkfout maak.

[KC27]

martinisoft schreef op dinsdag 6 mei 2025 @ 15:14:
Even een vraagje over de "entity balance switch".
Ik heb drie Sessy's in de DAO configuratie zitten en wil deze in NOM gaan sturen zodra deze switch is ingeschakeld.
Wat opvalt is dat er verschillen zitten in momenten waarop DAO de indivuele entity balance switches van de verschillende batterijen aan/uit zet.
Gevoelsmatig is er geen scenario waarbij het efficient is om de ene batterij in NOM te schakelen terwijl de ander aan het laden/ontladen is of zie ik dat verkeerd?
Ik weet dat ik één virtuele batterij kan maken maar ik probeer eerst even te begrijpen wat hier gebeurd en of ik zelf een denkfout maak.

Daar kan ik zo niks over zeggen.
Zijn de settings van alle drie gelijk?
Zijn de start-waarden van de SoC's gelijk?
Wat ook kan: uit oogpunt van effiency van de laad/ontlaad vermogens kan het goedkoper zijn om een of twee constant te laden/ontladen of uit te zetten en de schommelingen met een of twee andere op te vangen.
Als iemand erin moet duiken is er nodig:

• de settings van de sessy's
• de log van de berekening
• en de grafiek (leest makkelijker)

[mgroen81]

martinisoft schreef op dinsdag 6 mei 2025 @ 15:14:
Even een vraagje over de "entity balance switch".
Ik heb drie Sessy's in de DAO configuratie zitten en wil deze in NOM gaan sturen zodra deze switch is ingeschakeld.
Wat opvalt is dat er verschillen zitten in momenten waarop DAO de indivuele entity balance switches van de verschillende batterijen aan/uit zet.
Gevoelsmatig is er geen scenario waarbij het efficient is om de ene batterij in NOM te schakelen terwijl de ander aan het laden/ontladen is of zie ik dat verkeerd?
Ik weet dat ik één virtuele batterij kan maken maar ik probeer eerst even te begrijpen wat hier gebeurd en of ik zelf een denkfout maak.

Ik heb het afgelopen jaar met mijn 3 Sessy's en settings nog nooit gezien dat de balance switch gebruikt werd. Wat mij logisch lijkt. Misschien dat er iets nog niet helemaal juist ingesteld staat bij je? Ik heb de cycle cost bijvoorbeeld op 0.03 staan.
Overigens stuur ik nu de 3 Sessy's in DAO als 1 accu aan. Mocht DAO besluiten dat NOM noodzakelijk is worden de Sessy's allemaal op XOM gezet (PimDoos).

[martinisoft]

Dank voor jullie reacties..

mgroen81 schreef op dinsdag 6 mei 2025 @ 22:10:
[...]

Ik heb het afgelopen jaar met mijn 3 Sessy's en settings nog nooit gezien dat de balance switch gebruikt werd. Wat mij logisch lijkt. Misschien dat er iets nog niet helemaal juist ingesteld staat bij je? Ik heb de cycle cost bijvoorbeeld op 0.03 staan.
Overigens stuur ik nu de 3 Sessy's in DAO als 1 accu aan. Mocht DAO besluiten dat NOM noodzakelijk is worden de Sessy's allemaal op XOM gezet (PimDoos).

Ik heb de configuratie momenteel op "minimize consumption" staan en zie wel dat de balance switch regelmatig wordt aan gezet (cycle cost staat hier op 0.01 maar ik vermoedt dat dit meer in de strategy zit). Het probleem wat ik voorzie met één virtuele Sessy is dat indien de onderlinge SoC's sterk verschillen er niks meer klopt van de DAO voorspellingen/berekeningen er vanuitgaande dat je DAO de gemiddelde SoC als input gaat geven. Immers klopt er nadat één of twee van de drie Sessy's de 0% of 100% bereikt het opgegeven maximale laad/ontlaad vermogen niet meer en dit is een belangrijke variable in de DAO berekening lijkt me. Daar komt bij dat als je XoM gaat draaien met PimDoos dan kunnen de onderlinge SoC's juist uiteen gaan lopen omdat er bij laag vermogen iedere dag een andere Sessy aan de beurt is om XoM te houden.
Met NoM van Sessy zelf gebeurd iets vergelijkbaars dus ook daar kunnen de onderlingen SoC's behoorlijk gaan verschillen.
Gevoelsmatig zou je daarom willen/verwachten dat verschillende balanceer switches van de drie batterijen synchroon lopen. Al snap ik dat er soms iets anders uit de berekening kan komen.
Momenteel draai ik nog altijd "droog" en stuur nog geen van mijn apparaten aan met DAO. Ik probeer eerst de zaak zo optimaal mogelijk in te regelen en te begrijpen voordat ik die stap ga maken.

Ik zal mijn config hieronder eens delen, en eens kijken of ik de info zoals gevraagd door Corneel bijelkaar kan sprokkelen.

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",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes delivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes redelivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier delivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.0182
    },
    "cost supplier redelivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.0182
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2025-04-16",
    "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 delivery": "True",
    "prices redelivery": "True",
    "average delivery": "True"
  },
  "strategy": "minimize consumption",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.mitsubishi_tank_water_temperature",
    "entity setpoint": "number.mitsubishi_set_tank_water_temperature",
    "entity hysterese": "sensor.mitsubishi_dhw_temperature_drop",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 47,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.dao_boiler_on_off"
  },
  "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": "Sessy1",
      "entity actual level": "sensor.sessy_d7dd_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "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":
       {  
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.01,
      "entity set power feedin": "input_number.dao_sessy_d7dd_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_d7dd_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_d7dd",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_d7dd",
      "entity from battery": "input_number.dao_sessy_d7dd_from_battery",
      "entity from pv": "input_number.dao_sessy_d7dd_from_pv",
      "entity from ac": "input_number.dao_sessy_d7dd_from_ac",
      "entity calculated soc": "input_number.dao_sessy_d7dd_calculated_soc",
      "solar": []
    },
    {
      "name": "Sessy2",
      "entity actual level": "sensor.sessy_dug7_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "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":
       {  
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.01,
      "entity set power feedin": "input_number.dao_sessy_dug7_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_dug7_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_dug7",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_dug7",
      "entity from battery": "input_number.dao_sessy_dug7_from_battery",
      "entity from pv": "input_number.dao_sessy_dug7_from_pv",
      "entity from ac": "input_number.dao_sessy_dug7_from_ac",
      "entity calculated soc": "input_number.dao_sessy_dug7_calculated_soc",
      "solar": []
    },
    {
      "name": "Sessy3",
      "entity actual level": "sensor.sessy_d47p_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "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":
       {  
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.01,
      "entity set power feedin": "input_number.dao_sessy_d47p_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_d47p_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_d47p",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_d47p",
      "entity from battery": "input_number.dao_sessy_d47p_from_battery",
      "entity from pv": "input_number.dao_sessy_d47p_from_pv",
      "entity from ac": "input_number.dao_sessy_d47p_from_ac",
      "entity calculated soc": "input_number.dao_sessy_d47p_calculated_soc",
      "solar": []
    }
 ],
  "solar": [
  {"name": "West",
    "tilt": 10,
    "orientation": 90,
    "capacity": 4.05,
    "yield": 0.00961875,
    "entity pv switch": "input_boolean.pv_west_aan_uit"
  },
  {"name": "Oost",
    "tilt": 10,
    "orientation": -90,
    "capacity": 3.645,
    "yield": 0.00820125,
    "entity pv switch": "input_boolean.pv_oost_aan_uit"
  }
 ],
  "electric vehicle": [
    {
      "name": "Tessie",
      "capacity": 75,
      "entity position": "sensor.evcharger_nmha_carlocation",
      "entity max amperage": "input_number.dao_tesla_max_amperage",
      "charge three phase": "True",
      "entity actual level": "sensor.battery_level_4",
      "entity plugged in": "binary_sensor.evcharger_nmha_charger_pluggedin",
      "charge stages" : [
        {"ampere": 0, "efficiency": 0.00},
        {"ampere": 6, "efficiency": 0.85},
        {"ampere": 7, "efficiency": 0.87},
        {"ampere": 8, "efficiency": 0.89},
        {"ampere": 9, "efficiency": 0.90},
        {"ampere": 10, "efficiency": 0.91},
        {"ampere": 11, "efficiency": 0.915},
        {"ampere": 12, "efficiency": 0.92},
        {"ampere": 13, "efficiency": 0.925},
        {"ampere": 14, "efficiency": 0.93},
        {"ampere": 15, "efficiency": 0.935},
        {"ampere": 16, "efficiency": 0.94}
      ],  
      "charge scheduler": {
        "entity set level": "input_number.dao_tesla_gewenste_soc",
        "level margin": 4,
        "entity ready datetime": "input_datetime.dao_tesla_klaar_met_laden"
      },
      "charge switch": "input_boolean.dao_evcharger_nmha_aan_uit",
      "entity set charging ampere" : "input_number.dao_tesla_set_charge_ampere"
    }
   ],
  "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": "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"
  }
}

[ Voor 100% gewijzigd door martinisoft op 07-05-2025 08:37 ]

[mgroen81]

@martinisoft A ja met minimize consumption is dat natuurlijk wel logisch. Ik ben het met je eens dat ze alledrie tegelijk op NOM gezet zouden moeten worden.

[martinisoft]

Omdat ik inmiddels helemaal opgehyped ben door DAO nog even een vraagje/brainfart aangaande de balanceer switch
In bijgevoegde afbeelding zie je duidelijk dat DAO in de uren aangeduidt met de pijlen het een goed idee vind om alle overtollige opwek van dat moment in de batterij te stoppen. Om dit te laten slagen moeten zowel de voorspelde opbrengst als verbruik in de praktijk uit komen. De batterij wordt immers voor een uur op een bepaald laadvermogen gezet toch? Zou het niet gaaf zijn als we ook op die momenten een seintje krijgen via de balanceer switch? We weten namelijk dat DAO op dat moment geen inkoop en geen verkoop wenst en dat resultaat is het beste te halen door de batterij zelf NoM te laten regelen (in mijn geval al dan niet via PimDoos)

[ErnstH]

martinisoft schreef op woensdag 7 mei 2025 @ 16:08:
[Afbeelding]

Omdat ik inmiddels helemaal opgehyped ben door DAO nog even een vraagje/brainfart aangaande de balanceer switch
In bijgevoegde afbeelding zie je duidelijk dat DAO in de uren aangeduidt met de pijlen het een goed idee vind om alle overtollige opwek van dat moment in de batterij te stoppen. Om dit te laten slagen moeten zowel de voorspelde opbrengst als verbruik in de praktijk uit komen. De batterij wordt immers voor een uur op een bepaald laadvermogen gezet toch? Zou het niet gaaf zijn als we ook op die momenten een seintje krijgen via de balanceer switch? We weten namelijk dat DAO op dat moment geen inkoop en geen verkoop wenst en dat resultaat is het beste te halen door de batterij zelf NoM te laten regelen (in mijn geval al dan niet via PimDoos)

Volgens mij doet hij dat al.

[martinisoft]

ErnstH schreef op woensdag 7 mei 2025 @ 17:01:
[...]

Volgens mij doet hij dat al.

Oeps, ik denk dat je gelijk hebt.. door de eerder genoemde verschillen tussen de drie batterijen die ik heb zag dit er even niet zo uit.. my bad

[balk]

martinisoft schreef op woensdag 7 mei 2025 @ 08:29:
Dank voor jullie reacties..

[...]

Ik heb de configuratie momenteel op "minimize consumption" staan en zie wel dat de balance switch regelmatig wordt aan gezet (cycle cost staat hier op 0.01 maar ik vermoedt dat dit meer in de strategy zit). Het probleem wat ik voorzie met één virtuele Sessy is dat indien de onderlinge SoC's sterk verschillen er niks meer klopt van de DAO voorspellingen/berekeningen er vanuitgaande dat je DAO de gemiddelde SoC als input gaat geven. Immers klopt er nadat één of twee van de drie Sessy's de 0% of 100% bereikt het opgegeven maximale laad/ontlaad vermogen niet meer en dit is een belangrijke variable in de DAO berekening lijkt me. Daar komt bij dat als je XoM gaat draaien met PimDoos dan kunnen de onderlinge SoC's juist uiteen gaan lopen omdat er bij laag vermogen iedere dag een andere Sessy aan de beurt is om XoM te houden.
Met NoM van Sessy zelf gebeurd iets vergelijkbaars dus ook daar kunnen de onderlingen SoC's behoorlijk gaan verschillen.
Gevoelsmatig zou je daarom willen/verwachten dat verschillende balanceer switches van de drie batterijen synchroon lopen. Al snap ik dat er soms iets anders uit de berekening kan komen.
Momenteel draai ik nog altijd "droog" en stuur nog geen van mijn apparaten aan met DAO. Ik probeer eerst de zaak zo optimaal mogelijk in te regelen en te begrijpen voordat ik die stap ga maken.

Ik zal mijn config hieronder eens delen, en eens kijken of ik de info zoals gevraagd door Corneel bijelkaar kan sprokkelen.

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",
    "regular high": 0.50,
    "regular low": 0.40,
    "switch to low": 23,
    "energy taxes delivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "energy taxes redelivery": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.10880,
      "2025-01-01": 0.10154
    },
    "cost supplier delivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.0182
    },
    "cost supplier redelivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.0182
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2025-04-16",
    "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 delivery": "True",
    "prices redelivery": "True",
    "average delivery": "True"
  },
  "strategy": "minimize consumption",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.mitsubishi_tank_water_temperature",
    "entity setpoint": "number.mitsubishi_set_tank_water_temperature",
    "entity hysterese": "sensor.mitsubishi_dhw_temperature_drop",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 47,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.dao_boiler_on_off"
  },
  "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": "Sessy1",
      "entity actual level": "sensor.sessy_d7dd_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "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":
       {  
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.01,
      "entity set power feedin": "input_number.dao_sessy_d7dd_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_d7dd_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_d7dd",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_d7dd",
      "entity from battery": "input_number.dao_sessy_d7dd_from_battery",
      "entity from pv": "input_number.dao_sessy_d7dd_from_pv",
      "entity from ac": "input_number.dao_sessy_d7dd_from_ac",
      "entity calculated soc": "input_number.dao_sessy_d7dd_calculated_soc",
      "solar": []
    },
    {
      "name": "Sessy2",
      "entity actual level": "sensor.sessy_dug7_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "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":
       {  
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.01,
      "entity set power feedin": "input_number.dao_sessy_dug7_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_dug7_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_dug7",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_dug7",
      "entity from battery": "input_number.dao_sessy_dug7_from_battery",
      "entity from pv": "input_number.dao_sessy_dug7_from_pv",
      "entity from ac": "input_number.dao_sessy_dug7_from_ac",
      "entity calculated soc": "input_number.dao_sessy_dug7_calculated_soc",
      "solar": []
    },
    {
      "name": "Sessy3",
      "entity actual level": "sensor.sessy_d47p_state_of_charge",
      "capacity": 5.5,
      "upper limit": 100,
      "lower limit": 0,
      "optimal lower level": 0,
      "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":
       {  
       },
      "minimum power": 100,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.01,
      "entity set power feedin": "input_number.dao_sessy_d47p_power_setpoint",
      "entity set operating mode": "input_select.dao_ess_d47p_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_sessy_d47p",
      "entity balance switch": "input_boolean.dao_balanceer_grid_sessy_d47p",
      "entity from battery": "input_number.dao_sessy_d47p_from_battery",
      "entity from pv": "input_number.dao_sessy_d47p_from_pv",
      "entity from ac": "input_number.dao_sessy_d47p_from_ac",
      "entity calculated soc": "input_number.dao_sessy_d47p_calculated_soc",
      "solar": []
    }
 ],
  "solar": [
  {"name": "West",
    "tilt": 10,
    "orientation": 90,
    "capacity": 4.05,
    "yield": 0.00961875,
    "entity pv switch": "input_boolean.pv_west_aan_uit"
  },
  {"name": "Oost",
    "tilt": 10,
    "orientation": -90,
    "capacity": 3.645,
    "yield": 0.00820125,
    "entity pv switch": "input_boolean.pv_oost_aan_uit"
  }
 ],
  "electric vehicle": [
    {
      "name": "Tessie",
      "capacity": 75,
      "entity position": "sensor.evcharger_nmha_carlocation",
      "entity max amperage": "input_number.dao_tesla_max_amperage",
      "charge three phase": "True",
      "entity actual level": "sensor.battery_level_4",
      "entity plugged in": "binary_sensor.evcharger_nmha_charger_pluggedin",
      "charge stages" : [
        {"ampere": 0, "efficiency": 0.00},
        {"ampere": 6, "efficiency": 0.85},
        {"ampere": 7, "efficiency": 0.87},
        {"ampere": 8, "efficiency": 0.89},
        {"ampere": 9, "efficiency": 0.90},
        {"ampere": 10, "efficiency": 0.91},
        {"ampere": 11, "efficiency": 0.915},
        {"ampere": 12, "efficiency": 0.92},
        {"ampere": 13, "efficiency": 0.925},
        {"ampere": 14, "efficiency": 0.93},
        {"ampere": 15, "efficiency": 0.935},
        {"ampere": 16, "efficiency": 0.94}
      ],  
      "charge scheduler": {
        "entity set level": "input_number.dao_tesla_gewenste_soc",
        "level margin": 4,
        "entity ready datetime": "input_datetime.dao_tesla_klaar_met_laden"
      },
      "charge switch": "input_boolean.dao_evcharger_nmha_aan_uit",
      "entity set charging ampere" : "input_number.dao_tesla_set_charge_ampere"
    }
   ],
  "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": "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"
  }
}

Ik heb in de xom automation staan dat mijn twee Sessy's elk uur moeten roteren, met {{ now().hour }}
Dan lopen de %es niet zo ver uiteen. Met 1 virtuele sessie gaat de berekening wel sneller dan met twee of drie losse Sessy's.
Edit: met {{ (now().minute // 15) }} roteer je vier keer per uur. Met drie Sessy's zou je // 20 kunnen doen

[DaBit]

Vraagje over die balanceer-switch. Die ging vandaag voor het eerst aan bij mij geloof ik:

code:

2025-05-07 14:01:29 info: Grid set point: 0.0 W
2025-05-07 14:01:29 info: Cycle cost Accu schuur: 0.86 euro
2025-05-07 14:01:29 info: Netto vermogen naar(+)/uit(-) omvormer Accu schuur: 7097 W
2025-05-07 14:01:29 info: Balanceren: True
2025-05-07 14:01:29 info: Vermogen uit batterij: -6430W
2025-05-07 14:01:29 info: Vermogen dat binnenkomt van pv: 0W
2025-05-07 14:01:29 info: Vermogen dat binnenkomt van ac: 6430W
2025-05-07 14:01:29 info: Waarde SoC na eerste uur: 87.1%

Wat nog niet helemaal goed uitpakte in mijn automaties die dat regelen; die verschuiven het regelpunt van de batterijklemmen (balanceerswitch uit) naar de binnenkomstpunt van het net (balanceerswitch aan).
Met de switch uit betekent '1000W' dus 1000W de batterij in, met de switch aan betekent '1000W' dus 1000W afnemen van het net.

DAO zegt 'Grid set point: 0.0 W', maar communiceerde vervolgens een power-feedin van 7097W, wat niet het beoogde effect sorteerde.



Is balance switch aan altijd 'Grid setpoint 0.0W'?

[ Voor 4% gewijzigd door DaBit op 07-05-2025 22:52 ]

[storeman]

@DaBit Ik ben hier ook over aan het peinzen en hoe jij het nu opschrijft, helpt dan weer met mijn gedachten. Ik denk dat ik zou zeggen dat als de Balance Switch aan staat, dat je de andere velden gewoon moet negeren. DAO zal wel een schatting maken (en dit publiceren) wat de gemiddelde ontlading zal zijn (dit zijn dan de interne prognoses).

Dus je zou kunnen zeggen:
- Indien balancing: zet batterij op neutral
- Anders: kijk naar de charge/discharge rates

Ik zit zelf met een PV-Battery-Growatt combinatie welke werkt met de termen `battery first` en `grid first`, ik krijg nog niet helemaal goed in mijn hoofd (en in HA) hoe dit precies moet gaan, maar door steeds weer eens te kijken en er over na te denken verwacht ik dat dat wel goed komt. Voor nu gaat het al best goed.

[mgroen81]

storeman schreef op zaterdag 3 mei 2025 @ 08:26:
Ik heb het idee dat er iets niet helemaal goed gaat. Ik heb een accu, PV en boiler geconfigureerd. De optimalisatieslag geeft momenteel echter een negatieve opbrengst. Het grootste ding lijkt hoe de PV-opwek wordt weergegeven. Die macht niet tussen de verschillende grafieken.

[Afbeelding]

Ik had 1 van de entiteiten van de pv niet goed staan. Daardoor waren de berekende baseloads bij mij overdag negatief geworden. Mijn grafiek leek op die van jou.
Misschien heb je een soortgelijk foutje?

voor:


na:

[ Voor 6% gewijzigd door mgroen81 op 08-05-2025 00:15 ]

[storeman]

@mgroen81 ik kwam erachter dat automatische baseload berekening het probleem was. De baseloads kwamen hierdoor veel te hoog uit. De wasmachine en wasdroger draaien vooral in het weekend en de boiler werd dagelijks ook aangestuurd ingeschakeld, maar DOA kon dat niet goed ontleden en nam dus veel te hoge baseloads waar.

Ik heb de baseloads weer handmatig ingevoerd tussen de 150-350 watt. Nu gaat het weer goed.

[DaBit]

storeman schreef op woensdag 7 mei 2025 @ 22:56:
Ik denk dat ik zou zeggen dat als de Balance Switch aan staat, dat je de andere velden gewoon moet negeren.

Ik zou zeggen van niet.

Ik kan me zo 1-2-3 geen scenario bedenken waarin het noodzaak is om de accu op net-balanceren te zetten met een ander setpoint dan 0.0W (nul-op-meter), maar dat wil niet zeggen dat die niet bestaan. Software behoort dat dus niet per definitie te blokkeren en kan net zo goed 0W doorgeven dan dat impliciet verwachten. Scheelt weer een breaking change later in het ontwikkelproces mocht toch iemand dat willen.

Maar @KC27 is de enige die de vraag echt kan beantwoorden.

[storeman]

DaBit schreef op donderdag 8 mei 2025 @ 12:08:
[...]


Ik zou zeggen van niet.

Ik kan me zo 1-2-3 geen scenario bedenken waarin het noodzaak is om de accu op net-balanceren te zetten met een ander setpoint dan 0.0W (nul-op-meter), maar dat wil niet zeggen dat die niet bestaan. Software behoort dat dus niet per definitie te blokkeren en kan net zo goed 0W doorgeven dan dat impliciet verwachten. Scheelt weer een breaking change later in het ontwikkelproces mocht toch iemand dat willen.

Maar @KC27 is de enige die de vraag echt kan beantwoorden.

Dat @KC27 dit als enige met zekerheid kan zeggen, eens (hij heeft een thumbs-up op mijn antwoord gegeven, dus dat zou je ook als bevestiging kunnen zien).

DAO probeert rekening te houden met de baseload, bij het maken van een prognose en geen andere verwachte loads, zou de `entity from battery` dus de baseload van dat uur geven, zolang je SoC boven het gewenste minimum zit. Als je in de `entity from battery` 0 zou zetten, suggereert dat je SoC niet verder daalt.

[KC27]

Ik zie nu wat het probleem is met de baseload berekening i.c.m. machines:
De baseload wordt berekend ZONDER rekening te houden met de inzet van de machines, zodat de baseload hoger wordt als er een machine draait zonder dat dat wordt gecorrigeerd.

Dat zal ik binnenkort gaan corrigeren. Liefst met een werkende meter voor iedere machine, maar misschien kan ik - bij het ontbreken van meters - het corrigeren uit de geprognotiseerde inzet van de machines.
Dat kost wel even tijd en ik ben al druk....

[llevering]

@KC27 EMHASS lost dit op door je een extra sensor te laten maken in HA waarin je alle regelbare load + zonneenergie + accu exclude. Dus 'pure' niet regelbare baseload. Jouw optie is eleganter, maar erg veel werk voor jou en je zal altijd zaken overhouden die je niet in beeld kan hebben. Ik zeg niet dat je het zo moet doen, maar het is een mogelijkheid

[Torch1969]

DaBit schreef op donderdag 8 mei 2025 @ 12:08:
[...]


Ik zou zeggen van niet.

Ik kan me zo 1-2-3 geen scenario bedenken waarin het noodzaak is om de accu op net-balanceren te zetten met een ander setpoint dan 0.0W (nul-op-meter), maar dat wil niet zeggen dat die niet bestaan. Software behoort dat dus niet per definitie te blokkeren en kan net zo goed 0W doorgeven dan dat impliciet verwachten. Scheelt weer een breaking change later in het ontwikkelproces mocht toch iemand dat willen.

Maar @KC27 is de enige die de vraag echt kan beantwoorden.

In DOCS.md staat:

code:

 entity balance switch: entiteit waarmee je Home Assistant 
in samenwerking met de omvormer op "balanceren" zet 
(overrult set power feedin)

Dat laatste suggereert wel dat je de power feedin moet negeren.

Er zijn trouwens wel scenario’s waarbij je niet rond 0.0W wilt regelen, maar rond een ander setpoint. Bijvoorbeeld als je ook EV aan het laden bent en niet wilt dat je thuisbatterij daarheen leegloopt. Dan zet je de setpoint op het laadvermogen van je EV. In de Sessy topics wordt dat XOM (X op meter) genoemd,waarbij X het setpoint is waaromheen je wilt balanceren.

[edterbak]

Hoi slimme mensen !

Ik heb een vraag. Ik ben aan het 'klooien' om DAO in te stellen.

Ik heb zonnepanelen erin staan, dit lijkt te werken, stroomprijzen ook. Grafiekjes komen binnen.
Maar nu heb ik een warmtepomp. Deze warmtepomp (lucht/water) wordt gebruikt voor DHW tank van 300L en (vloer) verwarming.

Hoe moet ik deze invoeren in de config?
Ik denk dat de DHW tank de 'boiler' is voor DAO, right?

code:

"boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.panasonic_heat_pump_main_dhw_temp",
    "entity setpoint": "number.panasonic_heat_pump_main_dhw_target_temp",
    "entity hysterese": "number.panasonic_heat_pump_main_dhw_heat_delta",
    "cop": 4.0,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 52,
    "elec. power": 2000,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"

entity hysterese: Moet dit de entiteit voor uitlezen of bediening zijn?
activate entity: nog te maken.

[storeman]

@edterbak dat moet inderdaad een boiler worden. DAO gebruikt de hysterese-waarde om te bepalen wanneer hij uiterlijk de boiler inschakelt via de activate entity.

Doelwaarde: 53
Hysterese: 13
Temp below: 46

Bovenstaande zegt eigenlijk dat verwarming van de boiler tussen de 40 en 46 graden wordt ingepland. Zodra deze onder de 40 komt, gaat ie meteen verwarmen.

De activate entity moet een automation triggeren en moet die input ook weer uitschakelen.

[martinisoft]

Boiler inderdaad, ik heb een vergelijkbare situatie, namelijk een 300liter DHW vat in de binnenunit van mijn Mitshubishi Ecodan Warmtepomp.
Omdat ik de warmtepomp beschikbaar heb ik HA en daardoor al entities heb voor zowel de actuele Boiler Temp, Setpoint en de Drop (Hysterese) kon ik deze rechtstreeks in de DAO config opnemen:

code:

"boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.mitsubishi_tank_water_temperature",
    "entity setpoint": "number.mitsubishi_set_tank_water_temperature",
    "entity hysterese": "sensor.mitsubishi_dhw_temperature_drop",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 47,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.dao_boiler_on_off"
  },

[DaBit]

Torch1969 schreef op donderdag 8 mei 2025 @ 22:47:
Dat laatste suggereert wel dat je de power feedin moet negeren.

Hmm, inderdaad. Documentatie lezen blijft lastig blijkbaar, excuses.

Bijvoorbeeld als je ook EV aan het laden bent en niet wilt dat je thuisbatterij daarheen leegloopt.

Mjah, waarschijnlijk had je dan relatief goedkoop ingeslagen en wil je wat er in de batterij zit spreiden over de 'duurdere' uren waarbij er dan een deel in de EV verdwijnt. Dan voldoet het feedin setpoint.
Maar je hebt wederom gelijk; er zijn scenarios te bedenken.

[sjampeter]

edterbak schreef op vrijdag 9 mei 2025 @ 00:33:
Hoi slimme mensen !

Ik heb een vraag. Ik ben aan het 'klooien' om DAO in te stellen.

Ik heb zonnepanelen erin staan, dit lijkt te werken, stroomprijzen ook. Grafiekjes komen binnen.
Maar nu heb ik een warmtepomp. Deze warmtepomp (lucht/water) wordt gebruikt voor DHW tank van 300L en (vloer) verwarming.

Hoe moet ik deze invoeren in de config?
Ik denk dat de DHW tank de 'boiler' is voor DAO, right?

code:

"boiler": {
    "boiler present": "True",
    "entity actual temp.": "sensor.panasonic_heat_pump_main_dhw_temp",
    "entity setpoint": "number.panasonic_heat_pump_main_dhw_target_temp",
    "entity hysterese": "number.panasonic_heat_pump_main_dhw_heat_delta",
    "cop": 4.0,
    "cooling rate": 0.4,
    "volume": 300,
    "heating allowed below": 52,
    "elec. power": 2000,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"

entity hysterese: Moet dit de entiteit voor uitlezen of bediening zijn?
activate entity: nog te maken.

ik heb deze via "machine" aangestuurd.
ik gebruik volgens mij dezelfde "heishamon" als jou.
DAO geeft dus een window wanneer het vat verwarmt mag worden.
deze starttijd koppel ik naar Node-red welke vervolgens Heishamon triggerd om dat vat te verwarmen.
draait redelijk probleemloos.

heb je hier wat aan?

[edterbak]

@sjampeter en @martinisoft
Wat is dan het verschil tussen de beide oplossingen? 'boiler' vs 'machine' oplossing....

Klopt het dat dit alleen het 'bewustzijn' van de actuele DHW temperatuur is?

[edit]

In de 'Boiler' optie; Het lijkt mij dat ik ipv daadwerkelijke entities, ook gewoon fixed getallen er in mag zetten toch?

[ Voor 25% gewijzigd door edterbak op 09-05-2025 19:48 ]