Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[edterbak]

Aanvullend heb ik het volgende scenario.

Ik heb een functie gemaakt, welke de p1 meter uitleest. De functie heet "Solar²DHW" (copyrighted, trademark, patented, licenced... )
Ik heb hiermee een logica gemaakt dat wanneer er X kWh het huishouden UIT gegaan is, dat dan de warmtepomp de overtollige energie in het warm water gaat steken.
Dit doet hij nu door het Target temp te verhogen, en de DHW run te starten.
Een plaatje zegt meer dan woorden....


Deze functie/logica, is heeft een ander doel / use-case dan de 'dagelijkse DHW tank verwarming' denk ik.
Dagelijkse verwarming vs overtollige energie benutten.

Iemand een idee hoe deze 2 use-cases naast elkaar kunnen bestaan?

[KC27]

edterbak schreef op vrijdag 9 mei 2025 @ 19:39:
@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?

Zo slim is DAO nog niet. Dat staat wel op mijn wensenlijstje maar eerst belangrijkere updates, zoals optionele overgang naar 15min resolutie. Die waarschijnlijk 11 juni ingaat.

[edterbak]

@KC27
Hoi. Ik begrijp je antwoord niet helemaal. sorry.
Hoe bedoel je 'zo slim'. Waar doel je precies op dat dao nog niet kan.

Mijn vraag welke je quote, gaat meer over wat effectief het verschil is tussen de door Sjampeter zijn 'machine' implementatie vs Martinisoft zijn 'Boiler' implementatie.
Zit er een verschil tussen? Is er een voorkeur voor de twee opties en zo ja waarom


Geen haast. Its done when its done.

[storeman]

De boiler kan rekening houden met een gewenste temperatuur en de verliezen, dat is dus wat intelligenter dan een machine.

Een boiler heeft namelijk een bepaalde hoeveelheid energie nodig die je kunt berekenen adhv de te verwarmen massa en het temperatuurverschil dat overbrugd moet worden. Een machine gaat domweg aan en draait zijn programma.

[edterbak]

duidelijk. thanks

[KC27]

edterbak schreef op vrijdag 9 mei 2025 @ 23:18:
@KC27
Hoi. Ik begrijp je antwoord niet helemaal. sorry.
Hoe bedoel je 'zo slim'. Waar doel je precies op dat dao nog niet kan.

Ik bedoelde jouw opmerking dat je in plaats van de naam van de entiteit met een getal direct een getal invult in de settings (als je weet dat ie -bijna- nooit verandert).

[Torch1969]

KC27 schreef op zaterdag 10 mei 2025 @ 08:48:
[...]

Ik bedoelde jouw opmerking dat je in plaats van de naam van de entiteit met een getal direct een getal invult in de settings (als je weet dat ie -bijna- nooit verandert).

+1 voor dit feature request 😀

[sjampeter]

edterbak schreef op vrijdag 9 mei 2025 @ 23:18:
@KC27
Hoi. Ik begrijp je antwoord niet helemaal. sorry.
Hoe bedoel je 'zo slim'. Waar doel je precies op dat dao nog niet kan.

Mijn vraag welke je quote, gaat meer over wat effectief het verschil is tussen de door Sjampeter zijn 'machine' implementatie vs Martinisoft zijn 'Boiler' implementatie.
Zit er een verschil tussen? Is er een voorkeur voor de twee opties en zo ja waarom


Geen haast. Its done when its done.

heishamon is bij mij leidend qua verwarmen boilervat.
het enige wat ik zocht was een trigger wanneer dit het goedkoopst kan.
deze kan "machine" perfect leveren
mocht mijn warmtepomp of boiler minder intelligent zijn, zou ik inderdaad voor optie "boiler" gaan.
dit is echter in mjin geval niet nodig.

[edterbak]

sjampeter schreef op zaterdag 10 mei 2025 @ 13:54:
[...]


heishamon is bij mij leidend qua verwarmen boilervat.
het enige wat ik zocht was een trigger wanneer dit het goedkoopst kan.
deze kan "machine" perfect leveren
mocht mijn warmtepomp of boiler minder intelligent zijn, zou ik inderdaad voor optie "boiler" gaan.
dit is echter in mjin geval niet nodig.

Mag ik jou stukje code van "machine" lenen? Ik ben benieuwd hoe je die invult

[sjampeter]

code:

"machines" : [
    { "name": "warmtepomp",
        "programs":[
        {"name": "SWW uit",
        "power": []},
        {"name": "SWW aan",
        "power": [1700, 1700, 1700, 1700, 1700, 1700, 1700, 1700,1700]
        } 
        ],
        "entity start window": "input_datetime.start_window_warmtepomp",
        "entity end window": "input_datetime.end_window_warmtepomp",
        "entity selected program": "input_select.program_warmtepomp",
        "entity calculated start": "input_datetime.calculated_start_warmtepomp",
        "entity calculated end": "input_datetime.calculated_stop_warmtepomp"
    } ],

er rolt dus een starttijd uit. deze lees ik in via node-red en deze gooit de dhw aan. overigens zou het mooi zijn als we dit goed implementeren in heishamon, maar dat doen we wel in het juiste draadje. werkt nu nogal via een omweg.

[ Voor 15% gewijzigd door sjampeter op 10-05-2025 14:09 ]

[Torch1969]

sjampeter schreef op zaterdag 10 mei 2025 @ 14:07:

code:

"machines" : [
    { "name": "warmtepomp",
        "programs":[
        {"name": "SWW uit",
        "power": []},
        {"name": "SWW aan",
        "power": [1700, 1700, 1700, 1700, 1700, 1700, 1700, 1700,1700]
        } 
        ],
        "entity start window": "input_datetime.start_window_warmtepomp",
        "entity end window": "input_datetime.end_window_warmtepomp",
        "entity selected program": "input_select.program_warmtepomp",
        "entity calculated start": "input_datetime.calculated_start_warmtepomp",
        "entity calculated end": "input_datetime.calculated_stop_warmtepomp"
    } ],

er rolt dus een starttijd uit. deze lees ik in via node-red en deze gooit de dhw aan. overigens zou het mooi zijn als we dit goed implementeren in heishamon, maar dat doen we wel in het juiste draadje. werkt nu nogal via een omweg.

Je hebt een programma van 9 kwartier geconfigureerd. Komt dan dan overeen met de verwarmingsrun van je boiler?

[Asclepius8]

Ik zit verder te spelen met DAO.. ik laat DAO mijn batterij (20kWh) besturen, maar: dat doet hij enkel gebaseerd op prijs. Hoe kan ik ervoor zorgen (welke entity of welke combinatie)? dat buiten die momenten (die ik dus niet van te voren weet) de overige zonne-energie juist wel in mijn batterij laat lopen?

Als voorbeeld: morgen staat dat hij om 12u vol de batterij vol moet gooien (want flink negatieve prijs). Daarvoor leveren mijn panelen al terug, die energie zou ik liever direct de batterij in sturen, want die energie is alsnog goedkoper dan de negatieve prijs. Ik kan in node-red dat prima besturen, maar op een gegeven moment neemt DAO die besturing (lees setpoint) over.. hoe dat goed te maken?

[sjampeter]

Torch1969 schreef op zaterdag 10 mei 2025 @ 15:31:
[...]

Je hebt een programma van 9 kwartier geconfigureerd. Komt dan dan overeen met de verwarmingsrun van je boiler?

correct. een volledige dagelijkse run duurt ongeveer 2 uur.
feitelijk varieert dit natuurlijk wel afhankelijk van hoeveel water er verbruikt is.
ik gebruik enkel de berekende starttijd.
in theorie zou de warmptepomp ook bijvoorbeeld 4 uur kunnen draaien.
deze wordt niet "uitgezet" door DAO. hier zorgt de eigen besturing van de wp (heishamon) voor.
voor de berekening van het beste moment van starten komt deze 9 kwartier eigenlijk altijd wel uit.

[Faceless]

Asclepius8 schreef op zaterdag 10 mei 2025 @ 16:50:
Als voorbeeld: morgen staat dat hij om 12u vol de batterij vol moet gooien (want flink negatieve prijs). Daarvoor leveren mijn panelen al terug, die energie zou ik liever direct de batterij in sturen, want die energie is alsnog goedkoper dan de negatieve prijs. Ik kan in node-red dat prima besturen, maar op een gegeven moment neemt DAO die besturing (lees setpoint) over.. hoe dat goed te maken?

Deze redernatie snap ik niet.

De opbrengst van de zonnepanelen vóór de negatieve tarieven zijn geld waard, die wil je het grid op sturen.

Zodra er negatieve prijzen zijn, moet je geld bijleggen om ze het grid op te sturen en dus wil je juist die opbrengst in de batterijen stoppen.

Maar misschien mis ik iets.

[balk]

Mijn strategie voor vandaag is
- accu is leeg en idle tot twaalf uur (normaal draai ik nom wanneer DAO op 0 staat) . Zon overschot gaat dus het net op
- vullen vanaf twaalf uur en panelen uit
- panelen weer bij als de prijs negatief is. Op dat moment zal de accu ook vol zijn
- vanavond ontladen

Dit is volgens mij het maximale wat ik kan doen, los van onbalans handel

[M66B]

balk schreef op zondag 11 mei 2025 @ 06:34:
Mijn strategie voor vandaag is
- accu is leeg en idle tot twaalf uur (normaal draai ik nom wanneer DAO op 0 staat) . Zon overschot gaat dus het net op
- vullen vanaf twaalf uur en panelen uit
- panelen weer bij als de prijs negatief is. Op dat moment zal de accu ook vol zijn
- vanavond ontladen

Dit is volgens mij het maximale wat ik kan doen, los van onbalans handel

Heb je er rekening mee gehouden dat de prijs negatief is van 11:00-16:00 voor mensen die hun verbruik al gesaldeerd hebben? Vast wel denk ik, dus dan is dit meer een algemene opmerking.

[storeman]

@M66B nog nooit zo over nagedacht. Komt dat dan doordat je daar geen energiebelasting over terugkrijgt?

[M66B]

storeman schreef op zondag 11 mei 2025 @ 09:20:
@M66B nog nooit zo over nagedacht. Komt dat dan doordat je daar geen energiebelasting over terugkrijgt?

Inderdaad, het scheelt 12,3 cent energiebelasting (plus BTW) die je niet (meer) terugkrijgt.

Bij bijvoorbeeld Tibber zie je dit pas na een jaar op de eindafrekening, die je dan wat kan verrassen ...

Edit: het afname- (inkoop) en teruglevertarief (verkoop) zijn dus verschillend in deze situatie.

[ Voor 10% gewijzigd door M66B op 11-05-2025 09:28 ]

[KC27]

Asclepius8 schreef op zaterdag 10 mei 2025 @ 16:50:
Ik zit verder te spelen met DAO.. ik laat DAO mijn batterij (20kWh) besturen, maar: dat doet hij enkel gebaseerd op prijs. Hoe kan ik ervoor zorgen (welke entity of welke combinatie)? dat buiten die momenten (die ik dus niet van te voren weet) de overige zonne-energie juist wel in mijn batterij laat lopen?

Als voorbeeld: morgen staat dat hij om 12u vol de batterij vol moet gooien (want flink negatieve prijs). Daarvoor leveren mijn panelen al terug, die energie zou ik liever direct de batterij in sturen, want die energie is alsnog goedkoper dan de negatieve prijs. Ik kan in node-red dat prima besturen, maar op een gegeven moment neemt DAO die besturing (lees setpoint) over.. hoe dat goed te maken?

Als je DAO je accu willen laten besturen en je wilt zo weinig mogelijk inkopen, kun je de strategie "minimize consumption" kiezen. Je zou eens een proefberekening met die strategie kunnen maken en kijken hoe dit voor jou uitpakt:

• strategie aanpassen
• Run "Optimaliseringsberekening met debug"
• kijk hoe het uitpakt
• en als het niet bevalt zet je de strategie weer terug.

[simnet]

Hallo,

Ik heb intussen DAO een paar dagen draaien en ik merk dat een calculatie erg lang duurt (tenminste, dat lijkt zo).

Het duurt ongeveer 25 seconden voordat de run klaar is. Nu is dat niet heel erg, maar wie weet heeft iemand hier nog tips.

Info over mijn systeem:
- Intel N4500 dualcore, 1.1GHZ, 16G mem, intel nvme ssd
- Homeassistant Core container draaiend via podman, database in sqlite
- DAO 2025.4.2 container build volgens instructies in TS, draaiend via podman
- PV van Enphase, AC coupled over 3 fasen,
- Batterij van Marstek, aangesloten op fase C
- Geen tibber account en pas over 2 maanden een dynamisch contract, dus voor nu kan ik prima spelen, zonder financiele consequenties
- Tijdens een run staat het python proces op vrijwel 100% cpu user, geen iowait (dus lijkt het me geen io probleem).


De sqlite db van homeassistant is erg groot aan het worden (bijna 4GB) en ik zit na te denken om de recorder om te zetten naar influxdb. Ik geloof dat dit nog niet ondersteund wordt door DAO, dus hier wacht ik nog even mee. Ik ben daarnaast ook huiverig voor het verlies van historische data, die ik eigenlijk niet kwijt wil...

Voordat ik dus iets doe, wil ik kijken of DAO niet ergens kan optimaliseren.
Ergens tussen de baseload en output van de run, zijn er 23 seconden waarvan ik niet kan zien wat er gebeurd. Dat gat is overigens vrij consistent en wijkt maar met + of - 1 seconde af tussen runs.
In dit geval mis ik dus eigenlijk nog een trace output mode.

Hopelijk hebben mensen hier nog goede ideeen. Alvast bedankt voor het meedenken!


Mijn config:

code:

{
  "homeassistant": {
    "protocol api": "http",
    "ip adress": "127.0.0.1",
    "ip port": 8123,
    "token": "!secret ha_api_token"
  },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine": "sqlite",
    "db_path": "../data"
  },
  "meteoserver-key": "!secret meteoserver-key",
  "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.020496
    },
    "cost supplier redelivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2024-06-15",
    "tax refund": "False"
  },
  "logging level" : "info",
  "use_calc_baseload": "True",
  "baseload calc periode": 56,
  "baseload": [
    0.14,
    0.38,
    0.26,
    0.42,
    0.15,
    0.12,
    0.13,
    0.15,
    0.23,
    0.26,
    0.31,
    0.32,
    0.31,
    0.23,
    0.26,
    0.21,
    0.21,
    0.54,
    0.26,
    0.26,
    0.22,
    0.19,
    0.18,
    0.16
  ],
  "graphical backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "show" : "True",
    "battery balance": "True",
    "prices delivery": "True",
    "prices redelivery": "True",
    "average delivery": "True"
  },
  "strategy": "minimize consumption",
  "notifications": {
     "notification entity": "input_text.dao_notification",
     "opstarten": "True",
     "berekening": "True",
     "last activity entity": "input_datetime.dao_last_activity"
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5001
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
   {
      "name": "Marstek P3",
      "entity actual level": "sensor.marstek_battery_state_of_charge",
      "capacity": 5,
      "upper limit": 100,
      "lower limit": 11,
      "optimal lower level": 21,
      "entity min soc end opt": "input_number.dao_marstek_p3_min_soc_end_opt",
      "entity max soc end opt": "input_number.dao_marstek_p3_max_soc_end_opt",
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 2500.0,
          "efficiency": 0.885
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 2500.0,
          "efficiency": 0.885
        }
      ],
      "minimum power": 10,
      "dc_to_bat efficiency": 0.93,
      "bat_to_dc efficiency": 0.93,
      "cycle cost": 0.0065,
      "entity set power feedin": "input_number.dao_marstek_p3_feedin_grid_power",
      "entity set operating mode": "input_select.dao_marstek_p3_mode",
      "entity stop inverter": "input_datetime.dao_marstek_p3_stop_inverter",
      "entity balance switch": "input_boolean.dao_marstek_p3_balance_mode",
      "entity from ac": "input_number.dao_marstek_p3_charge_discharde_rate",
      "entity calculated soc": "input_number.dao_marstek_p3_calculates_soc_end_of_this",
      "solar": []
   }
  ],
  "solar": [
    { "name" : "dak woning",
    "tilt": 35,
    "orientation": 5,
    "capacity": 4.5,
    "yield": 0.009,
    "entity pv switch": "input_boolean.dao_pv_dak_on_off"
  }],
  "electric vehicle": [ ],
  "machines" : [
      { "name": "wasmachine",
        "programs":[
          {"name": "uit",
           "power": []},
          {"name": "30 graden",
           "power": [2000, 1500, 500, 400, 200, 300]
           },
          {"name": "wolwas",
           "power": [1500, 1000, 500, 400, 200, 300,200, 300]
           }
        ],
        "entity start window": "input_datetime.dao_start_window_wasmachine",
        "entity end window": "input_datetime.dao_end_window_wasmachine",
        "entity selected program": "input_select.dao_program_wasmachine",
        "entity calculated start": "input_datetime.dao_calculated_start_wasmachine",
        "entity calculated end": "input_datetime.dao_calculated_stop_wasmachine"
      },
      { "name": "vaatwasser",
        "programs":[
          {"name": "off",
           "power": []},
          {"name": "eco",
           "power": [2000, 2000, 1500, 1000, 500, 500, 1000, 1000]
           }
        ],
        "entity start window": "input_datetime.dao_start_window_vaatwasser",
        "entity end window": "input_datetime.dao_end_window_vaatwasser",
        "entity selected program": "input_select.dao_program_vaatwasser",
        "entity calculated start": "input_datetime.dao_calculated_start_vaatwasser",
        "entity calculated end": "input_datetime.dao_calculated_stop_vaatwasser"
      }
  ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.energy_consumption_tarif_1",
      "sensor.energy_consumption_tarif_2"
    ],
    "entities grid production": [
      "sensor.energy_production_tarif_1",
      "sensor.energy_production_tarif_2"
    ],
    "entities solar production ac": [
      "sensor.total_solar_production_roof"
    ],
    "entities battery consumption": [ "sensor.marstek_daily_charging_energy" ],
    "entities battery production": [ "sensor.marstek_daily_discharging_energy" ],
    "entity co2-intensity": ["sensor.co2_intensity"],
    "entities solar production dc": [],
    "entities ev consumption" : [],
    "entities wp consumption" : [],
    "entities boiler consumption": []
  },
  "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",
    "0930": "calc_baseloads"
  }
}

