Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Torch1969]

_ferry_ schreef op zondag 3 augustus 2025 @ 12:04:
Vandaag is rond de middag de stroom vrijwel gratis, wek volop PV op, maar ondanks dat ik wat met de variabelen klooi, komt er geen berekening uit waarin hij de accu's volgooit, terwijl die aardig leeg zijn/waren. Terwijl dat toch een soort uitgangspunt moet zijn voor de Minimale teruglevering strategie?

Het is een beetje lastig antwoorden zonder verder inzicht in je situatie en configuratie, maar algemeen geld (@KC27 correct me if I’m wrong):
De strategie is “minimal consumption”, oftewel minimale levering. DAO optimaliseert dus eerst op minimale afname van het net. Als je voldoende pv-opwek hebt, gaat dat dus goed. Daarná optimaliseert DAO op prijs, dus als er dan toch levering nodig is, dan in de goedkoopste uren. Waarom DAO dan nu je accu’s niet wil vullen is puur gissen. De accu’s zijn voldoende gevuld om de nacht door te komen? Accu’s vullen is per slot van rekening verlies (t.g.v. round trio efficiency), dus als het niet nodig is….. DAO kijkt ook niet verder dan zijn neus lang is (dus nu tot morgenavond 23:00).

@KC27 dit brengt mij ook wel op een vraag of een aparte strategie “minimal production” toch ook niet handig is? Na stoppen saldering is minimal production denk ik relevanter dan minimal consumption toch? Of wijkt die dan sowieso niet af?

[_ferry_]

Dat laatste zal wel relevant zijn geweest ja, 1 accu was vrijwel leeg, de andere nog 40%, wat genoeg is voor 1 nacht ja. Ik heb de log+afbeelding niet zo voor handen, en we zijn ook weer wat uren verder, dus ik zal er een andere keer nog eens in duiken. Voor vandaag heb ik ze lekker op NOM gezet, beide weer vol, kan ik de komende nachten er weer mee vooruit

[KC27]

Torch1969 schreef op zondag 3 augustus 2025 @ 14:40:
[...]


Het is een beetje lastig antwoorden zonder verder inzicht in je situatie en configuratie, maar algemeen geld (@KC27 correct me if I’m wrong):
De strategie is “minimal consumption”, oftewel minimale levering. DAO optimaliseert dus eerst op minimale afname van het net. Als je voldoende pv-opwek hebt, gaat dat dus goed. Daarná optimaliseert DAO op prijs, dus als er dan toch levering nodig is, dan in de goedkoopste uren. Waarom DAO dan nu je accu’s niet wil vullen is puur gissen. De accu’s zijn voldoende gevuld om de nacht door te komen? Accu’s vullen is per slot van rekening verlies (t.g.v. round trio efficiency), dus als het niet nodig is….. DAO kijkt ook niet verder dan zijn neus lang is (dus nu tot morgenavond 23:00).

@KC27 dit brengt mij ook wel op een vraag of een aparte strategie “minimal production” toch ook niet handig is? Na stoppen saldering is minimal production denk ik relevanter dan minimal consumption toch? Of wijkt die dan sowieso niet af?

Ik zal weleens een proefje doen met "minimal production", maar ik vrees dat DAO dan eerder de zonnepanelen uit gaat zetten. Dan opslaan. Dus dat zal dan (net als bij "minimal consumption") een soort hybride strategie worden.
Overigens @_ferry_:
De historie van je berekeningen en je logging kun je opvragen binnen DAO:

• klik op "Home"
• blader met de pijtjes terug naar de grafiek die je wilt zien
• klik op "tabel" (naast grafiek)
• blader met de pijtjes terug naar de tabel/logging die je wilt zien

[Bravo]

_ferry_ schreef op zondag 3 augustus 2025 @ 15:58:
Dat laatste zal wel relevant zijn geweest ja, 1 accu was vrijwel leeg, de andere nog 40%, wat genoeg is voor 1 nacht ja. Ik heb de log+afbeelding niet zo voor handen, en we zijn ook weer wat uren verder, dus ik zal er een andere keer nog eens in duiken. Voor vandaag heb ik ze lekker op NOM gezet, beide weer vol, kan ik de komende nachten er weer mee vooruit

Ik vermoed dat het te maken heeft met het verhogen van de cyclecost, waardoor het niet meer loont om je PV overschot op te slaan om op een later moment te exporteren en DOA voor zelfconsumptie laadt op het goedkoopste moment (mits nodig), als er geen grote spread in de prijs is.
Maar zonder logging is dit een gok.

[WhosYaDaddy]

_ferry_ schreef op vrijdag 1 augustus 2025 @ 21:28:
Ik vind het wel leuk om hier eens in te duiken nu ik 2 stuks Marstek thuisaccu heb. Afgelopen maand heb ik met een paar automations gewerkt, om ze op basis van PV, prijs en tijd al dan niet op NOM, uit, of laden te zetten. Dat werkt aardig, maar ik wil ook DAO testen voordat ik een keuze maak waar ik mijn energie en tijd in stop

Heb de berekeningen gedaan, en dan geeft hij netjes de waardes uit;
[Afbeelding]


[Afbeelding]

(inmiddels de cycle cost wat hoger gezet, want hij hoeft van mij niet elke dag de accu leeg te trekken omdat er een paar centen te verdienen zijn.)

Nu hoef ik dus eigenlijk alleen een automatisering (of 2) te maken die deze waardes intepeteert en daarmee de accu stuurt? Heeft iemand die al eens gemaakt? Ik zit vooral eventjes met de charge/discharge rate die positief kan zijn of negatief, terwijl de Marstek die waardes afzonderlijk heeft en daarbij de keuze tussen charge/discharge. Daar is dus nog een kleine conversieslag nodig.
edit; een beetje zoals hier: https://github.com/cornee...iscussioncomment-11695664
waarbij ik een soort
If value = negatief
then modus = discharge & set discharge current to value*-1
doe.

Ik heb het al een tijdje draaien met twee Marstek Venus-E batterijen. Ik heb wat automations gemaakt:

1. Zet de waarde in de charge/discharge settings (via Modbus/esphome)

code:

alias: Set charge_discharge value battery A
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_number.dao_battery_a_charge_discharge_rate
actions:
  - target:
      entity_id:
        - number.marstek_battery_a_forcible_discharge_power
        - number.marstek_battery_a_forcible_charge_power
    data:
      value: >-
        {{ (states('input_number.dao_battery_a_feedin_grid_power') | float) |
        abs}}
    action: number.set_value
mode: single

2. Kies of de batterij aan of uit moet (forcible charge mode heet het in esphome):

code:

alias: Set battery A charge mode
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_select.battery_a_mode
    from: Uit
    to: Aan
conditions: []
actions:
  - if:
      - condition: numeric_state
        entity_id: input_number.dao_battery_a_feedin_grid_power
        above: 0
    then:
      - device_id: b5bc16e17039b23b356cf618c9fb12e9
        domain: select
        entity_id: 325b59db791b2b8518f19f5695536c23
        type: select_option
        option: charge
    else:
      - device_id: b5bc16e17039b23b356cf618c9fb12e9
        domain: select
        entity_id: 325b59db791b2b8518f19f5695536c23
        type: select_option
        option: discharge
mode: single

Note: hier heb ik echter grote problemen mee (later meer)

3. In het geval de berekening niet echt correct was (wat elke keer is) zal de batterij te diep ontladen, dus dan maar een safeguard:

code:

alias: Battery A too low
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.marstek_battery_a_battery_state_of_charge
    below: 15
conditions: []
actions:
  - device_id: b5bc16e17039b23b356cf618c9fb12e9
    domain: select
    entity_id: 325b59db791b2b8518f19f5695536c23
    type: select_option
    option: stop
  - action: select.select_option
    metadata: {}
    data:
      option: Uit
    target:
      entity_id: select.marstek_battery_a_user_work_mode
mode: single

en dit zijn mijn settings in DAO:

code:

  "battery": [  
   { "name": "Battery A",
      "entity actual level": "sensor.marstek_battery_a_battery_state_of_charge",
      "capacity": 5.12,
      "upper limit": 100,
      "lower limit": 15,
      "optimal lower level": 15,
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 2787.5,
          "efficiency": 0.885
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 2787.5,
          "efficiency": 0.885
        }
      ],
      "minimum power": 250,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.00065,
      "entity set power feedin": "input_number.dao_battery_a_feedin_grid_power",
      "entity set operating mode": "input_select.battery_a_mode",
      "entity from ac": "input_number.dao_battery_a_charge_discharge_rate",
"solar": []
  },