Debug log van een recente run:

code:

2025-05-11 11:30:06 info: Day Ahead Optimalisering versie: 2025.4.2
2025-05-11 11:30:06 info: Day Ahead Optimalisering gestart op: 11-05-2025 11:30:06
2025-05-11 11:30:06 info: Day Ahead Optimalisatie gestart: 11-05-2025 11:30:06 taak: calc_optimum_met_debug
2025-05-11 11:30:06 info: Debug = True
2025-05-11 11:30:07 info: Zelf berekende baseload
2025-05-11 11:30:07 info: Start waarden: 
    uur                tijd      p_l      p_t   base     pv_ac  pv_dc
0    11 2025-05-11 11:00:00  0.06609  0.06609  0.602  1.277738      0
1    12 2025-05-11 12:00:00 -0.23847 -0.23847  0.566  2.947107      0
2    13 2025-05-11 13:00:00 -0.27584 -0.27584  0.692  3.116180      0
3    14 2025-05-11 14:00:00 -0.21525 -0.21525  0.802  3.051900      0
4    15 2025-05-11 15:00:00  0.01461  0.01461  0.409  2.741059      0
5    16 2025-05-11 16:00:00  0.12534  0.12534  0.539  2.229218      0
6    17 2025-05-11 17:00:00  0.14752  0.14752  1.385  1.717403      0
7    18 2025-05-11 18:00:00  0.24085  0.24085  0.646  1.131061      0
8    19 2025-05-11 19:00:00  0.28312  0.28312  0.526  0.532950      0
9    20 2025-05-11 20:00:00  0.29874  0.29874  0.461  0.113396      0
10   21 2025-05-11 21:00:00  0.28718  0.28718  0.453  0.000000      0
11   22 2025-05-11 22:00:00  0.26679  0.26679  0.416  0.000000      0
12   23 2025-05-11 23:00:00  0.25013  0.25013  0.366  0.000000      0
2025-05-11 11:30:30 info: Verbruik dit contractjaar: 2097.049 kWh
2025-05-11 11:30:30 info: Productie dit contractjaar: 3771.928 kWh
2025-05-11 11:30:30 info: All taxes refund (alles wordt gesaldeerd)
2025-05-11 11:30:31 info: No reduced hours applied for Marstek P3
2025-05-11 11:30:31 info: Startwaarde SoC Marstek P3: 95.0%
2025-05-11 11:30:31 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-05-11 11:30:31 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-05-11 11:30:31 info: Machine wasmachine wordt niet ingepland, want 2025-05-11 23:59:00 ligt voorbij de planningshorizon 23
2025-05-11 11:30:31 info: Machine wasmachine wordt niet ingepland, want er is gekozen voor uit
2025-05-11 11:30:31 info: Machine vaatwasser wordt niet ingepland, want 2025-05-11 23:59:00 ligt voorbij de planningshorizon 23
2025-05-11 11:30:31 info: Machine vaatwasser wordt niet ingepland, want er is gekozen voor uit
2025-05-11 11:30:31 info: Eerste berekening
2025-05-11 11:30:31 info: Kosten (euro): 1.26  
2025-05-11 11:30:31 info: Levering (kWh): 0.00  
2025-05-11 11:30:31 info: Herberekening
2025-05-11 11:30:31 info: Kosten (euro): -0.61 
2025-05-11 11:30:31 info: Levering (kWh): 0.00  
2025-05-11 11:30:31 info: Strategie: minimale levering
2025-05-11 11:30:31 info: Het programma heeft een optimale oplossing gevonden.
2025-05-11 11:30:31 info: Geen saldeer correctie
2025-05-11 11:30:31 info: Niet geoptimaliseerd, kosten met reguliere tarieven: -6.67 
2025-05-11 11:30:31 info: Niet geoptimaliseerd, kosten met day ahead tarieven: 1.70  
2025-05-11 11:30:31 info: Geoptimaliseerd, kosten met day ahead tarieven: -0.61 
2025-05-11 11:30:31 info: Levering: 0.00   (kWh)
2025-05-11 11:30:31 info: In- en uitgaande energie per uur batterij Marstek P3
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
    11  -1.10  88.50  -1.25   0.00  -1.25  93.00  -1.34  82.31  68.21
    12  -0.57  88.50  -0.64   0.00  -0.64  93.00  -0.69  82.31  54.45
    13  -0.69  88.50  -0.78   0.00  -0.78  93.00  -0.84  82.31  37.64
    14   2.25  88.50   1.99   0.00   1.99  93.00   1.85  82.31  74.67
    15   1.54  88.50   1.36   0.00   1.36  93.00   1.27  82.30 100.00
    16   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    17   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    18   0.00     --   0.00   0.00   0.00     --   0.00     -- 100.00
    19   0.00     --   0.00   0.00   0.00 107.53   0.00     -- 100.00
    20  -2.21  88.50  -2.50   0.00  -2.50  93.00  -2.69  82.31  46.24
    21  -0.62  88.50  -0.70   0.00  -0.70  93.00  -0.76  82.31  31.11
    22  -0.42  88.50  -0.47   0.00  -0.47  93.00  -0.51  82.30  21.00
    23  -0.41  88.50  -0.47   0.00  -0.47  93.00  -0.50  82.31  11.00
Totaal  -2.23     --  -3.45   0.00  -3.45     --  -4.20     --       
2025-05-11 11:30:31 info: Berekende prognoses zijn niet opgeslagen.
2025-05-11 11:30:31 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem   mach
 11.00    0.00     1.10   0.00   2.08   0.60   0.00   0.00   0.00   1.28   0.00   -0.14  20.00   0.00
 12.00    0.00     0.57   0.00  -0.00   0.57   0.00   0.00   0.00   0.00  -0.00    0.00  20.00   0.00
 13.00    0.00     0.69   0.00  -0.00   0.69   0.00   0.00   0.00   0.00  -0.00    0.00  20.00   0.00
 14.00    2.25     0.00   0.00  -0.00   0.80   0.00   0.00   0.00   3.05  -0.00    0.00  20.00   0.00
 15.00    1.54     0.00   0.00   0.79   0.41   0.00   0.00   0.00   2.74   0.00   -0.01  20.00   0.00
 16.00    0.00     0.00   0.00   1.69   0.54   0.00   0.00   0.00   2.23   0.00   -0.21  20.00   0.00
 17.00    0.00     0.00   0.00   0.33   1.39   0.00   0.00   0.00   1.72   0.00   -0.05  20.00   0.00
 18.00    0.00     0.00   0.00   0.49   0.65   0.00   0.00   0.00   1.13   0.00   -0.12  20.00   0.00
 19.00    0.00     0.00   0.00   0.01   0.53   0.00   0.00   0.00   0.53   0.00   -0.00  20.00   0.00
 20.00    0.00     2.21   0.00   1.86   0.46   0.00   0.00   0.00   0.11   0.00   -0.56  20.00   0.00
 21.00    0.00     0.62   0.00   0.17   0.45   0.00   0.00   0.00   0.00   0.00   -0.05  20.00   0.00
 22.00    0.00     0.42   0.00  -0.00   0.42   0.00   0.00   0.00   0.00   0.00   -0.00  20.00   0.00
 23.00    0.00     0.41   0.00   0.05   0.37   0.00   0.00   0.00   0.00   0.00   -0.01  20.00   0.00
Totaal    3.79     6.02   0.00   7.47   7.86   0.00   0.00   0.00  12.79   0.00   -1.15          0.00
2025-05-11 11:30:31 info: Winst: € 2.31
2025-05-11 11:30:31 info: Onderstaande settings worden NIET doorgezet naar HA
2025-05-11 11:30:31 info: PV dak woning zou zijn aangezet
2025-05-11 11:30:31 info: Grid set point: -4175.0 W
2025-05-11 11:30:31 info: Cycle cost Marstek P3: 0.07 euro
2025-05-11 11:30:31 info: Netto vermogen naar(+)/uit(-) batterij Marstek P3 zou zijn: -2212 W
2025-05-11 11:30:31 info: Balanceren zou zijn: False
2025-05-11 11:30:31 info: Apparaat: wasmachine
2025-05-11 11:30:31 info: Programma: uit
2025-05-11 11:30:31 info: Apparaat: vaatwasser
2025-05-11 11:30:31 info: Programma: uit

[sjampeter]

ik krijg nog steeds mijn report niet voor elkaar.
nu is het zo, dat ik meerdere meters heb. een pap en een sap.
zit er een maximum aantal sensoren op bijvoorbeeld " entities grid production" ?

code:

"report": {
    "entities grid consumption":["sensor.p1_sap_totaal_verbruik_tarief_2",
                                 "sensor.p1_sap_totaal_verbruik_tarief_1",
                                 "sensor.p1_pap_totaal_verbruik_tarief_2",
                                 "sensor.p1_pap_totaal_verbruik_tarief_1"],
    "entities grid production": ["sensor.p1_sap_totaal_teruglevering_tarief_2",
                                 "sensor.p1_sap_totaal_teruglevering_tarief_1",
                                 "sensor.p1_pap_totaal_teruglevering_tarief_2",
                                 "sensor.p1_pap_totaal_teruglevering_tarief_1"],
    "entities solar production ac": ["sensor.solarman_total_production",
                                     "sensor.totale_levering_solar_in_kwh"],
    "entities solar production dc": [],
    "entities ev consumption" : [],
    "entities wp consumption" : ["sensor.aquarea_pump_total_consumption_total"],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.victron_vebus_acin1toinverter_227"], 
    "entities battery production":  ["sensor.victron_vebus_invertertoacin1_227"]
    },

[simnet]

Debug log van een recente run:

code:

2025-05-11 11:30:07 info: Start waarden: 
    uur                tijd      p_l      p_t   base     pv_ac  pv_dc
0    11 2025-05-11 11:00:00  0.06609  0.06609  0.602  1.277738      0
1    12 2025-05-11 12:00:00 -0.23847 -0.23847  0.566  2.947107      0
2    13 2025-05-11 13:00:00 -0.27584 -0.27584  0.692  3.116180      0
3    14 2025-05-11 14:00:00 -0.21525 -0.21525  0.802  3.051900      0
4    15 2025-05-11 15:00:00  0.01461  0.01461  0.409  2.741059      0
5    16 2025-05-11 16:00:00  0.12534  0.12534  0.539  2.229218      0
6    17 2025-05-11 17:00:00  0.14752  0.14752  1.385  1.717403      0
7    18 2025-05-11 18:00:00  0.24085  0.24085  0.646  1.131061      0
8    19 2025-05-11 19:00:00  0.28312  0.28312  0.526  0.532950      0
9    20 2025-05-11 20:00:00  0.29874  0.29874  0.461  0.113396      0
10   21 2025-05-11 21:00:00  0.28718  0.28718  0.453  0.000000      0
11   22 2025-05-11 22:00:00  0.26679  0.26679  0.416  0.000000      0
12   23 2025-05-11 23:00:00  0.25013  0.25013  0.366  0.000000      0
2025-05-11 11:30:30 info: Verbruik dit contractjaar: 2097.049 kWh

Helaas kwam ik er nu pas achter dat een run met Debug: True alleen debug info toont als de logging output ook op debug staat... Dus run met Debug is dus eigenlijk meer een 'dry-run' dan een 'debug' run. Ik raakte een beetje in de war door de terminology

Ik zie nu een query dit bijna 15 seconden duurt:

code:

2025-05-11 13:13:50 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-05-11 13:14:04 info: Verbruik dit contractjaar: 2097.062 kWh

Ik zie alleen de prepared statement query, en niet de ingevulde waardes. Heeft iemand een hint wat ik voor de arguments moet invullen, zodat ik deze op mijn dao sqlite database kan uitvoeren?
Misschien is dit namelijk met een index al een stuk sneller te maken.

[Undertilted]

Is het eigenlijk mogelijk om da_cons en da_prod zelf te gaan overschrijven?

[KC27]

Undertilted schreef op zondag 11 mei 2025 @ 19:21:
Is het eigenlijk mogelijk om da_cons en da_prod zelf te gaan overschrijven?

Het staat op mijn to-do lijst zoiets te maken.
Met name voor de Belgische gebruikers van DAO (zoals jij?)
Mijn prioriteit-volgorde is nu:

• echte gemelde fouten uit de software halen
• pre build images zodat installaties en updates sneller verlopen
• 15min resolutie van de dynamische prijzen, gaat bij een aantal leveranciers waarschijnlijk op 11/12 juni a.s. in
• zelf formules maken voor je inkoop- en terugleverprijzen
• andere verzoeken

[mgroen81]

@KC27
DAO deed er nog steeds 32 seconden over om de gegevens (van 7maanden) op te halen uit de HomeAssistant database. Als de database leeg is duurt dit 1s. Het zou mooi zijn als dit uit te zetten is.
Of heeft dit veel invloed op de berekening? Opwek is hier meestal iets lager dan verbruik.

[KC27]

mgroen81 schreef op zondag 11 mei 2025 @ 23:06:
@KC27
DAO deed er nog steeds 32 seconden over om de gegevens (van 7maanden) op te halen uit de HomeAssistant database. Als de database leeg is duurt dit 1s. Het zou mooi zijn als dit uit te zetten is.
Of heeft dit veel invloed op de berekening? Opwek is hier meestal iets lager dan verbruik.

Ja ik zie dat meer mensen hiermee worstelen.
Uiteindelijk wordt de berekening alleen gebruikt om te bepalen of er kan worden gesaldeerd.
Ik kan de berekening eruit uithalen en dan op grond van de instelling

code:

"tax refund" : "True"

met of zonder energiebelasting op de teruglevering rekenen.
Is dat wat (bij vijf duimen komt ie op de lijst)?

[mgroen81]

KC27 schreef op zondag 11 mei 2025 @ 23:17:
[...]

Ja ik zie dat meer mensen hiermee worstelen.
Uiteindelijk wordt de berekening alleen gebruikt om te bepalen of er kan worden gesaldeerd.
Ik kan de berekening eruit uithalen en dan op grond van de instelling

code:

"tax refund" : "True"

met of zonder energiebelasting op de teruglevering rekenen.
Is dat wat (bij vijf duimen komt ie op de lijst)?

Goed idee. Of misschien als extra optie in de config.

[Torch1969]

KC27 schreef op zondag 11 mei 2025 @ 23:17:
[...]

Ja ik zie dat meer mensen hiermee worstelen.
Uiteindelijk wordt de berekening alleen gebruikt om te bepalen of er kan worden gesaldeerd.
Ik kan de berekening eruit uithalen en dan op grond van de instelling

code:

"tax refund" : "True"

met of zonder energiebelasting op de teruglevering rekenen.
Is dat wat (bij vijf duimen komt ie op de lijst)?

Lijkt me geen probleem. Over 1,5 jaar is de saldering sowieso voor iedereen weg en heeft deze config optie en berekening geen nut meer. Maar misschien is de mening voor de gebruikers waar de berekening wel zinvol is (die net op randje van wel/niet salderen balanceren) belangrijker. Zijn die er?

[Bravo]

Torch1969 schreef op maandag 12 mei 2025 @ 07:39:
[...]

Lijkt me geen probleem. Over 1,5 jaar is de saldering sowieso voor iedereen weg en heeft deze config optie en berekening geen nut meer. Maar misschien is de mening voor de gebruikers waar de berekening wel zinvol is (die net op randje van wel/niet salderen balanceren) belangrijker. Zijn die er?

Ik zit waarschijnlijk net op het randje, maar dat weet ik pas in november als er nauwelijks meer opwek is hoeveel ik nog over/tekort heb om de EV te laden tot de afrekening in januari. Tot nu toe is de PV opbrengst behoorlijk meer dan regulier.
Maar als ik eerder ga afschakelen, ga ik waarschijnlijk wel tekort komen (zoals vorig jaar waar okt/nov qua PV erg tegen vielen en ik in de zomer de PV had uitgeschakeld).
DAO hoeft dit niet voor mij uit te rekenen, ik zie het zelf ook wel in het energieoverzicht.

[ Voor 5% gewijzigd door Bravo op 12-05-2025 09:02 ]

[simnet]

Ik heb een vraagje over de solar.capacity instelling.
In de documentatie staat kWp. Dat zou dus de totale theoretische vermogen zijn van de opstelling. Ik merk echter dat de prognose van DAO structureel onder de opbrengst zit, dit terwijl ik de yield heb uitgerekend met de aangegeven formule.

Mijn vraag is nu als volgt: moet ik bij capacity de maximum kWp opgeven van de panelen, of van de omvormer(s)?

Mijn situatie: Enphase systeem, 15x400Wp panelen, 15x295W omvormers.
Moet ik bij solar.capacity nu 15x400 of 15x295 invullen?

[KC27]

simnet schreef op maandag 12 mei 2025 @ 10:03:
Ik heb een vraagje over de solar.capacity instelling.
In de documentatie staat kWp. Dat zou dus de totale theoretische vermogen zijn van de opstelling. Ik merk echter dat de prognose van DAO structureel onder de opbrengst zit, dit terwijl ik de yield heb uitgerekend met de aangegeven formule.

Mijn vraag is nu als volgt: moet ik bij capacity de maximum kWp opgeven van de panelen, of van de omvormer(s)?

Mijn situatie: Enphase systeem, 15x400Wp panelen, 15x295W omvormers.
Moet ik bij solar.capacity nu 15x400 of 15x295 invullen?

Als je structureel onder de opbrengst zit dan is het raadzaam om (over een langere periode bijv minimaal 1 week) uit te rekenen wat de prognose pv opbrengst gesommeerd over alle dagen van die periode. Zie daarvoor de log van de berekening iedere dag om 0:00 uur.
Je kijkt terug wat de echte opbrengst in dezelfde periode is geweest.
Je deelt die twee op elkaar: factor = echte opbrengst / prognose opbrengst
Je rekent je nieuwe yield uit met die factor: nieuw yield = oude yield x factor
Die nieuwe yield vul je weer in bij yield.

[storeman]

simnet schreef op maandag 12 mei 2025 @ 10:03:
Ik heb een vraagje over de solar.capacity instelling.
In de documentatie staat kWp. Dat zou dus de totale theoretische vermogen zijn van de opstelling. Ik merk echter dat de prognose van DAO structureel onder de opbrengst zit, dit terwijl ik de yield heb uitgerekend met de aangegeven formule.

Mijn vraag is nu als volgt: moet ik bij capacity de maximum kWp opgeven van de panelen, of van de omvormer(s)?

Mijn situatie: Enphase systeem, 15x400Wp panelen, 15x295W omvormers.
Moet ik bij solar.capacity nu 15x400 of 15x295 invullen?

Voor deze use-case heb ik ook een ticket ingeschoten. Eigenlijk zit er een cap op je opbrengst, maar dat wordt momenteel nog niet ondersteund.

[KC27]

storeman schreef op maandag 12 mei 2025 @ 10:22:
[...]


Voor deze use-case heb ik ook een ticket ingeschoten. Eigenlijk zit er een cap op je opbrengst, maar dat wordt momenteel nog niet ondersteund.

Deze heb ik opgenomen in de planning.

[KC27]

KC27 schreef op zondag 11 mei 2025 @ 23:17:
[...]

Ja ik zie dat meer mensen hiermee worstelen.
Uiteindelijk wordt de berekening alleen gebruikt om te bepalen of er kan worden gesaldeerd.
Ik kan de berekening eruit uithalen en dan op grond van de instelling

code:

"tax refund" : "True"

met of zonder energiebelasting op de teruglevering rekenen.
Is dat wat (bij vijf duimen komt ie op de lijst)?

In 12 uur 5 duimen: ik zet hem op de planning!

[Marcjeno1]

Hallo,

Het heeft bij mij een tijdje stil gelegen en wilde dit weer gaan oppakken.

Ik heb een docker omgeving draaien. Ik ben aan de slag gegaan en de API gegevens van meteo en HA ingevuld. Het lukt netjes om de meteo gegevens en de nordpool gegevens op te halen. Als ik dan een berekening wil uitvoeren krijg ik het volgende:

code:

Logging van bewerking "Optimaliseringsberekening met debug":
2025-05-12 12:29:15 info: Day Ahead Optimalisering versie: 2025.4.0
2025-05-12 12:29:15 info: Day Ahead Optimalisering gestart op: 12-05-2025 12:29:15
2025-05-12 12:29:15 info: Day Ahead Optimalisatie gestart: 12-05-2025 12:29:15 taak: calc_optimum_met_debug
2025-05-12 12:29:15 info: Debug = True
2025-05-12 12:29:15 fout: Er ontbreken voor een aantal uur gegevens (meteo en/of dynamische prijzen) er kan niet worden gerekend

[simnet]

Ik kreeg zojuist een fout bij de scheduled calculatie: waarschuwing: Geen oplossing voor: minimize consumption

Toen ik daarna handmatig een run startte, kon hij wel een oplossing vinden. Is dit een bug?

code:

 2025-05-12 15:00:00 info: Day Ahead Optimalisering versie: 2025.4.2
2025-05-12 15:00:00 info: Day Ahead Optimalisering gestart op: 12-05-2025 15:00:00
2025-05-12 15:00:00 info: Day Ahead Optimalisatie gestart: 12-05-2025 15:00:00 taak: calc_optimum
2025-05-12 15:00:00 info: Using Python-MIP package version 1.16rc0
2025-05-12 15:00:00 info: Debug = False
2025-05-12 15:00:00 info: Zelf berekende baseload
2025-05-12 15:00:00 info: Start waarden: 
    uur                tijd      p_l      p_t   base     pv_ac  pv_dc
0    15 2025-05-12 15:00:00  0.13449  0.13449  0.405  4.527759      0
1    16 2025-05-12 16:00:00  0.14316  0.14316  0.634  4.109129      0
2    17 2025-05-12 17:00:00  0.22567  0.22567  1.195  3.341207      0
3    18 2025-05-12 18:00:00  0.26330  0.26330  0.454  2.478691      0
4    19 2025-05-12 19:00:00  0.30498  0.30498  0.454  1.446742      0
5    20 2025-05-12 20:00:00  0.35266  0.35266  0.552  0.489993      0
6    21 2025-05-12 21:00:00  0.28994  0.28994  0.503  0.013817      0
7    22 2025-05-12 22:00:00  0.27004  0.27004  0.507  0.000000      0
8    23 2025-05-12 23:00:00  0.25710  0.25710  0.452  0.000000      0
9     0 2025-05-13 00:00:00  0.25315  0.25315  0.340  0.000000      0
10    1 2025-05-13 01:00:00  0.25051  0.25051  0.435  0.000000      0
11    2 2025-05-13 02:00:00  0.25055  0.25055  0.360  0.000000      0
12    3 2025-05-13 03:00:00  0.25792  0.25792  0.263  0.000000      0
13    4 2025-05-13 04:00:00  0.26094  0.26094  0.249  0.000000      0
14    5 2025-05-13 05:00:00  0.26616  0.26616  0.287  0.000000      0
15    6 2025-05-13 06:00:00  0.30534  0.30534  0.287  0.135138      0
16    7 2025-05-13 07:00:00  0.30064  0.30064  0.344  0.298536      0
17    8 2025-05-13 08:00:00  0.27096  0.27096  0.320  0.409533      0
18    9 2025-05-13 09:00:00  0.23903  0.23903  0.490  0.900843      0
19   10 2025-05-13 10:00:00  0.16702  0.16702  0.623  2.039169      0
20   11 2025-05-13 11:00:00  0.14636  0.14636  0.527  3.111172      0
21   12 2025-05-13 12:00:00  0.13568  0.13568  0.736  4.014701      0
22   13 2025-05-13 13:00:00  0.12150  0.12150  0.628  4.672756      0
23   14 2025-05-13 14:00:00  0.13879  0.13879  0.610  5.044400      0
24   15 2025-05-13 15:00:00  0.14263  0.14263  0.520  4.926406      0
25   16 2025-05-13 16:00:00  0.14778  0.14778  0.538  4.524893      0
26   17 2025-05-13 17:00:00  0.23146  0.23146  1.159  3.690958      0
27   18 2025-05-13 18:00:00  0.26503  0.26503  0.377  2.750513      0
28   19 2025-05-13 19:00:00  0.29839  0.29839  0.484  1.625310      0
29   20 2025-05-13 20:00:00  0.40530  0.40530  0.450  0.569873      0
30   21 2025-05-13 21:00:00  0.32719  0.32719  0.446  0.013817      0
31   22 2025-05-13 22:00:00  0.28346  0.28346  0.401  0.000000      0
32   23 2025-05-13 23:00:00  0.26771  0.26771  0.312  0.000000      0
2025-05-12 15:00:24 info: Verbruik dit contractjaar: 2098.739 kWh
2025-05-12 15:00:24 info: Productie dit contractjaar: 3804.757 kWh
2025-05-12 15:00:24 info: All taxes refund (alles wordt gesaldeerd)
2025-05-12 15:00:25 info: No reduced hours applied for Marstek P3
2025-05-12 15:00:25 info: Startwaarde SoC Marstek P3: 78.0%
2025-05-12 15:00:25 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-05-12 15:00:25 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
2025-05-12 15:00:25 info: Apparaat wasmachine met programma '30 graden' wordt ingepland tussen 2025-05-13 10:00 en 2025-05-13 16:00.
2025-05-12 15:00:25 info: Apparaat vaatwasser met programma 'eco' wordt ingepland tussen 2025-05-12 15:00 en 2025-05-12 17:00.
2025-05-12 15:00:25 waarschuwing: Geen oplossing  voor: minimize consumption

[simnet]

Marcjeno1 schreef op maandag 12 mei 2025 @ 14:35:
Ik heb een docker omgeving draaien. Ik ben aan de slag gegaan en de API gegevens van meteo en HA ingevuld. Het lukt netjes om de meteo gegevens en de nordpool gegevens op te halen. Als ik dan een berekening wil uitvoeren krijg ik het volgende:

Probeer het nog eens, maar dan met "logging level" : "debug", in de config. Dan krijg je iets meer dan alleen info.

[Marcjeno1]

simnet schreef op maandag 12 mei 2025 @ 15:12:
[...]


Probeer het nog eens, maar dan met "logging level" : "debug", in de config. Dan krijg je iets meer dan alleen info.

Ik had hem ook gestart met debug, maar dit is alles wat ik krijg.

Edit: Nu doet hij het wel! Niks veranderd maar het werkt in ieder geval

[ Voor 11% gewijzigd door Marcjeno1 op 12-05-2025 15:24 ]

[simnet]

Marcjeno1 schreef op maandag 12 mei 2025 @ 15:22:
[...]
Ik had hem ook gestart met debug, maar dit is alles wat ik krijg.

Die fout maakte ik eerst ook... "Met debug" is niet zozeer met debug logging, maar een dry-run. Dus doe alles, behalve naar HA sturen.

De logging level in de config bepaald of je debug logging ziet of niet.

[Marcjeno1]

simnet schreef op maandag 12 mei 2025 @ 15:28:
[...]


Die fout maakte ik eerst ook... "Met debug" is niet zozeer met debug logging, maar een dry-run. Dus doe alles, behalve naar HA sturen.

De logging level in de config bepaald of je debug logging ziet of niet.

Ik zou niet weten hoe ik dat voor elkaar krijg. Dacht dat je het debug knopje bedoelde😋

[georgeboot]

Hoe stellen jullie bij Victron omvormers de setpoint in? Van wat ik begrijp van de documentatie van Victron, is de grid setpoint wat in/uit het net gaat NA voeden van voorspelde baseloads en pv.

Las eerder ook ergens dat men de berekende "entity set power feedin" ook niet 1:1 doorstuurde naar de omvormers omdat de waarde niet exact en continue dat is. Maar over een uur gemiddeld klopt dat toch juist wel aardig?

Ik gebruik nu DynamicESS van Victron zelf krijg hem maar niet zo ver om de SystemEfficiency (goed) toe te passen, dus heb steeds allemaal onzin ladingen en ontladingen. En De DAO plugin is sowieso een heel stuk mooier werk

[KC27]

De "entity set power feedin" is het vermogen dat de Multiplus(sen) afneemt (of als negatief terugstuurt) op de AC-IN.
Dus als je aan de AC-outs belasting en pv-productie hebt hangen moet je die daarbij optellen/aftrekken wil je het netto laad-/ontlaadvermogen hebben.
Als je meters op de AC-outs hebt hangen kunt je in HA met een automation de feedin corrigeren voor de afname op de AC-out. Je kunt ook corrigeren met de geprognosticeerde vermogens van je afnemers.
Ik weet dat @tonvanboven zoiets doet, wellicht kan hij zijn automation hier delen.

Ik stuur vanuit HA de netto feedin met modbus en adres 2700 naar venus-os, maar het kan ook goed met mqtt. De Cerbo/venus-os heeft standaard een mqtt-broker. Ik heb het niet geprobeerd, maar mqtt schijnt sneller te zijn.

[Impossibl3]

simnet schreef op maandag 12 mei 2025 @ 10:03:
Ik heb een vraagje over de solar.capacity instelling.
In de documentatie staat kWp. Dat zou dus de totale theoretische vermogen zijn van de opstelling. Ik merk echter dat de prognose van DAO structureel onder de opbrengst zit, dit terwijl ik de yield heb uitgerekend met de aangegeven formule.

Mijn vraag is nu als volgt: moet ik bij capacity de maximum kWp opgeven van de panelen, of van de omvormer(s)?

Mijn situatie: Enphase systeem, 15x400Wp panelen, 15x295W omvormers.
Moet ik bij solar.capacity nu 15x400 of 15x295 invullen?

15x 295. Je Enphase kapt hem af op 295 dus ne kan nooit meer leveren.

[storeman]

@Impossibl3 dat geldt voor hele zonnige dagen op de top uren. Bij bewolking en de lagere uren heb je wél profijt van de hogere capaciteit van de panelen.

[Torch1969]

simnet schreef op maandag 12 mei 2025 @ 10:03:
Ik heb een vraagje over de solar.capacity instelling.
In de documentatie staat kWp. Dat zou dus de totale theoretische vermogen zijn van de opstelling. Ik merk echter dat de prognose van DAO structureel onder de opbrengst zit, dit terwijl ik de yield heb uitgerekend met de aangegeven formule.

Mijn vraag is nu als volgt: moet ik bij capacity de maximum kWp opgeven van de panelen, of van de omvormer(s)?

Mijn situatie: Enphase systeem, 15x400Wp panelen, 15x295W omvormers.
Moet ik bij solar.capacity nu 15x400 of 15x295 invullen?

Je hebt beide nodig. Tot het maximum van de omvormers het vermogen van de panelen, en daarboven het maximum van de omvormers. Er staat al een feature request op de backlog bij @KC27 om dit te kunnen configureren en gebruiken. Tot die tijd moet je kiezen. Ik zou (net als @storeman) gaan voor vermogen zonnepanelen, omdat je dan in de uren zonder maximale opwek een betere voorspelling hebt. In de uren met veel opwek berekent DAO dan wat teveel, maar dan heb je toch al teveel, en dit komt ook minder uren per jaar voor.

[georgeboot]

KC27 schreef op maandag 12 mei 2025 @ 22:05:
Dus als je aan de AC-outs belasting en pv-productie hebt hangen moet je die daarbij optellen/aftrekken wil je het netto laad-/ontlaadvermogen hebben.

Ja precies, bedankt.

Ik heb alles in mn huis aan de AC-Out-1 hangen, inclusief PV. De grid setpoint van Victron is dus geregeld op de ingebouwde meters van de multiplussen op de AC-in. Het regelt dus wat er dus daadwerkelijk door m’n slimme meter loopt.

DAO’s entity set power feedin heeft dezelfde berekening, omdat ook die de daadwerkelijke import/export van of naar het net reflecteert.

Conclusie: ik kan de voor entity power set power feedin dus direct schrijven naar Victron’s grid setpoint.

[Marcjeno1]

Nou ik heb mijn eerste grafiekjes gegenereerd met DAO! Ziet er goed uit . Vandaag eens aan de gang met automatiseringen in HA om de boel aangestuurd te krijgen op mijn victron ESS.

Ik heb nog wel een vraag over de grafieken.


Hoe komt het dat de accu uit en de teruglevering hetzelfde aantal Kwh geven. Ik heb bij de batterij netjes de efficiency ingevuld maar het lijkt er nu op dat het een efficiency van 100% gebruikt. Hoe staat dit bij jullie in de grafieken?

KC27 schreef op maandag 12 mei 2025 @ 22:05:
Ik stuur vanuit HA de netto feedin met modbus en adres 2700 naar venus-os, maar het kan ook goed met mqtt. De Cerbo/venus-os heeft standaard een mqtt-broker. Ik heb het niet geprobeerd, maar mqtt schijnt sneller te zijn.

Hiermee wil ik aan de gang gaan. Ik heb al data wat vanuit de GX wat binnenkomt op mijn HA via mqtt. Deze add-on of docker image heeft mij heel simpel al heel wat data automatisch in HA gezet: https://github.com/EvensS...ss-victron-mqtt-discovery. Wellicht leuk als je hiermee aan de gang wilt! Misschien ook een leuk idee om ergens wat voorbeeld automatiseringen te verwerken op de dao github handleiding?

[ Voor 32% gewijzigd door Marcjeno1 op 13-05-2025 09:14 ]

[Torch1969]

Marcjeno1 schreef op dinsdag 13 mei 2025 @ 09:08:
Nou ik heb mijn eerste grafiekjes gegenereerd met DAO! Ziet er goed uit . Vandaag eens aan de gang met automatiseringen in HA om de boel aangestuurd te krijgen op mijn victron ESS.

Ik heb nog wel een vraag over de grafieken.
[Afbeelding]

Hoe komt het dat de accu uit en de teruglevering hetzelfde aantal Kwh geven. Ik heb bij de batterij netjes de efficiency ingevuld maar het lijkt er nu op dat het een efficiency van 100% gebruikt. Hoe staat dit bij jullie in de grafieken?

Die Accu Uit is aan de AC kant van de accu, daar is het efficiency-verlies al vanaf. Dat is dus wat er daadwerkelijk voor je base load (en eventuele andere apparaten die je hebt geconfigureerd) wordt gebruikt en wat er dan overblijft wordt terug geleverd.
Kijk maar eens in de logging (home/tabel) van de optimalisatie berekening in de tabel bij “ In- en uitgaande energie per uur batterij…”.

[Marcjeno1]

Torch1969 schreef op dinsdag 13 mei 2025 @ 12:48:
[...]


Die Accu Uit is aan de AC kant van de accu, daar is het efficiency-verlies al vanaf. Dat is dus wat er daadwerkelijk voor je base load (en eventuele andere apparaten die je hebt geconfigureerd) wordt gebruikt en wat er dan overblijft wordt terug geleverd.
Kijk maar eens in de logging (home/tabel) van de optimalisatie berekening in de tabel bij “ In- en uitgaande energie per uur batterij…”.

Ah op die manier, dankjewel. Dan moet ik nog even wat aanpassen want ik kan geen 15kwh op het net zetten vanuit de batterij. Dat is hoogstens 13kwh als de victrons op vol vermogen ontladen.

[Bravo]

Marcjeno1 schreef op dinsdag 13 mei 2025 @ 16:23:
[...]


Ah op die manier, dankjewel. Dan moet ik nog even wat aanpassen want ik kan geen 15kwh op het net zetten vanuit de batterij. Dat is hoogstens 13kwh als de victrons op vol vermogen ontladen.

Dat moet je dan aanpassen in de efficiency waardes voor de batterij, en de min/max SOC. Dan 'verdwijnt' er energie bij het ontladen en gaat DAO niet rekenen tot een onderwaarde van 0% SOC.