DC efficientie enzo zijn voor mij niet relevant want netto gaat er 5kWh de batterij in en ik kan er 4.32 uit persen. Dus mijn systeemefficientie is eigenlijk wat het is (en of dat komt door de MPPT efficientie of iets anders is eigenlijk niet relevant voor mijn sturing (do correct me if I'm wrong)).


Waar ik echter tegenaanloop is hetvolgende:

input_number.dao_battery_a_feedin_grid_power blijft vaak onder de ingestelde waarde (soms 50W, -91 W, ...) dus daar kan ik niet op sturen.
Erger nog is dat input_select.battery_a_mode (de operating mode) heel vaak op "Aan" blijft staan of alleszins niet van state wisselt. Deze gebruik ik echter om de batterij te laten laden en ontladen, maar daardoor mis ik dus hele cycli.

In de grafieken echter werkt het allemaal netjes: , en is er geen onduidelijk laadgedrag. Dus als iemand me weet te vertellen hoe ik home assistant/DAO ervan overtuig alleen te volgen wat deze grafiek doet zou ik dat zeer op prijs stellen....

[Mirabis]

WhosYaDaddy schreef op dinsdag 5 augustus 2025 @ 08:02:
[...]


Ik heb het al een tijdje draaien met twee Marstek Venus-E batterijen. Ik heb wat automations gemaakt:

1. Zet de waarde in de charge/discharge settings (via Modbus/esphome)

code:

alias: Set charge_discharge value battery A
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_number.dao_battery_a_charge_discharge_rate
actions:
  - target:
      entity_id:
        - number.marstek_battery_a_forcible_discharge_power
        - number.marstek_battery_a_forcible_charge_power
    data:
      value: >-
        {{ (states('input_number.dao_battery_a_feedin_grid_power') | float) |
        abs}}
    action: number.set_value
mode: single

2. Kies of de batterij aan of uit moet (forcible charge mode heet het in esphome):

code:

alias: Set battery A charge mode
description: ""
triggers:
  - trigger: state
    entity_id:
      - input_select.battery_a_mode
    from: Uit
    to: Aan
conditions: []
actions:
  - if:
      - condition: numeric_state
        entity_id: input_number.dao_battery_a_feedin_grid_power
        above: 0
    then:
      - device_id: b5bc16e17039b23b356cf618c9fb12e9
        domain: select
        entity_id: 325b59db791b2b8518f19f5695536c23
        type: select_option
        option: charge
    else:
      - device_id: b5bc16e17039b23b356cf618c9fb12e9
        domain: select
        entity_id: 325b59db791b2b8518f19f5695536c23
        type: select_option
        option: discharge
mode: single

Note: hier heb ik echter grote problemen mee (later meer)

3. In het geval de berekening niet echt correct was (wat elke keer is) zal de batterij te diep ontladen, dus dan maar een safeguard:

code:

alias: Battery A too low
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.marstek_battery_a_battery_state_of_charge
    below: 15
conditions: []
actions:
  - device_id: b5bc16e17039b23b356cf618c9fb12e9
    domain: select
    entity_id: 325b59db791b2b8518f19f5695536c23
    type: select_option
    option: stop
  - action: select.select_option
    metadata: {}
    data:
      option: Uit
    target:
      entity_id: select.marstek_battery_a_user_work_mode
mode: single

en dit zijn mijn settings in DAO:

code:

  "battery": [  
   { "name": "Battery A",
      "entity actual level": "sensor.marstek_battery_a_battery_state_of_charge",
      "capacity": 5.12,
      "upper limit": 100,
      "lower limit": 15,
      "optimal lower level": 15,
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 2787.5,
          "efficiency": 0.885
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 2787.5,
          "efficiency": 0.885
        }
      ],
      "minimum power": 250,
      "dc_to_bat efficiency": 1,
      "bat_to_dc efficiency": 1,
      "cycle cost": 0.00065,
      "entity set power feedin": "input_number.dao_battery_a_feedin_grid_power",
      "entity set operating mode": "input_select.battery_a_mode",
      "entity from ac": "input_number.dao_battery_a_charge_discharge_rate",
"solar": []
  },

DC efficientie enzo zijn voor mij niet relevant want netto gaat er 5kWh de batterij in en ik kan er 4.32 uit persen. Dus mijn systeemefficientie is eigenlijk wat het is (en of dat komt door de MPPT efficientie of iets anders is eigenlijk niet relevant voor mijn sturing (do correct me if I'm wrong)).


Waar ik echter tegenaanloop is hetvolgende:

input_number.dao_battery_a_feedin_grid_power blijft vaak onder de ingestelde waarde (soms 50W, -91 W, ...) dus daar kan ik niet op sturen.
Erger nog is dat input_select.battery_a_mode (de operating mode) heel vaak op "Aan" blijft staan of alleszins niet van state wisselt. Deze gebruik ik echter om de batterij te laten laden en ontladen, maar daardoor mis ik dus hele cycli.

In de grafieken echter werkt het allemaal netjes: [Afbeelding], en is er geen onduidelijk laadgedrag. Dus als iemand me weet te vertellen hoe ik home assistant/DAO ervan overtuig alleen te volgen wat deze grafiek doet zou ik dat zeer op prijs stellen....

Hmm je laad/ontlaad Power (2787.5?) lijkt me wat vreemd voor de Marsteks. Ik heb een goed werkende automation met 1 batterij maar ik kan die vanavond (na werk) wel delen. Met wat kleine aanpassingen kan je het vast ook gebruiken met jouw setup.

[WhosYaDaddy]

Ja ik gebruik de AC feedin power. Met een efficientie van 0.885 (ook niet heel echt correct getal) kom ik dan op 2475W ongeveer uit als laadsetting.

Thanks!

[Mirabis]

Toch wat eerder i.v.m. pauze en VPN-mogelijkheid. Automation die ik gebruik is als volgt

code:

alias: DAO Batterij aansturing
description: Day Ahead Optimizer batterij aansturing voor marstek
triggers:
  - trigger: state
    entity_id:
      - input_number.dao_set_power_feedin
    from: null
  - trigger: state
    entity_id:
      - input_boolean.dao_balance_grid
    enabled: true
    from: null
  - trigger: state
    entity_id:
      - input_select.dao_set_operating_mode
    enabled: true
    from: null
  - at: input_datetime.dao_stop_marstek
    id: dao_stop_timer_trigger
    trigger: time
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_boolean.dao_balance_grid
            state: "on"
        sequence:
          - device_id: 8e18b1564e8dbb7c919394516850fb2d
            domain: select
            entity_id: 6c76d58307a6125930e68f44c3b90fac
            type: select_option
            option: stop
          - device_id: 8e18b1564e8dbb7c919394516850fb2d
            domain: select
            entity_id: 3e65e9a05aab30d7b8ecb50b7bd3c109
            type: select_option
            option: disable
          - device_id: 8e18b1564e8dbb7c919394516850fb2d
            domain: select
            entity_id: ea9ab2259ee937d8ccefd3b0a5799810
            type: select_option
            option: anti-feed
        alias: IF DAO Balance is ON, Marstek Anti-feed Mode
      - conditions:
          - condition: state
            entity_id: input_boolean.dao_balance_grid
            state: "off"
          - condition: state
            entity_id: input_select.dao_set_operating_mode
            state: Aan
          - condition: template
            value_template: "{{ states('input_number.dao_set_power_feedin') | int(0) == 0 }}"
        sequence:
          - if:
              - condition: device
                device_id: 8e18b1564e8dbb7c919394516850fb2d
                domain: select
                entity_id: 3e65e9a05aab30d7b8ecb50b7bd3c109
                type: selected_option
                option: disable
                alias: IF Control Mode = Disabled
            then:
              - device_id: 8e18b1564e8dbb7c919394516850fb2d
                domain: select
                entity_id: 3e65e9a05aab30d7b8ecb50b7bd3c109
                type: select_option
                option: enable
            alias: Enable Control Mode if not enabled
          - device_id: 8e18b1564e8dbb7c919394516850fb2d
            domain: select
            entity_id: 6c76d58307a6125930e68f44c3b90fac
            type: select_option
            option: stop
          - action: number.set_value
            data:
              value: "0"
            target:
              entity_id:
                - number.lilygo_rs485_marstek_forcible_discharge_power
                - number.lilygo_rs485_marstek_forcible_charge_power
        alias: if Balance=Off AND DAO setpoint is 0
      - conditions:
          - condition: state
            entity_id: input_boolean.dao_balance_grid
            state: "off"
          - condition: state
            entity_id: input_select.dao_set_operating_mode
            state: Aan
          - condition: template
            value_template: "{{ states('input_number.dao_set_power_feedin') | int(0) >= 0 }}"
        sequence:
          - if:
              - condition: device
                device_id: 8e18b1564e8dbb7c919394516850fb2d
                domain: select
                entity_id: 3e65e9a05aab30d7b8ecb50b7bd3c109
                type: selected_option
                option: disable
                alias: IF Control Mode = Disabled
            then:
              - device_id: 8e18b1564e8dbb7c919394516850fb2d
                domain: select
                entity_id: 3e65e9a05aab30d7b8ecb50b7bd3c109
                type: select_option
                option: enable
            alias: Enable Control Mode if not enabled
          - action: number.set_value
            data:
              value: "{{ states('input_number.dao_set_power_feedin') | float(0) }}"
            target:
              entity_id:
                - number.lilygo_rs485_marstek_forcible_charge_power
          - device_id: 8e18b1564e8dbb7c919394516850fb2d
            domain: select
            entity_id: 6c76d58307a6125930e68f44c3b90fac
            type: select_option
            option: charge
        alias: IF Balance=Off AND DAO wants to charge > 0
      - conditions:
          - condition: state
            entity_id: input_boolean.dao_balance_grid
            state: "off"
          - condition: state
            entity_id: input_select.dao_set_operating_mode
            state: Aan
          - condition: template
            value_template: "{{ states('input_number.dao_set_power_feedin') | int(0) < 0 }}"
        sequence:
          - if:
              - condition: device
                device_id: 8e18b1564e8dbb7c919394516850fb2d
                domain: select
                entity_id: 3e65e9a05aab30d7b8ecb50b7bd3c109
                type: selected_option
                option: disable
                alias: IF Control Mode = Disabled
            then:
              - device_id: 8e18b1564e8dbb7c919394516850fb2d
                domain: select
                entity_id: 3e65e9a05aab30d7b8ecb50b7bd3c109
                type: select_option
                option: enable
            alias: Enable Control Mode if not enabled
          - action: number.set_value
            data:
              value: >-
                {{ states('input_number.dao_set_power_feedin') | float(0) | abs
                }}
            target:
              entity_id:
                - number.lilygo_rs485_marstek_forcible_discharge_power
          - device_id: 8e18b1564e8dbb7c919394516850fb2d
            domain: select
            entity_id: 6c76d58307a6125930e68f44c3b90fac
            type: select_option
            option: discharge
        alias: if Balance=Off AND DAO wants to discharge < 0
      - conditions:
          - condition: trigger
            id:
              - dao_stop_timer_trigger
        sequence:
          - alias: Stop on timer trigger if still controlling
            if:
              - alias: IF Control Mode = Enabled
                condition: device
                device_id: 8e18b1564e8dbb7c919394516850fb2d
                domain: select
                entity_id: 3e65e9a05aab30d7b8ecb50b7bd3c109
                type: selected_option
                option: enable
            then:
              - device_id: 8e18b1564e8dbb7c919394516850fb2d
                domain: select
                entity_id: 6c76d58307a6125930e68f44c3b90fac
                type: select_option
                option: stop
mode: single

Ik heb daarnaast nog een losse automation die e.e.a. aanpast zodat Tibber de batterij niet leegtrekt bij grid reward laadsessies. Door de max_(dis)charges aan te passen verstoort het de andere werking en automations niet. Omdat het losstaand is, werkt het ook wanneer de batterij op NOM/XOM draait. Die is als volgt:

code:

alias: Marstek Pause on Easee Charge
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.voordeur_status
    id: easee_charge_lite_status_changed
    enabled: true
    from: null
  - trigger: state
    entity_id:
      - sensor.kwh_meter_3_phase_power
    from: null
    enabled: false
conditions: []
actions:
  - if:
      - condition: numeric_state
        entity_id: sensor.kwh_meter_3_phase_power
        above: 3000
        enabled: false
      - condition: numeric_state
        entity_id: number.lilygo_rs485_marstek_max_discharge_power
        above: 0
      - condition: or
        conditions:
          - condition: state
            entity_id: sensor.voordeur_status
            state: Charging
          - condition: state
            entity_id: sensor.voordeur_status
            state: Ready to charge
            enabled: false
    then:
      - device_id: 8e18b1564e8dbb7c919394516850fb2d
        domain: number
        entity_id: bcc31888c26ad943f3482ee1c3191339
        type: set_value
        value: 0
    else:
      - if:
          - condition: numeric_state
            entity_id: number.lilygo_rs485_marstek_max_discharge_power
            below: 2500
        then:
          - device_id: 8e18b1564e8dbb7c919394516850fb2d
            domain: number
            entity_id: bcc31888c26ad943f3482ee1c3191339
            type: set_value
            value: 2500
  - action: rest_command.start_dao_calc_zonder_debug
    data: {}
    enabled: false
mode: single

[diamanten]

Torch1969 schreef op vrijdag 1 augustus 2025 @ 08:19:
[...]

Heb je je dc_to_bat efficiency en bat_to_dc efficiency ook op 1 gezet?

Ik heb ook een 5kWh thuisbatterij, die kan wel met hogere vermogens (ont)laden dan die van jouw, daardoor kan ik in kortere tijd (lees de goedkopere uren) de batterij volladen. Ik heb vandaag ook maar €0,15 winst met minimize cost.

Jij vergelijkt verschillende situaties. Jij racet vandaag in een fiat panda met regenachtig weer tegen formule 1 auto’s (victron systemen met 30kWh of meer en hoge (ont)laad vermogens) op een zonnige dag…..dan ga je nooit dezelfde rondetijden halen.

Ik zou zeggen, zet je config op reeële waarden en kijk het eens een periode aan. Als je twijfelt over je config deel die dan nog even (in zijn geheel) hier (graag als quote, niet als code ivm de lengte van je post).

Cyclekosten en efficiency wat verder getuned en inderdaad de winst gaat behoorlijk omhoog (het zal ook wel aan het mooie weer liggen met redelijk volle accu's en 2 ontlaadcycli)

[ Voor 4% gewijzigd door diamanten op 05-08-2025 15:35 ]

[KC27]

WhosYaDaddy schreef op dinsdag 5 augustus 2025 @ 08:02:
[...]

DC efficientie enzo zijn voor mij niet relevant want netto gaat er 5kWh de batterij in en ik kan er 4.32 uit persen. Dus mijn systeemefficientie is eigenlijk wat het is (en of dat komt door de MPPT efficientie of iets anders is eigenlijk niet relevant voor mijn sturing (do correct me if I'm wrong)).
[...]

Als je 5 kWh erin stopt en er 4,32 kWh weer uithaalt is je round trip efficiency (=RTE) 86,5 % (=4,32/5)
Dat betekent dat je laad- en ontlaadeffiency (als beide gelijk zijn) dan 93 % moeten zijn (0,93 x 0,93 = 0,865)
Je hebt dus je laad- en ontlaadefficiency te laag ingesteld: beide staan nu op 0.885.

Waar ik echter tegenaanloop is hetvolgende:

input_number.dao_battery_a_feedin_grid_power blijft vaak onder de ingestelde waarde (soms 50W, -91 W, ...) dus daar kan ik niet op sturen.
Erger nog is dat input_select.battery_a_mode (de operating mode) heel vaak op "Aan" blijft staan of alleszins niet van state wisselt. Deze gebruik ik echter om de batterij te laten laden en ontladen, maar daardoor mis ik dus hele cycli.

Ik denk dat de automations van @Mirabis je een heel stuk verder kunnen helpen.
Mocht dat niet zo zijn: laat het hier weten en je wordt verder geholpen.

[robbinonline]

Mirabis schreef op dinsdag 5 augustus 2025 @ 10:24:
Toch wat eerder i.v.m. pauze en VPN-mogelijkheid. Automation die ik gebruik is als volgt

[...]


Ik heb daarnaast nog een losse automation die e.e.a. aanpast zodat Tibber de batterij niet leegtrekt bij grid reward laadsessies. Door de max_(dis)charges aan te passen verstoort het de andere werking en automations niet. Omdat het losstaand is, werkt het ook wanneer de batterij op NOM/XOM draait. Die is als volgt:


[...]

Dank, hier heb ook ik wat aan.
Zou je misschien ook je battery willen delen?

[WhosYaDaddy]

Ik heb twee batterijen en draai nu eentje met de versie van @Mirabis . En inderdaad die doet het alleszins consistenter (tot nu toe) dan mijn brouwsel.

Dus alvast dank, ik kijk het ff een dagje aan en dan schakel ik ook batterij 2 over.

[WhosYaDaddy]

[quote]KC27 schreef op dinsdag 5 augustus 2025 @ 22:53:
[...]
Als je 5 kWh erin stopt en er 4,32 kWh weer uithaalt is je round trip efficiency (=RTE) 86,5 % (=4,32/5)
Dat betekent dat je laad- en ontlaadeffiency (als beide gelijk zijn) dan 93 % moeten zijn (0,93 x 0,93 = 0,865)
Je hebt dus je laad- en ontlaadefficiency te laag ingesteld: beide staan nu op 0.885.
[...]

Het blijkt nog erger te zijn: de meeste dagen kom ik op een RTE van 0.776 tot 0.786, dus de efficientie is maar 0.883. Maar goed, die gaan we eens invullen, kijken wat dat geeft, thanks!

[Mirabis]

KC27 schreef op dinsdag 29 juli 2025 @ 23:14:
[...]

Ik draai ook 2025.7.4.rc1.
Bij mij geen foutmelding.

Hoe vaak per dag haal jij data op bij meteoserver?
Er is een maximum van 500 keer per maand voor het gratis account (en omdat DAO vaak de "harmonie"-data aanvult met gfs-data telt iedere keer voor twee!
Vier kier per dag volstaat om dat ze maar eens in de 6 uur worden ververst.
In een maand van 31 dagen heb je dan 31 x 4 x 2 = 248 dataverzoeken.
Je kunt inloggen op meteoserver en kijken hoe vaak je deze maand een call heb gedaan.

Helaas heb ik de foutmelding nog steeds. Heb even gezocht in het topic en zie dat @Mister I hetzelfde had en dat zijn account gedeactiveerd was. @Mister I hoe heb je dat opgelost ? Nieuw account?

Mister I schreef op maandag 19 mei 2025 @ 14:45:
Laat maar het is al gelukt, bleek toch een fout in de API te zijn (account gedeactiveerd). Maar goed laat de tekst hieronder staan, mocht iemand anders er tegen aan lopen.

Laat ik beginnen met complimenten geven voor hoe mooi dit systeem is! Ik ben nu ook langzaam maar zeker hier mee aan de gang gegaan. Eigenlijk nog niks gekoppeld, maar puur de basis neergezet. Dit ging de afgelopen weken goed, maar sinds vannacht lijkt de koppeling met met Meteo niet meer goed te gaan.
Ik krijg deze fout te zien:

code:

2025-05-19 14:34:49 info: Day Ahead Optimalisering versie: 2025.5.0
2025-05-19 14:34:49 info: Day Ahead Optimalisering gestart op: 19-05-2025 14:34:49
2025-05-19 14:34:49 info: Day Ahead Optimalisatie gestart: 19-05-2025 14:34:49 taak: get_meteo_data
2025-05-19 14:34:49 fout: No data recieved from meteoserver
2025-05-19 14:34:49 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 245, in get_meteo_data
    self.meteo.get_meteo_data(show_graph)
  File "/root/dao/prog/da_meteo.py", line 352, in get_meteo_data
    graphs.make_graph_meteo(
  File "/root/dao/prog/graphs.py", line 9, in make_graph_meteo
    df["gr"] = df["gr"].astype(float)
               ~~^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4102, in __getitem__
    indexer = self.columns.get_loc(key)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'gr'
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3528, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3507, in main
    da_calc.run_task_function("meteo")
  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 245, in get_meteo_data
    self.meteo.get_meteo_data(show_graph)
  File "/root/dao/prog/da_meteo.py", line 352, in get_meteo_data
    graphs.make_graph_meteo(
  File "/root/dao/prog/graphs.py", line 9, in make_graph_meteo
    df["gr"] = df["gr"].astype(float)
               ~~^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4102, in __getitem__
    indexer = self.columns.get_loc(key)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'gr'

Dacht dat het aan de api key lag dus een nieuwe aangevraagd, maar dat mocht niet helpen helaas.
In de config is volgens mij het enige wat ik kan instellen deze regel:
"meteoserver-key":

En ik haal dan 4x per dag de data op zoals in de standaard config staat. Enig idee waar ik kan zoeken waar dit fout gaat? Bedankt!

Bovenstaande foutmelding is bijna hetzelfde m.u.v. dat ik nog wel data lijk te ontvangen. Denk dat er dus in de verwerking iets nog niet goed gaat. Logging van mij onderstaand. Misschien een idee dat ik mijn solar array deel en dat je dat op je test instantie kan draaien @KC27 ?

code:

 2025-08-07 08:55:00 info: Day Ahead Optimalisering versie: 2025.8.0
2025-08-07 08:55:00 info: Day Ahead Optimalisering gestart op: 07-08-2025 08:55:00
2025-08-07 08:55:00 info: Day Ahead Optimalisatie gestart: 07-08-2025 08:55:00 taak: get_meteo_data
2025-08-07 08:55:00 info: Meteo data harmonie: 
          tijd           tijd_nl   gr temp solar_rad
0   1754550000  07-08-2025 09:00  135   18    238.47
1   1754553600  07-08-2025 10:00  195   20    310.61
2   1754557200  07-08-2025 11:00  245   21    361.82
3   1754560800  07-08-2025 12:00  256   22    342.91
4   1754564400  07-08-2025 13:00  133   22    142.68
5   1754568000  07-08-2025 14:00  160   23    168.49
6   1754571600  07-08-2025 15:00  150   23    149.69
7   1754575200  07-08-2025 16:00  105   23     98.01
8   1754578800  07-08-2025 17:00  133   23    115.93
9   1754582400  07-08-2025 18:00  105   23     81.72
10  1754586000  07-08-2025 19:00   11   22      8.44
11  1754589600  07-08-2025 20:00    3   22      3.00
12  1754593200  07-08-2025 21:00    0   21         0
13  1754596800  07-08-2025 22:00    0   21         0
14  1754600400  07-08-2025 23:00    0   20         0
15  1754604000  08-08-2025 00:00    0   19         0
16  1754607600  08-08-2025 01:00    0   18         0
17  1754611200  08-08-2025 02:00    0   18         0
18  1754614800  08-08-2025 03:00    0   18         0
19  1754618400  08-08-2025 04:00    0   18         0
20  1754622000  08-08-2025 05:00    0   18         0
21  1754625600  08-08-2025 06:00    0   18         0
22  1754629200  08-08-2025 07:00    6   18      3.44
23  1754632800  08-08-2025 08:00   43   18     63.99
24  1754636400  08-08-2025 09:00   67   19     90.60
25  1754640000  08-08-2025 10:00  101   20    129.15
26  1754643600  08-08-2025 11:00   85   20     94.49
27  1754647200  08-08-2025 12:00  128   21    144.19
28  1754650800  08-08-2025 13:00   56   21     56.19
29  1754654400  08-08-2025 14:00  145   22    151.02
30  1754658000  08-08-2025 15:00  142   23    141.27
31  1754661600  08-08-2025 16:00   44   23     40.75
32  1754665200  08-08-2025 17:00   40   22     35.60
33  1754668800  08-08-2025 18:00   80   22     64.68
34  1754672400  08-08-2025 19:00   50   22     36.58
2025-08-07 08:55:00 info: Aantal meteorecords harmonie: 35
2025-08-07 08:55:00 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 573, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 304, in get_meteo_data
    self.meteo.get_meteo_data(show_graph)
  File "/root/dao/prog/da_meteo.py", line 357, in get_meteo_data
    graphs.make_graph_meteo(
  File "/root/dao/prog/graphs.py", line 9, in make_graph_meteo
    df["gr"] = df["gr"].astype(float)
               ~~^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4107, in __getitem__
    indexer = self.columns.get_loc(key)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'gr'

robbinonline schreef op woensdag 6 augustus 2025 @ 14:14:
[...]

Dank, hier heb ook ik wat aan.
Zou je misschien ook je battery willen delen?

Hierbij mijn solar configuratie:

code:

"solar": [
    {
      "name": "9240Wp Phono Solar - Growatt MOD7000-TL XH (BP)",
      "max power": 7,
      "entity pv switch": "input_boolean.dao_panelen_aan_uit",
      "entities sensor": ["sensor.kwh_meter_3_phase_energy_export_2"],
      "strings": [
        {
          "name": "Growatt North-West 4200Wp",
          "tilt": 40,
          "orientation": -35,
          "capacity": 4.2,
          "yield": 0.008925
        },
        {
          "name": "Growatt South-East 5040Wp",
          "tilt": 40,
          "orientation": 146,
          "capacity": 5.04,
          "yield": 0.01071
        }
      ]
    }],

@robbinonline Denk dat je het dan over dit deel hebt?

code:

"battery": [
    {
      "name": "Marstek Venus-E 5.12kWh",
      "capacity": 5.12,
      "lower limit": 11,
      "upper limit": 100,
      "optimal lower level": 11,
      "charge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 100.0,
          "efficiency": 0.36
        },
        {
          "power": 200.0,
          "efficiency": 0.8221
        },
        {
          "power": 400.0,
          "efficiency": 0.8673
        },
        {
          "power": 600.0,
          "efficiency": 0.8861
        },
        {
          "power": 800.0,
          "efficiency": 0.8975
        },
        {
          "power": 1000.0,
          "efficiency": 0.8933
        },
        {
          "power": 1500.0,
          "efficiency": 0.9015
        },
        {
          "power": 2000.0,
          "efficiency": 0.9010
        },
        {
          "power": 2500.0,
          "efficiency": 0.9017
        }
      ],
      "discharge stages": [
        {
          "power": 0.0,
          "efficiency": 1
        },
        {
          "power": 100.0,
          "efficiency": 0.7907
        },
        {
          "power": 200.0,
          "efficiency": 0.8957
        },
        {
          "power": 400.0,
          "efficiency": 0.9581
        },
        {
          "power": 600.0,
          "efficiency": 0.9767
        },
        {
          "power": 800.0,
          "efficiency": 0.9812
        },
        {
          "power": 1000.0,
          "efficiency": 0.9890
        },
        {
          "power": 1500.0,
          "efficiency": 0.9907
        },
        {
          "power": 2000.0,
          "efficiency": 0.9841
        },
        {
          "power": 2500.0,
          "efficiency": 0.9928
        }
      ],
      "reduced hours": {},
      "dc_to_bat max power": 2500.0,
      "bat_to_dc max power": 2500.0,
      "dc_to_bat efficiency": 0.935,
      "bat_to_dc efficiency": 0.935,
      "cycle cost": 0.005,
      "minimum power": 400,
      "entity actual level": "sensor.lilygo_rs485_marstek_battery_state_of_charge",
      "entity min soc end opt": "input_number.dao_min_soc_einde_opt",
      "entity max soc end opt": "input_number.dao_max_soc_einde_opt",
      "entity set power feedin": "input_number.dao_set_power_feedin",
      "entity set operating mode": "input_select.dao_set_operating_mode",
      "entity stop inverter": "input_datetime.dao_stop_marstek",
      "entity balance switch": "input_boolean.dao_balance_grid",
      "entity from battery": "input_number.dao_from_battery",
      "entity from pv": "input_number.dao_marstek_from_pv",
      "entity from ac": "input_number.dao_marstek_from_ac",
      "entity calculated soc": "input_number.dao_marstek_calculated_soc",
      "solar": []
    }
  ],

[ErnstH]

@KC27 : zou het mogelijk zijn om een mogelijkheid in te bouwen dat automatisch gekozen wordt tussen beide strategieen op basis van een instelbaar kostenverschil:
- dus met beide strategieen de opbrengsten berekenen
- als het kostenverschil < instelbare delta : minimize consumption
- als het kostenverschil >= instelbare delta : minimize cost

Ik zou graag vnl minimize consumption draaien, maar wel maximaal de uitschieters willen meepakken mochten deze zich voordoen (zoals op de sporadische >0,60 EUR/kWh dagen).

Daarnaast, super mooi werk! Ik draai DAO met veel genoegen!

[Mirabis]

Aanvullend daarop (in theorie). Zou "tax refund" dynamisch gemaakt kunnen worden? We geven al een datum van "last invoice" op en de import en export entities zijn er al. Er zal dus berekend kunnen worden hoeveel al geëxporteerd en geïmporteerd is waarmee de nog te salderen kWh berekend kan worden. O.b.v. dat zou het dan mogelijk kunnen switchen tussen minimize consumption and minimize cost?

Just a thought

[Bravo]

ErnstH schreef op donderdag 7 augustus 2025 @ 12:12:
@KC27 : zou het mogelijk zijn om een mogelijkheid in te bouwen dat automatisch gekozen wordt tussen beide strategieen op basis van een instelbaar kostenverschil:
- dus met beide strategieen de opbrengsten berekenen
- als het kostenverschil < instelbare delta : minimize consumption
- als het kostenverschil >= instelbare delta : minimize cost

Ik zou graag vnl minimize consumption draaien, maar wel maximaal de uitschieters willen meepakken mochten deze zich voordoen (zoals op de sporadische >0,60 EUR/kWh dagen).

Daarnaast, super mooi werk! Ik draai DAO met veel genoegen!

Net even getest in mijn omgeving (met salderen en geen toeslagen op de prijs). Voor mijn systeem merk ik momenteel niet zoveel verschil tussen de modi, behalve dat de nacht ook wordt gedekt door minimize consumption (en niet door minimize cost). Waarschijnlijk omdat ik sowieso geen consumptie nodig heb om de batterij te laden, en het prijsverschil ontstaat alleen door de consumptie 's buiten de PV uren.
De batterij is groter dan het nachtverbruik, dus ik heb een overschot wat op het beste moment verkocht wordt, in beide modi is dat (op 2 kWh na) op hetzelfde moment met hetzelfde vermogen. Bij een grotere spread zal hier geen wijziging in ontstaan.

Enige verschil is wanneer je eigen opwek onvoldoende is om de batterij te vullen om maximaal te profiteren van de prijspiek, dan zal minimize consumption een remmende factor zijn.

[Bravo]

Mirabis schreef op donderdag 7 augustus 2025 @ 12:55:
Aanvullend daarop (in theorie). Zou "tax refund" dynamisch gemaakt kunnen worden? We geven al een datum van "last invoice" op en de import en export entities zijn er al. Er zal dus berekend kunnen worden hoeveel al geëxporteerd en geïmporteerd is waarmee de nog te salderen kWh berekend kan worden. O.b.v. dat zou het dan mogelijk kunnen switchen tussen minimize consumption and minimize cost?

Just a thought

Die functie is onlangs verwijderd, omdat het nogal wat extra rekentijd veroorzaakt om te bepalen of er nog saldeertegoed over is.
En het is een momentopname, momenteel heb ik meer geinjecteerd dan afgenomen, maar ik verwacht ook dat in november dit overschot verbruikt zal zijn. Dus nu meer afnemen omdat ik nu een overschot heb om extra in te voeden zal op een later moment mijn afname verhogen (want de omzetting is nooit 100%).

De keuze is gemaakt dat een ieder dat voor zichzelf mag instellen of er nog sprake is van 'tax refund'

[ErnstH]

Bravo schreef op donderdag 7 augustus 2025 @ 13:16:
[...]

Net even getest in mijn omgeving (met salderen en geen toeslagen op de prijs). Voor mijn systeem merk ik momenteel niet zoveel verschil tussen de modi, behalve dat de nacht ook wordt gedekt door minimize consumption (en niet door minimize cost). Waarschijnlijk omdat ik sowieso geen consumptie nodig heb om de batterij te laden, en het prijsverschil ontstaat alleen door de consumptie 's buiten de PV uren.
De batterij is groter dan het nachtverbruik, dus ik heb een overschot wat op het beste moment verkocht wordt, in beide modi is dat (op 2 kWh na) op hetzelfde moment met hetzelfde vermogen. Bij een grotere spread zal hier geen wijziging in ontstaan.

Enige verschil is wanneer je eigen opwek onvoldoende is om de batterij te vullen om maximaal te profiteren van de prijspiek, dan zal minimize consumption een remmende factor zijn.

Als ik het goed begrijp zal minimize consumption altijd eerst je eigen gebruik willen afdekken, en dan pas het overschot terugleveren. Dat wil ik dus niet vanaf een bepaald winst niveau.

[simnet]

[b]Mirabis in "Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO"Mirabis schreef op donderdag 7 augustus 2025

Bovenstaande foutmelding is bijna hetzelfde m.u.v. dat ik nog wel data lijk te ontvangen. Denk dat er dus in de verwerking iets nog niet goed gaat. Logging van mij onderstaand.

Ik heb precies dezelfde foutmelding. Wel data ontvangen maar een 'gr' keyerror.

[KC27]

@Mirabis @simnet @Mister I en anderen
Ik ben eens gaan bladeren in de logfiles van mijn meteo-verzoeken.
Daar bleek ook - af en toe - dezelfde fout voor te komen.
Ik ben het gaan analyseren en kom - voorlopig - tot de volgende conclusies:

• Die key-error ontstaat omdat er geen data terugkomen van Meteoserver op een dataverzoek. Dat is natuurlijke een verkeerde foutmelding en dat zal ik z.s.m. herstellen.
• Ik vermoed dat we allemaal tegelijk op hetzelfde tijdstip bij Meteoserver een dataverzoek indienen (van versie 2025.8.0 dan zijn er ca 200 packages gedownload). Ik denk dat de server van Meteoserver moeite heeft met zoveel dataverzoeken tegelijk (bijna iedereen werkt met hetzelfde tijdschema).
• Ik ga de code zo aanpassen dat het tijdstip van ophalen random wordt gekozen in de minuut na het triggeren van het ophalen.

Wat vinden jullie hiervan?
Zijn er nog betere suggesties?

[Mister I]

Mirabis schreef op donderdag 7 augustus 2025 @ 09:13:
[...]


Helaas heb ik de foutmelding nog steeds. Heb even gezocht in het topic en zie dat @Mister I hetzelfde had en dat zijn account gedeactiveerd was. @Mister I hoe heb je dat opgelost ? Nieuw account?

[...]


Bovenstaande foutmelding is bijna hetzelfde m.u.v. dat ik nog wel data lijk te ontvangen. Denk dat er dus in de verwerking iets nog niet goed gaat. Logging van mij onderstaand. Misschien een idee dat ik mijn solar array deel en dat je dat op je test instantie kan draaien @KC27 ?


[...]


[...]


Hierbij mijn solar configuratie:

[...]


@robbinonline Denk dat je het dan over dit deel hebt?


[...]

Nee had nieuwe api key aangevraagd. Daarna werkte het weer prima.

[KC27]

Mirabis schreef op donderdag 7 augustus 2025 @ 12:55:
Aanvullend daarop (in theorie). Zou "tax refund" dynamisch gemaakt kunnen worden? We geven al een datum van "last invoice" op en de import en export entities zijn er al. Er zal dus berekend kunnen worden hoeveel al geëxporteerd en geïmporteerd is waarmee de nog te salderen kWh berekend kan worden. O.b.v. dat zou het dan mogelijk kunnen switchen tussen minimize consumption and minimize cost?

Just a thought

Zoals @Bravo ook al schreef: deze functie is na een kleine "poll" in dit topic eruit gesloopt.
Ik ben niet van zins om die er weer terug in te bouwen. Het is aan de gebruiker om dit zelf bij te houden.

[KC27]

ErnstH schreef op donderdag 7 augustus 2025 @ 12:12:
@KC27 : zou het mogelijk zijn om een mogelijkheid in te bouwen dat automatisch gekozen wordt tussen beide strategieen op basis van een instelbaar kostenverschil:
- dus met beide strategieen de opbrengsten berekenen
- als het kostenverschil < instelbare delta : minimize consumption
- als het kostenverschil >= instelbare delta : minimize cost

Ik zou graag vnl minimize consumption draaien, maar wel maximaal de uitschieters willen meepakken mochten deze zich voordoen (zoals op de sporadische >0,60 EUR/kWh dagen).

Daarnaast, super mooi werk! Ik draai DAO met veel genoegen!

Het is een mooie suggestie, maar wel veel werk en ik probeer DAO niet te ingewikkeld (en uitgebreid) te maken.
Want zo kan ik er nog 10 bij verzinnen.
Op korte termijn kom ik er sowieso niet aan toe (o.a. druk met 15min-resolutie van de day ahead prijzen die op 30 september a.s. ingaan).
Ik ben wel van plan (later, ieder geval niet voor 30 september a.s.) om:

• meer data te gaan exporteren en beschikbaar te maken met een api.
• de strategie met een entity in HA instelbaar maken
• zodat een gebruiker dit soort afwegingen zelf kan maken in HA

[Mirabis]

KC27 schreef op donderdag 7 augustus 2025 @ 22:39:
@Mirabis @simnet @Mister I en anderen
Ik ben eens gaan bladeren in de logfiles van mijn meteo-verzoeken.
Daar bleek ook - af en toe - dezelfde fout voor te komen.
Ik ben het gaan analyseren en kom - voorlopig - tot de volgende conclusies:

• Die key-error ontstaat omdat er geen data terugkomen van Meteoserver op een dataverzoek. Dat is natuurlijke een verkeerde foutmelding en dat zal ik z.s.m. herstellen.
• Ik vermoed dat we allemaal tegelijk op hetzelfde tijdstip bij Meteoserver een dataverzoek indienen (van versie 2025.8.0 dan zijn er ca 200 packages gedownload). Ik denk dat de server van Meteoserver moeite heeft met zoveel dataverzoeken tegelijk (bijna iedereen werkt met hetzelfde tijdschema).
• Ik ga de code zo aanpassen dat het tijdstip van ophalen random wordt gekozen in de minuut na het triggeren van het ophalen.

Wat vinden jullie hiervan?
Zijn er nog betere suggesties?

Lijkt mij een goed begin. Maar is het niet makkelijker (voor jou) om voor nu de mensen tijdelijk even andere tijden te laten kiezen? Als dat het probleem verhelpt dan pas de randomization inbouwen.

[simnet]

Handmatig updaten kreeg ik dezelfde error. Ik heb een nieuwe api key aangemaakt en nu lijkt het weer te werken.

[Mirabis]

Zou je kunnen toelichten waar je dat doet? Ik zie nergens een knop voor API key vernieuwen. Of bedoelen jullie simpelweg het aanmaken van een nieuw account (en daarmee nieuwe api key bemachtigen)?

[simnet]

Ik heb een nieuw account aangemaakt. Maar dat was omdat ik de gebruikersnaam was vergeten. Ik heb geen idee of je ook een vernieuwing op hetzelfde account kunt doen.

[Los Tigros]

UPDATE: Excuus kom er achter dat 1 regel uit de config ontbrak. Werkt weer! Mag verwijderd worden.

Ik had de addon keurig draaien. Dankzij de fijne documentatie waarvoor dank. Ik krijg nu ineens geen day ahead prijzen meer binnen en dit is de foutmelding. Ik heb gewoon een API key erin staan. De ENTSO-E integratie zelf werkt zonder problemen? Zie ik iets over het hoofd?

code:

Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 573, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 327, in get_day_ahead_prices
    self.prices.get_prices(
  File "/root/dao/prog/da_prices.py", line 102, in get_prices
    client = EntsoePandasClient(api_key=api_key)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/entsoe/entsoe.py", line 66, in __init__
    raise TypeError("API key cannot be None")
TypeError: API key cannot be None
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3485, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3467, in main
    da_calc.run_task_function("prices")
  File "/root/dao/prog/da_base.py", line 573, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 327, in get_day_ahead_prices
    self.prices.get_prices(
  File "/root/dao/prog/da_prices.py", line 102, in get_prices
    client = EntsoePandasClient(api_key=api_key)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/entsoe/entsoe.py", line 66, in __init__
    raise TypeError("API key cannot be None")
TypeError: API key cannot be None

[Bravo]

Sinds een gisteren zie ik bij mij ook regelmatig fouten in het ophalen van de weerinformatie, ook bij het handmatig ophalen krijg ik een 'gr' fout, maar nadat er al een deel is binnengehaald.
Dit lijkt wat mij betreft niet te wijzen op een overbelaste server?

DAO versie 2025.8.0

code:

 2025-08-11 13:06:25 info: Day Ahead Optimalisering versie: 2025.8.0
2025-08-11 13:06:25 info: Day Ahead Optimalisering gestart op: 11-08-2025 13:06:25
2025-08-11 13:06:25 info: Day Ahead Optimalisatie gestart: 11-08-2025 13:06:25 taak: get_meteo_data
2025-08-11 13:06:25 info: Meteo data harmonie: 
          tijd           tijd_nl   gr temp   solar_rad
0   1754913600  11-08-2025 14:00  272   26  236.451029
1   1754917200  11-08-2025 15:00  253   27  254.267979
2   1754920800  11-08-2025 16:00  219   27  244.915114
3   1754924400  11-08-2025 17:00  174   27   211.07585
4   1754928000  11-08-2025 18:00  121   27   155.15529
5   1754931600  11-08-2025 19:00   66   26   85.742205
6   1754935200  11-08-2025 20:00   19   24   21.876224
7   1754938800  11-08-2025 21:00    0   23           0
8   1754942400  11-08-2025 22:00    0   22           0
9   1754946000  11-08-2025 23:00    0   21           0
10  1754949600  12-08-2025 00:00    0   20           0
11  1754953200  12-08-2025 01:00    0   19           0
12  1754956800  12-08-2025 02:00    0   19           0
13  1754960400  12-08-2025 03:00    0   19           0
14  1754964000  12-08-2025 04:00    0   18           0
15  1754967600  12-08-2025 05:00    0   18           0
16  1754971200  12-08-2025 06:00    5   17         5.0
17  1754974800  12-08-2025 07:00   41   17    3.864965
18  1754978400  12-08-2025 08:00   73   18    6.881524
19  1754982000  12-08-2025 09:00  123   20   14.699685
20  1754985600  12-08-2025 10:00   68   21   41.282285
21  1754989200  12-08-2025 11:00  127   23   63.541595
22  1754992800  12-08-2025 12:00   96   24   72.026452
23  1754996400  12-08-2025 13:00  183   26  141.009783
24  1755000000  12-08-2025 14:00   45   26   40.329564
25  1755003600  12-08-2025 15:00  248   28  249.442293
26  1755007200  12-08-2025 16:00  214   29  239.121315
27  1755010800  12-08-2025 17:00  169   30  204.413154
28  1755014400  12-08-2025 18:00  118   30  151.053071
29  1755018000  12-08-2025 19:00   64   30   82.981161
30  1755021600  12-08-2025 20:00   17   29   19.573463
31  1755025200  12-08-2025 21:00    0   28           0
32  1755028800  12-08-2025 22:00    0   27           0
33  1755032400  12-08-2025 23:00    0   26           0
34  1755036000  13-08-2025 00:00    0   25           0
2025-08-11 13:06:25 info: Aantal meteorecords harmonie: 35
2025-08-11 13:06:25 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 573, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 304, in get_meteo_data
    self.meteo.get_meteo_data(show_graph)
  File "/root/dao/prog/da_meteo.py", line 357, in get_meteo_data
    graphs.make_graph_meteo(
  File "/root/dao/prog/graphs.py", line 9, in make_graph_meteo
    df["gr"] = df["gr"].astype(float)
               ~~^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4107, in __getitem__
    indexer = self.columns.get_loc(key)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'gr'
Traceback (most recent call last):
  File "/root/dao/webserver/../prog/day_ahead.py", line 3485, in <module>
    main()
  File "/root/dao/webserver/../prog/day_ahead.py", line 3464, in main
    da_calc.run_task_function("meteo")
  File "/root/dao/prog/da_base.py", line 573, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 304, in get_meteo_data
    self.meteo.get_meteo_data(show_graph)
  File "/root/dao/prog/da_meteo.py", line 357, in get_meteo_data
    graphs.make_graph_meteo(
  File "/root/dao/prog/graphs.py", line 9, in make_graph_meteo
    df["gr"] = df["gr"].astype(float)
               ~~^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4107, in __getitem__
    indexer = self.columns.get_loc(key)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'gr'

In vorige versies gebeurde het wel eens dat er alleen maar harmonie data beschikbaar was, maar dat resulteerde niet in een foutmelding. Alleen een kortere horizon van ontvangen data.

[Batavia]

Mijn solar productie lijkt helemaal weg geoptimaliseerd te worden (gaat uit zodra ik iets over lijkt te hebben)

Ik zie niet goed waarom hij denkt dat dat kosten zijn

Verbruiksgegevens bij Tibber ophalen
Meteoprognoses ophalen
Day ahead prijzen ophalen prijzen_start
jjjj-mm-dd
prijzen_tot
jjjj-mm-dd

Bereken de baseloads
Logging van bewerking "Optimaliseringsberekening met debug":
2025-08-11 21:00:22 info: Day Ahead Optimalisering versie: 2025.8.0
2025-08-11 21:00:22 info: Day Ahead Optimalisering gestart op: 11-08-2025 21:00:22
2025-08-11 21:00:22 info: Day Ahead Optimalisatie gestart: 11-08-2025 21:00:22 taak: calc_optimum_met_debug
2025-08-11 21:00:22 info: Debug = True
2025-08-11 21:00:22 waarschuwing: "last invoice" (2022-09-01) is verouderd en moet worden bijgewerkt
2025-08-11 21:00:22 info: Baseload uit instellingen
2025-08-11 21:00:22 info: Start waarden:
uur tijd p_l p_t base pv_ac pv_dc
0 21 2025-08-11 21:00:00 0.315733 0.315733 0.19 0.000000 0
1 22 2025-08-11 22:00:00 0.279433 0.279433 0.18 0.000000 0
2 23 2025-08-11 23:00:00 0.263824 0.263824 0.16 0.000000 0
3 0 2025-08-12 00:00:00 0.260194 0.260194 0.14 0.000000 0
4 1 2025-08-12 01:00:00 0.256201 0.256201 0.38 0.000000 0
5 2 2025-08-12 02:00:00 0.250998 0.250998 0.26 0.000000 0
6 3 2025-08-12 03:00:00 0.249425 0.249425 0.42 0.000000 0
7 4 2025-08-12 04:00:00 0.248699 0.248699 0.15 0.000000 0
8 5 2025-08-12 05:00:00 0.255233 0.255233 0.12 0.000000 0
9 6 2025-08-12 06:00:00 0.270479 0.270479 0.13 2.715471 0
10 7 2025-08-12 07:00:00 0.271084 0.271084 0.15 33.082852 0
11 8 2025-08-12 08:00:00 0.266970 0.266970 0.23 83.427094 0
12 9 2025-08-12 09:00:00 0.259831 0.259831 0.26 133.890503 0
13 10 2025-08-12 10:00:00 0.243738 0.243738 0.31 180.678286 0
14 11 2025-08-12 11:00:00 0.196064 0.196064 0.32 103.550178 0
15 12 2025-08-12 12:00:00 0.157828 0.157828 0.31 181.327691 0
16 13 2025-08-12 13:00:00 0.151294 0.151294 0.23 67.442349 0
17 14 2025-08-12 14:00:00 0.153956 0.153956 0.26 201.863407 0
18 15 2025-08-12 15:00:00 0.190014 0.190014 0.21 154.892365 0
19 16 2025-08-12 16:00:00 0.234663 0.234663 0.21 117.049621 0
20 17 2025-08-12 17:00:00 0.262614 0.262614 0.54 157.179946 0
21 18 2025-08-12 18:00:00 0.269874 0.269874 0.26 101.713596 0
22 19 2025-08-12 19:00:00 0.328438 0.328438 0.26 48.303658 0
23 20 2025-08-12 20:00:00 0.335940 0.335940 0.22 12.700573 0
24 21 2025-08-12 21:00:00 0.317548 0.317548 0.19 0.000000 0
25 22 2025-08-12 22:00:00 0.285725 0.285725 0.18 0.000000 0
26 23 2025-08-12 23:00:00 0.261404 0.261404 0.16 0.000000 0
2025-08-11 21:00:23 info:

2025-08-11 21:00:23 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-08-11 21:00:23 fout: 'entity position'
2025-08-11 21:00:23 fout: 'entity actual level'
2025-08-11 21:00:23 info: Instellingen voor laden van EV: MG5
2025-08-11 21:00:23 info: Direct laden is uit
2025-08-11 21:00:23 info: Ampere Effic. Grid kW Accu kW
2025-08-11 21:00:23 info: 0.00 1.00 0.00 0.00
2025-08-11 21:00:23 info: 6.00 0.93 4.14 3.85
2025-08-11 21:00:23 info: 10.00 0.94 6.90 6.45
2025-08-11 21:00:23 info: 13.00 0.94 8.97 8.43
2025-08-11 21:00:23 info: 16.00 0.94 11.04 10.42
2025-08-11 21:00:23 info: 20.00 0.95 13.80 13.11
2025-08-11 21:00:23 info: Capaciteit accu: 61 kWh
2025-08-11 21:00:23 info: Maximaal laadvermogen: 13.8 kW
2025-08-11 21:00:23 info: Klaar met laden op: 12-08-2025 08:00:00
2025-08-11 21:00:23 info: Huidig laadniveau: 100.0 %
2025-08-11 21:00:23 info: Gewenst laadniveau:100.0 %
2025-08-11 21:00:23 info: Marge voor het laden: 10 %
2025-08-11 21:00:23 info: Locatie: away
2025-08-11 21:00:23 info: Ingeplugged:True
2025-08-11 21:00:23 info: Benodigde energie: 0 kWh
2025-08-11 21:00:23 info: Tijd nodig om te laden: 0.00 uur
2025-08-11 21:00:23 info: Afgerond naar hele uren: 0
2025-08-11 21:00:23 info: Stand laden schakelaar: off
2025-08-11 21:00:23 info: Stand aantal ampere laden: 0.0 A
2025-08-11 21:00:23 info: Opladen wordt niet ingepland, omdat werkelijk niveau (100.0%) hoger is of gelijk aan gewenst niveau (100.0% minus de marge 10%), auto is niet huis.

2025-08-11 21:00:23 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

Cbc0045I Nauty did not find any useful orbits in time 0.000115
Cbc0038I Initial state - 0 integers unsatisfied sum - 0
Cbc0038I Solution found of -3.39635
Cbc0038I Relaxing continuous gives -3.39635
Cbc0038I Before mini branch and bound, 2 integers at bound fixed and 4 continuous
Cbc0038I Mini branch and bound did not improve solution (0.00 seconds)
Cbc0038I After 0.00 seconds - Feasibility pump exiting with objective of -3.39635 - took 0.00 seconds
Cbc0012I Integer solution of -3.3963507 found by feasibility pump after 0 iterations and 0 nodes (0.01 seconds)
Cbc0001I Search completed - best objective -3.396350727879875, took 0 iterations and 0 nodes (0.01 seconds)
Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost
2025-08-11 21:00:23 info: Strategie: minimale kosten
2025-08-11 21:00:23 info: Het programma heeft een optimale oplossing gevonden.
2025-08-11 21:00:23 info: Niet geoptimaliseerd, kosten met day ahead tarieven: -345.16
2025-08-11 21:00:23 info: Geoptimaliseerd, kosten met day ahead tarieven: -3.40
2025-08-11 21:00:23 info: Levering: 6.08 (kWh)
2025-08-11 21:00:23 info: Berekende prognoses zijn niet opgeslagen.
2025-08-11 21:00:23 info: Berekende prognoses:
uur bat_in bat_out cons prod base boil wp ev pv_ac cost profit b_tem
21.00 0.00 0.00 0.19 0.00 0.19 0.00 0.00 0.00 0.00 0.06 -0.00 20.00
22.00 0.00 0.00 0.18 0.00 0.18 0.00 0.00 0.00 0.00 0.05 -0.00 20.00
23.00 0.00 0.00 0.16 0.00 0.16 0.00 0.00 0.00 0.00 0.04 -0.00 20.00
0.00 0.00 0.00 0.14 0.00 0.14 0.00 0.00 0.00 0.00 0.04 -0.00 20.00
1.00 0.00 0.00 0.38 0.00 0.38 0.00 0.00 0.00 0.00 0.10 -0.00 20.00
2.00 0.00 0.00 0.26 0.00 0.26 0.00 0.00 0.00 0.00 0.07 -0.00 20.00
3.00 0.00 0.00 0.42 0.00 0.42 0.00 0.00 0.00 0.00 0.10 -0.00 20.00
4.00 0.00 0.00 0.15 0.00 0.15 0.00 0.00 0.00 0.00 0.04 -0.00 20.00
5.00 0.00 0.00 0.12 0.00 0.12 0.00 0.00 0.00 0.00 0.03 -0.00 20.00
6.00 0.00 0.00 0.00 2.59 0.13 0.00 0.00 0.00 2.72 0.00 -0.70 20.00
7.00 0.00 0.00 0.15 0.00 0.15 0.00 0.00 0.00 0.00 0.04 -0.00 20.00
8.00 0.00 0.00 0.23 0.00 0.23 0.00 0.00 0.00 0.00 0.06 -0.00 20.00
9.00 0.00 0.00 0.26 0.00 0.26 0.00 0.00 0.00 0.00 0.07 -0.00 20.00

[Torch1969]

Dan doe ik ook nog maar even een duit in het zakje met de “gr”-fout bij ophalen van meteo-data.
Ik haal 4 x per dag om xx:45 de data op. Soms treedt de fout op. Soms ook bij handmatig ophalen.

Als ik de foutloggingen in dit topic zo terug kijk, dan valt het me op dat de fout steeds optreedt op het moment dat de harmonie data binnen is en het ophalen van de gfs data moet beginnen.

code:

 2025-08-10 23:45:00 info: Day Ahead Optimalisering versie: 2025.8.0
2025-08-10 23:45:00 info: Day Ahead Optimalisering gestart op: 10-08-2025 23:45:00
2025-08-10 23:45:00 info: Day Ahead Optimalisatie gestart: 10-08-2025 23:45:00 taak: get_meteo_data
2025-08-10 23:45:00 info: Meteo data harmonie: 
          tijd           tijd_nl   gr temp solar_rad
0   1754863200  11-08-2025 00:00    0   11         0
1   1754866800  11-08-2025 01:00    0   10         0
2   1754870400  11-08-2025 02:00    0    9         0
3   1754874000  11-08-2025 03:00    0    9         0
4   1754877600  11-08-2025 04:00    0    8         0
5   1754881200  11-08-2025 05:00    0    8         0
6   1754884800  11-08-2025 06:00    8    8      7.06
7   1754888400  11-08-2025 07:00   47   10      4.32
8   1754892000  11-08-2025 08:00  100   13      9.18
9   1754895600  11-08-2025 09:00  154   16     14.14
10  1754899200  11-08-2025 10:00  190   18     17.44
11  1754902800  11-08-2025 11:00  212   20     93.08
12  1754906400  11-08-2025 12:00  218   22    154.10
13  1754910000  11-08-2025 13:00  255   23    219.50
14  1754913600  11-08-2025 14:00  229   24    223.98
15  1754917200  11-08-2025 15:00  232   24    251.07
16  1754920800  11-08-2025 16:00  181   24    204.12
17  1754924400  11-08-2025 17:00   93   24     99.65
18  1754928000  11-08-2025 18:00  102   24    122.68
19  1754931600  11-08-2025 19:00   63   24     76.91
20  1754935200  11-08-2025 20:00   18   22     20.40
21  1754938800  11-08-2025 21:00    0   20         0
22  1754942400  11-08-2025 22:00    0   18         0
23  1754946000  11-08-2025 23:00    0   17         0
24  1754949600  12-08-2025 00:00    0   16         0
25  1754953200  12-08-2025 01:00    0   16         0
26  1754956800  12-08-2025 02:00    0   16         0
27  1754960400  12-08-2025 03:00    0   16         0
28  1754964000  12-08-2025 04:00    0   16         0
29  1754967600  12-08-2025 05:00    0   16         0
30  1754971200  12-08-2025 06:00    1   16      1.00
31  1754974800  12-08-2025 07:00   14   17      1.34
32  1754978400  12-08-2025 08:00   36   18     17.46
33  1754982000  12-08-2025 09:00   60   19     31.22
34  1754985600  12-08-2025 10:00  116   21     45.50
35  1754989200  12-08-2025 11:00  109   22     71.29
36  1754992800  12-08-2025 12:00   48   22     39.74
37  1754996400  12-08-2025 13:00  231   24    199.91
2025-08-10 23:45:00 info: Aantal meteorecords harmonie: 38
2025-08-10 23:45:00 fout: Er is een fout opgetreden, zie de fout-tracering
Traceback (most recent call last):
  File "/root/dao/prog/da_base.py", line 573, in run_task_function
    getattr(self, run_task["function"])()
  File "/root/dao/prog/da_base.py", line 304, in get_meteo_data
    self.meteo.get_meteo_data(show_graph)
  File "/root/dao/prog/da_meteo.py", line 357, in get_meteo_data
    graphs.make_graph_meteo(
  File "/root/dao/prog/graphs.py", line 9, in make_graph_meteo
    df["gr"] = df["gr"].astype(float)
               ~~^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/frame.py", line 4107, in __getitem__
    indexer = self.columns.get_loc(key)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/dao/venv/day_ahead/lib/python3.11/site-packages/pandas/core/indexes/range.py", line 417, in get_loc
    raise KeyError(key)
KeyError: 'gr'

[KC27]

Wat betreft het ophalen van de meteodata:
Er is een fix van DAO in de maak voor een betere foutafhandeling bij het ophalen van de meteodata.
Het niet binnenkrijgen van data ligt aan de server van meteoserver.
De data van het harmonie-model gaan niet verder dan 35 - 40 uur in de toekomst.
Voor DAO zelf is dat net voldoende (om 13 uur zijn er 36 uur-voorspellingen nodig), maar voor gebruikers die een verder reikende api-prognose willen van hun pv-productie is dat te kort (tot en met overmorgen)
Het GFS-model haalt nu tot 96 uur vooruit op (maar is niet zo fijnmazig).
Mijn ervaring tot nu toe is: het is allemaal werkbaar door iedere 6 uur zowel de harmonie-data als de gfs-data op te halen: meestal lukt het, soms is er een kink in de "server". Dat wordt dan bij de volgende beurt bijna altijd ingehaald en rechtgezet.

[KC27]

Batavia schreef op maandag 11 augustus 2025 @ 21:03:
Mijn solar productie lijkt helemaal weg geoptimaliseerd te worden (gaat uit zodra ik iets over lijkt te hebben)

Ik zie niet goed waarom hij denkt dat dat kosten zijn


[...]

Ik zie niet zo goed wat er gebeurt.
Heb je ook de grafiek van de berekening van 21:00 uur?

[Eärendil]

KC27 schreef op maandag 11 augustus 2025 @ 22:49:
De data van het harmonie-model gaan niet verder dan 35 - 40 uur in de toekomst.

Harmonie is in elke run 60 uur vooruit t.o.v. het initialisatietijdstip, dus dat is in de praktijk (na aftrek van rekentijd en wachttijd tot de volgende run) 55-57 uur.

Als je maar 35-40 uur krijgt is dat een beperking van Meteoserver

https://www.knmidata.nl/open-data/harmonie

[ Voor 5% gewijzigd door Eärendil op 12-08-2025 07:48 ]

[Torch1969]

KC27 schreef op maandag 11 augustus 2025 @ 22:49:
Wat betreft het ophalen van de meteodata:
Er is een fix van DAO in de maak voor een betere foutafhandeling bij het ophalen van de meteodata.
Het niet binnenkrijgen van data ligt aan de server van meteoserver.
De data van het harmonie-model gaan niet verder dan 35 - 40 uur in de toekomst.
Voor DAO zelf is dat net voldoende (om 13 uur zijn er 36 uur-voorspellingen nodig), maar voor gebruikers die een verder reikende api-prognose willen van hun pv-productie is dat te kort (tot en met overmorgen)
Het GFS-model haalt nu tot 96 uur vooruit op (maar is niet zo fijnmazig).
Mijn ervaring tot nu toe is: het is allemaal werkbaar door iedere 6 uur zowel de harmonie-data als de gfs-data op te halen: meestal lukt het, soms is er een kink in de "server". Dat wordt dan bij de volgende beurt bijna altijd ingehaald en rechtgezet.

Dank voor de uitleg. Ik zie (nu) ook een api voor “zon actueel”, die geeft ook de verwachting voor de komende 4 dagen. Is dat wellicht een alternatief?

Ik zag ook een situatie dat de harmonie data niet kon worden opgehaald (geeft wel een “nette” foutmelding) en de gfs data wel. Wat doe je in die situatie? Behoud je de meer gedetailleerde (maar wellicht verouderde) harmonie data? Of overschrijf je die met de nieuwere, maar minder gedetailleerde gfs data?

[ Voor 5% gewijzigd door Torch1969 op 12-08-2025 07:54 ]

[KC27]

Voor de testers:
Er is een nieuwe test release gepubliceerd, versie 2025.8.1.rc1
Dit staat in de changelog:

• Fixed error handling getting meteo-data
• Clear new graph with the new meteodata
• Retry once if no meteodata recieved

In deze versie wordt een tweede "ophaalpoging" gedaan als de eerste mislukt.
Dat gebeurt zowel met de gfs-data als met de harmoniedata.
Mijn ervaring hiermee - tot nu toe - is dat de kans op fouten een stuk kleiner is geworden.
In een "worst-case" worden er dan in een maand 4 x 2 x 2 x 31 ophaalpogingen gedaan = 496 pogingen.
Daarmee blijven we binnen de grens van maximaal 500 gratis ophaal-pogingen bij Meteoserver.
Ik heb nog wel een kleine test gedaan: Meteoserver telt alleen geslaagde ophaalpogingen, dus het blijft dan bij 248 pogingen.

Zo ziet de nieuwe grafiek eruit:

[Los Tigros]

Complimenten voor deze addon! Ik ben zelf wat dat betreft niet de meest handige op IT gebied maar door de uitgebreide manual en info uit dit forum ben ik echt al een heel eind!

[Mirabis]

KC27 schreef op woensdag 13 augustus 2025 @ 00:37:
Voor de testers:
Er is een nieuwe test release gepubliceerd, versie 2025.8.1.rc1
Dit staat in de changelog:

• Fixed error handling getting meteo-data
• Clear new graph with the new meteodata
• Retry once if no meteodata recieved

In deze versie wordt een tweede "ophaalpoging" gedaan als de eerste mislukt.
Dat gebeurt zowel met de gfs-data als met de harmoniedata.
Mijn ervaring hiermee - tot nu toe - is dat de kans op fouten een stuk kleiner is geworden.
In een "worst-case" worden er dan in een maand 4 x 2 x 2 x 31 ophaalpogingen gedaan = 496 pogingen.
Daarmee blijven we binnen de grens van maximaal 500 gratis ophaal-pogingen bij Meteoserver.
Ik heb nog wel een kleine test gedaan: Meteoserver telt alleen geslaagde ophaalpogingen, dus het blijft dan bij 248 pogingen.

Zo ziet de nieuwe grafiek eruit:
[Afbeelding]

In het "worst-case" scenario staat de actie nog gewoon 4 keer in scheduler? Is me niet helemaal duidelijk of ik dat ook moet aanpassen voor de beta.

[KC27]

Mirabis schreef op woensdag 13 augustus 2025 @ 11:30:
[...]

In het "worst-case" scenario staat de actie nog gewoon 4 keer in scheduler? Is me niet helemaal duidelijk of ik dat ook moet aanpassen voor de beta.

Ja gewoon 4 keer ophalen.
Als je de beta draait "naast" de productie en je gebruikt verschillende databases (bijv sqlite) dan wordt bij beide versies 4 keer data opgehaald en dan gaat het hard.
4 keer ophalen betekent dat er per keer minimaal twee dataverzoeken worden gedaan: een voor data uit het harmonie-model en een met data uit het gfs-model.
Als beide de eerste keer falen dan worden er per keer vier dataverzoeken gedaan.
Maar de data bij Meteoserver worden vier keer per dag vernieuwd.
Meteoserver zegt op haar website:

Nieuwe data in deze API zijn beschikbaar om 5:30, 11:30, 17:30 en 23:30 Nederlandse tijd.

Ik had in het begin (in 2022!) slecht ervaringen met het ophalen in het eerste uur na bovenstaande tijdstippen (data waren nog niet goed verwerkt, met bijvoorbeeld veel globale straling om 3 uur 's nachts).
Wellicht is het nu allemaal flink verbeterd, maar ik ben zelf tevreden met mijn huidige voorspellingen (never change a winning team?).
Maar voel je vrij om met de ophaal tijdstippen te spelen in de scheduler.

[Batavia]

KC27 schreef op maandag 11 augustus 2025 @ 22:59:
[...]

Ik zie niet zo goed wat er gebeurt.
Heb je ook de grafiek van de berekening van 21:00 uur?

Ik heb een beter idee waar het nu mis lijkt te gaan (of in iedergeval 1 afwijking)
Ik heb als prijs-bron tibber. Echter hij vult dan het productietarief niet

Als ik als tijdsbron nordpool gebruik en ik haal een ander tijdsvak op lijkt hij deze kolom wel te vullen

[KC27]

Batavia schreef op woensdag 13 augustus 2025 @ 16:49:
[...]


Ik heb een beter idee waar het nu mis lijkt te gaan (of in iedergeval 1 afwijking)
Ik heb als prijs-bron tibber. Echter hij vult dan het productietarief niet

Als ik als tijdsbron nordpool gebruik en ik haal een ander tijdsvak op lijkt hij deze kolom wel te vullen

[Afbeelding]

De tabel die je laat zien maakt voor mij niks duidelijk: je productie (teruglevering) is in alle uren 0, dus je opbrengst ook (dus onafhankelijk van je productietarief).
Nogmaals: zou je de grafiek die DAO genereert na een berekening (zichtbaar via "Home") hier willen delen incl de laatste deel-grafiek met de tarieven info, Zoiets als deze:

[Torch1969]

KC27 schreef op woensdag 13 augustus 2025 @ 00:37:
Voor de testers:
Er is een nieuwe test release gepubliceerd, versie 2025.8.1.rc1
Dit staat in de changelog:

• Fixed error handling getting meteo-data
• Clear new graph with the new meteodata
• Retry once if no meteodata recieved

In deze versie wordt een tweede "ophaalpoging" gedaan als de eerste mislukt.
Dat gebeurt zowel met de gfs-data als met de harmoniedata.
Mijn ervaring hiermee - tot nu toe - is dat de kans op fouten een stuk kleiner is geworden.
In een "worst-case" worden er dan in een maand 4 x 2 x 2 x 31 ophaalpogingen gedaan = 496 pogingen.
Daarmee blijven we binnen de grens van maximaal 500 gratis ophaal-pogingen bij Meteoserver.
Ik heb nog wel een kleine test gedaan: Meteoserver telt alleen geslaagde ophaalpogingen, dus het blijft dan bij 248 pogingen.

Zo ziet de nieuwe grafiek eruit:
[Afbeelding]

Zit er nog een betekenis achter de verschillende kleuren blauw voor de zon opbrengst?

[Torch1969]

KC27 schreef op woensdag 13 augustus 2025 @ 16:44:
[...]

Ja gewoon 4 keer ophalen.
Als je de beta draait "naast" de productie en je gebruikt verschillende databases (bijv sqlite) dan wordt bij beide versies 4 keer data opgehaald en dan gaat het hard.
4 keer ophalen betekent dat er per keer minimaal twee dataverzoeken worden gedaan: een voor data uit het harmonie-model en een met data uit het gfs-model.
Als beide de eerste keer falen dan worden er per keer vier dataverzoeken gedaan.
Maar de data bij Meteoserver worden vier keer per dag vernieuwd.
Meteoserver zegt op haar website:

[...]

Ik had in het begin (in 2022!) slecht ervaringen met het ophalen in het eerste uur na bovenstaande tijdstippen (data waren nog niet goed verwerkt, met bijvoorbeeld veel globale straling om 3 uur 's nachts).
Wellicht is het nu allemaal flink verbeterd, maar ik ben zelf tevreden met mijn huidige voorspellingen (never change a winning team?).
Maar voel je vrij om met de ophaal tijdstippen te spelen in de scheduler.

De update tijden voor harmonie data en gfs data verschillen volgens de site:

GFS:

Nieuwe data in deze API zijn beschikbaar om 0:30, 7:30, 12:30 en 18:30 Nederlandse tijd.

Harmonie:

Nieuwe data in deze API zijn beschikbaar om 5:30, 11:30, 17:30 en 23:30 Nederlandse tijd.

Omdat de harmonie data meer actueel is, kies ik ervoor daar dicht bij te updaten. Ik doe dat nu na een kwartier. Ik zal er eens op letten of dat dan al is bijgewerkt.

[Mirabis]

KC27 schreef op woensdag 13 augustus 2025 @ 16:44:
[...]

Ja gewoon 4 keer ophalen.
Als je de beta draait "naast" de productie en je gebruikt verschillende databases (bijv sqlite) dan wordt bij beide versies 4 keer data opgehaald en dan gaat het hard.
4 keer ophalen betekent dat er per keer minimaal twee dataverzoeken worden gedaan: een voor data uit het harmonie-model en een met data uit het gfs-model.
Als beide de eerste keer falen dan worden er per keer vier dataverzoeken gedaan.
Maar de data bij Meteoserver worden vier keer per dag vernieuwd.
Meteoserver zegt op haar website:

[...]

Ik had in het begin (in 2022!) slecht ervaringen met het ophalen in het eerste uur na bovenstaande tijdstippen (data waren nog niet goed verwerkt, met bijvoorbeeld veel globale straling om 3 uur 's nachts).
Wellicht is het nu allemaal flink verbeterd, maar ik ben zelf tevreden met mijn huidige voorspellingen (never change a winning team?).
Maar voel je vrij om met de ophaal tijdstippen te spelen in de scheduler.

Ok thanks. Ik moet eerst een ander probleem achterhalen hehe. Op een of andere manier stopt soms de periodieke berekening. Kwam er vandaag om 21;00 achter (niet thuis) dat hij niet zoals gepland heeft ontladen. VPN aan en zie laatste berekening was 15:00... Daarna niks meer.

Morgen maar eens uitzoeken...was toch wel €1 winst dat ik had kunnen maken >.<

[creon]

Heeft iemand voor mij de batterij instellingen voor een deye voor mij welke ik kan gebruiken ter inspiratie

[KC27]

Torch1969 schreef op woensdag 13 augustus 2025 @ 20:31:
[...]

Zit er nog een betekenis achter de verschillende kleuren blauw voor de zon opbrengst?

Nee, door de smalle staafjes lijken sommige een andere kleur te hebben.
Ik zal zien of ik dat kan fixen.

[Tomsworld]

Ik lees de documentatie nu - maar ik woon in België.

En het 1e waar ik bij vast zit is dit.

Ik heb ecopower met een dynamisch tarief ( uurprijzen - binnenkort kwartier ).

Los van de vaste meter kosten heb ik het volgende voor de variabele kosten.

Afname :

{% set s = {
"bijz_accijns": 0.04748,
"energiebijdrage": 0.0019261,
"kost_gsc": 0.011,
"kost_wkk": 0.00392,
"afnametarief": 0.0585279,
"btw": 1.06,
"marge_procentueel": 1.02,
"marge_per_kwh": 0.004
} %}
{{((((current_price * s.marge_procentueel) + s.marge_per_kwh) + s.bijz_accijns + s.energiebijdrage + s.kost_gsc + s.kost_wkk + s.afnametarief) * s.btw) | float}}

Injectie :

{% set s = {
"marge_procentueel": 0.98,
"marge_per_kwh": 0.015
} %}
{{((current_price * s.marge_procentueel) - s.marge_per_kwh) | float}}

Ik gebruik nu voor andere dingen in mijn HA de entseo plugin met 2 definities een keer injectie een keer consumption ( moet het nog naar een Noordpool omzetten ).

Iemand een tip ?

[Bravo]

Tomsworld schreef op donderdag 14 augustus 2025 @ 13:38:
Ik lees de documentatie nu - maar ik woon in België.

En het 1e waar ik bij vast zit is dit.

Ik heb ecopower met een dynamisch tarief ( uurprijzen - binnenkort kwartier ).

Los van de vaste meter kosten heb ik het volgende voor de variabele kosten.

Afname :

{% set s = {
"bijz_accijns": 0.04748,
"energiebijdrage": 0.0019261,
"kost_gsc": 0.011,
"kost_wkk": 0.00392,
"afnametarief": 0.0585279,
"btw": 1.06,
"marge_procentueel": 1.02,
"marge_per_kwh": 0.004
} %}
{{((((current_price * s.marge_procentueel) + s.marge_per_kwh) + s.bijz_accijns + s.energiebijdrage + s.kost_gsc + s.kost_wkk + s.afnametarief) * s.btw) | float}}

Injectie :

{% set s = {
"marge_procentueel": 0.98,
"marge_per_kwh": 0.015
} %}
{{((current_price * s.marge_procentueel) - s.marge_per_kwh) | float}}

Ik gebruik nu voor andere dingen in mijn HA de entseo plugin met 2 definities een keer injectie een keer consumption ( moet het nog naar een Noordpool omzetten ).

Iemand een tip ?

Ik zie geen optie binnen DAO om die marge_procentueel om te zetten, misschien dat @KC27 nog iets slims weet?
---

Momenteel zie ik wat rare gegevens terugkomen van meteoserver, de gr en solar_rad blijven sky high tot 18:00 uur en storten dan in. Eerder heb ik dit ook wel gezien bij de getallen van morgen, maar nu blijft het ook voor vandaag staan.
DAO 2025.8.0

code:

 2025-08-14 16:32:00 info: Day Ahead Optimalisering versie: 2025.8.0
2025-08-14 16:32:00 info: Day Ahead Optimalisering gestart op: 14-08-2025 16:32:00
2025-08-14 16:32:00 info: Day Ahead Optimalisatie gestart: 14-08-2025 16:32:00 taak: get_meteo_data
2025-08-14 16:32:00 fout: No data recieved from meteoserver
2025-08-14 16:32:00 info: Meteo data gfs: 
           tijd           tijd_nl   gr temp solar_rad
0    1755183600  14-08-2025 17:00  204   28    262.30
1    1755187200  14-08-2025 18:00  180   26    269.94
2    1755190800  14-08-2025 19:00   13   24     14.92
3    1755194400  14-08-2025 20:00    6   22      6.91
4    1755198000  14-08-2025 21:00    4   21      4.00
5    1755201600  14-08-2025 22:00    3   20      3.00
6    1755205200  14-08-2025 23:00    3   19      3.00
7    1755208800  15-08-2025 00:00    2   19      2.00
8    1755212400  15-08-2025 01:00    0   18         0
9    1755216000  15-08-2025 02:00    0   18         0
10   1755219600  15-08-2025 03:00    0   17         0
11   1755223200  15-08-2025 04:00    0   17         0
12   1755226800  15-08-2025 05:00    1   17      1.00
13   1755230400  15-08-2025 06:00    7   18      6.34
14   1755234000  15-08-2025 07:00   93   20      8.77
15   1755237600  15-08-2025 08:00  121   22     11.41
16   1755241200  15-08-2025 09:00  147   24     13.86
17   1755244800  15-08-2025 10:00  170   26     24.12
18   1755248400  15-08-2025 11:00  184   27     55.74
19   1755252000  15-08-2025 12:00  197   28    114.59
20   1755255600  15-08-2025 13:00  273   29    192.40
21   1755259200  15-08-2025 14:00  263   29    230.75
22   1755262800  15-08-2025 15:00  248   28    251.64
23   1755266400  15-08-2025 16:00  228   27    260.96
24   1755270000  15-08-2025 17:00  206   25    267.12
25   1755273600  15-08-2025 18:00  181   23    274.29
26   1755277200  15-08-2025 19:00   12   21     13.81
27   1755280800  15-08-2025 20:00    6   19      6.91
28   1755284400  15-08-2025 21:00    4   18      4.00
29   1755288000  15-08-2025 22:00    3   18      3.00
30   1755291600  15-08-2025 23:00    3   18      3.00
31   1755295200  16-08-2025 00:00    2   18      2.00
32   1755298800  16-08-2025 01:00    0   18         0
33   1755302400  16-08-2025 02:00    0   18         0
34   1755306000  16-08-2025 03:00    0   18         0
35   1755309600  16-08-2025 04:00    0   18         0
36   1755313200  16-08-2025 05:00    0   18         0
37   1755316800  16-08-2025 06:00    4   18      4.00
38   1755320400  16-08-2025 07:00   50   19      4.71
39   1755324000  16-08-2025 08:00   92   20      8.67
40   1755327600  16-08-2025 09:00  127   21     11.97
41   1755331200  16-08-2025 10:00  154   21     32.14
42   1755334800  16-08-2025 11:00  177   22     56.79
43   1755338400  16-08-2025 12:00  194   22    113.52
44   1755342000  16-08-2025 13:00  276   22    194.02
45   1755345600  16-08-2025 14:00  266   22    233.80
46   1755349200  16-08-2025 15:00  251   22    255.82
47   1755352800  16-08-2025 16:00  231   21    266.23
48   1755356400  16-08-2025 17:00  208   20    272.07
49   1755360000  16-08-2025 18:00  184   19    283.11
50   1755363600  16-08-2025 19:00   12   18     13.82
51   1755367200  16-08-2025 20:00    6   17      6.91
52   1755370800  16-08-2025 21:00    4   16      4.00
53   1755374400  16-08-2025 22:00    3   15      3.00
54   1755378000  16-08-2025 23:00    3   15      3.00
55   1755381600  17-08-2025 00:00    2   15      2.00
56   1755385200  17-08-2025 01:00    0   14         0
57   1755388800  17-08-2025 02:00    0   14         0
58   1755392400  17-08-2025 03:00    0   13         0
59   1755396000  17-08-2025 04:00    0   13         0
60   1755399600  17-08-2025 05:00    0   13         0
61   1755403200  17-08-2025 06:00    6   14      5.44
62   1755406800  17-08-2025 07:00   88   16      8.30
63   1755410400  17-08-2025 08:00  116   17     10.94
64   1755414000  17-08-2025 09:00  142   19     13.39
65   1755417600  17-08-2025 10:00  166   20     24.67
66   1755421200  17-08-2025 11:00  175   20     56.41
67   1755424800  17-08-2025 12:00  172   20    106.69
68   1755428400  17-08-2025 13:00  118   20     96.72
69   1755432000  17-08-2025 14:00   98   20     87.91
70   1755435600  17-08-2025 15:00   88   20     83.35
71   1755439200  17-08-2025 16:00   81   20     80.55
72   1755442800  17-08-2025 17:00   74   20     77.85
73   1755446400  17-08-2025 18:00   66   19     75.12
74   1755450000  17-08-2025 19:00    4   18      4.00
75   1755453600  17-08-2025 20:00    2   18      2.00
76   1755457200  17-08-2025 21:00    1   18      1.00
77   1755460800  17-08-2025 22:00    1   17      1.00
78   1755464400  17-08-2025 23:00    1   16      1.00
79   1755468000  18-08-2025 00:00    1   15      1.00
80   1755471600  18-08-2025 01:00    0   14         0
81   1755475200  18-08-2025 02:00    0   14         0
82   1755478800  18-08-2025 03:00    0   13         0
83   1755482400  18-08-2025 04:00    0   13         0
84   1755486000  18-08-2025 05:00    0   13         0
85   1755489600  18-08-2025 06:00    6   13      5.44
86   1755493200  18-08-2025 07:00   87   15      8.20
87   1755496800  18-08-2025 08:00  116   17     10.94
88   1755500400  18-08-2025 09:00  143   19     13.48
89   1755504000  18-08-2025 10:00  166   21     23.70
90   1755507600  18-08-2025 11:00  186   23     52.09
91   1755511200  18-08-2025 12:00  201   24    114.68
92   1755514800  18-08-2025 13:00  272   25    192.26
93   1755518400  18-08-2025 14:00  261   26    230.57
94   1755522000  18-08-2025 15:00  245   26    250.65
95   1755525600  18-08-2025 16:00  225   25    260.10
96   1755529200  18-08-2025 17:00  202   24    265.00
97   1755532800  18-08-2025 18:00  178   22    275.03
98   1755536400  18-08-2025 19:00   10   20     11.51
99   1755540000  18-08-2025 20:00    5   19      5.00
100  1755543600  18-08-2025 21:00    3   18      3.00
101  1755547200  18-08-2025 22:00    3   17      3.00
102  1755550800  18-08-2025 23:00    2   16      2.00
103  1755561600  19-08-2025 02:00    0   15         0
104  1755572400  19-08-2025 05:00    6   15      5.44
105  1755583200  19-08-2025 08:00  141   19     13.29
106  1755594000  19-08-2025 11:00  197   22     46.68
107  1755604800  19-08-2025 14:00  241   23    213.79
108  1755615600  19-08-2025 17:00  175   21    221.33
109  1755626400  19-08-2025 20:00    3   19      3.00
110  1755637200  19-08-2025 23:00    1   17      1.00
111  1755648000  20-08-2025 02:00    0   15         0
112  1755658800  20-08-2025 05:00    5   15      5.00
113  1755669600  20-08-2025 08:00  136   17     12.82
114  1755680400  20-08-2025 11:00  186   19     49.95
115  1755691200  20-08-2025 14:00  233   20    207.29
116  1755702000  20-08-2025 17:00  170   18    214.48
117  1755712800  20-08-2025 20:00    3   16      3.00
118  1755723600  20-08-2025 23:00    1   14      1.00
119  1755734400  21-08-2025 02:00    0   13         0
120  1755745200  21-08-2025 05:00    2   14      2.00
121  1755756000  21-08-2025 08:00   52   16      5.83
122  1755766800  21-08-2025 11:00   85   18     52.04
123  1755777600  21-08-2025 14:00  121   19    108.75
124  1755788400  21-08-2025 17:00   94   18    104.05
125  1755799200  21-08-2025 20:00    2   16      2.00
126  1755810000  21-08-2025 23:00    1   15      1.00
127  1755820800  22-08-2025 02:00    0   14         0
128  1755831600  22-08-2025 05:00    3   14      3.00
129  1755842400  22-08-2025 08:00   74   17      6.98
130  1755853200  22-08-2025 11:00   70   17     46.33
131  1755864000  22-08-2025 14:00   13   16     11.73
132  1755874800  22-08-2025 17:00   30   16     31.09
133  1755885600  22-08-2025 20:00    2   15      2.00
134  1755896400  22-08-2025 23:00    1   15      1.00
135  1755907200  23-08-2025 02:00    0   15         0
136  1755918000  23-08-2025 05:00    1   15      1.00
137  1755928800  23-08-2025 08:00   23   16     12.28
138  1755939600  23-08-2025 11:00   92   20     53.53
139  1755950400  23-08-2025 14:00  102   22     91.98
140  1755961200  23-08-2025 17:00   74   21     79.26
141  1755972000  23-08-2025 20:00    1   19      1.00
142  1755982800  23-08-2025 23:00    0   18         0
143  1755993600  24-08-2025 02:00    0   17         0
2025-08-14 16:32:00 info: Aantal meteorecords gfs: 144

[KC27]

Bravo schreef op donderdag 14 augustus 2025 @ 16:54:
[...]

Ik zie geen optie binnen DAO om die marge_procentueel om te zetten, misschien dat @KC27 nog iets slims weet?

Ik ben bezig om de tariefberekening flexibel te maken, zodat je en de Belgische-epex-prijzen kunt ophalen en ook de Belgische tariefstructuur in DAO kunt emuleren.
Graag nog even geduld.

Momenteel zie ik wat rare gegevens terugkomen van meteoserver, de gr en solar_rad blijven sky high tot 18:00 uur en storten dan in. Eerder heb ik dit ook wel gezien bij de getallen van morgen, maar nu blijft het ook voor vandaag staan.
DAO 2025.8.0


[...]

[Afbeelding]

[Afbeelding]

Mijn ervaring van een paar jaar terug was dat dit optreedt als je vrij snel na de verversingstijdstippen van Meteoserver die genoemd zijn door @Torch1969 de data ophaalt bij Meteoserver.
Hoe zijn jouw ophaaltijdstippen geconfigureerd?
Die van mij staan nu op 4:30, 10:30, 16:30 en 22:30 en bij mij treedt het verschijnsel niet meer op.

[Bravo]

KC27 schreef op donderdag 14 augustus 2025 @ 19:56:
[...]

[...]

Mijn ervaring van een paar jaar terug was dat dit optreedt als je vrij snel na de verversingstijdstippen van Meteoserver die genoemd zijn door @Torch1969 de data ophaalt bij Meteoserver.
Hoe zijn jouw ophaaltijdstippen geconfigureerd?
Die van mij staan nu op 4:30, 10:30, 16:30 en 22:30 en bij mij treedt het verschijnsel niet meer op.

Bij mij is het twee minuten later, om evt piekbelasting te ontwijken:
"0432": "get_meteo_data",
"1032": "get_meteo_data",
"1632": "get_meteo_data",
"2232": "get_meteo_data",
Maar dat zou dezelfde datablokken moeten opleveren.

[Torch1969]

KC27 schreef op donderdag 14 augustus 2025 @ 19:56:

Die van mij staan nu op 4:30, 10:30, 16:30 en 22:30 en bij mij treedt het verschijnsel niet meer op.

@KC27 en @Bravo Wat is de rationale om 4 uren na de gfs en zelfs 5 uren na de harmonie data update te gaan zitten? Zo lang duurt het toch niet dat de data echt beschikbaar is via de api? Daarmee loop je toch onnodig achter met het updaten van de voorspelde data?

Ik gebruik 5:45, 11:45, 17:45 en 23:45 (zoals gezegd een kwartier na de harmonie update). DOA rekent op het hele uur, dus theoretisch kan ik nog wat later gaan zitten (b.v. op xx:55), dan heb je de eerste berekening na de update meteen de meest actuele voorspelde situatie te pakken.
Zoals gezegd heb ik nog geen gekkigheid gezien waarbij ik dacht dat ik te vroeg de update doe, maar ik zal dat eens wat strakker monitoren.

[KC27]

Torch1969 schreef op donderdag 14 augustus 2025 @ 22:20:
[...]


@KC27 en @Bravo Wat is de rationale om 4 uren na de gfs en zelfs 5 uren na de harmonie data update te gaan zitten? Zo lang duurt het toch niet dat de data echt beschikbaar is via de api? Daarmee loop je toch onnodig achter met het updaten van de voorspelde data?

Ik gebruik 5:45, 11:45, 17:45 en 23:45 (zoals gezegd een kwartier na de harmonie update). DOA rekent op het hele uur, dus theoretisch kan ik nog wat later gaan zitten (b.v. op xx:55), dan heb je de eerste berekening na de update meteen de meest actuele voorspelde situatie te pakken.
Zoals gezegd heb ik nog geen gekkigheid gezien waarbij ik dacht dat ik te vroeg de update doe, maar ik zal dat eens wat strakker monitoren.

Dat klinkt allemaal heel goed.
Dank voor het uitzoekwerk.
Ik ga jouw tijden ook eens proberen (om 5:44 enz, om te spreiden )
Als het allemaal goed werkt zet ik ze zo ook in de voorbeeld-instellingen.

[Batavia]

KC27 schreef op woensdag 13 augustus 2025 @ 17:02:
[...]

De tabel die je laat zien maakt voor mij niks duidelijk: je productie (teruglevering) is in alle uren 0, dus je opbrengst ook (dus onafhankelijk van je productietarief).
Nogmaals: zou je de grafiek die DAO genereert na een berekening (zichtbaar via "Home") hier willen delen incl de laatste deel-grafiek met de tarieven info, Zoiets als deze:
[Afbeelding]

[KC27]

Batavia schreef op vrijdag 15 augustus 2025 @ 09:27:
[...]

[Afbeelding]

Deze grafiek is heel bijzonder om verschillende redenen o.a.:

• Je pv productie is erg hoog
• De optimaliseringsberekening zet je pv uit
• Er wordt wel een terugleveringstarief getoond, maar geen leveringstarief

Waarschijnlijk staan een paar instellingen verkeerd,
Wil je ook je instellingen delen?

[Torch1969]

KC27 schreef op vrijdag 15 augustus 2025 @ 23:35:
[...]

• Er wordt wel een terugleveringstarief getoond, maar geen leveringstarief

Die 2 lijnen liggen over elkaar heen (teruglevertarief = levertarief).
De spotprijzen lijn mist wel.

En wat doet die rode punt daar in de middelste grafiek?
En 250kWh is wel heel veel PV opbrengst in een uur…..

[ Voor 6% gewijzigd door Torch1969 op 16-08-2025 08:49 ]

[KC27]

Voor de testers:
Ik heb 2025.8.1.rc2 gepubliceerd met de volgende aanpassingen t.o.v rc1:

• Improved graphical presentation received meteodata
• improved logging getting meteodata.

Graag jullie bevindingen.

[Batavia]

KC27 schreef op vrijdag 15 augustus 2025 @ 23:35:
[...]

Deze grafiek is heel bijzonder om verschillende redenen o.a.:

• Je pv productie is erg hoog
• De optimaliseringsberekening zet je pv uit
• Er wordt wel een terugleveringstarief getoond, maar geen leveringstarief

Waarschijnlijk staan een paar instellingen verkeerd,
Wil je ook je instellingen delen?

https://github.com/corneel27/day-ahead/issues/355

ik heb even een github issue aangemaakt om alles bij elkaar te zetten

Alvast bedankt voor je hulp

[Torch1969]

KC27 schreef op zaterdag 16 augustus 2025 @ 16:20:
Voor de testers:
Ik heb 2025.8.1.rc2 gepubliceerd met de volgende aanpassingen t.o.v rc1:

• Improved graphical presentation received meteodata
• improved logging getting meteodata.

Graag jullie bevindingen.

Ziet er goed uit :-)

[Torch1969]

Batavia schreef op maandag 18 augustus 2025 @ 09:14:
[...]


https://github.com/corneel27/day-ahead/issues/355

ik heb even een github issue aangemaakt om alles bij elkaar te zetten

Alvast bedankt voor je hulp

Top, er vallen me al een aantal zaken op :-) zie GitHub voor verdere communicatie hierover.

[hemertje]

KC27 schreef op zaterdag 16 augustus 2025 @ 16:20:
Voor de testers:
Ik heb 2025.8.1.rc2 gepubliceerd met de volgende aanpassingen t.o.v rc1:

• Improved graphical presentation received meteodata
• improved logging getting meteodata.

Graag jullie bevindingen.

@KC27
hier een leuke discussie over DAO

hemertje in "Evcc slim laden met de zon en dynamische tarieven"

[KC27]

hemertje schreef op maandag 18 augustus 2025 @ 21:51:
[...]


@KC27
hier een leuke discussie over DAO

hemertje in "Evcc slim laden met de zon en dynamische tarieven"

Ik denk inderdaad dat evcc en dao gecombineerd de beste oplossing realiseren:
DAO voor de strategie per uur (en straks per kwartier) en de lange termijn
EVCC voor de realtime aansturing binnen het uur (kwartier).
Wel jammer dat evcc alleen werkt met een abbo (of heb ik dat verkeerd begrepen)?

[Get!em]

KC27 schreef op maandag 18 augustus 2025 @ 22:40:
[...]

Ik denk inderdaad dat evcc en dao gecombineerd de beste oplossing realiseren:
DAO voor de strategie per uur (en straks per kwartier) en de lange termijn
EVCC voor de realtime aansturing binnen het uur (kwartier).
Wel jammer dat evcc alleen werkt met een abbo (of heb ik dat verkeerd begrepen)?

Evcc werkt alleen met abonnement.

Maar realtime Loadbalancing op zonnestroom wordt door steeds meer laadpalen ook zelf gedaan. En bijv mijn Peblar kan ik dus op PV only zetten of op Minimum (6A)+PV of op maximaal (11kW)

Ik zit zelf te twijfelen of ik EVCC er tussen zet of niet. Evcc kan ter test met een gratis maand token gedraaid worden. (Elke maand een nieuwe gratis token ). Evcc heeft namelijk ook een planning (laad de auto voor 10u morgenochtend op tot 80%, kies zelf de gunstige momenten. Hij neemt nu de solar forecast en lage tarieven mee)

Binnenkort ga ik DAO eens installeren. Wat is meest praktisch: als eigen lxc container of als addon op HA? De data van mij HA staat in een aparte MariaDB.

[ Voor 17% gewijzigd door Get!em op 18-08-2025 23:23 ]

[KC27]

Zojuist versie 2025.8.1.rc3 gepubliceerd (de laatste rc voor versie 2025.8.1):
Met deze fix:
Fixed index-error when more than one batteries are used, reported by @PSMGoossens)

[Get!em]

Aanvullend: het EVCC team (meest Duits) werkt momenteel aan dat prognose en planning stuk. Misschien zie je (@KC27 ) mogelijkheden ter integratie/aanvulling.
Ze hebben namelijk recent best veel apparaten configurabel toegevoegd, waaronder ook SmartGrid+ compatibel warmtepompen, batterijen en ook andere grote verbruikers zijn modulair te configureren en aan te sturen . Allen hun prognose is nog basaal (maar wel met solar forecast en dynamische tarieven al)

[KC27]

Get!em schreef op maandag 18 augustus 2025 @ 23:19:
[...]

Evcc werkt alleen met abonnement.

Maar realtime Loadbalancing op zonnestroom wordt door steeds meer laadpalen ook zelf gedaan. En bijv mijn Peblar kan ik dus op PV only zetten of op Minimum (6A)+PV of op maximaal (11kW)

Ik zit zelf te twijfelen of ik EVCC er tussen zet of niet. Evcc kan ter test met een gratis maand token gedraaid worden. (Elke maand een nieuwe gratis token ). Evcc heeft namelijk ook een planning (laad de auto voor 10u morgenochtend op tot 80%, kies zelf de gunstige momenten. Hij neemt nu de solar forecast en lage tarieven mee)

Binnenkort ga ik DAO eens installeren. Wat is meest praktisch: als eigen lxc container of als addon op HA? De data van mij HA staat in een aparte MariaDB.

Je kunt DAO als losse container en als HA-addon installeren. De laatste is iets makkelijker als je HA draait op HA-OS. Voor meer info: zie de wiki op github:
https://github.com/cornee...tie-en-basis-configuratie.
DAO werkt zowel met mariadb (als addon of als losse db), sqlite of postgresql en dat geldt zowel voor de database van HA als voor de database van DAO zelf.

[Sander]

Get!em schreef op maandag 18 augustus 2025 @ 23:19:
[...]

Evcc werkt alleen met abonnement.

Maar realtime Loadbalancing op zonnestroom wordt door steeds meer laadpalen ook zelf gedaan. En bijv mijn Peblar kan ik dus op PV only zetten of op Minimum (6A)+PV of op maximaal (11kW)

Ik zit zelf te twijfelen of ik EVCC er tussen zet of niet. Evcc kan ter test met een gratis maand token gedraaid worden. (Elke maand een nieuwe gratis token ). Evcc heeft namelijk ook een planning (laad de auto voor 10u morgenochtend op tot 80%, kies zelf de gunstige momenten. Hij neemt nu de solar forecast en lage tarieven mee)

Binnenkort ga ik DAO eens installeren. Wat is meest praktisch: als eigen lxc container of als addon op HA? De data van mij HA staat in een aparte MariaDB.

Wat werkt alleen met abonnement? Bepaalde integraties zijn idd alleen mogelijk als je doneert, vaak omdat er ook kosten aan zitten voor EVCC, maar voor load management staat er heel duidelijk dat voor thuisgebruikers gratis blijft maar voor grotere installaties niet. Ik verwacht dat ze daar een limiet gaan implementeren op X laadpalen voor je moet betalen.

Ik betaal helemaal niks voor EVCC (behalve vrijwillige sponsoring) en het werkt allemaal prima.

[ Voor 3% gewijzigd door Sander op 19-08-2025 07:39 ]

[Get!em]

Sander schreef op dinsdag 19 augustus 2025 @ 07:26:
[...]


Wat werkt alleen met abonnement? Bepaalde integraties zijn idd alleen mogelijk als je doneert, vaak omdat er ook kosten aan zitten voor EVCC, maar voor load management staat er heel duidelijk dat voor thuisgebruikers gratis blijft maar voor grotere installaties niet. Ik verwacht dat ze daar een limiet gaan implementeren op X laadpalen voor je moet betalen.

Ik betaal helemaal niks voor EVCC (behalve vrijwillige sponsoring) en het werkt allemaal prima.

Ah, ja, nuance was op z’n plaats: in de lijst met devices staat voor welke devices een sponsortoken nodig is. Bij mij zo al 2 of 3. Dus kreeg meteen de melding.

[Sander]

Get!em schreef op dinsdag 19 augustus 2025 @ 08:52:
[...]

Ah, ja, nuance was op z’n plaats: in de lijst met devices staat voor welke devices een sponsortoken nodig is. Bij mij zo al 2 of 3. Dus kreeg meteen de melding.

Als je al Homeassistant oid hebt kun je dat soort devices (als ze daar ook werken) vaak ook via de HA API naar EVCC halen. Ik gebruik bijv voor m’n Tesla lokale aansturing dmv BLE, puur om niet afhankelijk te zijn van Tesla’s API of internet thuis. Dat regel ik via EspHome en lees+stuur ik in EVCC direct

[KC27]

Bericht voor de testers van de rc's van versie 2025.8.1.
Het blijkt dat Meteoserver ieder dataverzoek telt als 2 dataverzoeken (dit is mij telefonisch bevestigd door de beheerder van de site).
De manier waarop ik het nu heb geïmplementeerd in de rc's loopt het aantal geregisteerde dataverzoeken bij Meteoserver te hard op en zitten we aan het eind van de maand boven de 500 gratis verzoeken (door die factor 2).
Er komt vandaag/vanavond een nieuwe rc uit waarin je kunt kiezen welke model je wilt gebruiken:

• harmonie: iets nauwkeuriger (grid van 1 bij 1km) en ca 35 uur vooruit
• , dat wordt de default
• gfs: grover (grid van 15 x 15km) en 4 dagen vooruit, vooral interessant voor mensen die met een api de pv productie verder willen voorspellen

Daarmee blijft het aantal dataverzoeken op maandbasis beperkt binnen de gratis 500.

[Torch1969]

KC27 schreef op dinsdag 19 augustus 2025 @ 10:33:
Bericht voor de testers van de rc's van versie 2025.8.1.
Het blijkt dat Meteoserver ieder dataverzoek telt als 2 dataverzoeken (dit is mij telefonisch bevestigd door de beheerder van de site).
De manier waarop ik het nu heb geïmplementeerd in de rc's loopt het aantal geregisteerde dataverzoeken bij Meteoserver te hard op en zitten we aan het eind van de maand boven de 500 gratis verzoeken (door die factor 2).
Er komt vandaag/vanavond een nieuwe rc uit waarin je kunt kiezen welke model je wilt gebruiken:

• harmonie: iets nauwkeuriger (grid van 1 bij 1km) en ca 35 uur vooruit
• , dat wordt de default
• gfs: grover (grid van 15 x 15km) en 4 dagen vooruit, vooral interessant voor mensen die met een api de pv productie verder willen voorspellen

Daarmee blijft het aantal dataverzoeken op maandbasis beperkt binnen de gratis 500.

Hm, bijzonder, mijn teller staat nu op 182 verzoeken, dat is dus 19 dagen x 4xper dag x 2 verzoeken (harmonie en gfs) = 152 (plus nog wat losse en test updates). Als de uitspraak van die beheerder klopt dan zouden dit er al 364 moeten zijn……

Een alternatief voorstel: een aparte call voor harmonie en aparte voor gfs maken en die apart inplanbaar maken. Dan kan ieder voor zich bepalen welke aanroep wanneer en hoe vaak gedaan wordt. (B.v. 1x gfs en 3 x harmonie). En stel ik neem een abonnement, dan kan ik vaker aanroepen….

Edit: heb net een losse aanroep (run) gedaan en de teller springt van 182 naar 186?? Heeft die beheerder dit net aangepast of zo….??.

[ Voor 4% gewijzigd door Torch1969 op 19-08-2025 12:46 ]

[diamanten]

Torch1969 schreef op dinsdag 19 augustus 2025 @ 12:39:
[...]

Hm, bijzonder, mijn teller staat nu op 182 verzoeken, dat is dus 19 dagen x 4xper dag x 2 verzoeken (harmonie en gfs) = 152 (plus nog wat losse en test updates). Als de uitspraak van die beheerder klopt dan zouden dit er al 364 moeten zijn……

Een alternatief voorstel: een aparte call voor harmonie en aparte voor gfs maken en die apart inplanbaar maken. Dan kan ieder voor zich bepalen welke aanroep wanneer en hoe vaak gedaan wordt. (B.v. 1x gfs en 3 x harmonie). En stel ik neem een abonnement, dan kan ik vaker aanroepen….

Edit: heb net een losse aanroep (run) gedaan en de teller springt van 182 naar 186?? Heeft die beheerder dit net aangepast of zo….??.

Waarom geen gebruik van andere (ook gratis) providers zoals Open Meteo, Solcast of Forecast.solar? Deze gebruikt EMHASS ook. Of zijn deze minder nauwkeurig?

[hemertje]

KC27 schreef op maandag 18 augustus 2025 @ 22:40:
[...]

Ik denk inderdaad dat evcc en dao gecombineerd de beste oplossing realiseren:
DAO voor de strategie per uur (en straks per kwartier) en de lange termijn
EVCC voor de realtime aansturing binnen het uur (kwartier).
Wel jammer dat evcc alleen werkt met een abbo (of heb ik dat verkeerd begrepen)?

Ik volg DAO al een tijdje, nog niet geïnstalleerd, maar had niet in de gaten dat het geen sturing doet? Maar alleen de strategie doet…?

De sturing gebeurt dan binnen HA die je met DAO aanstuurt?

Biedt DAO wel de code voor de apparaten binnen HA aan?

[Torch1969]

hemertje schreef op dinsdag 19 augustus 2025 @ 18:54:
[...]


Ik volg DAO al een tijdje, nog niet geïnstalleerd, maar had niet in de gaten dat het geen sturing doet? Maar alleen de strategie doet…?

De sturing gebeurt dan binnen HA die je met DAO aanstuurt?

Biedt DAO wel de code voor de apparaten binnen HA aan?

Je koppelt de sturende entiteiten van DAO aan de desbetreffende entiteiten van je devices in HA. Kan rechtstreeks, maar verstandiger is er een automatisering tussen te zetten, dan kun je eventueel ook eenvoudig ontkoppelen (automatisering uit). Op die manier stuurt DAO na een calculatie de devices aan. In principe eens per uur (op het hele uur bij wisseling van prijs). Soms heb je dan aanvullende functionaliteit in HA nodig b.v. voor je balanceren van je batterij (nul op meter).

[Torch1969]

diamanten schreef op dinsdag 19 augustus 2025 @ 13:48:
[...]

Waarom geen gebruik van andere (ook gratis) providers zoals Open Meteo, Solcast of Forecast.solar? Deze gebruikt EMHASS ook. Of zijn deze minder nauwkeurig?

Ik ben zelf erg gecharmeerd van Solcast (gebruik die zelf ook in HA). Geeft vaker (per half uur) een update en reageert goed op plots overkomende bewolking. Voor gratis account wel gelimiteerd tot 10 aanroepen per dag, maar dat is in principe genoeg, als je tijdens zonuren per uur een update doet.

Mijn gedachtekronkel is om DAo te koppelen aan de zon voorspelling van HA, dan kan iedereen daarin zelf zijn eigen voorkeurs voorspelling inrichten (en hergebruiken voor andere doeleinden). Maar tot nu toe heb ik nog niet kunnen ontdekken of die zon voorspelling ook buiten HA te gebruiken is.

[KC27]

Torch1969 schreef op dinsdag 19 augustus 2025 @ 12:39:
[...]

Hm, bijzonder, mijn teller staat nu op 182 verzoeken, dat is dus 19 dagen x 4xper dag x 2 verzoeken (harmonie en gfs) = 152 (plus nog wat losse en test updates). Als de uitspraak van die beheerder klopt dan zouden dit er al 364 moeten zijn……

Een alternatief voorstel: een aparte call voor harmonie en aparte voor gfs maken en die apart inplanbaar maken. Dan kan ieder voor zich bepalen welke aanroep wanneer en hoe vaak gedaan wordt. (B.v. 1x gfs en 3 x harmonie). En stel ik neem een abonnement, dan kan ik vaker aanroepen….

Edit: heb net een losse aanroep (run) gedaan en de teller springt van 182 naar 186?? Heeft die beheerder dit net aangepast of zo….??.

Het is duidelijk: er zijn veel smaken en veel keuzes en verschillende prioriteiten op dit punt.
Voor de korte termijn kan ik dat niet allemaal als keuze implementeren en aanbieden. Dat wil ik op termijn voor volgende voorjaar wel klaar hebben, maar mijn topprioriteit ligt nu op het afmaken van het 15min interval voor de dynamische prijzen (moet testbaar zijn rond 1 september, gaat 1 oktober in)
Wat betreft het aantal aanvragen per maand bij Meteoserver: het blijkt (na wederom navraag ) dat hij soms dubbel telt en soms niet, dat schijnt te maken te hebben met de server waarnaar je aanvraag wordt gestuurd door de load-balancer: de load-balancer telt voor een keer en een van de twee "afwerk"-servers telt ook een keer de andere niet.
Mocht iemand in de problemen komen: je kunt met een tweede email-adres en accountnaam een tweede api-key aanvragen.
Voor de hele korte termijn: ik maak een nieuwe rc met daarin twee optionele keuzes;
- voor het model (default harmonie = fijnmaziger en voldoende voor het rekenwerk van DAO)
- het maximaal aantal pogingen op data op te halen, default op 2
Zijn jullie hiermee akkoord?

[KC27]

Voor de testers: ik heb versie 2025.8.1.rc4 gepubliceerd.
Changelog:
- You can configure the meteo-model for your data (option, default harmonie)
- You can configure the max number of attempts (option, default 2)

Dit staat er in DOCS.md:

Je kunt desgewenst nog een twee zaken aanpassen:
meteo-model
Met de instelling "meteoserver-model" kun je het meteodata-model kiezen waarmee de op te halen data worden gegenereerd.
Er zijn twee modellen:
* harmonie: voorspelt maximaal 40 uur vooruit en berekent data voor ieder grid van 1 x 1 km (fijnmazig)
* gfs: voorspelt tot minimaal 96 uur vooruit en berekent data voor een grid van 10 x 10 km (grofmazig)
Deze instelling is optioneel. Als je niets instelt wordt "harmonie" als model gekozen.
De laatste is het best bruikbaar voor gebruikers die via een api een langere termijn voorspelling willen van hun pv-productie.

ophaalpogingen
Met de instelling "meteoserver-attemps" kun je het aantal maximaal aantal pogingen instellen die DAO doet om meteodata binnen te krijgen.
Ook deze instelling is optioneel. Als je niets instelt worden er maximaal 2 ophaalpogingen per keer gedaan.

[patatman12]

Ik ben even benieuwd hoe mensen hier met het volgende zouden omgaan.
Op 21 augustus heb ik vanuit Liander een hele dag geen stroom (grid onderbreking voor onderhoud).

Mijn idee nu is: Dao uitzetten, Victron DESS uitzetten en het systeem het huis laten voorzien.
DAO zal vandaag 20 augustus al uit gaan, om te zorgen voor voldoende lading.

Of is er een betere, andere manier die ik over het hoofd zie?

[KC27]

patatman12 schreef op woensdag 20 augustus 2025 @ 08:40:
Ik ben even benieuwd hoe mensen hier met het volgende zouden omgaan.
Op 21 augustus heb ik vanuit Liander een hele dag geen stroom (grid onderbreking voor onderhoud).

Mijn idee nu is: Dao uitzetten, Victron DESS uitzetten en het systeem het huis laten voorzien.
DAO zal vandaag 20 augustus al uit gaan, om te zorgen voor voldoende lading.

Of is er een betere, andere manier die ik over het hoofd zie?

Dit lijkt mij een prima oplossing.
Ik zou vandaag wel even "proefdraaien" (hoofdschakelaar in de kast uit) en kijken of het allemaal werkt. Zoniet dan kun je het vandaag nog herstellen.

[DaBit]

KC27 schreef op woensdag 20 augustus 2025 @ 00:25:
Voor de testers: ik heb versie 2025.8.1.rc4 gepubliceerd.
Changelog:
- You can configure the meteo-model for your data (option, default harmonie)
- You can configure the max number of attempts (option, default 2)

Even gevalideerd dat het ook inderdaad zo werkt, en dat doet het.
Ik had geen meteo-server problemen, dus of daar iets verbeterd is kan ik niet voor je testen.

[DaBit]

patatman12 schreef op woensdag 20 augustus 2025 @ 08:40:
Of is er een betere, andere manier die ik over het hoofd zie?

Ik zou lekker uit eten en vroeg naar bed gaan

Maar kwa DAO: als je DAO uitzet en je geeft de "entity set power feedin" en "entity set operating mode" inputs zelf een waarde dan gaat de batterij laden.

[KC27]

Productieversie 2025.8.1 is gepubliceerd (= testversie 2025.8.1.rc5).
Changelog (t.o.v. versie 2025.8.0):
- You can configure the meteo-model for your data (option, default **harmonie**)
- You can configure the max number of attempts (option, default 2)
More info in DOCS.md
- Fixed index-error when more than one batteries are used (reported by @PSMGoossens)
- Improved graphical presentation received meteodata
- Improved logging getting meteodata
- Fixed error handling getting meteo-data

[diamanten]

KC27 schreef op woensdag 20 augustus 2025 @ 19:30:
Productieversie 2025.8.1 is gepubliceerd (= testversie 2025.8.1.rc5).
Changelog (t.o.v. versie 2025.8.0):
- You can configure the meteo-model for your data (option, default **harmonie**)
- You can configure the max number of attempts (option, default 2)
More info in DOCS.md
- Fixed index-error when more than one batteries are used (reported by @PSMGoossens)
- Improved graphical presentation received meteodata
- Improved logging getting meteodata
- Fixed error handling getting meteo-data

Dank voor de update! Net even de meteodata grafiek vergeleken met de info van de open-meteo solar forecast integration: lijkt zo op het zicht voor vandaag in elk geval vrijwel gelijk.

Open-meteo solar forecast:

[KC27]

diamanten schreef op vrijdag 22 augustus 2025 @ 09:29:
[...]

Dank voor de update! Net even de meteodata grafiek vergeleken met de info van de open-meteo solar forecast integration: lijkt zo op het zicht voor vandaag in elk geval vrijwel gelijk.
[Afbeelding]
Open-meteo solar forecast:
[Afbeelding]

De voorspelling van de globale straling komt nooit exact overeen met de voorspelling van de zonopbrengst omdat helling en oriëntatie ook een belangrijke factor zijn.
Ik ben eigenlijk ook wel benieuwd als je zonproductie voorspelling van DAO vergelijkt met die van open-meteo.
Zou je dat willen doen?
De voorspelling staat in de uurlijkse berekening, maar je kunt ook via de api de voorspelling van vandaag en morgen opvragen. Bijvoorbeeld:

code:

http://192.168.178.36:5000/api/report/pv_ac/vandaag_en_morgen

[diamanten]

KC27 schreef op vrijdag 22 augustus 2025 @ 14:01:
[...]

De voorspelling van de globale straling komt nooit exact overeen met de voorspelling van de zonopbrengst omdat helling en oriëntatie ook een belangrijke factor zijn.
Ik ben eigenlijk ook wel benieuwd als je zonproductie voorspelling van DAO vergelijkt met die van open-meteo.
Zou je dat willen doen?
De voorspelling staat in de uurlijkse berekening, maar je kunt ook via de api de voorspelling van vandaag en morgen opvragen. Bijvoorbeeld:

code:

http://192.168.178.36:5000/api/report/pv_ac/vandaag_en_morgen

Ik weet niet of de produktie in DAO de totale zonproduktie van mijn panelen voor vandaag en morgen dient te zijn, maar het komt niet overeen met de open-meteo cijfers.
En:

Misschien een config dingetjes:

code:

  "solar": [ 
    {
      "name": "Enphase",
      "tilt": 30,
      "orientation": 220,
      "capacity": 11.680,
      "yield": 0.007,
      "entity pv switch": "input_boolean.solar_pv_on_off",
      "sensor history": "sensor.envoy_totale_energieproductie_kwh"
    }
  ],

[ Voor 12% gewijzigd door diamanten op 22-08-2025 14:35 ]

[Bravo]

@KC27 Dat overzicht van Solar Forecast vs DAO heb ik al in mn dashboard zitten:
Geel: DAO
Blauw: Realisatie
Grijs: Solcast


Als iemand een apex chart voorbeeld heeft om vanuit de Forecast Solar plugin te visualiseren, dan kan ik die er ook nog wel bij plotten.

[ Voor 18% gewijzigd door Bravo op 22-08-2025 14:55 ]

[Mirabis]

@Bravo ik gebruik ook Forecast Solar i.v.m. 2 strings op andere hellingshoek. In HA heb ik deze hacs integratie draaien om het binnen te halen: https://github.com/BJReplay/ha-solcast-solar

In de Readme staat ook een apex chart die je waarschijnlijk als input kan gebruiken:

code:

type: custom:apexcharts-card
header:
  title: Solar forecast
  show: true
  show_states: true
  colorize_states: true
apex_config:
  chart:
    height: 300px
  tooltip:
    enabled: true
    shared: true
    followCursor: true
graph_span: 24h
span:
  start: day
yaxis:
  - id: capacity
    show: true
    opposite: true
    decimals: 0
    max: 100
    min: 0
    apex_config:
      tickAmount: 10
  - id: kWh
    show: true
    min: 0
    apex_config:
      tickAmount: 10
  - id: header_only
    show: false
series:
  - entity: sensor.SOLAR_POWER
    name: Solar Power (now)
    type: line
    stroke_width: 2
    float_precision: 2
    color: Orange
    yaxis_id: kWh
    unit: kW
    extend_to: now
    show:
      legend_value: true
      in_header: false
    group_by:
      func: avg
      duration: 5m
  - entity: sensor.solcast_pv_forecast_forecast_today
    name: Forecast
    color: Grey
    opacity: 0.3
    stroke_width: 0
    type: area
    time_delta: +15min
    extend_to: false
    yaxis_id: kWh
    show:
      legend_value: false
      in_header: false
    data_generator: |
      return entity.attributes.detailedForecast.map((entry) => {
            return [new Date(entry.period_start), entry.pv_estimate];
          });
  - entity: sensor.solcast_pv_forecast_forecast_today
    name: Forecast 10%
    color: Grey
    opacity: 0.3
    stroke_width: 0
    type: area
    time_delta: +15min
    extend_to: false
    yaxis_id: kWh
    show:
      legend_value: false
      in_header: false
    data_generator: |
      return entity.attributes.detailedForecast.map((entry) => {
            return [new Date(entry.period_start), entry.pv_estimate10];
          });
  - entity: sensor.SOLAR_GENERATION_ENERGY_TODAY
    yaxis_id: header_only
    name: Today Actual
    stroke_width: 2
    color: Orange
    show:
      legend_value: true
      in_header: true
      in_chart: false
  - entity: sensor.solcast_pv_forecast_forecast_today
    yaxis_id: header_only
    name: Today Forecast
    color: Grey
    show:
      legend_value: true
      in_header: true
      in_chart: false
  - entity: sensor.solcast_pv_forecast_forecast_today
    attribute: estimate10
    yaxis_id: header_only
    name: Today Forecast 10%
    color: Grey
    opacity: 0.3
    show:
      legend_value: true
      in_header: true
      in_chart: false
  - entity: sensor.solcast_pv_forecast_forecast_remaining_today
    yaxis_id: header_only
    name: Remaining
    color: Grey
    show:
      legend_value: true
      in_header: true
      in_chart: false

[Bravo]

Mirabis schreef op vrijdag 22 augustus 2025 @ 16:50:
@Bravo ik gebruik ook Forecast Solar i.v.m. 2 strings op andere hellingshoek. In HA heb ik deze hacs integratie draaien om het binnen te halen: https://github.com/BJReplay/ha-solcast-solar

In de Readme staat ook een apex chart die je waarschijnlijk als input kan gebruiken:

[...]

Dat is de plugin die ik nu al geplot heb Solcast (van BJReplay)
Er is ook nog een andere integratie voor PV verwachting: Forecast Solar

[KC27]

diamanten schreef op vrijdag 22 augustus 2025 @ 14:19:
[...]

Ik weet niet of de produktie in DAO de totale zonproduktie van mijn panelen voor vandaag en morgen dient te zijn, maar het komt niet overeen met de open-meteo cijfers.[Afbeelding]
En:
[Afbeelding]
Misschien een config dingetjes:

code:

  "solar": [ 
    {
      "name": "Enphase",
      "tilt": 30,
      "orientation": 220,
      "capacity": 11.680,
      "yield": 0.007,
      "entity pv switch": "input_boolean.solar_pv_on_off",
      "sensor history": "sensor.envoy_totale_energieproductie_kwh"
    }
  ],

De kolom productie in je tabel uit DAO, is de teruglevering aan het net.
Als je de pv-productie in dao in een tabel wilt zien neem dan deze (kolom pv_ac):

of in grafiek:

[diamanten]

KC27 schreef op vrijdag 22 augustus 2025 @ 19:24:
[...]

De kolom productie in je tabel uit DAO, is de teruglevering aan het net.
Als je de pv-productie in dao in een tabel wilt zien neem dan deze (kolom pv_ac):
[Afbeelding]
of in grafiek:
[Afbeelding]

Ah, dank!
Het klopt dan erg goed:
DAO = 18.642 kWh en daadwerkelijk nu = 18.9kWh.
Open-meteo = 20.9 kWh, Solcast = 22.6 kWh en Forecast.Solar = 14.8 kWh (heb ze alle drie draaien ).
Kortom: DAO is vandaag de nauwkeurigste voorspeller!

[Torch1969]

diamanten schreef op vrijdag 22 augustus 2025 @ 19:31:
[...]

Ah, dank!
Het klopt dan erg goed:
DAO = 18.642 kWh en daadwerkelijk nu = 18.9kWh.
Open-meteo = 20.9 kWh, Solcast = 22.6 kWh en Forecast.Solar = 14.8 kWh (heb ze alle drie draaien ).
Kortom: DAO is vandaag de nauwkeurigste voorspeller!

Op totaal is mooi, maar per uur is belangrijker…

[konehead]

KC27 schreef op vrijdag 22 augustus 2025 @ 19:24:
[...]

De kolom productie in je tabel uit DAO, is de teruglevering aan het net.
Als je de pv-productie in dao in een tabel wilt zien neem dan deze (kolom pv_ac):
[Afbeelding]
of in grafiek:
[Afbeelding]

@KC27 Even een check: de kolom pv_ac bevat niet de voorspelling toch? Bij mij is dit alleen de productie, ook als ik het vinkje prognose aan heb staan. Klopt dit?

[KC27]

konehead schreef op zaterdag 23 augustus 2025 @ 10:05:
[...]

@KC27 Even een check: de kolom pv_ac bevat niet de voorspelling toch? Bij mij is dit alleen de productie, ook als ik het vinkje prognose aan heb staan. Klopt dit?

Als je "prognose" inschakelt wordt wel degelijk voor de toekomstige uren de door DAO berekende prognose getoond.
Hoe zou DAO kunnen weten wat jouw zonnepanelenj over twee uur aan daadwerkelijke pv-productie gaat realiseren?

[konehead]

KC27 schreef op zaterdag 23 augustus 2025 @ 22:12:
[...]

Als je "prognose" inschakelt wordt wel degelijk voor de toekomstige uren de door DAO berekende prognose getoond.
Hoe zou DAO kunnen weten wat jouw zonnepanelenj over twee uur aan daadwerkelijke pv-productie gaat realiseren?

Dan gaat er iets niet goed, ik heb de laatste versie. Dit was om 10h. Ik zie alleen de productie in de tabel. Is dit een bug?

[KC27]

konehead schreef op zaterdag 23 augustus 2025 @ 23:20:
[...]


Dan gaat er iets niet goed, ik heb de laatste versie. Dit was om 10h. Ik zie alleen de productie in de tabel. Is dit een bug?

[Afbeelding]

Ik denk dat het iets met je instellingen te maken heeft.
Kun je de grafiek en de logging (level info, opnemen als "quote" zodat hij wordt ingeklapt) van de laatste berekening hier delen?
Ook een kopie van je instellingen kan handig zijn (ook liefst als quote).

[hemertje]

Vraag mbt de PV-berekeningen

Ik heb 5 dakvlakken in totaal
- plak dak
- muur verticaal
- en drie dakvlakken van het hoofddak

Met welke PV forecast module hebben jullie in HA de beste ervaringen waar ik deze 5 vlakken in kwijt kan?

En hoe kan ik met de iPhone in de hand het beste de ligging bepalen?

[konehead]

KC27 schreef op zaterdag 23 augustus 2025 @ 23:44:
[...]

Ik denk dat het iets met je instellingen te maken heeft.
Kun je de grafiek en de logging (level info, opnemen als "quote" zodat hij wordt ingeklapt) van de laatste berekening hier delen?
Ook een kopie van je instellingen kan handig zijn (ook liefst als quote).

Fijn als je er naar wil kijken!!

code:

 2025-08-24 10:00:00 info: Day Ahead Optimalisering versie: 2025.8.1
2025-08-24 10:00:00 info: Day Ahead Optimalisering gestart op: 24-08-2025 10:00:00
2025-08-24 10:00:00 info: Day Ahead Optimalisatie gestart: 24-08-2025 10:00:00 taak: calc_optimum
2025-08-24 10:00:00 info: Debug = False
2025-08-24 10:00:00 info: Baseload uit instellingen
2025-08-24 10:00:00 info: Start waarden: 
    uur                tijd    p_l    p_t   base  pv_ac  pv_dc
0    10 2025-08-24 10:00:00   0.15   0.15   0.56      0   1.08
1    11 2025-08-24 11:00:00   0.15   0.15   0.57      0   0.82
2    12 2025-08-24 12:00:00   0.15   0.15   0.69      0   0.56
3    13 2025-08-24 13:00:00   0.14   0.14   0.59      0   0.68
4    14 2025-08-24 14:00:00   0.14   0.14   0.54      0   1.69
5    15 2025-08-24 15:00:00   0.15   0.15   0.37      0   1.86
6    16 2025-08-24 16:00:00   0.15   0.15   0.29      0   1.35
7    17 2025-08-24 17:00:00   0.22   0.22   0.33      0   0.29
8    18 2025-08-24 18:00:00   0.27   0.27   0.73      0   0.08
9    19 2025-08-24 19:00:00   0.29   0.29   0.67      0   0.11
10   20 2025-08-24 20:00:00   0.29   0.29   0.46      0   0.02
11   21 2025-08-24 21:00:00   0.29   0.29   0.48      0   0.00
12   22 2025-08-24 22:00:00   0.28   0.28   0.38      0   0.00
13   23 2025-08-24 23:00:00   0.27   0.27   0.22      0   0.00
2025-08-24 10:00:00 info: No reduced hours applied for Simulatie
2025-08-24 10:00:00 info: Startwaarde SoC Simulatie: 16.0%
2025-08-24 10:00:00 info: 

2025-08-24 10:00:00 info: Boiler niet aanwezig of staat uit, boiler wordt niet ingepland
2025-08-24 10:00:00 info: Warmtepomp niet aanwezig of enabled - warmtepomp wordt niet ingepland

2025-08-24 10:00:00 info: Strategie: minimale kosten
2025-08-24 10:00:00 info: Het programma heeft een optimale oplossing gevonden.
2025-08-24 10:00:00 info: Niet geoptimaliseerd, kosten met day ahead tarieven: 0.21  
2025-08-24 10:00:00 info: Geoptimaliseerd, kosten met day ahead tarieven: -1.13 
2025-08-24 10:00:00 info: Levering: 7.64   (kWh)
2025-08-24 10:00:00 info: In- en uitgaande energie per uur batterij Simulatie
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
    10   0.00     --   0.00   1.08   1.08  98.00   1.06     --  24.30
    11   0.00     --   0.00   0.82   0.82  98.00   0.81     --  30.61
    12   0.00     --   0.00   0.56   0.56  98.00   0.55     --  34.92
    13   2.00  94.00   1.88   0.68   2.56  98.00   2.51 125.67  54.56
    14   1.09  94.83   1.04   1.69   2.72  98.00   2.67 244.47  75.41
    15   0.00     --   0.00   1.86   1.86  98.00   1.83     --  89.68
    16   0.00     --   0.00   1.35   1.35  98.00   1.32     -- 100.00
    17  -0.27  94.00  -0.29   0.29   0.00     --   0.00     -- 100.00
    18  -0.07  94.00  -0.08   0.08   0.00     --   0.00     -- 100.00
    19  -3.00  92.00  -3.26   0.11  -3.15  99.00  -3.18  94.24  75.13
    20  -3.00  92.00  -3.26   0.02  -3.24  99.00  -3.27  91.64  49.56
    21  -3.00  92.00  -3.26   0.00  -3.26  99.00  -3.29  91.08  23.82
    22  -1.63  93.00  -1.75   0.00  -1.75  99.00  -1.77  92.07  10.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
Totaal  -7.88     --  -8.99   8.55  -0.43     --  -0.77     --       
2025-08-24 10:00:00 info: Berekende prognoses: 
   uur  bat_in  bat_out   cons   prod   base   boil     wp     ev  pv_ac   cost  profit  b_tem
 10.00    0.00     0.00   0.56   0.00   0.56   0.00   0.00   0.00   0.00   0.09   -0.00  20.00
 11.00    0.00     0.00   0.57   0.00   0.57   0.00   0.00   0.00   0.00   0.09   -0.00  20.00
 12.00    0.00     0.00   0.69   0.00   0.69   0.00   0.00   0.00   0.00   0.10   -0.00  20.00
 13.00    2.00     0.00   2.59   0.00   0.59   0.00   0.00   0.00   0.00   0.37   -0.00  20.00
 14.00    1.09     0.00   1.63   0.00   0.54   0.00   0.00   0.00   0.00   0.23   -0.00  20.00
 15.00    0.00     0.00   0.37   0.00   0.37   0.00   0.00   0.00   0.00   0.06   -0.00  20.00
 16.00    0.00     0.00   0.29   0.00   0.29   0.00   0.00   0.00   0.00   0.04   -0.00  20.00
 17.00    0.00     0.27   0.06   0.00   0.33   0.00   0.00   0.00   0.00   0.01   -0.00  20.00
 18.00    0.00     0.07   0.66   0.00   0.73   0.00   0.00   0.00   0.00   0.18   -0.00  20.00
 19.00    0.00     3.00   0.00   2.33   0.67   0.00   0.00   0.00   0.00   0.00   -0.67  20.00
 20.00    0.00     3.00   0.00   2.54   0.46   0.00   0.00   0.00   0.00   0.00   -0.75  20.00
 21.00    0.00     3.00   0.00   2.52   0.48   0.00   0.00   0.00   0.00   0.00   -0.73  20.00
 22.00    0.00     1.63   0.00   1.25   0.38   0.00   0.00   0.00   0.00   0.00   -0.35  20.00
 23.00    0.00     0.00   0.22   0.00   0.22   0.00   0.00   0.00   0.00   0.06   -0.00  20.00
Totaal    3.09    10.97   7.64   8.64   6.88   0.00   0.00   0.00   0.00   1.23   -2.50       
2025-08-24 10:00:00 info: Winst: € 1.33
2025-08-24 10:00:00 info: Doorzetten van alle settings naar HA
2025-08-24 10:00:00 info: Grid set point: 560.0 W
2025-08-24 10:00:00 info: Cycle cost Simulatie: 0.00 euro
2025-08-24 10:00:00 info: Netto vermogen naar(+)/uit(-) omvormer Simulatie: 0 W
2025-08-24 10:00:00 info: Balanceren: False
2025-08-24 10:00:00 info: Vermogen uit batterij: -1083W
2025-08-24 10:00:00 info: Vermogen dat binnenkomt van pv: 1083W
2025-08-24 10:00:00 info: Vermogen dat binnenkomt van ac: 0W
2025-08-24 10:00:00 info: Waarde SoC na eerste uur: 24.3%

code:

{
    "homeassistant": {},
    "database ha": {
        "engine": "mysql",
        "password": "!secret db_da_password"
    },
    "database da": {
        "engine": "sqlite",
        "db_path": "../data"
    },
    "meteoserver-key": "!secret meteoserver-key",
    "prices": {
        "source day ahead": "nordpool",
        "entsoe-api-key": "!secret entsoe-api-key",
        "energy taxes consumption": {
            "2023-01-01": 0.12599,
            "2024-01-01": 0.1088,
            "2025-01-01": 0.10154
        },
        "energy taxes production": {
            "2022-01-01": 0.06729,
            "2023-01-01": 0.12599,
            "2024-01-01": 0.1088,
            "2025-01-01": 0.10154
        },
        "cost supplier consumption": {
            "2024-04-01": 0.02923,
            "2025-08-01": 0.02398
        },
        "cost supplier production": {
            "2024-04-01": 0.02923,
            "2025-08-01": 0.02398
        },
        "vat": {
            "2024-01-01": 21
        },
        "last invoice": "2025-07-19",
        "tax refund": "True"
    },
    "logging level": "info",
    "use_calc_baseload": "false",
    "baseload calc periode": 20,
    "baseload": [
        0.31,
        0.24,
        0.34,
        0.33,
        0.29,
        0.29,
        0.26,
        0.51,
        0.34,
        0.78,
        0.56,
        0.57,
        0.69,
        0.59,
        0.54,
        0.37,
        0.29,
        0.33,
        0.73,
        0.67,
        0.46,
        0.48,
        0.38,
        0.22
    ],
    "graphical backend": "",
    "graphics": {
        "style": "Solarize_Light2",
        "show": "true",
        "prices consumption": "True",
        "prices production": "True",
        "average consumption": "True",
        "battery balance": "True"
    },
    "strategy": "minimize cost",
    "notifications": {
        "notification entity": "",
        "opstarten": "False",
        "berekening": "False",
        "last activity entity": "input_datetime.dao_last_activity"
    },
    "grid": {
        "max_power": 17
    },
    "history": {
        "save days": 7
    },
    "dashboard": {
        "port": 5000
    },
    "boiler": {
        "boiler present": "False"
    },
    "heating": {
        "heater present": "False"
    },
    "battery": [
        {
            "name": "Simulatie",
            "entity actual level": "sensor.growatt2_battery_soc",
            "capacity": 12.8,
            "upper limit": 100,
            "lower limit": 10,
            "minimum power": 500,
            "dc_to_bat efficiency": 0.98,
            "bat_to_dc efficiency": 0.99,
            "dc_to_bat max power": 4600,
            "bat_to_dc_max_power": 4600,
            "cycle cost": 0,
            "entity set power feedin": "input_number.dao_set_power_feedin",
            "entity set operating mode": "input_select.dao_bat_sim_operating_mode",
            "entity stop inverter": "input_datetime.dao_stop_inverter",
            "entity balance switch": "input_boolean.dao_balance_switch",
            "entity calculated soc": "input_number.dao_entity_calculated_soc",
            "entity from pv": "input_number.dao_from_pv",
            "entity from ac": "input_number.dao_from_ac",
            "entity from battery": "input_number.dao_from_battery",
            "solar": [
             {
              "name": "Dak Woning",
              "tilt": 35,
              "orientation": 0,
              "capacity": 3.12,
              "yield": 0.00663,
              "entity pv switch": ""
              }
            ],
            "charge stages": [
                {
                    "power": 0,
                    "efficiency": 1
                },
                {
                    "power": 1000,
                    "efficiency": 0.95
                },
                {
                    "power": 2000,
                    "efficiency": 0.94
                },
                {
                    "power": 3000,
                    "efficiency": 0.93
                },
                {
                    "power": 4000,
                    "efficiency": 0.91
                },
                {
                    "power": 4500,
                    "efficiency": 0.9
                }
            ],
            "discharge stages": [
                {
                    "power": 0,
                    "efficiency": 1
                },
                {
                    "power": 1000,
                    "efficiency": 0.94
                },
                {
                    "power": 2000,
                    "efficiency": 0.93
                },
                {
                    "power": 3000,
                    "efficiency": 0.92
                },
                {
                    "power": 4000,
                    "efficiency": 0.91
                },
                {
                    "power": 4500,
                    "efficiency": 0.9
                }
            ]
        }
    ],
    "solar": [],
    "electric vehicle": [],
    "machines": [],
    "tibber": {
        "api_token": "!secret tibber_api_token"
    },
    "report": {
        "entities grid consumption": [
            "sensor.growatt2_total_from_grid"
        ],
        "entities grid production": [
            "sensor.growatt2_total_to_grid"
        ],
        "entities solar production ac": [
            "sensor.growatt2_total_production_pv2"
        ],
        "entities solar production dc": [
            "sensor.growatt2_pv2_power"
        ],
        "entities ev consumption": [
            "sensor.wieg_energy_added"
        ],
        "entities wp consumption": [],
        "entities boiler consumption": [],
        "entities battery consumption": [
            "sensor.growatt2_total_battery_charge"
        ],
        "entities battery production": [
            "sensor.growatt2_total_battery_discharge"
        ]
    },
    "scheduler": {
        "1255": "get_day_ahead_prices",
        "1355": "get_day_ahead_prices",
        "1455": "get_day_ahead_prices",
        "1554": "get_day_ahead_prices",
        "1630": "get_meteo_data",
        "1655": "get_day_ahead_prices",
        "2230": "get_meteo_data",
        "2359": "clean_data",
        "0544": "get_meteo_data",
        "1144": "get_meteo_data",
        "1745": "get_meteo_data",
        "2345": "get_meteo_data",
        "0930": "calc_baseloads",
        "xx00": "calc_optimum",
        "xx15": "calc_optimum",
        "xx30": "calc_optimum",
        "xx45": "calc_optimum"
    }
}

[Ferrox1]

Was het al een tijdje van plan, maar ook nu met DAO begonnen ter voorbereiding op volgend jaar. Ik heb zelf al de nodige Home Assistant helpers, scripts en automations geschreven om zo goedkoop mogelijk dingen te plannen. Dit gaat best goed, maar is wel alleen op basis van alleen de prijzen. Op dit moment is er geen accu systeem aanwezig dus een langere termijn is minder relevant.

Mijn situatie is als volgt:
26 zonnepanelen oost west (die moeten nog in DAO)
plug-in hybride (wordt nu gepland via een HASS plugin, werkt best goed) en SMART EVSE
PAP + SAP op de huisaansluiting, automatisch geschakeld, beide met P1 meter en rekent via Home Assistant dus netto verbruik van de aansluiting uit ter voorkoming van overbelasting van de grondzekering of interne onderdelen van de groepenkast
2 airco's voor verwarming

Komt volgend jaar er nog bij:
Warmtepompboiler voor SWW (zit nu op stadsverwarming en die is echt te duur voor alleen SWW)
Mogelijk 3 fasen Victron systeem met accu's

En nu komt het lastige, op 1 meter (PAP) is DAO prima te gebruiken. Ik heb beide meters inmiddels al wel in in DAO zitten. Ik heb in home assitant een YAML helper geschreven die beide meters samenvoegen tot 1 teruglever tarief en 1 verbruikstarief. De salderingen lopen ook niet gelijk (minder relevant als deze komt te vervallen). Nu gaat de meter met de laatste saldering op TLV vergoeding waardoor de eerst aflopen saldering prio krijgt op teruglevering.

Het mooiste zou zijn als je beide meters los in kunt voeren met hun eigen contracten, prijzen en salderingsdata. En dat DAO bepaald wanneer en waar het beste op verbruikt kan worden danwel terug geleverd kan worden (de eerste meter die gesaldeerd moet worden, heeft dan een hoger belang). Vervolgens kan ik HASS wel laten schakelen. Uiteindelijk doel is zelfs om wanneer dit het beste uitkomt, volledig op eilandbedrijf te gaan zodat onnodig verbruik of teruglevering compleet voorkomen word. Dus alleen wanneer ik (of het systeem) dit nodig acht maken we verbinding met het net. Dit kan ook als het nodig is om hogere vermogen te vragen dan beschikbaar van het Victron systeem voor bijvoorbeeld bij lage prijzen, volladen accu's en auto / koelen / verwarmen huis.

Een andere oplossing dat ik in plaats van de nordpool prijzen te laten ophalen door DAO, mijn berekende verbruik en terugleveringsprijzen in DAO kan laden. Dit scheelt ook dubbel opvragen vanuit hetzelfde adres.

Ik ben vooral benieuwd of er anderen zijn met een dergelijke opstelling en hoe zij dit gedaan hebben. Ik kom maar 1 iemand in dit topic vinden met een SAP en dat was @sjampeter . @KC27 , hoe denk jij hier over, hoe zou jij dit opzetten? Ik heb een vermoeden dat dit te complex is en een dergelijke opstelling komt niet vaak voor. Omdat dit ook redelijk schud aan de basis hoe DAO is opgebouwd om dit vrijer op te kunnen zetten.

[KC27]

konehead schreef op zondag 24 augustus 2025 @ 10:13:
[...]

Fijn als je er naar wil kijken!!


[...]


[...]

Je hebt in je instellingen geen pv_ac geconfigureerd, maar je hebt je pv geconfigureerd bij je batterij en die is in de grafiek zichtbaar als pv_dc (dus aangesloten op dc-bar van je batterij).
De voorspelde productie daarvan staat in de overzichtstabel van je batterij in de kolom pv->dc

code:

2025-08-24 10:00:00 info: In- en uitgaande energie per uur batterij Simulatie
   uur   ac->    eff   ->dc pv->dc   dc->    eff  ->bat  o_eff    SoC
          kWh      %    kWh    kWh    kWh      %    kWh      %      %
    10   0.00     --   0.00   1.08   1.08  98.00   1.06     --  24.30
    11   0.00     --   0.00   0.82   0.82  98.00   0.81     --  30.61
    12   0.00     --   0.00   0.56   0.56  98.00   0.55     --  34.92
    13   2.00  94.00   1.88   0.68   2.56  98.00   2.51 125.67  54.56
    14   1.09  94.83   1.04   1.69   2.72  98.00   2.67 244.47  75.41
    15   0.00     --   0.00   1.86   1.86  98.00   1.83     --  89.68
    16   0.00     --   0.00   1.35   1.35  98.00   1.32     -- 100.00
    17  -0.27  94.00  -0.29   0.29   0.00     --   0.00     -- 100.00
    18  -0.07  94.00  -0.08   0.08   0.00     --   0.00     -- 100.00
    19  -3.00  92.00  -3.26   0.11  -3.15  99.00  -3.18  94.24  75.13
    20  -3.00  92.00  -3.26   0.02  -3.24  99.00  -3.27  91.64  49.56
    21  -3.00  92.00  -3.26   0.00  -3.26  99.00  -3.29  91.08  23.82
    22  -1.63  93.00  -1.75   0.00  -1.75  99.00  -1.77  92.07  10.00
    23   0.00     --   0.00   0.00   0.00     --   0.00     --  10.00
Totaal  -7.88     --  -8.99   8.55  -0.43     --  -0.77     --

Er is ook een api waarmee je de prognose van pv_dc in HA kunt opvragen:

code:

http://192.168.178.36:5000/api/report/pv_dc/vandaag_en_morgen

Voor wat betreft de rapportage van je werkelijke productie heb je twee entities geconfigureerd:

code:

        "entities solar production ac": [
            "sensor.growatt2_total_production_pv2"
        ],
        "entities solar production dc": [
            "sensor.growatt2_pv2_power"
        ],

Mijn vraag is nu:
Hoe zit je pv nu echt aangesloten en klopt dit met je configuratie?

[konehead]

KC27 schreef op zondag 24 augustus 2025 @ 22:26:
[...]

Je hebt in je instellingen geen pv_ac geconfigureerd, maar je hebt je pv geconfigureerd bij je batterij en die is in de grafiek zichtbaar als pv_dc (dus aangesloten op dc-bar van je batterij).
De voorspelde productie daarvan staat in de overzichtstabel van je batterij in de kolom pv->dc

[...]

Er is ook een api waarmee je de prognose van pv_dc in HA kunt opvragen:

code:

http://192.168.178.36:5000/api/report/pv_dc/vandaag_en_morgen

Voor wat betreft de rapportage van je werkelijke productie heb je twee entities geconfigureerd:

code:

        "entities solar production ac": [
            "sensor.growatt2_total_production_pv2"
        ],
        "entities solar production dc": [
            "sensor.growatt2_pv2_power"
        ],

Mijn vraag is nu:
Hoe zit je pv nu echt aangesloten en klopt dit met je configuratie?

Dank voor je check!!

Check, dan heb ik je implementatie verkeerd begrepen. Ik dacht dat je AC en DC beide moest configureren. AC voor het gedeelte wat van de zonnepanelen en het net op gaat en DC voor panelen naar de batterij.

Mijn systeem: Ik heb een growatt inverter voor de panelen en batterij. Ik heb dus geen aparte inverter voor zon en geen aparte inverter voor de batterij. Als ik je reactie goed begrijp: ik moet dit dus als DC configureren?