[hemertje]

Marcjeno1 schreef op dinsdag 13 mei 2025 @ 09:08:
Wellicht leuk als je hiermee aan de gang wilt! Misschien ook een leuk idee om ergens wat voorbeeld automatiseringen te verwerken op de dao github handleiding?

Al leek, lees met geen programmeerknobbel dus eerder een veredelde gebruiker, heb ik hier ook behoefte aan

Kunnen deze ook via Github aangeboden worden samen met DAO?
of eventueel los via HACS?

[KC27]

hemertje schreef op dinsdag 13 mei 2025 @ 19:03:
[...]


Al leek, lees met geen programmeerknobbel dus eerder een veredelde gebruiker, heb ik hier ook behoefte aan

Kunnen deze ook via Github aangeboden worden samen met DAO?
of eventueel los via HACS?

Allemaal hele goede ideeën, maar ik heb kwa tijd mijn beperkingen. Iik richt mij nu vooral op de feature-requests en de komende aanpassing ivm 15min resulotie van de day ahead prijzen. Iik zou het super vinden als een paar van hier mij willen helpen met het aanvullen van de handleiding, evt 2e handleiding of uitbreiding van de TS.
Ik sta overal voor open.

[georgeboot]

@KC27 wat is eigenlijk het verschil tussen "entity balance switch" aan, en een "entity set power feedin" van 0? Beiden doen toch het zelfde? Of is het de bedoeling om bij balance grid ook de pv te knijpen als accu vol is zodat net op 0 blijft?

[hemertje]

KC27 schreef op dinsdag 13 mei 2025 @ 19:21:
[...]

Allemaal hele goede ideeën, maar ik heb kwa tijd mijn beperkingen. Iik richt mij nu vooral op de feature-requests en de komende aanpassing ivm 15min resulotie van de day ahead prijzen. Iik zou het super vinden als een paar van hier mij willen helpen met het aanvullen van de handleiding, evt 2e handleiding of uitbreiding van de TS.
Ik sta overal voor open.

geen probleem dat ze voor nu geen prioriteit krijgen
hopelijk kunnen anderen bijdragen aan al je werk

[KC27]

georgeboot schreef op dinsdag 13 mei 2025 @ 19:27:
@KC27 wat is eigenlijk het verschil tussen "entity balance switch" aan, en een "entity set power feedin" van 0? Beiden doen toch het zelfde? Of is het de bedoeling om bij balance grid ook de pv te knijpen als accu vol is zodat net op 0 blijft?

Inderdaad precies hetzelfde, de balance switch kan eigenlijk weg, is nog een reliek uit mijn verleden 😊

[arro3038]

KC27 schreef op dinsdag 13 mei 2025 @ 21:39:
[...]

Inderdaad precies hetzelfde, de balance switch kan eigenlijk weg, is nog een reliek uit mijn verleden 😊

Is die niet meer nodig? Ik heb DAO op minimize consumption staan. Ik zie dat vooral in de avond en nacht deze switch aan wordt gezet, waarop ik mijn batterij NOM laat draaien. Dit werkt beter dan puur de waarde van power feedin te volgen. Die laatste is tenslotte gebaseerd op een gemiddelde op basis van historie qua base load etc.
Juist door die switch draait ik dan beter op NOM op een moment dat de power feedin niet gelijk is aan 0.

Is power feedin wel gelijk aan 0, dan doet mijn batterij ook niets. Zou ik dan nom gaan draaien, dan krijg ik dat de batterij in de ochtend al weer gaat laden op overschot zonenergie als de prijs nog redelijk hoog is. Dan lever ik liever alles terug. DAO geeft op zonnige dagen als vandaag aan om pas om 12 uur te gaan laden als de prijs laag is. De combi met power feedin en de balance switch werkt voor mij juist erg goed. Ik zie niet dat die switch overbodig is geworden. Of ik snap het niet, dat kan natuurlijk ook.

[simnet]

arro3038 schreef op woensdag 14 mei 2025 @ 07:43:
[...]

Juist door die switch draait ik dan beter op NOM op een moment dat de power feedin niet gelijk is aan 0.

Is power feedin wel gelijk aan 0, dan doet mijn batterij ook niets.

Zou jij je automation logica (of de hele automation) kunnen delen? Ik heb een identieke situatie, maar op een of andere manier krijg ik de volgorde/logica niet goed.

[arro3038]

simnet schreef op woensdag 14 mei 2025 @ 09:21:
[...]


Zou jij je automation logica (of de hele automation) kunnen delen? Ik heb een identieke situatie, maar op een of andere manier krijg ik de volgorde/logica niet goed.

Bij gebrek aan lokale aansturing of een goede API gebruik ik een slimme meter simulator om mijn evapower te foppen. Evapower leest een p1 meter die in de simulator zit. Middels de automation stuur ik aangepaste waardes naar de simulator zodat ik op die manier de evapower door DAO aan kan laten sturen.

Zie deze post

Travelan in "Eva Power hybride thuisaccu"

Waar ik een aanpassing op heb gedaan tbv de balance switch

arro3038 in "Eva Power hybride thuisaccu"

[georgeboot]

arro3038 schreef op woensdag 14 mei 2025 @ 07:43:
[...]
Juist door die switch draait ik dan beter op NOM op een moment dat de power feedin niet gelijk is aan 0.

Is het onderliggende probleem dan niet dat power feedin niet 0 is terwijl hij wel balance aan zet? Dat lijkt me sowieso bijzonder.
Mijns inziens zou DAO net zo goed feedin naar 0 kunnen forceren, dan heb je het zelfde effect.

[simnet]

georgeboot schreef op woensdag 14 mei 2025 @ 09:37:
[...]


Is het onderliggende probleem dan niet dat power feedin niet 0 is terwijl hij wel balance aan zet? Dat lijkt me sowieso bijzonder.
Mijns inziens zou DAO net zo goed feedin naar 0 kunnen forceren, dan heb je het zelfde effect.

Dat laatste is alleen het geval als je batterij niet zichzelf kan sturen.
Mijn batterij is volledig autonoom in staat om 'nul op de meter' te draaien door het uitlezen van een p1 meter.
De batterij gaat daardoor op de seconde nauwkeurig sturen op vermogen om de grid export zo dicht mogelijk bij 0 te houden. Dit is iets wat DAO natuurlijk niet kan, aangezien deze eenmaal per uur iets doorgeeft aan HA.

Voor mij is de 'entity balance switch' dus weldegelijk relevant, omdat ik op die manier onderscheid kan maken tussen 'draai null-op-de-meter' en 'nu helemaal niets doen, want <reden>'.

[ErnstH]

simnet schreef op woensdag 14 mei 2025 @ 09:21:
[...]


Zou jij je automation logica (of de hele automation) kunnen delen? Ik heb een identieke situatie, maar op een of andere manier krijg ik de volgorde/logica niet goed.

Dit is wat ik zelf gebrui. Er zitten wat overbodige dingen in en zou er eigenlijk een blueprint van moeten maken, maar ja, het werkt..

code:

# Automation to control Sessy battery based on DAO variables:
# - set to NOM if entity balance switch is ON (input_boolean.dao_balanceer_grid_sessy_XXXX)
# - otherwise, if entity set operating mode is OFF (input_select.dao_sessy_XXXX_operating_mode)
#      set to IDLE, but override in case solar power generation exceeds threshold (set to NOM)
# - otherwise, check setpoint with entity set power feedin (input_number.dao_sessy_XXXX_power_setpoint)
#      but set to NOM if setpoint too small
# - OVERRIDE: if the car is charging, NOM is NOT selected (either OFF or setpoint)
#
# TODO:
# -
#
# --- AUTOMATIONS ---
automation:
  - id: "dao_sessy_control"
    alias: "Sessy control according to Day Ahead Optimizer calculated plan"
    description: "This automation controls the Sessy according to the Day Ahead Optimizer calculated plan."
    triggers:
      - trigger: time_pattern
        minutes: "/15"
      - trigger: state
        entity_id:
          - input_boolean.dao_balanceer_grid_sessy_XXXX
          - input_select.dao_sessy_XXXX_operating_mode
          - input_number.dao_sessy_XXXX_power_setpoint
          - input_number.dao_solar_threshold
          - input_number.dao_setpoint_threshold

    conditions: []

    action:
      - if:
          - condition: state
            entity_id: input_boolean.dao_balanceer_grid_sessy_XXXX
            state: "on"

        then:
          - if:
              - condition: template
                value_template: >
                  {%- set chargePower = (states('sensor.energy_socket_5c2faf0c7e2a_active_power') | float(0)) -%}
                  {{ (chargePower < 10) }}

            then:
              - if:
                  - condition: template
                    value_template: >
                      {%- set currentStrategy = states('select.sessy_XXXX_power_strategy') -%}
                      {{ currentStrategy != "nom" }}

                then:
                  - service: select.select_option
                    target:
                      entity_id: select.sessy_XXXX_power_strategy
                    data:
                      option: nom

                  - service: notify.mobile_app_mi_9t
                    data:
                      title: >
                        {{ now().strftime('%H:%M')}} : Sessy put to NOM
                      message: >
                        NOM mode selected by DAO.
                      data:
                        tag: >
                          {{ now().strftime('%H')}}-dao-control

            else:
              - if:
                  - condition: template
                    value_template: >
                      {%- set currentStrategy = states('select.sessy_XXXX_power_strategy') -%}
                      {%- set currentSetPoint = (states('number.sessy_XXXX_power_setpoint') | float(0)) -%}
                      {%- set targetSetPoint = (states('input_number.dao_sessy_XXXX_power_setpoint') | float(0)) * -1 -%}
                      {{ (currentStrategy != "api") or (currentSetPoint != targetSetPoint) }}
                then:
                  - service: select.select_option
                    target:
                      entity_id: select.sessy_XXXX_power_strategy
                    data:
                      option: api

                  - service: number.set_value
                    data_template:
                      entity_id: number.sessy_XXXX_power_setpoint
                      value: |
                        {{ (states('input_number.dao_sessy_XXXX_power_setpoint') | float(0)) * -1}}

                  - service: notify.mobile_app_mi_9t
                    data:
                      title: >
                        {{ now().strftime('%H:%M')}} : Sessy put to API
                      message: >
                        NOM mode overridden by charging car. Following power setpoint set by DAO: {{ (states('input_number.dao_sessy_XXXX_power_setpoint') | float(0) | round(0)) * -1 }} W.
                      data:
                        tag: >
                          {{ now().strftime('%H')}}-dao-control

        else:
          - if:
              - condition: state
                entity_id: input_select.dao_sessy_XXXX_operating_mode
                state: "Uit"

            then:
              - if:
                  - condition: template
                    value_template: >
                      {%- set solarThreshold = (states('input_number.dao_solar_threshold') | float(0)) -%}
                      {%- set combinedSolarPower = (states('sensor.combined_solar_output') | float(0)) -%}
                      {%- set chargePower = (states('sensor.energy_socket_5c2faf0c7e2a_active_power') | float(0)) -%}
                      {{ (combinedSolarPower > solarThreshold) and (chargePower < 10) }}

                then:
                  - if:
                      - condition: template
                        value_template: >
                          {%- set currentStrategy = states('select.sessy_XXXX_power_strategy') -%}
                          {{ currentStrategy != "nom" }}
                    then:
                      - service: select.select_option
                        target:
                          entity_id: select.sessy_XXXX_power_strategy
                        data:
                          option: nom

                      - service: notify.mobile_app_mi_9t
                        data:
                          title: >
                            {{ now().strftime('%H:%M')}} : Sessy put to NOM
                          message: >
                            IDLE mode overridden by solar threshold!
                          data:
                            tag: >
                              {{ now().strftime('%H')}}-dao-control

                else:
                  - if:
                      - condition: template
                        value_template: >
                          {%- set currentStrategy = states('select.sessy_XXXX_power_strategy') -%}
                          {{ currentStrategy != "idle" }}
                    then:
                      - service: select.select_option
                        target:
                          entity_id: select.sessy_XXXX_power_strategy
                        data:
                          option: idle

                      - service: notify.mobile_app_mi_9t
                        data:
                          title: >
                            {{ now().strftime('%H:%M')}} : Sessy put to IDLE
                          message: >
                            IDLE mode selected by DAO.
                          data:
                            tag: >
                              {{ now().strftime('%H')}}-dao-control

            else:
              - if:
                  - condition: template
                    value_template: >
                      {%- set setpointThreshold = (states('input_number.dao_setpoint_threshold') | float(0)) -%}
                      {%- set powerSetPoint = ((states('input_number.dao_sessy_XXXX_power_setpoint') | float(0)) | abs) -%}
                      {%- set chargePower = (states('sensor.energy_socket_5c2faf0c7e2a_active_power') | float(0)) -%}
                      {{ (powerSetPoint < setpointThreshold) and (chargePower < 10) }}

                then:
                  - if:
                      - condition: template
                        value_template: >
                          {%- set currentStrategy = states('select.sessy_XXXX_power_strategy') -%}
                          {{ currentStrategy != "nom" }}
                    then:
                      - service: select.select_option
                        target:
                          entity_id: select.sessy_XXXX_power_strategy
                        data:
                          option: nom

                      - service: notify.mobile_app_mi_9t
                        data:
                          title: >
                            {{ now().strftime('%H:%M')}} : Sessy put to NOM
                          message: >
                            DAO power setpoint overridden!
                          data:
                            tag: >
                              {{ now().strftime('%H')}}-dao-control

                else:
                  - if:
                      - condition: template
                        value_template: >
                          {%- set currentStrategy = states('select.sessy_XXXX_power_strategy') -%}
                          {%- set currentSetPoint = (states('number.sessy_XXXX_power_setpoint') | float(0)) -%}
                          {%- set targetSetPoint = (states('input_number.dao_sessy_XXXX_power_setpoint') | float(0)) * -1 -%}
                          {{ (currentStrategy != "api") or (currentSetPoint != targetSetPoint) }}
                    then:
                      - service: select.select_option
                        target:
                          entity_id: select.sessy_XXXX_power_strategy
                        data:
                          option: api

                      - service: number.set_value
                        data_template:
                          entity_id: number.sessy_XXXX_power_setpoint
                          value: |
                            {{ (states('input_number.dao_sessy_XXXX_power_setpoint') | float(0)) * -1}}

                      - service: notify.mobile_app_mi_9t
                        data:
                          title: >
                            {{ now().strftime('%H:%M')}} : Sessy put to API
                          message: >
                            Power setpoint set by DAO: {{ (states('input_number.dao_sessy_XXXX_power_setpoint') | float(0) | round(0)) * -1 }} W.
                          data:
                            tag: >
                              {{ now().strftime('%H')}}-dao-control

    mode: queued

[georgeboot]

simnet schreef op woensdag 14 mei 2025 @ 10:16:
[...]


Dat laatste is alleen het geval als je batterij niet zichzelf kan sturen.
Mijn batterij is volledig autonoom in staat om 'nul op de meter' te draaien door het uitlezen van een p1 meter.
De batterij gaat daardoor op de seconde nauwkeurig sturen op vermogen om de grid export zo dicht mogelijk bij 0 te houden. Dit is iets wat DAO natuurlijk niet kan, aangezien deze eenmaal per uur iets doorgeeft aan HA.

Ik had het bij mijn Growatt systeem zo geconfigureerd dat als grid feedin 0 is, hij de accu op 'balanceer' modus zette zodat hij inderdaad met zn eigen meter de boel op 0 houdt.

Is die waarde niet 0, dan liet ik hem (ont)laden met de waarde van "entity from battery".

[simnet]

Na wat nadenken en doorlezen van andere comments kom ik op de volgende pseudocode. Klinkt dit logisch? Mijn DAO strategie is 'minimize consumption'

code:

# balance_mode == entity balance switch (Aan / Uit)
# inverter_state == entity set operating mode (Aan / Uit)
# feedinrate == entity set power feedin (in W)

select first match {
  case balance_mode == 'Aan' OR (inverter_state == 'Aan' AND feedinrate == 0):
    set battery mode to 'null-op-de-meter'

  case inverter_state == 'Uit':
    set battery mode to idle/disable inverter

  case feedinrate < 0:
    set battery mode to discharge;
    set discharge power to feedinrate * -1

  case feedinrate > 0:
    set battery mode to charge;
    set charge power to feedinrate

}

[georgeboot]

simnet schreef op woensdag 14 mei 2025 @ 11:19:
Na wat nadenken en doorlezen van andere comments kom ik op de volgende pseudocode. Klinkt dit logisch? Mijn DAO strategie is 'minimize consumption'

code:

# balance_mode == entity balance switch (Aan / Uit)
# inverter_state == entity set operating mode (Aan / Uit)
# feedinrate == entity set power feedin (in W)

select first match {
  case balance_mode == 'Aan' OR (inverter_state == 'Aan' AND feedinrate == 0):
    set battery mode to 'null-op-de-meter'

  case inverter_state == 'Uit':
    set battery mode to idle/disable inverter

  case feedinrate < 0:
    set battery mode to discharge;
    set discharge power to feedinrate * -1

  case feedinrate > 0:
    set battery mode to charge;
    set charge power to feedinrate

}

Bijna.
Je hebt een extra variabele nodig: "entity from battery". Deze waarde geeft de daadwerkelijke (ont)laadsnelheid van je batterij.

Stel, je verbruik is geschat op 300W en DAO geeft een feedinrate van -5000W, dan moet je omvormer dus 5300W produceren: 300W verbruik, plus 5000W om aan de export van 5000W te komen.

[simnet]

Ooh, ik ben er telkens vanuit gegaan dat de "entity set power feedin" betekend: ontlaad de batterij met deze snelheid
En dus niet, zorg ervoor dat je met deze snelheid naar het grid exporteert.

[arro3038]

simnet schreef op woensdag 14 mei 2025 @ 11:41:
Ooh, ik ben er telkens vanuit gegaan dat de "entity set power feedin" betekend: ontlaad de batterij met deze snelheid
En dus niet, zorg ervoor dat je met deze snelheid naar het grid exporteert.

Ik gebruik het op dezelfde manier. Ontlaad batterij met en niet exporteer naar grid. Zeker in de stand minimise consumption is dat totaal niet logisch. Dan zou ik de hele avond en nacht naar het net exporteren. Dat is in mijn ogen niet minimise consumption.

[KC27]

Update mbt invoering van het 15min interval van de Day Ahead tarieven.
Voor Nederland en de ons omringende landen is dit uitgesteld tot 30 september a.s.
Info:
https://www.nordpoolgroup...ute-market-time-unit-mtu/

[georgeboot]

In mijn ogen (@KC27 double check me AUB!) de betekenissen van de instellingen:

entity balance switch: helper die aangeeft of je omvormer nul-op-de-meter moet doen. Van wat ik begrijp is dit een overblijfsel uit eerdere tijden.

entity set power feedin: Het totale AC vermogen van alle fasen in watt, gemeten bij je slimmer meter, die je huis in- of uit gaat. Positief is verbruik, natarief is terugleveren. Bij balance aan, is deze altijd 0 en andersom.

entity from battery: Het DC vermogen dat je batterij ontlaadt. Positief is ontladen, negatief is laden.

entity from pv: Het DC vermogen van je PV omvormer dat invoedt op de DC busbar. De meeste zullen een AC-gekoppelde omvormer hebben, en deze entiteit is dan niet relevant.

entity from ac Het DC vermogen dat je omvormer op de DC busbar zet. Dit is dus het (ont)laadvermogen van de batterij.

Heb je dus een losse accu, dan zou ik bij een entity set power feedin=0 of entity balance switch=true, de batterij in nul-op-de-meter zetten. Zo niet, dan moet je de batterij laten laden/ontladen met de waarde van entity from battery. Let op dat deze waarde de DC waarde is. Als je batterij het getal interpreteert als AC, moet je nog corrigeren voor efficiëntie.

[Bravo]

georgeboot schreef op woensdag 14 mei 2025 @ 17:35:
In mijn ogen (@KC27 double check me AUB!) de betekenissen van de instellingen:

entity balance switch: helper die aangeeft of je omvormer nul-op-de-meter moet doen. Van wat ik begrijp is dit een overblijfsel uit eerdere tijden.

entity set power feedin: Het totale AC vermogen van alle fasen in watt, gemeten bij je slimmer meter, die je huis in- of uit gaat. Positief is verbruik, natarief is terugleveren. Bij balance aan, is deze altijd 0 en andersom.

entity from battery: Het DC vermogen dat je batterij ontlaadt. Positief is ontladen, negatief is laden.

entity from pv: Het DC vermogen van je PV omvormer dat invoedt op de DC busbar. De meeste zullen een AC-gekoppelde omvormer hebben, en deze entiteit is dan niet relevant.

entity from ac Het DC vermogen dat je omvormer op de DC busbar zet. Dit is dus het (ont)laadvermogen van de batterij.

Heb je dus een losse accu, dan zou ik bij een entity set power feedin=0 of entity balance switch=true, de batterij in nul-op-de-meter zetten. Zo niet, dan moet je de batterij laten laden/ontladen met de waarde van entity from battery. Let op dat deze waarde de DC waarde is. Als je batterij het getal interpreteert als AC, moet je nog corrigeren voor efficiëntie.

Status van dit moment:

code:

2025-05-14 19:00:06 info: Grid set point: -885.0 W
2025-05-14 19:00:06 info: Netto vermogen naar(+)/uit(-) omvormer battery: 0 W
2025-05-14 19:00:06 info: Balanceren: False
2025-05-14 19:00:06 info: Vermogen uit batterij: 0W
2025-05-14 19:00:06 info: Vermogen dat binnenkomt van pv: 0W
2025-05-14 19:00:06 info: Vermogen dat binnenkomt van ac: 0W

Het grid setpoint wordt niet geexporteerd naar HA, wel het vermogen van de batterij (set power feedin).
Er zijn dus situaties dat de batterij niets doet, en alle overtollige PV naar het grid laat stromen om geld te verdienen (of omdat de batterij vol zit)

[georgeboot]

Bravo schreef op woensdag 14 mei 2025 @ 19:29:

Het grid setpoint wordt niet geexporteerd naar HA, wel het vermogen van de batterij (set power feedin).
Er zijn dus situaties dat de batterij niets doet, en alle overtollige PV naar het grid laat stromen om geld te verdienen (of omdat de batterij vol zit)

Hmm dan snap ik het ook niet meer haha. Dat zou betekenen dat het enige verschil tussen "entity from ac" en "entity set power feedin" DC en AC is. Vóór en ná conversie dus.

KC27 heeft zelf een systeem van victron en daar geef je netbalans op als parameter ("zorg dat er bij de p1 meter x watt in of uit gaat"). Maar die parameter zou volgens deze theorie niet beschikbaar worden gesteld.

[KC27]

@georgeboot @Bravo @arro3038 @simnet
DAO is niet zonder historie.
Ik heb het eerst voor mezelf gemaakt met een victron systeem zonder belastingen op ACout (heb ik nog steeds niet, maar dat gaat dit jaar wel veranderen).
Ik had genoeg aan drie entiteiten:

1. ess feedin power: het vermogen dat het victron systeem opneemt (+) of afgeeft (-). Dat is bij een Sessy juist andersom. Dat vermogen ging de batterij in of eruit. Toen kwam als tweede gebruiker @tonvanboven en die heeft (bijna) alle belasting op de ACout (net als george) en dan is ess feedin power de som van wat er naar de batterij gaat plus de belasting op ACout.
2. operating mode. Hiermee kun je het systeem aan/uit zetten. Dat kan ook bij een Sessy, maar het kan natuurlijk niet bij een Victron systeem met belasting op de ACout. Ik had behoefte om het systeem "uit" te zetten als ik niks hoefde te laden/ontladen (feedin = 0) om zo de stilstandsverliezen van het systeem (ca 100W) te omzeilen. Dat kon omdat ik geen belasting op ACout had.
3. balance switch Ik voorzag dat er soms situaties zijn en zeker komen na afloop van de saldering dat je "nul op de meter" wil handhaven met je thuisbatterij. DAO zet deze (meestal een input_boolean) aan en ik heb een automation gemaakt die door deze switch wordt getriggerd en iedere seconde uit mijn p1-meter het netto vermogen binnen krijgt en op basis daarvan de ess feedin power bijstelt (soort mini pid-regeling).

Later zijn er een aantal entiteiten bijgekomen om de aansturing van andere systemen makkelijker te maken. Ik citeer uit de changelog van versie 2024.8.0 (augustus 2024):

There are 4 extra possible (=optional) entities which you can use to manage and operate your battery(ies):

1. entity from battery: how much energy is going from the battery to the dc-bar (W)
2. entity from pv: how much energy is going from the dc-solar system to the dc-bar (W)
3. entity from ac: how much energy is going from the inverter to the dc-bar (W)
4. entity calculated soc: what is the expected value of the SoC after this hour (%)<br>

De eerste drie hebben alle drie betrekking op het DC-vermogen dat de busbar in de het batterij systeem ontvangt. Dus "entity from ac" is het naar DC geconverteerde AC-vermogen dat de batterij ingaat.
Alles wat naar de busbar gaat is positief, alles wat de busbar verlaat is negatief. En omdat ook hier de wet van behoud van energie van toepassing is geldt hier dat de som van die drie altijd nul moet zijn.

Ooit is daar nog bijgekomen entity ess grid setpoint die geeft aan hoeveel energie er door de inkoopmeter stroomt. Deze is slecht (zeg maar niet, verbeterpuntje voor mij) gedocumenteerd in DOCS.md. Als de balance switch aan staat wordt deze waarde nul. Vandaar dat ik suggereerde om de balance switch op te doeken en eventueel een automation te hangen aan deze waarde. Maar gezien het protest tegen het opdoeken van de balance-switch gaat dat voorlopig niet gebeuren.
De entity ess grid setpoint hoort helemaal niet bij de batterij(en), want die kan ook worden berekend, getoond en geëxporteerd zonder batterij.

Hopelijk is nu wat duidelijker. Als er nog vragen zijn hoor ik het graag.

[Marcjeno1]

hemertje schreef op dinsdag 13 mei 2025 @ 19:03:
[...]


Al leek, lees met geen programmeerknobbel dus eerder een veredelde gebruiker, heb ik hier ook behoefte aan

Kunnen deze ook via Github aangeboden worden samen met DAO?
of eventueel los via HACS?

Ik heb een beetje hetzelfde probleem met programmeren .

Ik wil nu een automation maken die mijn batterij moet gaan opladen en ontladen. DAO heeft nu helpers in home assistant die ik moet gaan omzetten in communicatie naar mijn batterij. Als ik handmatig mijn batterij oplaadt zet ik bijvoorbeeld de slider in VRM naar 100% en dan laadt de batterij naar 100%. En als ik hem dan handmatig naar 5% zet ontlaadt het systeem tot 5% omdat ik mijn grid setpoint altijd negatief heb staan.

Dit stuk moet ik dus geautomatiseerd zien te krijgen. Als ik het goed begrijp gebruik ik entity set power feedin voor het grid setpoint gedeelte van victron.

Begrijp ik het goed als ik entity min soc end opt en entity max soc end opt hetzelfde doet als de slider in VRM? Dan kan ik deze namelijk gaan gebruiken voor mijn automation. Ik gebruik de batterij alleen maar voor het handelen van de stroom.

Edit:

Werkt helemaal anders . Moet dus met power feed in gaan werken. Waar haalt DAO trouwens datum/tijd vandaan? Deze staat op UTC 0, maar dat gaat dus niet lekker met instellen naar de helpers in HA. Kan ik dit ergens wijzigen?

Edit2:

Datum/tijd gewijzigd in de docker compose. Nu pakt hij wel de goede tijd

environment:
- TZ=Europe/Amsterdam

[ Voor 13% gewijzigd door Marcjeno1 op 15-05-2025 10:54 ]

[KC27]

Er is een nieuwe testversie gepubliceerd op Github in de addon-branche: versie 2025.5.0.rc4c
Dit staat er in de changelog:

• Start with a pre-builded repository on Github (thanks to bvw)
• Introduction of a check on "last invoice", warning when more than one year ago.
• Fix Dockerfile for build error Pillow library
• Corrected VAT-calculation when calculating the profit during the DAO optimal-calculation (reported bij bvw)
• Fix heatpump planning: when heat_demand-entity is false there will be no heat-pump power calculated in the first hour (reported by bvw)
• Fixed error planning machine when planning calculation is in the previous planned period (reported by @sjampeter)
• Fixed error and show error-message when no entities are configured for setting the calculated planning of a machine in HA (reported by llevering)
• Fixed error with postgresql during reporting of balance and calculation of baseloads (reported by @balk77)
• Fixed error not switching off pv-switch with negative prices with more than one pv-string

Voor het eerst is er een pre-build versie gemaakt.
Dit betekent: sneller installeren.
Gebruikers met HA-OS hoeven niks te doen alles staat goed ingesteld in config.yaml
Gebruikers die HA en DAO draaien in een container kunnen nu makkelijker en sneller installeren.
De addon-image staat op:
ghcr.io/corneel27/dao-aarch64-addon:2025.5.0.rc4c
Na het testen (over ca 1 tot 2 dagen) komt de productie release vrij op:
ghcr.io/corneel27/dao-aarch64:2025.5.0
Dus zonder addon in de naam en de rcxx toevoeging is er dan ook niet meer.
Opmerking : vervang evt aarch64 door amd64 of i386

Wie helpt mij om de TS aan te passen met deze info?

Planning:
Als deze test-versie wordt goedgekeurd (graag zoveel mogelijk testen) en is gepromoveerd naar de productieversie ga ik met de andere feature requests aan de gang omdat de invoering van het 15min-interval is uitgesteld.

[sjampeter]

@KC27 vraagje,


ik draai nu 2025.5.0.rc1a
betreffende mijn issue qua inplannen "machine" werkt deze bijna correct.
dit is ook beschreven op Github.
laatst probeerde ik 2025.5.0.rc1 (ik meen b en/of c) waar de machine voor de volgende dag helemaal niet meer ingepland werd.
zit er tussen deze versie's verschil in dit script?
op versie a, werkt ie goed genoeg maar had het idee dat b en c volledig fout liepen.

uiteraard wil ik nogmaals testen, maar ik wil graag weten of er iets aan de code veranderd is vanaf versie a

[KC27]

@sjampeter
De verschillen zaten in het testen van de automatische builds niet meer in de python-code.
Zou je voor de zekerheid ook nog versie rc4c willen testen?

[ Voor 4% gewijzigd door KC27 op 15-05-2025 13:28 ]

[Torch1969]

KC27 schreef op donderdag 15 mei 2025 @ 10:48:
Er is een nieuwe testversie gepubliceerd op Github in de addon-branche: versie 2025.5.0.rc4c
Dit staat er in de changelog:

• Start with a pre-builded repository on Github (thanks to bvw)
• Introduction of a check on "last invoice", warning when more than one year ago.
• Fix Dockerfile for build error Pillow library
• Corrected VAT-calculation when calculating the profit during the DAO optimal-calculation (reported bij bvw)
• Fix heatpump planning: when heat_demand-entity is false there will be no heat-pump power calculated in the first hour (reported by bvw)
• Fixed error planning machine when planning calculation is in the previous planned period (reported by @sjampeter)
• Fixed error and show error-message when no entities are configured for setting the calculated planning of a machine in HA (reported by llevering)
• Fixed error with postgresql during reporting of balance and calculation of baseloads (reported by @balk77)
• Fixed error not switching off pv-switch with negative prices with more than one pv-string

Voor het eerst is er een pre-build versie gemaakt.
Dit betekent: sneller installeren.
Gebruikers met HA-OS hoeven niks te doen alles staat goed ingesteld in config.yaml
Gebruikers die HA en DAO draaien in een container kunnen nu makkelijker en sneller installeren.
De addon-image staat op:
ghcr.io/corneel27/dao-aarch64-addon:2025.5.0.rc4c
Na het testen (over ca 1 tot 2 dagen) komt de productie release vrij op:
ghcr.io/corneel27/dao-aarch64:2025.5.0
Dus zonder addon in de naam en de rcxx toevoeging is er dan ook niet meer.
Opmerking : vervang evt aarch64 door amd64 of i386

Wie helpt mij om de TS aan te passen met deze info?

Planning:
Als deze test-versie wordt goedgekeurd (graag zoveel mogelijk testen) en is gepromoveerd naar de productieversie ga ik met de andere feature requests aan de gang omdat de invoering van het 15min-interval is uitgesteld.

Ok, container met testversie draait op basis van de gepubliceerde image. De docker-compose file is nu als volgt:

code:

  dao:
    container_name: dao
    image: ghcr.io/corneel27/<docker-image>:latest
    volumes:
      - /volume1/docker/homeassistant/config:/homeassistant
      - /volume1/docker/dao/data:/config
    ports:
      - <poortnummer>:5000
    restart: unless-stopped
    environment:
      - TZ=Europe/Amsterdam

Waarbij <docker-image> voor test-versie:
- ghcr.io/corneel27/dao-amd64-addon
- ghcr.io/corneel27/dao-aarch64-addon
- ghcr.io/corneel27/dao-i386-addon

en <docker-image> voor productie-versie:
- ghcr.io/corneel27/dao-amd64
- ghcr.io/corneel27/dao-aarch64
- ghcr.io/corneel27/dao-i386

@KC27 dit kun je in de openingspost verwerken zodra de productieversie ook live staat. Het stukje eronder mbt het builden kan dan weg. Ik stuur je via PM een volledig bijgewerkte tekst :-)

[Torch1969]

KC27 schreef op donderdag 15 mei 2025 @ 10:48:
Er is een nieuwe testversie gepubliceerd op Github in de addon-branche: versie 2025.5.0.rc4c
Dit staat er in de changelog:

• Start with a pre-builded repository on Github (thanks to bvw)
• Introduction of a check on "last invoice", warning when more than one year ago.
• Fix Dockerfile for build error Pillow library
• Corrected VAT-calculation when calculating the profit during the DAO optimal-calculation (reported bij bvw)
• Fix heatpump planning: when heat_demand-entity is false there will be no heat-pump power calculated in the first hour (reported by bvw)
• Fixed error planning machine when planning calculation is in the previous planned period (reported by @sjampeter)
• Fixed error and show error-message when no entities are configured for setting the calculated planning of a machine in HA (reported by llevering)
• Fixed error with postgresql during reporting of balance and calculation of baseloads (reported by @balk77)
• Fixed error not switching off pv-switch with negative prices with more than one pv-string

Voor het eerst is er een pre-build versie gemaakt.
Dit betekent: sneller installeren.
Gebruikers met HA-OS hoeven niks te doen alles staat goed ingesteld in config.yaml
Gebruikers die HA en DAO draaien in een container kunnen nu makkelijker en sneller installeren.
De addon-image staat op:
ghcr.io/corneel27/dao-aarch64-addon:2025.5.0.rc4c
Na het testen (over ca 1 tot 2 dagen) komt de productie release vrij op:
ghcr.io/corneel27/dao-aarch64:2025.5.0
Dus zonder addon in de naam en de rcxx toevoeging is er dan ook niet meer.
Opmerking : vervang evt aarch64 door amd64 of i386

Wie helpt mij om de TS aan te passen met deze info?

Planning:
Als deze test-versie wordt goedgekeurd (graag zoveel mogelijk testen) en is gepromoveerd naar de productieversie ga ik met de andere feature requests aan de gang omdat de invoering van het 15min-interval is uitgesteld.

@KC27 Ik ben wat door de testversie aan het klikken en het volgende valt me op:

In reports gaan een aantal zaken niet goed voor vandaag, morgen, vandaag en morgen. Zowel in tabel als grafiek, zowel in grid als balans. Bijvoorbeeld kosten/opbrengsten missen (grid/tabel&grafiek/vandaag), hele tabel mist (grid/tabel/morgen), internal server error (grid/grafiek/morgen), grafiek is leeg (balans/grafiek/morgen).
Soortgelijk iets in de savings tabellen en grafieken. Gegevens voor morgen ontbreken daar.

Als je het kunt reproduceren, dan is het waarschijnlijk een bug, zoniet, dan is het mijn test-omgeving

[KC27]

Torch1969 schreef op donderdag 15 mei 2025 @ 22:00:
[...]

@KC27 Ik ben wat door de testversie aan het klikken en het volgende valt me op:

In reports gaan een aantal zaken niet goed voor vandaag, morgen, vandaag en morgen. Zowel in tabel als grafiek, zowel in grid als balans. Bijvoorbeeld kosten/opbrengsten missen (grid/tabel&grafiek/vandaag), hele tabel mist (grid/tabel/morgen), internal server error (grid/grafiek/morgen), grafiek is leeg (balans/grafiek/morgen).
Soortgelijk iets in de savings tabellen en grafieken. Gegevens voor morgen ontbreken daar.

Als je het kunt reproduceren, dan is het waarschijnlijk een bug, zoniet, dan is het mijn test-omgeving

Ik krijg jouw fouten niet gereproduceerd.
Bijvoorbeeld grid/grafiek/morgen:

Dus waarschijnlijk zijn je settings in je testomgeving niet identiek.
Mochten anderen dezelfde fouten ervaring als @Torch1969 dan hoor ik het graag, want moet ik wel verder kijken....

[KC27]

@sjampeter en anderen
Ik ben zelf nog een klein foutje op het spoor gekomen in de "machine planning".
Ik heb een nieuwe testversie in de addon-branche gezet, versie 2025.5.0.rc5.
Willen jullie deze testen?

[Marcjeno1]

@KC27 De versienummering die jij gebruikt zit niet gekoppeld aan de versie van HA toch? Ik draai nog een oudere HA omgeving namelijk.

[KC27]

Marcjeno1 schreef op vrijdag 16 mei 2025 @ 08:17:
@KC27 De versienummering die jij gebruikt zit niet gekoppeld aan de versie van HA toch? Ik draai nog een oudere HA omgeving namelijk.

Nee: geen koppeling!
Wel een beetje dezelfde systematiek: jaar en maand geven aan in welke kalendermaand en versie het licht ziet. Het derde nummer is opvolgend.
Voor de communicatie met HA ben ik afhankelijk van de api van HA, zolang die hetzelfde blijft kan DAO met iedere HA-versie communiceren.
Bij HA zijn de nieuwe kalendermaand versies altijd versies met nieuwe functionaliteit en de daarop volgende versies zijn hoofdzakelijk bugfixes.

[Marcjeno1]

KC27 schreef op vrijdag 16 mei 2025 @ 09:19:
[...]

Nee: geen koppeling!
Wel een beetje dezelfde systematiek: jaar en maand geven aan in welke kalendermaand en versie het licht ziet. Het derde nummer is opvolgend.
Voor de communicatie met HA ben ik afhankelijk van de api van HA, zolang die hetzelfde blijft kan DAO met iedere HA-versie communiceren.
Bij HA zijn de nieuwe kalendermaand versies altijd versies met nieuwe functionaliteit en de daarop volgende versies zijn hoofdzakelijk bugfixes.

Oke dankjewel, ik zal van het weekend eens kijken of ik de nieuwe image gedraaid krijg. Ik heb inmiddels een sturing voor elkaar vanuit DAO -> HA -> Victron GX mqtt. Ik heb de waarde gebruikt die dao geeft op de power feed in. Deze kopieert hij nu als grid setpoint maar ik merk nu dus als de zon gaat schijnen dat de batterij op gaat laden omdat de grid setpoint niet mee veranderd als de zon feller begint te schijnen.

Hoe doen jullie dat dan? Jullie laten een automation meelopen die de PV meeneemt met het instellen van gridsetpoint + power feed in van de batterij? Dit probleem heb je natuurlijk alleen bij s'ochtends ontladen.

[KC27]

Marcjeno1 schreef op vrijdag 16 mei 2025 @ 09:46:
[...]


Oke dankjewel, ik zal van het weekend eens kijken of ik de nieuwe image gedraaid krijg. Ik heb inmiddels een sturing voor elkaar vanuit DAO -> HA -> Victron GX mqtt. Ik heb de waarde gebruikt die dao geeft op de power feed in. Deze kopieert hij nu als grid setpoint maar ik merk nu dus als de zon gaat schijnen dat de batterij op gaat laden omdat de grid setpoint niet mee veranderd als de zon feller begint te schijnen.

Hoe doen jullie dat dan? Jullie laten een automation meelopen die de PV meeneemt met het instellen van gridsetpoint + power feed in van de batterij? Dit probleem heb je natuurlijk alleen bij s'ochtends ontladen.

Het is maar net wat je wilt en wat je situatie is:

• wat is je strategie: minder kosten of minder inkopen?
• heb je meer pv-productie dan je verbruik zodat je geen energiebelasting terugkrijgt bij meer terugleveren
• zit je pv aansluiting achter de AC-out of naast de AC-in van je Victrons
• enz

Misschien kun je een plaatje van de berekening vanmorgen om 8 uur posten?

[balk]

Marcjeno1 schreef op vrijdag 16 mei 2025 @ 09:46:
[...]


Oke dankjewel, ik zal van het weekend eens kijken of ik de nieuwe image gedraaid krijg. Ik heb inmiddels een sturing voor elkaar vanuit DAO -> HA -> Victron GX mqtt. Ik heb de waarde gebruikt die dao geeft op de power feed in. Deze kopieert hij nu als grid setpoint maar ik merk nu dus als de zon gaat schijnen dat de batterij op gaat laden omdat de grid setpoint niet mee veranderd als de zon feller begint te schijnen.

Hoe doen jullie dat dan? Jullie laten een automation meelopen die de PV meeneemt met het instellen van gridsetpoint + power feed in van de batterij? Dit probleem heb je natuurlijk alleen bij s'ochtends ontladen.

Ik ben bezig voor mezelf om een strategie matrix te ontwikkelen. Wat te doen in welke situatie, accu vol/leeg/halfvol. Prijs hoog/laag/negatief/medium en daarna stijgend of dalend. Elk van die situaties heeft een eigen laad en PV strategie nodig. Vervolgens wil ik via een automation die matrix toepassen op mijn accu. Voorbeeld: Als DAO "0" geeft bij medium (trend up) prijs (tweede helft middag) bij volle accu, dan staat de accu op idle. Een wolkje zorgt dan voor E import van grid. Als de accu nog niet vol was, dan draai ik op dat moment NoM. etc. Zo'n matrix is erg afhankelijk van je wensen en aanwezige hardware. Mijn accu is ongeveer even groot als mijn dagopbrengst bijvoorbeeld. Ik doe dus een soort hybride tussen max opbrengst en min consumptie

[Marcjeno1]

KC27 schreef op vrijdag 16 mei 2025 @ 11:51:
[...]

Het is maar net wat je wilt en wat je situatie is:

• wat is je strategie: minder kosten of minder inkopen?
• heb je meer pv-productie dan je verbruik zodat je geen energiebelasting terugkrijgt bij meer terugleveren
• zit je pv aansluiting achter de AC-out of naast de AC-in van je Victrons
• enz

Misschien kun je een plaatje van de berekening vanmorgen om 8 uur posten?

Ik draai de strategie: minimize cost. Ik verbruik jaarlijks meer dan mijn PV installatie levert dus kan de energiebelasting wegstrepen.

De zonnepanelen draaien bij mij op de AC out van de Victrons. Wat ik eerder al zei merkte ik dat dao nog opdracht gaf om te gaan ontladen van mijn batterij met de set power feed in. Op dat moment kwam er ook al 3kw aan zonnestroom binnen en omdat de battery feed in op -1900 watt stond ging mijn batterij alsnog laden met ongeveer 900W. Ik heb nu een automation gemaakt die de zonnelevering meeneemt wanneer de battery feed in negatief is. Dus in dit voorbeeld zou dat -1900 - 3000 = -4900 op de grid set point.

Dit werkt momenteel heel mooi . Wanneer er 0 op de battery feed in staat wil ik dat stroom van pv op grid gezet wordt, dit heb ik er ook in verwerkt. En wanneer de battery feed in positief is, wil ik met PV batterij opladen. Volgens mij gebeurd er dan precies wat DAO berekent. Allemaal gelukt dankzij ChatGPT trouwens . Had dit zelf echt nooit voor elkaar gekregen.

[ Voor 3% gewijzigd door Marcjeno1 op 16-05-2025 15:22 ]

[balk]

@KC27 ik heb nu 2025.5.0.rc5 en krijg deze foutmelding bij bepalen van de baseloads:

code:

2025-05-16 22:46:32 info: Day Ahead Optimalisering versie: 2025.5.0.rc5
2025-05-16 22:46:32 info: Day Ahead Optimalisering gestart op: 16-05-2025 22:46:32
2025-05-16 22:46:32 info: Day Ahead Optimalisatie gestart: 16-05-2025 22:46:32 taak: calc_baseloads
2025-05-16 22:46:32 waarschuwing: "last invoice" (2022-09-01) is verouderd en moet worden bijgewerkt
2025-05-16 22:46:32 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 425, in calc_baseloads
    report.calc_save_baseloads()
  File "/root/dao/prog/da_report.py", line 2785, in calc_save_baseloads
    baseload = self.calc_weekday_baseload(weekday)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2711, in calc_weekday_baseload
    ev_consumption = self.get_sensor_week_sum(
                     ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2670, in get_sensor_week_sum
    for sensor in sensor_list:
TypeError: 'NoneType' object is not iterable
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3516, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3510, in main
    da_calc.run_task_function("calc_baseloads")
  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 425, in calc_baseloads
    report.calc_save_baseloads()
  File "/root/dao/prog/da_report.py", line 2785, in calc_save_baseloads
    baseload = self.calc_weekday_baseload(weekday)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2711, in calc_weekday_baseload
    ev_consumption = self.get_sensor_week_sum(
                     ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_report.py", line 2670, in get_sensor_week_sum
    for sensor in sensor_list:
TypeError: 'NoneType' object is not iterable

Opvallend is regel 4: waarschuwing: "last invoice" (2022-09-01) is verouderd en moet worden bijgewerkt

Gerelateerd aan https://github.com/corneel27/day-ahead/issues/212
Ik heb de beta geinstalleerd en dezelfde config gevoerd als de productie versie (data in postgres)

====
aha, die last invoice waarschuwing verdwijnt als ik dat aanpas in de config. Maar de error blijft.

====
Dit zit in de log van de addon. Er lijkt iets mis te gaan tussen DAO en HA.

code:

=> directory dao_data made, files copied
=> /root/dao/data doesn't exist, made
=> /root/dao/webserver/app/static/data exist
Setting up watches.
Watches established.
[2025-05-16 22:45:08 +0200] [15] [INFO] Starting gunicorn 23.0.0
[2025-05-16 22:45:08 +0200] [15] [INFO] Listening at: http://0.0.0.0:5000 (15)
[2025-05-16 22:45:08 +0200] [15] [INFO] Using worker: sync
[2025-05-16 22:45:08 +0200] [25] [INFO] Booting worker with pid: 25
[2025-05-16 22:45:08 +0200] [26] [INFO] Booting worker with pid: 26
fout:root:Check your settings for Home Assistant database
../data/options.json MODIFY 
Setting up watches.
Watches established.
Traceback (most recent call last):
  File "/root/dao/prog/da_scheduler.py", line 64, in <module>
    main()
  File "/root/dao/prog/da_scheduler.py", line 59, in main
    da_sched = DaScheduler("../data/options.json")
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/prog/da_scheduler.py", line 9, in __init__
    super().__init__(file_name)
  File "/root/dao/prog/da_base.py", line 93, in __init__
    super().__init__(hassurl=self.hassurl, token=self.hasstoken)
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 36, in __init__
    self._assert_api_running()
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 40, in _assert_api_running
    if not self._api_is_running():
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/hassapi/client/base.py", line 46, in _api_is_running
    return self._get("/")["message"] == "API running."  # 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.Unauthorised: 401 status code returned from http://192.168.1.7:8123/api/
../data/secrets.json MODIFY 
./watchdog.sh: line 6: kill: (29) - No such process
Setting up watches.
Watches established.
../data/options.json MODIFY 
Setting up watches.
Watches established.

[ Voor 38% gewijzigd door balk op 16-05-2025 23:00 . Reden: last invoice ]

[KC27]

Ik denk dat er iets fout zit met de configuratie van de HA database in je settings.
Het kan ook zijn dat je bij het wijzigen van je settings een typefoutje hebt gemaakt (bijv komma vergeten), waardoor het geen geldig json-bestand meer is.

[KC27]

@sjampeter en anderen.
Er kwam vanavond bij mij toch nog een foutje aan het licht in de machine planning.
Dat is verholpen in versie 2025.5.0.rc5a in de addon-branche.

[ Voor 6% gewijzigd door KC27 op 16-05-2025 23:12 ]

[balk]

KC27 schreef op vrijdag 16 mei 2025 @ 23:09:
Ik denk dat er iets fout zit met de configuratie van de HA database in je settings.
Het kan ook zijn dat je bij het wijzigen van je settings een typefoutje hebt gemaakt (bijv komma vergeten), waardoor het geen geldig json-bestand meer is.

die unauthorized heb ik verholpen door een nieuwe token aan te maken. Maar de foutmelding blijft

[balk]

Ik heb ook mijn json gecheckt. Er zat wel een fout in (duplicate key in reduced hours) maar geen komma verkeerd. Deze duplicate veroorzaakte niet de foutmelding. Ik heb een trace op github gezet.

[mgroen81]

@KC27 Ik heb sinds vanmorgen 2025.5.0.rc5a op HA OS draaien en deze werkt voor mij foutloos.
Ik heb geen machines geconfigureerd.
Ik heb de baseload bestanden van de vorige configuratie overgezet dus dat heb ik niet getest.

[ Voor 27% gewijzigd door mgroen81 op 18-05-2025 21:28 ]

[Njord1]

Wie kan mij helpen om 3 stuks Marstek met Elfin in DAO te intregeren?

[hood]

Njord1 schreef op zondag 18 mei 2025 @ 13:30:
Wie kan mij helpen om 3 stuks Marstek met Elfin in DAO te intregeren?

Waar loop je vast? Ik denk dat er hier veel mensen bereid zijn om je te helpen. Begin met je eerst opzet en laat weten waar je vast loopt en welk deel van de handleiding je niet begrijpt.

[Njord1]

hood schreef op zondag 18 mei 2025 @ 13:52:
[...]

Waar loop je vast? Ik denk dat er hier veel mensen bereid zijn om je te helpen. Begin met je eerst opzet en laat weten waar je vast loopt en welk deel van de handleiding je niet begrijpt.

Ik heb totaal geen idee, hoe ik het moet opzetten, ben een absolute nitwit in dit soort dingen, dus alle hulp vanaf scratch is zeer welkom.

[storeman]

@Njord1 zo werkt het hier niet. Je wil iets, dan moet je ook iets proberen. De documentatie helpt je op weg en er staan ook een groot aantal configs in dit topic. Begin zo klein en simpel mogelijk met je wensen. Lees de documentatie, pas dingen aan en probeer. Als je dan concrete problemen hebt of zaken niet begrijpt, dan is hier een zeer behulpzame community

[hood]

Njord1 schreef op zondag 18 mei 2025 @ 14:29:
[...]

Ik heb totaal geen idee, hoe ik het moet opzetten, ben een absolute nitwit in dit soort dingen, dus alle hulp vanaf scratch is zeer welkom.

Aangezien je in dit topic terecht bent gekomen neem ik aan dat je weet wat Home Assistant is. Is het al gelukt om DOA te installeren?
Neem dit even door https://github.com/corneel27/day-ahead/blob/main/dao/DOCS.md

[Njord1]

hood schreef op zondag 18 mei 2025 @ 15:16:
[...]


Aangezien je in dit topic terecht bent gekomen neem ik aan dat je weet wat Home Assistant is. Is het al gelukt om DOA te installeren?
Neem dit even door https://github.com/corneel27/day-ahead/blob/main/dao/DOCS.md

Dat is allemaal gelukt, dank zij de beschrijvingen, alle 3 Marsteks lees ik uit met elk een Elwin in HA, maar na 3x DOA opnieuw installeren omdat het hele DOA niet meer werkt na fouten en het niet meer weet, vraag ik daarom hulp, simpel omdat ik er geen kaas van heb gegeten, maar ik zal geen vragen meer stellen, jammer dat er geen hulp is voor mensen die het echt niet weten.

[hood]

Njord1 schreef op zondag 18 mei 2025 @ 16:44:
[...]

Dat is allemaal gelukt, dank zij de beschrijvingen, alle 3 Marsteks lees ik uit met elk een Elwin in HA, maar na 3x DOA opnieuw installeren omdat het hele DOA niet meer werkt na fouten en het niet meer weet, vraag ik daarom hulp, simpel omdat ik er geen kaas van heb gegeten, maar ik zal geen vragen meer stellen, jammer dat er geen hulp is voor mensen die het echt niet weten.

Sorry hoor, je stelt een vraag met nul informatie. Wat verwacht je? Ik stel voor dat je met een versie install begint en je start met de basis instellingen. Heb je errors waar je niet uitkomt dat post je die hier en dan kunnen we je helpen. Eerder niet, we hebben hier geen glazen bol.

[Roekeloos]

Hier krijg ik het helaas ook niet aan de praat. Steeds "Geen oplossing voor: minimize cost", terwijl ik uit de overige logging geen root cause kan halen.

Logging:

code:

2025-05-18 19:00:00 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-05-18 19:00:00 info: Day Ahead Optimalisering versie: 2025.4.2
2025-05-18 19:00:00 info: Day Ahead Optimalisering gestart op: 18-05-2025 19:00:00
2025-05-18 19:00:00 debug: Locatie: latitude 52.3731339 longitude: 4.8903147
2025-05-18 19:00:00 info: Day Ahead Optimalisatie gestart: 18-05-2025 19:00:00 taak: calc_optimum
2025-05-18 19:00:00 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 479 in /root/dao/prog/da_base.py
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/ HTTP/1.1" 200 26
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/config HTTP/1.1" 200 5345
2025-05-18 19:00:00 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 144 in /root/dao/prog/da_base.py
2025-05-18 19:00:00 info: Debug = False
2025-05-18 19:00:00 debug: Prognose data:
          time                tijd   temp  glob_rad  pv_rad  da_price
0   1747587600 2025-05-18 19:00:00  19.00     75.00   65.17      0.10
1   1747591200 2025-05-18 20:00:00  18.00     32.00   25.43      0.12
2   1747594800 2025-05-18 21:00:00  17.00      3.00    3.00      0.13
3   1747598400 2025-05-18 22:00:00  16.00      0.00    0.00      0.12
4   1747602000 2025-05-18 23:00:00  15.00      0.00    0.00      0.10
5   1747605600 2025-05-19 00:00:00  14.00      0.00    0.00      0.11
6   1747609200 2025-05-19 01:00:00  14.00      0.00    0.00      0.10
7   1747612800 2025-05-19 02:00:00  14.00      0.00    0.00      0.09
8   1747616400 2025-05-19 03:00:00  13.00      0.00    0.00      0.09
9   1747620000 2025-05-19 04:00:00  13.00      0.00    0.00      0.09
10  1747623600 2025-05-19 05:00:00  13.00      1.00    1.00      0.10
11  1747627200 2025-05-19 06:00:00  13.00     24.00   21.19      0.13
12  1747630800 2025-05-19 07:00:00  14.00     72.00    6.61      0.14
13  1747634400 2025-05-19 08:00:00  15.00    129.00   11.84      0.12
14  1747638000 2025-05-19 09:00:00  16.00    186.00   87.34      0.09
15  1747641600 2025-05-19 10:00:00  17.00    238.00  190.83      0.06
16  1747645200 2025-05-19 11:00:00  18.00    279.00  269.06      0.03
17  1747648800 2025-05-19 12:00:00  19.00    304.00  320.22      0.01
18  1747652400 2025-05-19 13:00:00  20.00    319.00  350.73      0.01
19  1747656000 2025-05-19 14:00:00  21.00    311.00  345.00      0.01
20  1747659600 2025-05-19 15:00:00  21.00    285.00  312.36      0.03
21  1747663200 2025-05-19 16:00:00  21.00    247.00  263.21      0.07
22  1747666800 2025-05-19 17:00:00  21.00    197.00  200.22      0.09
23  1747670400 2025-05-19 18:00:00  21.00    141.00  133.80      0.11
24  1747674000 2025-05-19 19:00:00  20.00     84.00   72.71      0.13
25  1747677600 2025-05-19 20:00:00  19.00     34.00   26.84      0.19
26  1747681200 2025-05-19 21:00:00  18.00      3.00    3.00      0.15
27  1747684800 2025-05-19 22:00:00  17.00      0.00    0.00      0.12
28  1747688400 2025-05-19 23:00:00  16.00      0.00    0.00      0.10
2025-05-18 19:00:00 info: Zelf berekende baseload
2025-05-18 19:00:00 debug: Query: 
 SELECT concat(year(from_unixtime(t1.time)), %(concat_1)s, lpad(month(from_unixtime(t1.time)), %(lpad_1)s, %(lpad_2)s)) AS maand, min(from_unixtime(t1.time)) AS vanaf, max(from_unixtime(t1.time)) AS tot, sum(t1.value) AS consumption 
FROM `values` AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = %(code_1)s AND t1.time >= unix_timestamp(%(unix_timestamp_1)s) AND t1.time < unix_timestamp(%(unix_timestamp_2)s) GROUP BY maand
2025-05-18 19:00:00 debug: Query: 
 SELECT concat(year(from_unixtime(t1.time)), %(concat_1)s, lpad(month(from_unixtime(t1.time)), %(lpad_1)s, %(lpad_2)s)) AS maand, min(from_unixtime(t1.time)) AS vanaf, max(from_unixtime(t1.time)) AS tot, sum(t1.value) AS production 
FROM `values` AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = %(code_1)s AND t1.time >= unix_timestamp(%(unix_timestamp_1)s) AND t1.time < unix_timestamp(%(unix_timestamp_2)s) GROUP BY maand
2025-05-18 19:00:00 debug: Query: 
 SELECT concat(year(from_unixtime(t1.time)), %(concat_1)s, lpad(month(from_unixtime(t1.time)), %(lpad_1)s, %(lpad_2)s)) AS maand, min(from_unixtime(t1.time)) AS vanaf, max(from_unixtime(t1.time)) AS tot, sum(t1.value) AS cost 
FROM `values` AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = %(code_1)s AND t1.time >= unix_timestamp(%(unix_timestamp_1)s) AND t1.time < unix_timestamp(%(unix_timestamp_2)s) GROUP BY maand
2025-05-18 19:00:00 debug: Query: 
 SELECT concat(year(from_unixtime(t1.time)), %(concat_1)s, lpad(month(from_unixtime(t1.time)), %(lpad_1)s, %(lpad_2)s)) AS maand, min(from_unixtime(t1.time)) AS vanaf, max(from_unixtime(t1.time)) AS tot, sum(t1.value) AS profit 
FROM `values` AS t1, variabel AS v1 
WHERE t1.variabel = v1.id AND v1.code = %(code_1)s AND t1.time >= unix_timestamp(%(unix_timestamp_1)s) AND t1.time < unix_timestamp(%(unix_timestamp_2)s) GROUP BY maand
2025-05-18 19:00:00 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-05-18 19:00:00 debug: sensordata raw, sensor sensor.dsmr_reading_electricity_delivered_1,
                        uur                tijd                 tot  consumption
tijd                                                                           
2025-05-17 00:00:00  00:00 2025-05-17 00:00:00 2025-05-17 00:00:00         0.47
2025-05-17 01:00:00  01:00 2025-05-17 01:00:00 2025-05-17 01:00:00         0.36
2025-05-17 02:00:00  02:00 2025-05-17 02:00:00 2025-05-17 02:00:00         0.36
2025-05-17 03:00:00  03:00 2025-05-17 03:00:00 2025-05-17 03:00:00         0.56
2025-05-17 04:00:00  04:00 2025-05-17 04:00:00 2025-05-17 04:00:00         0.30
2025-05-17 05:00:00  05:00 2025-05-17 05:00:00 2025-05-17 05:00:00         0.33
2025-05-17 06:00:00  06:00 2025-05-17 06:00:00 2025-05-17 06:00:00         0.12
2025-05-17 07:00:00  07:00 2025-05-17 07:00:00 2025-05-17 07:00:00         0.02
2025-05-17 08:00:00  08:00 2025-05-17 08:00:00 2025-05-17 08:00:00         0.01
2025-05-17 09:00:00  09:00 2025-05-17 09:00:00 2025-05-17 09:00:00         0.12
2025-05-17 10:00:00  10:00 2025-05-17 10:00:00 2025-05-17 10:00:00         0.00
2025-05-17 11:00:00  11:00 2025-05-17 11:00:00 2025-05-17 11:00:00         0.00
2025-05-17 12:00:00  12:00 2025-05-17 12:00:00 2025-05-17 12:00:00         0.03
2025-05-17 13:00:00  13:00 2025-05-17 13:00:00 2025-05-17 13:00:00         2.66
2025-05-17 14:00:00  14:00 2025-05-17 14:00:00 2025-05-17 14:00:00         1.08
2025-05-17 15:00:00  15:00 2025-05-17 15:00:00 2025-05-17 15:00:00         7.90
2025-05-17 16:00:00  16:00 2025-05-17 16:00:00 2025-05-17 16:00:00         7.42
2025-05-17 17:00:00  17:00 2025-05-17 17:00:00 2025-05-17 17:00:00         8.62
2025-05-17 18:00:00  18:00 2025-05-17 18:00:00 2025-05-17 18:00:00         9.43
2025-05-17 19:00:00  19:00 2025-05-17 19:00:00 2025-05-17 19:00:00         1.05
2025-05-17 20:00:00  20:00 2025-05-17 20:00:00 2025-05-17 20:00:00         0.28
2025-05-17 21:00:00  21:00 2025-05-17 21:00:00 2025-05-17 21:00:00         0.60
2025-05-17 22:00:00  22:00 2025-05-17 22:00:00 2025-05-17 22:00:00         0.63
2025-05-17 23:00:00  23:00 2025-05-17 23:00:00 2025-05-17 23:00:00         0.95
2025-05-18 00:00:00  00:00 2025-05-18 00:00:00 2025-05-18 00:00:00         0.90
2025-05-18 01:00:00  01:00 2025-05-18 01:00:00 2025-05-18 01:00:00         0.76
2025-05-18 02:00:00  02:00 2025-05-18 02:00:00 2025-05-18 02:00:00         0.31
2025-05-18 03:00:00  03:00 2025-05-18 03:00:00 2025-05-18 03:00:00         0.35
2025-05-18 04:00:00  04:00 2025-05-18 04:00:00 2025-05-18 04:00:00         0.30
2025-05-18 05:00:00  05:00 2025-05-18 05:00:00 2025-05-18 05:00:00         1.75
2025-05-18 06:00:00  06:00 2025-05-18 06:00:00 2025-05-18 06:00:00         0.33
2025-05-18 07:00:00  07:00 2025-05-18 07:00:00 2025-05-18 07:00:00         0.10
2025-05-18 08:00:00  08:00 2025-05-18 08:00:00 2025-05-18 08:00:00         0.10
2025-05-18 09:00:00  09:00 2025-05-18 09:00:00 2025-05-18 09:00:00         1.50
2025-05-18 10:00:00  10:00 2025-05-18 10:00:00 2025-05-18 10:00:00         0.01
2025-05-18 11:00:00  11:00 2025-05-18 11:00:00 2025-05-18 11:00:00         0.00
2025-05-18 12:00:00  12:00 2025-05-18 12:00:00 2025-05-18 12:00:00         0.00
2025-05-18 13:00:00  13:00 2025-05-18 13:00:00 2025-05-18 13:00:00         0.00
2025-05-18 14:00:00  14:00 2025-05-18 14:00:00 2025-05-18 14:00:00         0.00
2025-05-18 15:00:00  15:00 2025-05-18 15:00:00 2025-05-18 15:00:00         0.00
2025-05-18 16:00:00  16:00 2025-05-18 16:00:00 2025-05-18 16:00:00         0.00
2025-05-18 17:00:00  17:00 2025-05-18 17:00:00 2025-05-18 17:00:00         0.00
2025-05-18 19:00:00 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-05-18 19:00:00 debug: sensordata raw, sensor sensor.dsmr_reading_electricity_delivered_2,
                        uur                tijd                 tot  consumption
tijd                                                                           
2025-05-17 00:00:00  00:00 2025-05-17 00:00:00 2025-05-17 00:00:00            0
2025-05-17 01:00:00  01:00 2025-05-17 01:00:00 2025-05-17 01:00:00            0
2025-05-17 02:00:00  02:00 2025-05-17 02:00:00 2025-05-17 02:00:00            0
2025-05-17 03:00:00  03:00 2025-05-17 03:00:00 2025-05-17 03:00:00            0
2025-05-17 04:00:00  04:00 2025-05-17 04:00:00 2025-05-17 04:00:00            0
2025-05-17 05:00:00  05:00 2025-05-17 05:00:00 2025-05-17 05:00:00            0
2025-05-17 06:00:00  06:00 2025-05-17 06:00:00 2025-05-17 06:00:00            0
2025-05-17 07:00:00  07:00 2025-05-17 07:00:00 2025-05-17 07:00:00            0
2025-05-17 08:00:00  08:00 2025-05-17 08:00:00 2025-05-17 08:00:00            0
2025-05-17 09:00:00  09:00 2025-05-17 09:00:00 2025-05-17 09:00:00            0
2025-05-17 10:00:00  10:00 2025-05-17 10:00:00 2025-05-17 10:00:00            0
2025-05-17 11:00:00  11:00 2025-05-17 11:00:00 2025-05-17 11:00:00            0
2025-05-17 12:00:00  12:00 2025-05-17 12:00:00 2025-05-17 12:00:00            0
2025-05-17 13:00:00  13:00 2025-05-17 13:00:00 2025-05-17 13:00:00            0
2025-05-17 14:00:00  14:00 2025-05-17 14:00:00 2025-05-17 14:00:00            0
2025-05-17 15:00:00  15:00 2025-05-17 15:00:00 2025-05-17 15:00:00            0
2025-05-17 16:00:00  16:00 2025-05-17 16:00:00 2025-05-17 16:00:00            0
2025-05-17 17:00:00  17:00 2025-05-17 17:00:00 2025-05-17 17:00:00            0
2025-05-17 18:00:00  18:00 2025-05-17 18:00:00 2025-05-17 18:00:00            0
2025-05-17 19:00:00  19:00 2025-05-17 19:00:00 2025-05-17 19:00:00            0
2025-05-17 20:00:00  20:00 2025-05-17 20:00:00 2025-05-17 20:00:00            0
2025-05-17 21:00:00  21:00 2025-05-17 21:00:00 2025-05-17 21:00:00            0
2025-05-17 22:00:00  22:00 2025-05-17 22:00:00 2025-05-17 22:00:00            0
2025-05-17 23:00:00  23:00 2025-05-17 23:00:00 2025-05-17 23:00:00            0
2025-05-18 00:00:00  00:00 2025-05-18 00:00:00 2025-05-18 00:00:00            0
2025-05-18 01:00:00  01:00 2025-05-18 01:00:00 2025-05-18 01:00:00            0
2025-05-18 02:00:00  02:00 2025-05-18 02:00:00 2025-05-18 02:00:00            0
2025-05-18 03:00:00  03:00 2025-05-18 03:00:00 2025-05-18 03:00:00            0
2025-05-18 04:00:00  04:00 2025-05-18 04:00:00 2025-05-18 04:00:00            0
2025-05-18 05:00:00  05:00 2025-05-18 05:00:00 2025-05-18 05:00:00            0
2025-05-18 06:00:00  06:00 2025-05-18 06:00:00 2025-05-18 06:00:00            0
2025-05-18 07:00:00  07:00 2025-05-18 07:00:00 2025-05-18 07:00:00            0
2025-05-18 08:00:00  08:00 2025-05-18 08:00:00 2025-05-18 08:00:00            0
2025-05-18 09:00:00  09:00 2025-05-18 09:00:00 2025-05-18 09:00:00            0
2025-05-18 10:00:00  10:00 2025-05-18 10:00:00 2025-05-18 10:00:00            0
2025-05-18 11:00:00  11:00 2025-05-18 11:00:00 2025-05-18 11:00:00            0
2025-05-18 12:00:00  12:00 2025-05-18 12:00:00 2025-05-18 12:00:00            0
2025-05-18 13:00:00  13:00 2025-05-18 13:00:00 2025-05-18 13:00:00            0
2025-05-18 14:00:00  14:00 2025-05-18 14:00:00 2025-05-18 14:00:00            0
2025-05-18 15:00:00  15:00 2025-05-18 15:00:00 2025-05-18 15:00:00            0
2025-05-18 16:00:00  16:00 2025-05-18 16:00:00 2025-05-18 16:00:00            0
2025-05-18 17:00:00  17:00 2025-05-18 17:00:00 2025-05-18 17:00:00            0
2025-05-18 19:00:00 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-05-18 19:00:00 debug: sensordata raw, sensor sensor.dsmr_reading_electricity_returned_1,
                        uur                tijd                 tot  production
tijd                                                                          
2025-05-17 00:00:00  00:00 2025-05-17 00:00:00 2025-05-17 00:00:00        0.00
2025-05-17 01:00:00  01:00 2025-05-17 01:00:00 2025-05-17 01:00:00        0.00
2025-05-17 02:00:00  02:00 2025-05-17 02:00:00 2025-05-17 02:00:00        0.00
2025-05-17 03:00:00  03:00 2025-05-17 03:00:00 2025-05-17 03:00:00        0.00
2025-05-17 04:00:00  04:00 2025-05-17 04:00:00 2025-05-17 04:00:00        0.00
2025-05-17 05:00:00  05:00 2025-05-17 05:00:00 2025-05-17 05:00:00        0.00
2025-05-17 06:00:00  06:00 2025-05-17 06:00:00 2025-05-17 06:00:00        0.02
2025-05-17 07:00:00  07:00 2025-05-17 07:00:00 2025-05-17 07:00:00        0.41
2025-05-17 08:00:00  08:00 2025-05-17 08:00:00 2025-05-17 08:00:00        1.81
2025-05-17 09:00:00  09:00 2025-05-17 09:00:00 2025-05-17 09:00:00        3.20
2025-05-17 10:00:00  10:00 2025-05-17 10:00:00 2025-05-17 10:00:00        5.40
2025-05-17 11:00:00  11:00 2025-05-17 11:00:00 2025-05-17 11:00:00        4.36
2025-05-17 12:00:00  12:00 2025-05-17 12:00:00 2025-05-17 12:00:00        4.16
2025-05-17 13:00:00  13:00 2025-05-17 13:00:00 2025-05-17 13:00:00        3.36
2025-05-17 14:00:00  14:00 2025-05-17 14:00:00 2025-05-17 14:00:00        3.97
2025-05-17 15:00:00  15:00 2025-05-17 15:00:00 2025-05-17 15:00:00        0.05
2025-05-17 16:00:00  16:00 2025-05-17 16:00:00 2025-05-17 16:00:00        0.00
2025-05-17 17:00:00  17:00 2025-05-17 17:00:00 2025-05-17 17:00:00        0.00
2025-05-17 18:00:00  18:00 2025-05-17 18:00:00 2025-05-17 18:00:00        0.00
2025-05-17 19:00:00  19:00 2025-05-17 19:00:00 2025-05-17 19:00:00        0.00
2025-05-17 20:00:00  20:00 2025-05-17 20:00:00 2025-05-17 20:00:00        0.00
2025-05-17 21:00:00  21:00 2025-05-17 21:00:00 2025-05-17 21:00:00        0.00
2025-05-17 22:00:00  22:00 2025-05-17 22:00:00 2025-05-17 22:00:00        0.00
2025-05-17 23:00:00  23:00 2025-05-17 23:00:00 2025-05-17 23:00:00        0.08
2025-05-18 00:00:00  00:00 2025-05-18 00:00:00 2025-05-18 00:00:00        0.00
2025-05-18 01:00:00  01:00 2025-05-18 01:00:00 2025-05-18 01:00:00        0.00
2025-05-18 02:00:00  02:00 2025-05-18 02:00:00 2025-05-18 02:00:00        0.00
2025-05-18 03:00:00  03:00 2025-05-18 03:00:00 2025-05-18 03:00:00        0.00
2025-05-18 04:00:00  04:00 2025-05-18 04:00:00 2025-05-18 04:00:00        0.00
2025-05-18 05:00:00  05:00 2025-05-18 05:00:00 2025-05-18 05:00:00        0.00
2025-05-18 06:00:00  06:00 2025-05-18 06:00:00 2025-05-18 06:00:00        0.00
2025-05-18 07:00:00  07:00 2025-05-18 07:00:00 2025-05-18 07:00:00        0.05
2025-05-18 08:00:00  08:00 2025-05-18 08:00:00 2025-05-18 08:00:00        0.31
2025-05-18 09:00:00  09:00 2025-05-18 09:00:00 2025-05-18 09:00:00        0.29
2025-05-18 10:00:00  10:00 2025-05-18 10:00:00 2025-05-18 10:00:00        1.28
2025-05-18 11:00:00  11:00 2025-05-18 11:00:00 2025-05-18 11:00:00        2.50
2025-05-18 12:00:00  12:00 2025-05-18 12:00:00 2025-05-18 12:00:00        3.17
2025-05-18 13:00:00  13:00 2025-05-18 13:00:00 2025-05-18 13:00:00        6.16
2025-05-18 14:00:00  14:00 2025-05-18 14:00:00 2025-05-18 14:00:00        6.77
2025-05-18 15:00:00  15:00 2025-05-18 15:00:00 2025-05-18 15:00:00        3.76
2025-05-18 16:00:00  16:00 2025-05-18 16:00:00 2025-05-18 16:00:00        2.19
2025-05-18 17:00:00  17:00 2025-05-18 17:00:00 2025-05-18 17:00:00        1.62
2025-05-18 19:00:00 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-05-18 19:00:00 debug: sensordata raw, sensor sensor.dsmr_reading_electricity_returned_2,
                        uur                tijd                 tot  production
tijd                                                                          
2025-05-17 00:00:00  00:00 2025-05-17 00:00:00 2025-05-17 00:00:00           0
2025-05-17 01:00:00  01:00 2025-05-17 01:00:00 2025-05-17 01:00:00           0
2025-05-17 02:00:00  02:00 2025-05-17 02:00:00 2025-05-17 02:00:00           0
2025-05-17 03:00:00  03:00 2025-05-17 03:00:00 2025-05-17 03:00:00           0
2025-05-17 04:00:00  04:00 2025-05-17 04:00:00 2025-05-17 04:00:00           0
2025-05-17 05:00:00  05:00 2025-05-17 05:00:00 2025-05-17 05:00:00           0
2025-05-17 06:00:00  06:00 2025-05-17 06:00:00 2025-05-17 06:00:00           0
2025-05-17 07:00:00  07:00 2025-05-17 07:00:00 2025-05-17 07:00:00           0
2025-05-17 08:00:00  08:00 2025-05-17 08:00:00 2025-05-17 08:00:00           0
2025-05-17 09:00:00  09:00 2025-05-17 09:00:00 2025-05-17 09:00:00           0
2025-05-17 10:00:00  10:00 2025-05-17 10:00:00 2025-05-17 10:00:00           0
2025-05-17 11:00:00  11:00 2025-05-17 11:00:00 2025-05-17 11:00:00           0
2025-05-17 12:00:00  12:00 2025-05-17 12:00:00 2025-05-17 12:00:00           0
2025-05-17 13:00:00  13:00 2025-05-17 13:00:00 2025-05-17 13:00:00           0
2025-05-17 14:00:00  14:00 2025-05-17 14:00:00 2025-05-17 14:00:00           0
2025-05-17 15:00:00  15:00 2025-05-17 15:00:00 2025-05-17 15:00:00           0
2025-05-17 16:00:00  16:00 2025-05-17 16:00:00 2025-05-17 16:00:00           0
2025-05-17 17:00:00  17:00 2025-05-17 17:00:00 2025-05-17 17:00:00           0
2025-05-17 18:00:00  18:00 2025-05-17 18:00:00 2025-05-17 18:00:00           0
2025-05-17 19:00:00  19:00 2025-05-17 19:00:00 2025-05-17 19:00:00           0
2025-05-17 20:00:00  20:00 2025-05-17 20:00:00 2025-05-17 20:00:00           0
2025-05-17 21:00:00  21:00 2025-05-17 21:00:00 2025-05-17 21:00:00           0
2025-05-17 22:00:00  22:00 2025-05-17 22:00:00 2025-05-17 22:00:00           0
2025-05-17 23:00:00  23:00 2025-05-17 23:00:00 2025-05-17 23:00:00           0
2025-05-18 00:00:00  00:00 2025-05-18 00:00:00 2025-05-18 00:00:00           0
2025-05-18 01:00:00  01:00 2025-05-18 01:00:00 2025-05-18 01:00:00           0
2025-05-18 02:00:00  02:00 2025-05-18 02:00:00 2025-05-18 02:00:00           0
2025-05-18 03:00:00  03:00 2025-05-18 03:00:00 2025-05-18 03:00:00           0
2025-05-18 04:00:00  04:00 2025-05-18 04:00:00 2025-05-18 04:00:00           0
2025-05-18 05:00:00  05:00 2025-05-18 05:00:00 2025-05-18 05:00:00           0
2025-05-18 06:00:00  06:00 2025-05-18 06:00:00 2025-05-18 06:00:00           0
2025-05-18 07:00:00  07:00 2025-05-18 07:00:00 2025-05-18 07:00:00           0
2025-05-18 08:00:00  08:00 2025-05-18 08:00:00 2025-05-18 08:00:00           0
2025-05-18 09:00:00  09:00 2025-05-18 09:00:00 2025-05-18 09:00:00           0
2025-05-18 10:00:00  10:00 2025-05-18 10:00:00 2025-05-18 10:00:00           0
2025-05-18 11:00:00  11:00 2025-05-18 11:00:00 2025-05-18 11:00:00           0
2025-05-18 12:00:00  12:00 2025-05-18 12:00:00 2025-05-18 12:00:00           0
2025-05-18 13:00:00  13:00 2025-05-18 13:00:00 2025-05-18 13:00:00           0
2025-05-18 14:00:00  14:00 2025-05-18 14:00:00 2025-05-18 14:00:00           0
2025-05-18 15:00:00  15:00 2025-05-18 15:00:00 2025-05-18 15:00:00           0
2025-05-18 16:00:00  16:00 2025-05-18 16:00:00 2025-05-18 16:00:00           0
2025-05-18 17:00:00  17:00 2025-05-18 17:00:00 2025-05-18 17:00:00           0
2025-05-18 19:00:00 debug: query get prognose data:
 SELECT from_unixtime(p1.time) AS tijd, p1.value AS consumption, p2.value AS production, %(param_1)s 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 = %(code_1)s AND p2.variabel = v2.id AND v2.code = %(code_2)s AND p1.time >= unix_timestamp(%(unix_timestamp_1)s) AND p1.time < unix_timestamp(%(unix_timestamp_2)s)
2025-05-18 19:00:00 info: Verbruik dit contractjaar: 707.461 kWh
2025-05-18 19:00:00 info: Productie dit contractjaar: 856.428 kWh
2025-05-18 19:00:00 info: All taxes refund (alles wordt gesaldeerd)
2025-05-18 19:00:00 info: No reduced hours applied for Accu
2025-05-18 19:00:00 debug: cycle cost: 0 eur/kWh
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/states/sensor.solaredge_huis_b1_state_of_energy HTTP/1.1" 200 449
2025-05-18 19:00:00 info: Startwaarde SoC Accu: 11.0%
2025-05-18 19:00:00 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/states/input_boolean.dao_plugged_in HTTP/1.1" 200 350
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/states/input_boolean.dao_car_home HTTP/1.1" 200 346
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/states/sensor.rik_s_tesla_battery HTTP/1.1" 200 485
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/states/input_number.dao_target_soc HTTP/1.1" 200 442
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/states/input_datetime.dao_target_departure HTTP/1.1" 200 499
2025-05-18 19:00:00 info: Instellingen voor laden van EV: Tesla
2025-05-18 19:00:00 info:  Ampere  Effic. Grid kW Accu kW
2025-05-18 19:00:00 info:    0.00    0.00    0.00    0.00
2025-05-18 19:00:00 info:   16.00    0.90   11.04    9.94
2025-05-18 19:00:00 info: Capaciteit accu: 57.5 kWh
2025-05-18 19:00:00 info: Maximaal laadvermogen: 11.04 kW
2025-05-18 19:00:00 info: Klaar met laden op: 18-05-2025 09:00:00
2025-05-18 19:00:00 info: Huidig laadniveau: 61.0 %
2025-05-18 19:00:00 info: Gewenst laadniveau:100.0 %
2025-05-18 19:00:00 info: Marge voor het laden: 4 %
2025-05-18 19:00:00 info: Locatie: on
2025-05-18 19:00:00 info: Ingeplugged:True
2025-05-18 19:00:00 info: Benodigde energie: -99.36 kWh
2025-05-18 19:00:00 info: Tijd nodig om te laden: -10.00 uur
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/states/input_boolean.dao_charging HTTP/1.1" 200 346
2025-05-18 19:00:00 debug: Starting new HTTP connection (1): supervisor:80
2025-05-18 19:00:00 debug: http://supervisor:80 "GET /core/api/states/number.wallbox_pulsar_pro_sn_1140416_maximum_charging_current HTTP/1.1" 200 447
2025-05-18 19:00:00 info: Afgerond naar hele uren: -10
2025-05-18 19:00:00 info: Stand laden schakelaar: on
2025-05-18 19:00:00 info: Stand aantal ampere laden: 32 A
2025-05-18 19:00:00 info: Opladen wordt niet ingepland, omdat auto is niet huis, opgegeven tijdstip (2025-05-18 09:00:00) is verouderd.
2025-05-18 19:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland
Starting solution of the Linear programming relaxation problem using Dual Simplex
Clp0024I Matrix will be packed to eliminate 174 small elements
Coin0507I Presolve determined that the problem was infeasible with tolerance of 1e-08
Clp3003W Analysis indicates model infeasible or unbounded
Clp0014I Perturbing problem by 0.001% of 0.15826545 - largest nonzero change 0 ( 0%) - largest zero change 0.00020017253
Clp0006I 0  Obj -999.98321 Primal inf 9828.1663 (60)
Clp0001I Primal infeasible - objective value -130.1095
Clp0032I PrimalInfeasible objective -130.1094988 - 11 iterations time 0.002
2025-05-18 19:00:00 waarschuwing: Geen oplossing  voor: minimize cost
2025-05-18 19:00:00 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 482 in /root/dao/prog/da_base.py
Clp3003W Analysis indicates model infeasible or unbounded
Clp0014I Perturbing problem by 0.001% of 0.15826545 - largest nonzero change 0 ( 0%) - largest zero change 0.00020017253
Clp0006I 0  Obj -999.98321 Primal inf 9828.1663 (60)
Clp0001I Primal infeasible - objective value -130.1095
Clp0032I PrimalInfeasible objective -130.1094988 - 11 iterations time 0.002
2025-05-18 19:00:00 waarschuwing: Geen oplossing  voor: minimize cost
2025-05-18 19:00:00 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 482 in /root/dao/prog/da_base.py
2025-05-18 19:00:00 debug: Connection status Pool size: 5  Connections in pool: 1 Current Overflow: -4 Current Checked out connections: 0 at line 482 in /root/dao/prog/da_base.py

Config:

code:

{
  "homeassistant": { },
  "database ha": {
    "engine": "sqlite",
    "database": "home-assistant_v2.db",
    "db_path": "/homeassistant"
  },
  "database da": {
    "engine" : "mysql",
    "database": "day_ahead",
    "username": "day_ahead",
    "password": "!secret db_da_password"
}, 
  "meteoserver-key": "!secret meteoserver-key",
  "prices": {
    "source day ahead": "tibber",
    "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.020496
    },
    "cost supplier redelivery": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496
    },
    "vat": {
      "2022-01-01": 21,
      "2022-07-01": 9,
      "2023-01-01": 21
    },
    "last invoice": "2022-09-01",
    "tax refund": "True"
  },
  "logging level" : "debug",
  "use_calc_baseload": "True",
  "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 cost",
  "notifications": {
  },
  "grid": {
    "max_power": 17
  },
  "history": {
    "save days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "boiler": {
    "boiler present": "False",
    "entity actual temp.": "sensor.boiler_gemeten",
    "entity setpoint": "sensor.boiler_ingesteld",
    "entity hysterese": "sensor.hysterese_hot_water",
    "cop": 2.9,
    "cooling rate": 0.4,
    "volume": 180,
    "heating allowed below": 44,
    "elec. power": 1500,
    "activate service": "press",
    "activate entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater present": "False",
    "degree days factor": 3.6,
    "stages": [
      {
        "max_power": 225,
        "cop": 7.1
      },
      {
        "max_power": 300,
        "cop": 7.0
      },
      {
        "max_power": 400,
        "cop": 6.5
      },
      {
        "max_power": 500,
        "cop": 6.0
      },
      {
        "max_power": 600,
        "cop": 5.5
      },
      {
        "max_power": 750,
        "cop": 5.0
      },
      {
        "max_power": 1000,
        "cop": 4.5
      },
      {
        "max_power": 1250,
        "cop": 4.0
      }
    ],
    "entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",
    "adjustment factor": 0.04
  },
  "battery": [
    {
      "name": "Accu",
      "entity actual level": "sensor.solaredge_huis_b1_state_of_energy",
      "capacity": 8,
      "upper limit": 100,
      "lower limit": 10,
      "optimal lower level": 10,
      "charge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 1500,
          "efficiency": 0.785
        },
        {
          "power": 3000,
          "efficiency": 0.872
        },
        {
          "power": 4500,
          "efficiency": 0.897
        },
        {
          "power": 5000,
          "efficiency": 0.899
        }
      ],
      "discharge stages": [
        {
          "power": 0,
          "efficiency": 1
        },
        {
          "power": 600,
          "efficiency": 0.891
        },
        {
          "power": 1500,
          "efficiency": 0.935
        },
        {
          "power": 3000,
          "efficiency": 0.952
        },
        {
          "power": 4500,
          "efficiency": 0.952
        },
        {
          "power": 5000,
          "efficiency": 0.934
        }
      ],
      "minimum power": 100,
      "dc_to_bat efficiency": 0.9838,
      "bat_to_dc efficiency": 0.9838,
      "cycle cost": 0,
      "entity set power feedin": "input_number.dao_set_power_feedin",
      "entity set operating mode": "input_select.dao_set_operation_mode",
      "entity stop inverter": "input_datetime.dao_stop_inverter",
      "entity balance switch": "input_boolean.dao_balance_switch",
      "entity from battery": "input_number.dao_from_battery",
      "entity from pv": "input_number.dao_from_pv",
      "entity from ac": "input_number.dao_from_ac",
      "entity calculated soc": "input_number.dao_calculated_soc",
      "solar": []
    }
  ],
  "solar": [ ],
  "electric vehicle": [
    {
      "name": "Tesla",
      "capacity": 57.5,
      "entity max amperage": 16,
      "charge three phase": "True",
      "entity position": "input_boolean.dao_car_home",
      "entity actual level": "sensor.rik_s_tesla_battery",
      "entity plugged in": "input_boolean.dao_plugged_in",
      "charge stages" : [
        {"ampere": 0, "efficiency": 0.00},
        {"ampere": 16, "efficiency": 0.90}
      ],      
      "charge scheduler": {
        "entity set level": "input_number.dao_target_soc",
        "level margin": 4,
        "entity ready datetime": "input_datetime.dao_target_departure"
      },
      "charge switch": "input_boolean.dao_charging",
      "entity set charging ampere" : "number.wallbox_pulsar_pro_sn_1140416_maximum_charging_current"
    }
  ],
  "machines" : [ ],
  "tibber": {
    "api_token": "!secret tibber_api_token"
  },
  "report": {
    "entities grid consumption": [
      "sensor.dsmr_reading_electricity_delivered_1",
      "sensor.dsmr_reading_electricity_delivered_2"
    ],
    "entities grid production": [
      "sensor.dsmr_reading_electricity_returned_1",
      "sensor.dsmr_reading_electricity_returned_2"
    ],
    "entities solar production ac": [
      "sensor.solaredge_huis_i1_ac_energy_kwh",
      "sensor.solaredge_garage_i1_ac_energy_kwh"
    ],
    "entities solar production dc": [],
    "entities ev consumption" : ["sensor.ev_charger_energy"],
    "entities wp consumption" : ["sensor.heat_pump_energy"],
    "entities boiler consumption": [],
    "entities battery consumption": ["sensor.solaredge_b1_energy_import"],
    "entities battery production": ["sensor.solaredge_b1_energy_export"]
  },
  "scheduler": {
    "active": "true",
    "0200": "get_tibber_data",
    "0300": "calc_baseloads",
    "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"
  }
}

[hood]

Er gaat volgens mij wat fout bij de auto.

"entity position": "input_boolean.dao_car_home", geeft aan dat hij niet thuis is.

R291: 2025-05-18 19:00:00 info: Ingeplugged:True. Dat komt niet overeen met elkaar zou ik zeggen. Is "entity position" noodzakelijk? Als de auto gewoon voor de deur staat zou ik die even verwijderen en dan kijken of hij wel een oplossing kan vinden.