Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[rescla]

Beekforel schreef op dinsdag 29 september 2026 @ 16:01:
Is dat dan omdat jullie accu sneller kan laden/ontladen oid? Bij mij maar minimale activiteiten op de accu.

Kan je efficiëntie of afschrijving zijn denk ik, capaciteit en laadsnelheid zou niet uit moeten maken. Heb je je config al een keer gepost (in een quote)?

[edterbak]

Wat is nu de geadviseerde route om met DAO meerdere batterijen aan te sturen?

1 - Moet ik DAO voeden met 1 virtuele batterij met alle gegevens.
2 - Moet ik DAO voeden met 3 separate batterijen en de werkelijke informatie per batterij.

Ik hang nog een beetje omhoog met deze vraag. Ik heb wat sturing nodig. Advies.

Optie 1, dan moet ik de output van DAO verwerken en zelf daarop de batterij aansturen.
Optie 2, dan is DAO zelf in control over iedere batterij.

Het scenario dat ik heb is dat ik 2 verschillende batterijen heb. 1 venus A en 2x venus E, allen een eigen fase..

Gr.

[Beekforel]

rescla schreef op dinsdag 29 september 2026 @ 18:10:
[...]

Kan je efficiëntie of afschrijving zijn denk ik, capaciteit en laadsnelheid zou niet uit moeten maken. Heb je je config al een keer gepost (in een quote)?

Eerder wel eens maar ook wel weer eens wat aan veranderd. Achter de battery zitten 3 Marstek Venus A batterijen die ik via Home Assistant als 1 heb gemaakt. De aansturing werkt vlekkeloos.

JSON:

{
  "config_version": 2,
  "homeassistant": {
    "ip_address": "supervisor",
    "protocol_api": "http"
  },
  "database_ha": {
    "engine": "sqlite",
    "db_path": "/homeassistant",
    "database": "home-assistant_v2.db"
  },
  "database_da": {
    "engine": "sqlite",
    "db_path": "../data",
    "database": "day_ahead.db"
  },
  "meteoserver_key": "!secret meteoserver-key",
  "meteoserver_model": "harmonie",
  "meteoserver_attemps": 2,
  "prices": {
    "source_day_ahead": "nordpool",
    "energy_taxes_consumption": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161
    },
    "energy_taxes_production": {
      "2022-01-01": 0.06729,
      "2023-01-01": 0.12599,
      "2024-01-01": 0.1088,
      "2025-01-01": 0.10154,
      "2026-01-01": 0.09161,
      "2027-01-01": 0.0
    },
    "cost_supplier_consumption": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2026-01-01": 0.01653,
      "2026-04-29": 0.0205
    },
    "cost_supplier_production": {
      "2022-01-01": 0.002,
      "2023-03-01": 0.018,
      "2024-04-01": 0.0175,
      "2024-08-01": 0.020496,
      "2026-01-01": 0.01653,
      "2026-04-29": -0.0205
    },
    "vat_consumption": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0
    },
    "vat_production": {
      "2022-01-01": 21.0,
      "2022-07-01": 9.0,
      "2023-01-01": 21.0
    },
    "multiplier_consumption": {
      "2000-01-01": 1.0
    },
    "multiplier_production": {
      "2000-01-01": 1.0
    },
    "last_invoice": "2026-08-07",
    "tax_refund": true,
    "regular_high": 0.5,
    "regular_low": 0.4,
    "switch_to_low": 23
  },
  "logging_level": "info",
  "use_calc_baseload": false,
  "baseload_calc_periode": 28,
  "baseload": [
    0.223, 0.264, 0.471, 0.606, 0.566, 0.442, 0.307, 0.417, 0.515, 0.707, 0.687,
    0.902, 1.192, 1.18, 1.16, 1.094, 0.906, 1.085, 0.562, 0.29, 0.119, 0.188,
    0.27, 0.293
  ],
  "graphical_backend": "",
  "graphics": {
    "style": "Solarize_Light2",
    "battery_balance": true,
    "prices_consumption": true,
    "prices_production": false,
    "prices_spot": true,
    "average_consumption": true,
    "show": "true"
  },
  "interval": "15min",
  "strategy": "minimize cost",
  "max_gap": 0.03,
  "notifications": {
    "notification_entity": "input_text.dao_notification",
    "opstarten": false,
    "berekening": false,
    "last_activity_entity": "input_datetime.dao_last_activity"
  },
  "grid": {
    "max_power": 17.0,
    "entity_balance_switch": "input_boolean.dao_battery_balance_mode"
  },
  "history": {
    "save_days": 7
  },
  "dashboard": {
    "port": 5000
  },
  "battery": [
    {
      "name": "Marstek",
      "entity_actual_level": "sensor.dao_battery_soc_combined",
      "capacity": 12.4,
      "upper_limit": 100,
      "lower_limit": 11,
      "penalty_low_soc": 0.0025,

      "charge_stages": [
        { "power": 0.0, "efficiency": 1.0 },
        { "power": 200.0, "efficiency": 0.9 },
        { "power": 2250.0, "efficiency": 0.97 },
        { "power": 4500.0, "efficiency": 0.95 }
      ],

      "discharge_stages": [
        { "power": 0.0, "efficiency": 1.0 },
        { "power": 200.0, "efficiency": 0.9 },
        { "power": 2250.0, "efficiency": 0.97 },
        { "power": 4500.0, "efficiency": 0.95 }
      ],

      "reduce_power_low_soc": [],
      "reduce_power_high_soc": [],

      "minimum_power": 200,

      "dc_to_bat_efficiency": 0.95,
      "bat_to_dc_efficiency": 0.95,

      "cycle_cost": 0.05,

      "entity_set_power_feedin": "input_number.dao_battery_power_feedin",
      "entity_set_operating_mode": "input_select.dao_battery_operating_mode",
      "entity_set_operating_mode_on": "Aan",
      "entity_set_operating_mode_off": "Uit",
      "entity_stop_inverter": "input_datetime.dao_battery_stop",

      "solar": []
    }
  ],
  "solar": [
    {
      "name": "growatt1",
      "entity_pv_switch": "switch.growatt1_inverter_enable",
      "tilt": 55.0,
      "orientation": -30.0,
      "capacity": 4.34,
      "yield_factor": 0.0102175,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": ["sensor.growatt1_total_energy_production"],
      "max_power": 3.6
    },
    {
      "name": "growatt2",
      "entity_pv_switch": "switch.growatt2_inverter_enable",
      "tilt": 55.0,
      "orientation": -30.0,
      "capacity": 6.885,
      "yield_factor": 0.016305,
      "strings": [],
      "ml_prediction": true,
      "ml_training_start_date": "2000-01-01",
      "entities_sensors": ["sensor.growatt2_total_energy_production"],
      "max_power": 6.0
    }
  ],
  "machines": [
    {
      "name": "ariston_boost",
      "programs": [
        {
          "name": "off",
          "power": []
        },
        {
          "name": "boost-1",
          "power": [1300.0, 1300.0, 1300.0, 1300.0]
        },
        {
          "name": "boost-2",
          "power": [
            1300.0, 1300.0, 1300.0, 1300.0, 1300.0, 1300.0, 1300.0, 1300.0
          ]
        }
      ],
      "entity_start_window": "input_datetime.dao_ariston_boost_start_window",
      "entity_end_window": "input_datetime.dao_ariston_boost_end_window",
      "entity_selected_program": "input_select.dao_ariston_boost_selected_program",
      "entity_calculated_start": "input_datetime.dao_ariston_boost_calculated_start",
      "entity_calculated_end": "input_datetime.dao_ariston_boost_calculated_end"
    }
  ],
  "boiler": {
    "boiler_present": false,
    "entity_actual_temp.": "sensor.ariston_temperatuur",
    "entity_setpoint": "input_number.dao_boiler_setpoint",
    "entity_hysterese": "input_number.dao_boiler_hysterese",
    "cop": 1.9,
    "cooling_rate": 0.4,
    "volume": 100,
    "heating_allowed_below": 44,
    "elec._power": 190,
    "boiler_heated_by_heatpump": true,
    "activate_service": "press",
    "activate_entity": "input_button.hw_trigger"
  },
  "heating": {
    "heater_present": true,
    "degree_days_factor": "sensor.dao_degree_days_factor",
    "adjustment": "heating curve",
    "stages": [
      {
        "max_power": 0.0,
        "cop": 8.0
      },
      {
        "max_power": 300.0,
        "cop": 5.5
      },
      {
        "max_power": 500.0,
        "cop": 4.8
      },
      {
        "max_power": 700.0,
        "cop": 4.2
      },
      {
        "max_power": 900.0,
        "cop": 3.8
      },
      {
        "max_power": 1100.0,
        "cop": 3.4
      },
      {
        "max_power": 1400.0,
        "cop": 3.0
      }
    ],
    "entity_adjust_heating_curve": "input_number.dao_heating_curve_adjustment",
    "adjustment_factor": 0.1,
    "min_run_length": 1,
    "entity_hp_cop": "sensor.aquarea_cop",
    "entity_hp_heat_produced": "sensor.aquarea_heatpump_dao_panasonic_heat_power_produced_today"
  },
  "tibber": {
    "api_token": "!secret tibber_api_token",
    "api_url": "https://api.tibber.com/v1-beta/gql"
  },
  "xgboost": {
    "tune_hyperparameters": true
  },
  "report": {
    "entities_grid_consumption": ["sensor.verbruik_totaal"],
    "entities_grid_production": ["sensor.productie_totaal"],
    "entities_solar_production_ac": [
      "sensor.growatt1_total_energy_production_persistent",
      "sensor.growatt2_total_energy_production_persistent"
    ],
    "entities_solar_production_dc": [],
    "entities_ev_consumption": ["sensor.smartevse_8876_evtotalenergycharged"],
    "entities_wp_consumption": [
      "sensor.panasonic_heat_pump_s0_watthourtotal_1",
      "sensor.panasonic_heat_pump_s0_watthourtotal_2"
    ],
    "entities_boiler_consumption": [],
    "entities_battery_consumption": [
      "sensor.marstek_m2_lifetime_charging_energy",
      "sensor.marstek_m3_lifetime_charging_energy"
    ],
    "entities_battery_production": [
      "sensor.marstek_m2_lifetime_discharging_energy",
      "sensor.marstek_m3_lifetime_discharging_energy"
    ],
    "entities_machine_consumption": ["sensor.boiler_energy_corrected"]
  },
  "scheduler": {
    "active": true,
    "schedule": [
      {
        "time": "0430",
        "action": "get_meteo_data"
      },
      {
        "time": "1030",
        "action": "get_meteo_data"
      },
      {
        "time": "0935",
        "action": "calc_baseloads"
      },
      {
        "time": "1630",
        "action": "get_meteo_data"
      },
      {
        "time": "2230",
        "action": "get_meteo_data"
      },
      {
        "time": "1305",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1310",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1400",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1555",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "1655",
        "action": "get_day_ahead_prices"
      },
      {
        "time": "xx00",
        "action": "calc_optimum"
      },
      {
        "time": "xx15",
        "action": "calc_optimum"
      },
      {
        "time": "xx30",
        "action": "calc_optimum"
      },
      {
        "time": "xx45",
        "action": "calc_optimum"
      },
      {
        "time": "2350",
        "action": "train_ml_predictions"
      },
      {
        "time": "2359",
        "action": "clean_data"
      }
    ]
  },
  "meteoserver_attempts": 2
}

Ik heb electric_vehicle er even uit gehaald, anders is het teveel karakters voor GoT.

[pimNH]

Beekforel schreef op dinsdag 29 september 2026 @ 20:34:
[...]

Eerder wel eens maar ook wel weer eens wat aan veranderd. Achter de battery zitten 3 Marstek Venus A batterijen die ik via Home Assistant als 1 heb gemaakt. De aansturing werkt vlekkeloos.

[...]


Ik heb electric_vehicle er even uit gehaald, anders is het teveel karakters voor GoT.

Ik heb het als volgt gedaan met twee marsteks:

{

"config_version": 2,

"homeassistant": {

"ip_address": "supervisor",

"protocol_api": "http"

},

"database_ha": {

"engine": "sqlite",

"db_path": "/homeassistant",

"database": "home-assistant_v2.db"

},

"database_da": {

"engine": "sqlite",

"db_path": "../data",

"database": "day_ahead.db"

},

"meteoserver_key": "!secret meteoserver-key",

"meteoserver_model": "harmonie",

"meteoserver_attemps": 2,

"prices": {

"source_day_ahead": "nordpool",

"energy_taxes_consumption": {

"2026-01-01": 0.09161

},

"energy_taxes_production": {

"2026-01-01": 0.09161

},

"cost_supplier_consumption": {

"2024-08-01": 0.0165

},

"cost_supplier_production": {

"2024-08-01": 0.0165

},

"vat_consumption": {

"2023-01-01": 21.0

},

"vat_production": {

"2023-01-01": 21.0

},

"multiplier_consumption": {

"2000-01-01": 1.0

},

"multiplier_production": {

"2000-01-01": 1.0

},

"last_invoice": "2022-09-01",

"tax_refund": true,

"regular high": 0.5,

"regular low": 0.4,

"switch to low": 23

},

"logging_level": "info",

"use_calc_baseload": false,

"baseload_calc_periode": 56,

"baseload": [

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.14,

0.6,

0.3,

0.3,

0.3,

0.3,

0.14,

0.14

],

"graphical_backend": "",

"graphics": {

"style": "default",

"battery_balance": true,

"prices_consumption": true,

"prices_production": true,

"prices_spot": true,

"average_consumption": true,

"show": "true"

},

"interval": "15min",

"strategy": "minimize cost",

"max_gap": 0.005,

"notifications": {

"opstarten": false,

"berekening": false

},

"grid": {

"max_power": 17.0,

"entity_balance_switch": "input_boolean.DAO_Bat_balance"

},

"history": {

"save_days": 7

},

"dashboard": {

"port": 5000

},

"battery": [

{

"name": "Marstek 1",

"entity_actual_level": "sensor.marstek1_battery_soc",

"capacity": 5,

"upper_limit": 100,

"lower_limit": 10,

"optimal_lower_level": 12,

"penalty_low_soc": 0.0025,

"charge stages": [

{

"power": 0.0,

"efficiency": 1

},

{

"power": 100,

"efficiency": 0.1089

},

{

"power": 200,

"efficiency": 0.5377

},

{

"power": 300,

"efficiency": 0.7095

},

{

"power": 400,

"efficiency": 0.7789

},

{

"power": 500,

"efficiency": 0.8273

},

{

"power": 600,

"efficiency": 0.8576

},

{

"power": 700,

"efficiency": 0.878

},

{

"power": 800,

"efficiency": 0.8921

},

{

"power": 900,

"efficiency": 0.9041

},

{

"power": 1000,

"efficiency": 0.9137

},

{

"power": 1100,

"efficiency": 0.9197

},

{

"power": 1200,

"efficiency": 0.9256

},

{

"power": 1300,

"efficiency": 0.9298

},

{

"power": 1400,

"efficiency": 0.9341

},

{

"power": 1500,

"efficiency": 0.9365

},

{

"power": 1600,

"efficiency": 0.9404

},

{

"power": 1700,

"efficiency": 0.9416

},

{

"power": 1800,

"efficiency": 0.9431

},

{

"power": 1900,

"efficiency": 0.9440

},

{

"power": 2000,

"efficiency": 0.9453

},

{

"power": 2100,

"efficiency": 0.9460

},

{

"power": 2200,

"efficiency": 0.9471

},

{

"power": 2300,

"efficiency": 0.9485

},

{

"power": 2400,

"efficiency": 0.9490

},

{

"power": 2500,

"efficiency": 0.9485

}

],

"discharge stages": [

{

"power": 0.0,

"efficiency": 1

},

{

"power": 100,

"efficiency": 0.5053

},

{

"power": 200,

"efficiency": 0.644

},

{

"power": 300,

"efficiency": 0.7146

},

{

"power": 400,

"efficiency": 0.7581

},

{

"power": 500,

"efficiency": 0.7855

},

{

"power": 600,

"efficiency": 0.8048

},

{

"power": 700,

"efficiency": 0.8181

},

{

"power": 800,

"efficiency": 0.8276

},

{

"power": 900,

"efficiency": 0.8352

},

{

"power": 1000,

"efficiency": 0.8414

},

{

"power": 1100,

"efficiency": 0.8450

},

{

"power": 1200,

"efficiency": 0.8482

},

{

"power": 1300,

"efficiency": 0.8510

},

{

"power": 1400,

"efficiency": 0.8522

},

{

"power": 1500,

"efficiency": 0.8533

},

{

"power": 1600,

"efficiency": 0.8552

},

{

"power": 1700,

"efficiency": 0.8556

},

{

"power": 1800,

"efficiency": 0.8554

},

{

"power": 1900,

"efficiency": 0.8547

},

{

"power": 2000,

"efficiency": 0.8540

},

{

"power": 2100,

"efficiency": 0.8543

},

{

"power": 2200,

"efficiency": 0.8543

},

{

"power": 2300,

"efficiency": 0.8552

},

{

"power": 2400,

"efficiency": 0.8555

},

{

"power": 2500,

"efficiency": 0.8553

}

],

"minimum_power": 100,

"dc_to_bat_efficiency": 1.0,

"bat_to_dc_efficiency": 1.0,

"cycle_cost": 0.02,

"entity_set_power_feedin": "input_number.DAO_Bat_pwr",

"entity_set_operating_mode": "input_select.DAO_Bat_opmode",

"entity_set_operating_mode_on": "Aan",

"entity_set_operating_mode_off": "Uit",

"solar": []

},

{

"name": "Marstek 2",

"entity_actual_level": "sensor.marstek2_battery_soc",

"capacity": 5,

"upper_limit": 100,

"lower_limit": 10,

"optimal_lower_level": 12,

"penalty_low_soc": 0.0025,

"charge stages": [

{

"power": 0.0,

"efficiency": 1

},

{

"power": 100,

"efficiency": 0.1089

},

{

"power": 200,

"efficiency": 0.5377

},

{

"power": 300,

"efficiency": 0.7095

},

{

"power": 400,

"efficiency": 0.7789

},

{

"power": 500,

"efficiency": 0.8273

},

{

"power": 600,

"efficiency": 0.8576

},

{

"power": 700,

"efficiency": 0.878

},

{

"power": 800,

"efficiency": 0.8921

},

{

"power": 900,

"efficiency": 0.9041

},

{

"power": 1000,

"efficiency": 0.9137

},

{

"power": 1100,

"efficiency": 0.9197

},

{

"power": 1200,

"efficiency": 0.9256

},

{

"power": 1300,

"efficiency": 0.9298

},

{

"power": 1400,

"efficiency": 0.9341

},

{

"power": 1500,

"efficiency": 0.9365

},

{

"power": 1600,

"efficiency": 0.9404

},

{

"power": 1700,

"efficiency": 0.9416

},

{

"power": 1800,

"efficiency": 0.9431

},

{

"power": 1900,

"efficiency": 0.9440

},

{

"power": 2000,

"efficiency": 0.9453

},

{

"power": 2100,

"efficiency": 0.9460

},

{

"power": 2200,

"efficiency": 0.9471

},

{

"power": 2300,

"efficiency": 0.9485

},

{

"power": 2400,

"efficiency": 0.9490

},

{

"power": 2500,

"efficiency": 0.9485

}

],

"discharge stages": [

{

"power": 0.0,

"efficiency": 1

},

{

"power": 100,

"efficiency": 0.5053

},

{

"power": 200,

"efficiency": 0.644

},

{

"power": 300,

"efficiency": 0.7146

},

{

"power": 400,

"efficiency": 0.7581

},

{

"power": 500,

"efficiency": 0.7855

},

{

"power": 600,

"efficiency": 0.8048

},

{

"power": 700,

"efficiency": 0.8181

},

{

"power": 800,

"efficiency": 0.8276

},

{

"power": 900,

"efficiency": 0.8352

},

{

"power": 1000,

"efficiency": 0.8414

},

{

"power": 1100,

"efficiency": 0.8450

},

{

"power": 1200,

"efficiency": 0.8482

},

{

"power": 1300,

"efficiency": 0.8510

},

{

"power": 1400,

"efficiency": 0.8522

},

{

"power": 1500,

"efficiency": 0.8533

},

{

"power": 1600,

"efficiency": 0.8552

},

{

"power": 1700,

"efficiency": 0.8556

},

{

"power": 1800,

"efficiency": 0.8554

},

{

"power": 1900,

"efficiency": 0.8547

},

{

"power": 2000,

"efficiency": 0.8540

},

{

"power": 2100,

"efficiency": 0.8543

},

{

"power": 2200,

"efficiency": 0.8543

},

{

"power": 2300,

"efficiency": 0.8552

},

{

"power": 2400,

"efficiency": 0.8555

},

{

"power": 2500,

"efficiency": 0.8553

}

],

"minimum_power": 100,

"dc_to_bat_efficiency": 1.0,

"bat_to_dc_efficiency": 1.0,

"cycle_cost": 0.02,

"entity_set_power_feedin": "input_number.DAO_Bat_pwr_2",

"entity_set_operating_mode": "input_select.DAO_Bat_opmode_2",

"entity_set_operating_mode_on": "Aan",

"entity_set_operating_mode_off": "Uit",

"solar": []

}

],

"solar": [

{

"name": "achter",

"entity_pv_switch": "input_boolean.ZonnepanelenUit",

"tilt": 41.0,

"orientation": -65.0,

"capacity": 5.0,

"yield_factor": 0.01852,

"strings": [],

"ml_prediction": true,

"ml_training_start_date": "2000-01-01",

"entities_sensors": [

"sensor.sn_3020730749_pv_gen_meter"

]

}

],

"electric_vehicle": [],

"machines": [

{

"name": "vaatwasser",

"programs": [

{

"name": "auto",

"power": [

2.0,

2.0,

0.1,

0.1,

2.0,

0.14,

0.14,

0.14

]

},

{

"name": "Uit",

"power": []

}

],

"entity_start_window": "input_datetime.dao_vaatwasser_start_window",

"entity_end_window": "input_datetime.dao_vaatwasser_end_window",

"entity_selected_program": "input_select.dao_vaatwasser_programma",

"entity_calculated_start": "input_datetime.dao_vaatwasser_calculated_start",

"entity_calculated_end": "input_datetime.dao_vaatwasser_calculated_end"

},

{

"name": "Koelkast",

"programs": [

{

"name": "Kouder",

"power": [

1.55,

1.55,

1.45,

1.35,

1.35,

1.35,

1.25,

1.25,

1.25,

1.15,

1.15,

1.05,

1.05,

0.95,

0.85,

0.75

]

},

{

"name": "Uit",

"power": []

}

],

"entity_start_window": "input_datetime.dao_koelkast_start_window",

"entity_end_window": "input_datetime.dao_koelkast_end_window",

"entity_selected_program": "input_select.dao_koelkast_programma",

"entity_calculated_start": "input_datetime.dao_koelkast_calculated_start",

"entity_calculated_end": "input_datetime.dao_koelkast_calculated_end"

},

{

"name": "WPBoiler",

"programs": [

{

"name": "Aan",

"power": [

1.0,

1.1,

1.2

]

},

{

"name": "Uit",

"power": []

}

],

"entity_start_window": "input_datetime.dao_wpboiler_start_window",

"entity_end_window": "input_datetime.dao_wpboiler_end_window",

"entity_selected_program": "input_select.dao_wpboiler_programma",

"entity_calculated_start": "input_datetime.dao_wpboiler_calculated_start",

"entity_calculated_end": "input_datetime.dao_wpboiler_calculated_end"

}

],

"boiler": {

"boiler_present": false,

"entity actual temp.": "sensor.ecodan_heatpump_dhw_current_temp",

"entity setpoint": "sensor.ecodan_heatpump_dhw_setpoint_value",

"entity hysterese": 15,

"cop": 2.2,

"cooling rate": 0.2,

"volume": 200,

"heating allowed below": 45,

"elec. power": 1500,

"activate service": "turn_on",

"activate entity": "input_boolean.forcedhwhelper"

},

"heating": {

"heater_present": false,

"degree days factor": 3.6,

"stages": [

{

"max_power": 225,

"cop": 7.1

},

{

"max_power": 300,

"cop": 7.0

},

{

"max_power": 400,

"cop": 6.5

},

{

"max_power": 500,

"cop": 6.0

},

{

"max_power": 600,

"cop": 5.5

},

{

"max_power": 750,

"cop": 5.0

},

{

"max_power": 1000,

"cop": 4.5

},

{

"max_power": 1250,

"cop": 4.0

}

],

"entity adjust heating curve": "input_number.stooklijn_verschuiving_day_ahead",

"adjustment factor": 0.04

},

"tibber": {

"api_token": "!secret tibber_api_token",

"api_url": "https://api.tibber.com/v1-beta/gql"

},

"xgboost": {

"tune_hyperparameters": true

},

"report": {

"entities_grid_consumption": [

"sensor.electricity_meter_energieverbruik_tarief_1",

"sensor.electricity_meter_energieverbruik_tarief_2"

],

"entities_grid_production": [

"sensor.electricity_meter_energieproductie_tarief_1",

"sensor.electricity_meter_energieproductie_tarief_2"

],

"entities_solar_production_ac": [

"sensor.sn_3020730749_pv_gen_meter"

],

"entities_solar_production_dc": [],

"entities_ev_consumption": [

"sensor.laadpunt_total_energy"

],

"entities_wp_consumption": [],

"entities_boiler_consumption": [],

"entities_battery_consumption": [

"sensor.marstek1_total_charging_energy"

],

"entities_battery_production": [

"sensor.marstek1_total_discharging_energy"

],

"entities_machine_consumption": []

},

"scheduler": {

"active": true,

"schedule": [

{

"time": "0432",

"action": "get_meteo_data"

},

{

"time": "1031",

"action": "get_meteo_data"

},

{

"time": "1633",

"action": "get_meteo_data"

},

{

"time": "2234",

"action": "get_meteo_data"

},

{

"time": "1256",

"action": "get_day_ahead_prices"

},

{

"time": "1340",

"action": "get_day_ahead_prices"

},

{

"time": "1455",

"action": "get_day_ahead_prices"

},

{

"time": "1554",

"action": "get_day_ahead_prices"

},

{

"time": "1655",

"action": "get_day_ahead_prices"

},

{

"time": "xx00",

"action": "calc_optimum"

},

{

"time": "xx15",

"action": "calc_optimum"

},

{

"time": "xx30",

"action": "calc_optimum"

},

{

"time": "xx45",

"action": "calc_optimum"

},

{

"time": "2352",

"action": "clean_data"

}

]

},

"meteoserver_attempts": 2

}

[rescla]

Beekforel schreef op dinsdag 29 september 2026 @ 20:34:
[...]

Eerder wel eens maar ook wel weer eens wat aan veranderd. Achter de battery zitten 3 Marstek Venus A batterijen die ik via Home Assistant als 1 heb gemaakt. De aansturing werkt vlekkeloos.

[...]


Ik heb electric_vehicle er even uit gehaald, anders is het teveel karakters voor GoT.

Het grootste verschil dat ik zie is dit:

code:

      "dc_to_bat_efficiency": 0.98,
      "bat_to_dc_efficiency": 0.98,
      "cycle_cost": 0.01,

Maar het is ook niet zo dat hij per-se die cycle MOET pakken natuurlijk. Als het met jouw instellingen niet fiscaal aantrekkelijk is kan hij hem gewoon skippen. In totaal is het voor de 2 cycli die er nu in staan 4.56 Euro winst, op ik denk in totaal zo rond de 60kWh. Dus zo veel levert het niet op.

[KC27]

Voogel schreef op dinsdag 29 september 2026 @ 10:28:
@KC27 het lijkt er op dat de "entity adjust heating curve" blijft staan op de laatste waarde wanneer de warmtepomp eerst wel en later niet meer nodig is volgens DAO, klopt dat en is dat bewust? Zou het niet handiger zijn om deze naar 0 te zetten wanneer er geen warmtepomp inzet nodig is?

Als je in DAO de wp uit zet (door "heater_present":false of via "entity_hp_enabled"). Dan verandert DAO niks meer aan de waarde in "entity adjust heating curve".
Als in de planning de wp "uit" gaat dan blijft DAO die waarde wel veranderen. Meestal zal de stooklijn dan omlaag gaan.

[Beekforel]

rescla schreef op dinsdag 29 september 2026 @ 22:25:
[...]

Het grootste verschil dat ik zie is dit:

code:

      "dc_to_bat_efficiency": 0.98,
      "bat_to_dc_efficiency": 0.98,
      "cycle_cost": 0.01,

Maar het is ook niet zo dat hij per-se die cycle MOET pakken natuurlijk. Als het met jouw instellingen niet fiscaal aantrekkelijk is kan hij hem gewoon skippen. In totaal is het voor de 2 cycli die er nu in staan 4.56 Euro winst, op ik denk in totaal zo rond de 60kWh. Dus zo veel levert het niet op.

Ja zo is het ook. Ben ook wel tevreden over hoe het nu werkt, maar altijd nieuwsgierig of het beter kan natuurlijk.

De meeste mensen met batterijen om mij heen hebben vooral focus op 0 import/export merk ik. De energiemaatschappij is evil en met 0 ben je het beste uit, toch?

[rescla]

Beekforel schreef op woensdag 30 september 2026 @ 10:11:
[...]

Ja zo is het ook. Ben ook wel tevreden over hoe het nu werkt, maar altijd nieuwsgierig of het beter kan natuurlijk.

De meeste mensen met batterijen om mij heen hebben vooral focus op 0 import/export merk ik. De energiemaatschappij is evil en met 0 ben je het beste uit, toch?

Mijn ouders ook. Op zich is het ook wel fijn om het gevoel van zelfstandigheid te hebben natuurlijk. En lang niet iedereen "snapt" elektra. Vanaf volgend jaar gaat het financiële verschil van NoM ten opzichte van kostenoptimalisatie ook omlaag, dus het is dan nog minder belangrijk dan nu Maar het betekent wel dat je in een gemiddelde Nederlandse winter de accu vrijwel niet gebruikt, dus dat is wel jammer. Zeker als er grote spread is qua kosten en je toch al niet je verbruik efficient verschuift.

[ErnstH]

Wij zijn sinds kort van het gas af, en de warmtepomp-boiler wordt nu ook door DAO aangestuurd (ipv simpelweg om 14.00h)! Ik had wel eerst nog een probleempje dat ik dacht dat hystereses een negatief getal moest zijn.. :)

Andere vraag: is er al een manier op de Zonneplan Zonnebonus correct te implementeren (dus niet via de "vlakke" multiplier)? Of komt er een optie om zelf DAO van prijsinformatie te voorzien, die je dan simpelweg zelf op elk mogelijke manier kan invullen?

[KVan]

rescla schreef op woensdag 30 september 2026 @ 10:16:
[...]

Mijn ouders ook. Op zich is het ook wel fijn om het gevoel van zelfstandigheid te hebben natuurlijk. En lang niet iedereen "snapt" elektra. Vanaf volgend jaar gaat het financiële verschil van NoM ten opzichte van kostenoptimalisatie ook omlaag, dus het is dan nog minder belangrijk dan nu Maar het betekent wel dat je in een gemiddelde Nederlandse winter de accu vrijwel niet gebruikt, dus dat is wel jammer. Zeker als er grote spread is qua kosten en je toch al niet je verbruik efficient verschuift.

In de winter ga je wel degelijk de accu vanuit het net opladen op de "goedkope" momenten (nog steeds relatief duur, maar wel minder duur dan in de avaond). S'avonds stuur je dan die stroom weer terug het net op als hij duur is net als in de zomer. Het voordeel zal enkel kleiner zijn omdat er geen zonnestroom bij zit

Volgend jaar wordt eea flink anders. Dan zal het lang niet zo vaak gunstig zijn om stroom terug te verkopen omdat de belasting niet goed gemaakt wordt, DAO stuurt in die periodes automatisch "0 op de meter" aan. Wanneer de prijsverschillen groot genoeg zijn (of je overschot zonnestroom hebt) gaat hij nog steeds terugleveren.

Ik ben mid augustus DAO gaan gebruiken met Zonneplan en heb ondertussen -90Eur kosten. Ik heb er een simulatie naast lopen die 0 op de meter simuleerd en dan zouden de 520 kWh die ik boven op mijn zonnepanelen nodig had mij 148Eur gekost hebben met een vast contract, een voordeel van 238Euro in anderhalve maand dus.

[rescla]

KVan schreef op woensdag 30 september 2026 @ 14:50:
[...]

In de winter ga je wel degelijk de accu vanuit het net opladen op de "goedkope" momenten (nog steeds relatief duur, maar wel minder duur dan in de avaond). S'avonds stuur je dan die stroom weer terug het net op als hij duur is net als in de zomer. Het voordeel zal enkel kleiner zijn omdat er geen zonnestroom bij zit

Volgend jaar wordt eea flink anders. Dan zal het lang niet zo vaak gunstig zijn om stroom terug te verkopen omdat de belasting niet goed gemaakt wordt, DAO stuurt in die periodes automatisch "0 op de meter" aan. Wanneer de prijsverschillen groot genoeg zijn (of je overschot zonnestroom hebt) gaat hij nog steeds terugleveren.

Ik ben mid augustus DAO gaan gebruiken met Zonneplan en heb ondertussen -90Eur kosten. Ik heb er een simulatie naast lopen die 0 op de meter simuleerd en dan zouden de 520 kWh die ik boven op mijn zonnepanelen nodig had mij 148Eur gekost hebben met een vast contract, een voordeel van 238Euro in anderhalve maand dus.

Ik bedoel dat als je een accu instelt op "zelfverbruik/NoM" dat je daar alleen wat aan hebt als je zonnepanelen daadwerkelijk meer produceren dan dat je verbruikt. Dus iedereen die nu blij is met accu's omdat ze dan "geen stroom gebruiken van het net", gebruikt z'n accu niet in de winter, tenzij ze de strategie aanpassen.

Als je de accu met DAO aanstuurt met minimize cost werkt het gewoon prima uiteraard

[KVan]

rescla schreef op woensdag 30 september 2026 @ 15:31:
[...]

Ik bedoel dat als je een accu instelt op "zelfverbruik/NoM" dat je daar alleen wat aan hebt als je zonnepanelen daadwerkelijk meer produceren dan dat je verbruikt. Dus iedereen die nu blij is met accu's omdat ze dan "geen stroom gebruiken van het net", gebruikt z'n accu niet in de winter, tenzij ze de strategie aanpassen.

Als je de accu met DAO aanstuurt met minimize cost werkt het gewoon prima uiteraard

Klopt,
Met een vast contract en nul op de meter (wat een Deye, maar vast zowat alle inverters) prima zelf kan bereik je het maximum dat met een vast conctract kan.
Met een dynamisch contract is 0 op de meter zoals de inverter dat doet zelfs een magere strategie want de accu/omvormer houd de meter op nul zodra de zonnepanelen minder stroom opwekken dan je verbruikt. Dat is meestal niet het duurste moment. I heb niet echt geprobeert hoe DAO hiermee omgaat maar ga er van uit dat hij de 0 op de meter periode naar het duurste stuk verschuift en de rest uit het net trekt (zolang je geen overschot zonnestroom hebt natuurlijk).
Verder vermoed ik dat DAO de batterij gaat opladen in de goedkoopste periode ook als je 0 op de meter strategie voert als er tekort aan zonnestroom is.

[hemertje]

hemertje schreef op woensdag 16 september 2026 @ 08:17:
Goedemorgen,

nav onderstaande berekening


[...]

Omdat er geen oplossing is wordt het beoogd verbruikt met de oplossing niet getoond?

Is het niet logischer om de beoorde verbruik (hoogste grafiek) en de andere normale grafieken te tonen met in de grafiek een melding 'Geen oplossing voor: minimize cost'

Dan weet je als gebruiker wat er aan de hand is ipv de meteo grafiek te tonen.

[Afbeelding]

kan iemand mij uitleggen waarom ik soms alleen de metedata zie?
en waarom dit voorkomt?

[rescla]

hemertje schreef op woensdag 30 september 2026 @ 21:22:
[...]


kan iemand mij uitleggen waarom ik soms alleen de metedata zie?
en waarom dit voorkomt?

Ik snap de vraag niet helemaal, maar de meteodata wordt getoond als dat er meteodata is opgehaald nadat de laatste optimaliseerberekening heeft gedraaid. In de config onder scheduler kan je zien wanneer dat zou moeten gebeuren. Dat je altijd de meteodata ziet als de berekening blijft falen voor lange periodes is daar een gevolg van.

[ErnstH]

hemertje schreef op woensdag 30 september 2026 @ 21:22:
[...]


kan iemand mij uitleggen waarom ik soms alleen de metedata zie?
en waarom dit voorkomt?

Hij laat gewoon het resultaat van de laatste actie zien.

[KVan]

hemertje schreef op woensdag 30 september 2026 @ 21:22:
[...]


kan iemand mij uitleggen waarom ik soms alleen de metedata zie?
en waarom dit voorkomt?

Je ziet het resultaat van de laatste actie, in dit geval meteo. Bovenaan staan pijltjes waarmee je ook eerdere tijdstippen door kan bladeren. - LOL, de server liep flink achter deze was al meermaals beantwoord.

[ Voor 9% gewijzigd door KVan op 01-10-2026 11:21 ]

[buiter]

Even een vraag.
Ik snap dat je DOA instelt en er verder niet naar omkijkt, maar wordt er ook gewerkt aan een iets gebruiksvriendelijkere/geilere interface?
Of ben ik de enige die gegenereerde grafieken als jpg een beetje primitief vindt?
Ook het configureren van DAO is toch niet helemaal anno 2026?
En nee, UI V2 is dat ook niet.

Misschien ben ik te kritisch, ik zou het namelijk zelf niet kunnen.
Of is juist de presentatie en interactie het lastigst te bouwen?

Omdat energiebeheer komend jaar veel belangrijker wordt heb ik ook nog wel een paar suggesties:
Elektrisch laden inplannen, opwarmen boiler uitstellen op basis van gedrag en zon, samenvatting van de dag in begrijpelijk taal, baseload op basis van historie en weerstation selecteren.

Update: Met AI een mockup laten maken

Suggestie van landingspagina:


Suggestie voor baseload:


En suggestie voor het inplannen van de auto:

[ Voor 42% gewijzigd door buiter op 01-10-2026 17:21 ]

[Koplopert]

Sinds een jaartje heb ik DAO in gebruik. Eerst om een virtuele batterij aan te sturen, sinds een week of twee stuurt-ie een echte aan. Ik ben er erg tevreden over!

Nu probeer The Ultimate DAO Graph te bouwen en loop tegen een issue aan.



Ik haal de prognoses en historie binnen via de API. Voor bat_in en bat_uit gaat dat prima. Voor de pv_ac krijg ik alleen de prognose te zien. Als ik de entitity attributes bekijk, dan zijn ook alleen de prognoses gevuld, alle waardes uit het verleden ('recorded') hebben de waarde 0. De stippellijn is de prognose van SolCast. Die weet niks over mijn historische waarden, dus dat blijft altijd een voorspelling, ook voor het verleden.

De juiste entity is ingevuld bij de report entities in de config en via het DAO dashboard krijg ik wel historische waardem te zien. Enig idee wat er mis kan zijn?

De rest call is: (niet wezenlijk anders dan van bat_in en bat_out)

code:

  - resource: http://192. ... :5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 300
    sensor:
      - name: DAO PV AC
        unique_id: dao_pv_ac
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

En verder (en ik heb het gevoel dat dit al eerder is langsgekomen), is het mogelijk 15-min data uit de api te halen ipv uurdata?

[ Voor 5% gewijzigd door Koplopert op 01-10-2026 13:33 ]

[Torch1969]

buiter schreef op donderdag 1 oktober 2026 @ 13:06:
Even een vraag.
Ik snap dat je DOA instelt en er verder niet naar omkijkt, maar wordt er ook gewerkt aan een iets gebruiksvriendelijkere/geilere interface?
Of ben ik de enige die gegenereerde grafieken als jpg een beetje primitief vindt?
Ook het configureren van DAO is toch niet helemaal anno 2026?
En nee, UI V2 is dat ook niet.

Misschien ben ik te kritisch, ik zou het namelijk zelf niet kunnen.
Of is juist de presentatie en interactie het lastigst te bouwen?

Omdat energiebeheer komend jaar veel belangrijker wordt heb ik ook nog wel een paar suggesties:
Elektrisch laden inplannen, opwarmen boiler uitstellen op basis van gedrag en zon, samenvatting van de dag in begrijpelijk taal, baseload op basis van historie en weerstation selecteren.

Update: Met AI een mockup laten maken

Suggestie van landingspagina:
[Afbeelding]

Suggestie voor baseload:
[Afbeelding]

En suggestie voor het inplannen van de auto:
[Afbeelding]

Hoi @buiter leuk dat je creatief meedenkt. De gui is duidelijk niet het belangrijkste aspect van DAO, dat is de uitmuntende functionaliteit onder de motorkap. Er zijn maar een paar ontwikkelaars betrokken en die stoppen hun vrije tijd en ziel en zaligheid hier voor ons in. Had je je dit gerealiseerd voordat je je bericht hier plaatste?

[Torch1969]

Koplopert schreef op donderdag 1 oktober 2026 @ 13:32:
Sinds een jaartje heb ik DAO in gebruik. Eerst om een virtuele batterij aan te sturen, sinds een week of twee stuurt-ie een echte aan. Ik ben er erg tevreden over!

Nu probeer The Ultimate DAO Graph te bouwen en loop tegen een issue aan.

[Afbeelding]

Ik haal de prognoses en historie binnen via de API. Voor bat_in en bat_uit gaat dat prima. Voor de pv_ac krijg ik alleen de prognose te zien. Als ik de entitity attributes bekijk, dan zijn ook alleen de prognoses gevuld, alle waardes uit het verleden ('recorded') hebben de waarde 0. De stippellijn is de prognose van SolCast. Die weet niks over mijn historische waarden, dus dat blijft altijd een voorspelling, ook voor het verleden.

De juiste entity is ingevuld bij de report entities in de config en via het DAO dashboard krijg ik wel historische waardem te zien. Enig idee wat er mis kan zijn?

De rest call is: (niet wezenlijk anders dan van bat_in en bat_out)

code:

  - resource: http://192. ... :5000/api/report/pv_ac/vandaag_en_morgen
    verify_ssl: false
    scan_interval: 300
    sensor:
      - name: DAO PV AC
        unique_id: dao_pv_ac
        unit_of_measurement: 'kWh'
        value_template: "{{ (value_json.data[now().hour].value) | round(3) }}"
        json_attributes:
          - data

En verder (en ik heb het gevoel dat dit al eerder is langsgekomen), is het mogelijk 15-min data uit de api te halen ipv uurdata?

Ik gebruik voor de historische data de historie van de (state van de) entiteit zelf waarin je de voorspelling opslaat. De state van die entiteit bevat de voorspelling van dat uur, en daarmee heb je de historie dus gewoon in HA zelf zitten. Zie de grijze balkjes in onderstaande grafiek. De rode zijn de voorspelling uit het data attribuut van de entiteit.

[Dogooder]

buiter schreef op donderdag 1 oktober 2026 @ 13:06:
Even een vraag.
Ik snap dat je DOA instelt en er verder niet naar omkijkt, maar wordt er ook gewerkt aan een iets gebruiksvriendelijkere/geilere interface?
Of ben ik de enige die gegenereerde grafieken als jpg een beetje primitief vindt?
Ook het configureren van DAO is toch niet helemaal anno 2026?
En nee, UI V2 is dat ook niet.

Misschien ben ik te kritisch, ik zou het namelijk zelf niet kunnen.
Of is juist de presentatie en interactie het lastigst te bouwen?

Omdat energiebeheer komend jaar veel belangrijker wordt heb ik ook nog wel een paar suggesties:
Elektrisch laden inplannen, opwarmen boiler uitstellen op basis van gedrag en zon, samenvatting van de dag in begrijpelijk taal, baseload op basis van historie en weerstation selecteren.

Update: Met AI een mockup laten maken

Suggestie van landingspagina:
[Afbeelding]

Suggestie voor baseload:
[Afbeelding]

En suggestie voor het inplannen van de auto:
[Afbeelding]

DAO is bedacht als add on voor home assistant. Je suggesties kunnen eigenlijk allemaal al met home assistant. EV inplannen, boiler inplannen, vaatwasser, wasmachine, elk apparaat jij wilt, baseload bereken op basis van historie. Dat kan DAO al allemaal en met home assistant kan je daar een mooie gui voor maken.

Je AI suggesties hebben ook veel weg van home assistant

[hemertje]

rescla schreef op woensdag 30 september 2026 @ 21:39:
[...]

Ik snap de vraag niet helemaal, maar de meteodata wordt getoond als dat er meteodata is opgehaald nadat de laatste optimaliseerberekening heeft gedraaid. In de config onder scheduler kan je zien wanneer dat zou moeten gebeuren. Dat je altijd de meteodata ziet als de berekening blijft falen voor lange periodes is daar een gevolg van.

Meteo data wordt toch 1x per dag opgehaald?
Berekeningen ieder kwartier uitgevoerd?

Dus dan verwacht ik het resultaat van de berekeningen, niet de meteo data die een paar uur eerder is opgehaald?

[thomvh]

hemertje schreef op donderdag 1 oktober 2026 @ 23:05:
[...]


Meteo data wordt toch 1x per dag opgehaald?
Berekeningen ieder kwartier uitgevoerd?

Dus dan verwacht ik het resultaat van de berekeningen, niet de meteo data die een paar uur eerder is opgehaald?

Zie je dit constant ofzo? Want als jij toevallig net na de meteo data kijkt zie je dat tot de hercalculatie heeft plaatsgevonden.

[dannyll]

Kunnen jullie eens meekijken? Mijn baseload geeft nog negatieve waarden. Dat kan natuurlijk niet kloppen. Ik vermoed dat mijn sensoren van mijn batterij nog niet goed ingesteld staan. Wat gaat er fout volgens jullie en waar moet ik dit aanpassen?

[thomvh]

dannyll schreef op vrijdag 2 oktober 2026 @ 11:21:
Kunnen jullie eens meekijken? Mijn baseload geeft nog negatieve waarden. Dat kan natuurlijk niet kloppen. Ik vermoed dat mijn sensoren van mijn batterij nog niet goed ingesteld staan. Wat gaat er fout volgens jullie en waar moet ik dit aanpassen?

[Afbeelding]

Waar gaat die productie heen van de zonnepanelen? Kun je dat achterhalen?

[Deikke]

Tussen 7 en 9 wordt er teruggeleverd, maar is er geen PV productie/accu opbrengst. Komt wellicht uit de accu, die lijkt namelijk 4.5kwh terug te leveren tussen 9 en 10. Wellicht is de sensor een tijdlang niet geupdate?

[dannyll]

thomvh schreef op vrijdag 2 oktober 2026 @ 11:23:
[...]

Waar gaat die productie heen van de zonnepanelen? Kun je dat achterhalen?

op dat moment nog terug het net in. De batterij is gisteren om 14.00uur met 2kw gaan laden

[dannyll]

Deikke schreef op vrijdag 2 oktober 2026 @ 11:28:
Tussen 7 en 9 wordt er teruggeleverd, maar is er geen PV productie/accu opbrengst. Komt wellicht uit de accu, die lijkt namelijk 4.5kwh terug te leveren tussen 9 en 10. Wellicht is de sensor een tijdlang niet geupdate?

Ik denk dat je gelijk hebt. De sensor geeft de waarde dus te laat terug waardoor deze in het verkeerde uur komt

[buiter]

Torch1969 schreef op donderdag 1 oktober 2026 @ 20:02:
[...]

Hoi @buiter leuk dat je creatief meedenkt. De gui is duidelijk niet het belangrijkste aspect van DAO, dat is de uitmuntende functionaliteit onder de motorkap. Er zijn maar een paar ontwikkelaars betrokken en die stoppen hun vrije tijd en ziel en zaligheid hier voor ons in. Had je je dit gerealiseerd voordat je je bericht hier plaatste?

Zeker realiseer ik me dat, waaruit zou blijken dat ik niet besef?
Omdat ik commentaar heb?
DAO als tool is super en waardeer ik, alleen het visuele gedeelte is gewoon niet sexy.
Waarom heeft DAO in de basis een blauwe achtergrond?
Dat mag wat mij betreft in de eerstvolgende release gewoon wit gemaakt worden.

Ik heb Claude gevraagd voor een vebeterde configuratiepagina (en dat heeft ie gebouwd) en dat werkt goed.
De nieuwe configuratie schijft ie weg naar de JSON file.
Daarmee heb ik tegelijk en check op fouten, eventuele opmerkingen bij velden etc etc.
Veel gebruiksvriendelijker en handiger dan werken in een JSON bestand. Vandaar ook mijn post.

Over het inplannen van de auto
Volgens mij houdt DAO pas rekening met het laden van de auto als deze wordt ingeplugd. Dat is een beetje laat als DAO daarvoor net de accu heeft leeg laten lopen. Daarom wil ik graag dat DAO rekening houdt met geplande laadmomenten. Straks in de winter heb ik misschien ook liever dat DAO spaarzamer is met de thuisaccu om mijn auto gunstig op te laden. Je kunt dicuseren over wat wenselijk is omdat je pas één dag vooruit weet wat de prijzen zijn.

Dat is trouwens niet helemaal waar.
Op deze website zie je een verwachting van de komende 7 dagen: https://wattwanneer.nl/
Geen idee hoe betrouwbaar zoeits is.

Met de configuratie van "machines" is er nog wel ruimte voor het aanmaken van geplande energieverbruikers.
Dan maak ik daarin misschien wel een configuratie van een auto/laadpaal aan.

Dogooder schreef op donderdag 1 oktober 2026 @ 20:36:
[...]

DAO is bedacht als add on voor home assistant. Je suggesties kunnen eigenlijk allemaal al met home assistant. EV inplannen, boiler inplannen, vaatwasser, wasmachine, elk apparaat jij wilt, baseload bereken op basis van historie. Dat kan DAO al allemaal en met home assistant kan je daar een mooie gui voor maken.

Je AI suggesties hebben ook veel weg van home assistant

Dat klopt, het inplannen van zaken kan in HA zelf. Maar het is toch zeer functioneel dat essentiële informatie/configuratie gewoon in DAO beschikbaar is?

[konehead]

buiter schreef op donderdag 1 oktober 2026 @ 13:06:
Even een vraag.
Ik snap dat je DOA instelt en er verder niet naar omkijkt, maar wordt er ook gewerkt aan een iets gebruiksvriendelijkere/geilere interface?
Of ben ik de enige die gegenereerde grafieken als jpg een beetje primitief vindt?
Ook het configureren van DAO is toch niet helemaal anno 2026?
En nee, UI V2 is dat ook niet.

Misschien ben ik te kritisch, ik zou het namelijk zelf niet kunnen.
Of is juist de presentatie en interactie het lastigst te bouwen?

Omdat energiebeheer komend jaar veel belangrijker wordt heb ik ook nog wel een paar suggesties:
Elektrisch laden inplannen, opwarmen boiler uitstellen op basis van gedrag en zon, samenvatting van de dag in begrijpelijk taal, baseload op basis van historie en weerstation selecteren.

Update: Met AI een mockup laten maken

Suggestie van landingspagina:
[Afbeelding]

Suggestie voor baseload:
[Afbeelding]

En suggestie voor het inplannen van de auto:
[Afbeelding]

Dankjewel voor je inspiratie. Vanwege het geweldige werk van de DAO ontwikkelaars, kan je dit helemaal zelf maken met de API interface. Zie hieronder obv echte data. Merk op dat mijn DAO 1,5 dag heeft uitgestaan, inverter was gestopt (heeft Growatt gefixed. Vandaar de lage opbrengst.

[Doopy-X-]

konehead schreef op vrijdag 2 oktober 2026 @ 14:28:
[...]

Dankjewel voor je inspiratie. Vanwege het geweldige werk van de DAO ontwikkelaars, kan je dit helemaal zelf maken met de API interface. Zie hieronder obv echte data. Merk op dat mijn DAO 1,5 dag heeft uitgestaan, inverter was gestopt (heeft Growatt gefixed. Vandaar de lage opbrengst.

[Afbeelding]

Dat ziet er prachtig uit, zou je de yaml kunnen delen?

[hemertje]

thomvh schreef op donderdag 1 oktober 2026 @ 23:19:
[...]

Zie je dit constant ofzo? Want als jij toevallig net na de meteo data kijkt zie je dat tot de hercalculatie heeft plaatsgevonden.

nee af en toe
maar dan zie ik dat de meteo bv een paar uur eerder is opgehaald terwijl de berekeningen ieder kwartier draaien

[hemertje]

buiter schreef op vrijdag 2 oktober 2026 @ 11:58:
[...]

Zeker realiseer ik me dat, waaruit zou blijken dat ik niet besef?
Omdat ik commentaar heb?
DAO als tool is super en waardeer ik, alleen het visuele gedeelte is gewoon niet sexy.
Waarom heeft DAO in de basis een blauwe achtergrond?
Dat mag wat mij betreft in de eerstvolgende release gewoon wit gemaakt worden.

Ik heb Claude gevraagd voor een vebeterde configuratiepagina (en dat heeft ie gebouwd) en dat werkt goed.
De nieuwe configuratie schijft ie weg naar de JSON file.
Daarmee heb ik tegelijk en check op fouten, eventuele opmerkingen bij velden etc etc.
Veel gebruiksvriendelijker en handiger dan werken in een JSON bestand. Vandaar ook mijn post.

Over het inplannen van de auto
Volgens mij houdt DAO pas rekening met het laden van de auto als deze wordt ingeplugd. Dat is een beetje laat als DAO daarvoor net de accu heeft leeg laten lopen. Daarom wil ik graag dat DAO rekening houdt met geplande laadmomenten. Straks in de winter heb ik misschien ook liever dat DAO spaarzamer is met de thuisaccu om mijn auto gunstig op te laden. Je kunt dicuseren over wat wenselijk is omdat je pas één dag vooruit weet wat de prijzen zijn.

Dat is trouwens niet helemaal waar.
Op deze website zie je een verwachting van de komende 7 dagen: https://wattwanneer.nl/
Geen idee hoe betrouwbaar zoeits is.

Met de configuratie van "machines" is er nog wel ruimte voor het aanmaken van geplande energieverbruikers.
Dan maak ik daarin misschien wel een configuratie van een auto/laadpaal aan.


[...]

Dat klopt, het inplannen van zaken kan in HA zelf. Maar het is toch zeer functioneel dat essentiële informatie/configuratie gewoon in DAO beschikbaar is?

met het laden van je auto uit je thuisaccu heb je 3x laadverliezen (accu in > accu uit > auto in)
het is gunstiger om je auto direct uit het net te laten laden wanneer de prijzen gunstig zijn

[mgroen81]

hemertje schreef op vrijdag 2 oktober 2026 @ 16:50:
[...]


met het laden van je auto uit je thuisaccu heb je 3x laadverliezen (accu in > accu uit > auto in)
het is gunstiger om je auto direct uit het net te laten laden wanneer de prijzen gunstig zijn

Als de prijzen gunstig zijn kan het prima uit. Zeker met 400v systemen met een hoger dan 95% roundtrip efficiëntie.

[konehead]

Doopy-X- schreef op vrijdag 2 oktober 2026 @ 14:35:
[...]


Dat ziet er prachtig uit, zou je de yaml kunnen delen?

Dank Dank! Stuur mij ff een DM met je email, dan stuur ik hem op (is meer dan 300 regels code )

[anboni]

konehead schreef op vrijdag 2 oktober 2026 @ 19:53:
[...]

Dank Dank! Stuur mij ff een DM met je email, dan stuur ik hem op (is meer dan 300 regels code )

Misschien kan @KC27 'm als voorbeeld in de github opnemen?

[konehead]

anboni schreef op vrijdag 2 oktober 2026 @ 19:59:
[...]

Misschien kan @KC27 'm als voorbeeld in de github opnemen?

Vanmiddag een update gemaakt: Actual vs FC en Vandaag en Morgen. Goed idee qua github, laat maar weten of dit voorbeeld waardig is :)

[pimNH]

konehead schreef op vrijdag 2 oktober 2026 @ 20:08:
[...]

[Afbeelding][Afbeelding] Vanmiddag een update gemaakt: Actual vs FC en Vandaag en Morgen. Goed idee qua github, laat maar weten of dit voorbeeld waardig is :)

Ik ben ook wel geïnteresseerd, is het ook mogelijk om verbruik van ingeplande apparaten uit de api te halen?

[KC27]

konehead schreef op vrijdag 2 oktober 2026 @ 20:08:
[...]

[Afbeelding][Afbeelding] Vanmiddag een update gemaakt: Actual vs FC en Vandaag en Morgen. Goed idee qua github, laat maar weten of dit voorbeeld waardig is :)

Stuur een kopie van die DM maar naar @Torch1969
Hij is de primaire maintainer van de Wiki.
Dan zal het snel in de Wiki komen en hij zal ongetwijfeld ook hier een link naar die pagina plaatsen.

[hemertje]

mgroen81 schreef op vrijdag 2 oktober 2026 @ 17:55:
[...]

Als de prijzen gunstig zijn kan het prima uit. Zeker met 400v systemen met een hoger dan 95% roundtrip efficiëntie.

volgens mij is er geen systeem dat boven de 86-90% RTE uit komt?

[The Source]

Torch1969 schreef op donderdag 1 oktober 2026 @ 20:02:
[...]

Hoi @buiter leuk dat je creatief meedenkt. De gui is duidelijk niet het belangrijkste aspect van DAO, dat is de uitmuntende functionaliteit onder de motorkap. Er zijn maar een paar ontwikkelaars betrokken en die stoppen hun vrije tijd en ziel en zaligheid hier voor ons in. Had je je dit gerealiseerd voordat je je bericht hier plaatste?

Nu moet ik ook van mij laten horen, want ik ben ook voor een makkelijkere configuratie en interface. Echter heb ik mijn mond gehouden omdat ik weet dat dit een hobbyproject is dat enorm veel tijd vraagt van jullie en het doel is niet om iemand te beledigen. Ik ben zeer tevreden over DAO, het is een geweldig project en juist daarom hebben zullen gebruikers meningen hebben.

Ik denk wel dat er over de toekomst nagedacht moet worden. Het is nu vooral op de Nederlandse markt gericht, met Nederlandse uitleg. De configuratie is zelfs voor gevorderden niet makkelijk omdat JSON erg kieskeurig is en geen comments verdraagt. Mocht er behoefte zijn om in de toekomst een groter publiek te bereiken, dan is mijn suggestie om aan de interface te werken.

Er zijn projecten zoals EMHASS die hetzelfde doen, maar wel een interface voor config hebben. En dan is er EVCC dat erg makkelijk qua config is en ook met een optimizer bezig is. Hier zit wel een verdienmodel aan vast.

Ik weet niet of jullie met Claude programmeren en hoe jullie daarover denken, maar voor interface en presentatie is dat een eitje (en wat tokens) om dat te genereren. Als ik op mijn werk zie hoe mijn senior Node.js-developer tegenwoordig dingen doet, dan is het gewoon bangelijk. Zeker omdat je zegt dat voor jullie de interface niet een hoge prioriteit heeft, zou dit misschien m.b.v. Claude te maken kunnen zijn. High impact, low effort. De core onder de moterkap waar de kracht in zit kan dan nog steeds handmatig gemaakt worden.

Nogmaals, dit is een suggestie om jullie harde werk bij een groot publiek te introduceren. Dus zie het als een suggestie en compliment.

buiter schreef op vrijdag 2 oktober 2026 @ 11:58:
[...]
Op deze website zie je een verwachting van de komende 7 dagen: https://wattwanneer.nl/
Geen idee hoe betrouwbaar zoeits is.

Redelijk betrouwbaar
Iig betrouwbaar genoeg om de goedkoopste 4 of 6 uurs tijdvakken in de week te bepalen voor het laden van een auto bv.

[ Voor 15% gewijzigd door The Source op 02-10-2026 22:39 ]

[KC27]

The Source schreef op vrijdag 2 oktober 2026 @ 22:34:
[...]


Nu moet ik ook van mij laten horen, want ik ben ook voor een makkelijkere configuratie en interface. Echter heb ik mijn mond gehouden omdat ik weet dat dit een hobbyproject is dat enorm veel tijd vraagt van jullie en het doel is niet om iemand te beledigen. Ik ben zeer tevreden over DAO, het is een geweldig project en juist daarom hebben zullen gebruikers meningen hebben.

Ik denk wel dat er over de toekomst nagedacht moet worden. Het is nu vooral op de Nederlandse markt gericht, met Nederlandse uitleg. De configuratie is zelfs voor gevorderden niet makkelijk omdat JSON erg kieskeurig is en geen comments verdraagt. Mocht er behoefte zijn om in de toekomst een groter publiek te bereiken, dan is mijn suggestie om aan de interface te werken.

Er zijn projecten zoals EMHASS die hetzelfde doen, maar wel een interface voor config hebben. En dan is er EVCC dat erg makkelijk qua config is en ook met een optimizer bezig is. Hier zit wel een verdienmodel aan vast.

Ik weet niet of jullie met Claude programmeren en hoe jullie daarover denken, maar voor interface en presentatie is dat een eitje (en wat tokens) om dat te genereren. Als ik op mijn werk zie hoe mijn senior Node.js-developer tegenwoordig dingen doet, dan is het gewoon bangelijk. Zeker omdat je zegt dat voor jullie de interface niet een hoge prioriteit heeft, zou dit misschien m.b.v. Claude te maken kunnen zijn. High impact, low effort. De core onder de moterkap waar de kracht in zit kan dan nog steeds handmatig gemaakt worden.

Nogmaals, dit is een suggestie om jullie harde werk bij een groot publiek te introduceren. Dus zie het als een suggestie en compliment.


[...]

Redelijk betrouwbaar
Iig betrouwbaar genoeg om de goedkoopste 4 of 6 uurs tijdvakken in de week te bepalen voor het laden van een auto bv.
[Afbeelding]

Er ligt een ontwerp voor een config-gui van @simnet .
Door tijdgebrek (wie kent hem niet) is dit blijven liggen.
@storeman is - as we speak - bezig met het default maken van V2-GUI en als dat klaar is gaat hij de config-gui van @simnet actualiseren en activeren.
@Dogooder heeft intussen een complete CI-workflow met bijbehorende test-suites geschreven zodat alle codewijzigingen eerst worden getest voordat ze met de main-branche worden gemerged.
Tenslotte ben ik zelf afgelopen maand druk geweest met het implementeren van het verleggen van de planningshorizon m.b.v. prijsvoorspellingen (diverse bronnen) voorlopig tot 96 uur voorbij de door epex vastgestelde prijshorizon.
Sneak-preview:


Als jullie dit allemaal niet snel/geil/sexy genoeg vinden: er zijn genoeg andere goede alternatieven (emhass, evcc, gbb) voor DAO.

[Doopy-X-]

KC27 schreef op vrijdag 2 oktober 2026 @ 23:34:
[...]

Er ligt een ontwerp voor een config-gui van @simnet .
Door tijdgebrek (wie kent hem niet) is dit blijven liggen.
@storeman is - as we speak - bezig met het default maken van V2-GUI en als dat klaar is gaat hij de config-gui van @simnet actualiseren en activeren.
@Dogooder heeft intussen een complete CI-workflow met bijbehorende test-suites geschreven zodat alle codewijzigingen eerst worden getest voordat ze met de main-branche worden gemerged.
Tenslotte ben ik zelf afgelopen maand druk geweest met het implementeren van het verleggen van de planningshorizon m.b.v. prijsvoorspellingen (diverse bronnen) voorlopig tot 96 uur voorbij de door epex vastgestelde prijshorizon.
Sneak-preview:
[Afbeelding]

Als jullie dit allemaal niet snel/geil/sexy genoeg vinden: er zijn genoeg andere goede alternatieven (emhass, evcc, gbb) voor DAO.

Thanks voor de update en sneak peak! Er komen zo te zien coole dingen aan en volgens mij waardeert iedereen de geweldige werking van dit project en de tijd die erin wordt gestoken. Uiteindelijk gaat het om het innerlijk, niet om de looks 😎

[KVan]

@KC27 ik ben het in ieder geval eens met het motto: "functie voor vorm" dat je (jullie) hier volgen. Ik had al je GitHub gezien met langere termijn voorspellingen, die wordt vast in de winter periode erg handig daar zie je in historische data vaak grote dag na dag verschillen. Cudos voor het harde werk hier!

Wat een "geile" interface betreft: waarom niet een aantal verschillende naast elkaar laten bestaan. Je hebt al een api, dus kunnen er neven projecten die grafische kant maken. Op die manier kan je de functie geconcentreerd houden en krijgen gebruikers keuze wat ze graag willen.

Hetzelfde zou kunnen met repositories voor de automatisering, bijvoorbeeld per merk omvormer. Hier wordt het wel moeilijk met aansturen van apparaten, maar de basis sturing van de inverter moet kunnen.

Er zullen mensen moeten opstaan om dit te doen, voor het core team is het dan niet meer dan een lijst met links naar mogelijkheden die naast de bestaande interface werken (met de nodige disclaimer). Op die manier bedien je mij, die aan de core functionaliteit genoeg heeft maar ook diegene die graag een mooie grafisch uitgebreide interface ziet (ik vind een dergelijke interface best interessant maar nodig is wat anders).

[DaBit]

KC27 schreef op vrijdag 2 oktober 2026 @ 23:34:
Tenslotte ben ik zelf afgelopen maand druk geweest met het implementeren van het verleggen van de planningshorizon m.b.v. prijsvoorspellingen (diverse bronnen) voorlopig tot 96 uur voorbij de door epex vastgestelde prijshorizon.

Kijk, daar word ik dan weer vrolijk van!

GUI's, ach, overrated. Als er een knopje of vinkje op zit wat doet dat het moet doen, het presenteert de informatie die je wil zien en je hoeft niet 5x te klikken als het in 1x ook had gekund dan is het al gauw goed genoeg. De rest is mode. Over 2 jaar zijn we denk ik wel op het punt dat de X Athena Widgets of Motif gepresenteerd wordt als 'de designtaal van 2029, het minimalistische design laat meer ruimte over voor echte informatie en leid minder af, blablabla blabla bla'.

[oscaarbasgitaar]

Helemaal eens dat "mooie plaatjes met een fancy strik errond" bijkomstig zijn aan het doel van de Add-on: kosten besparen.

Na een weekje monitoren snap ik best wel dat deze add-on mijn thuisbatterij beter zou aansturen dan de Solis-"AI"-EMS. Dus ben ik overgeschakeld van de solis-API-integratie naar de modbusversie om zo de batterij te sturen. De API heeft namelijk wel af en toe wat issues met stabiliteit. De twee naast elkaar draaien heeft geen zin: veel modbus requests zorgen ervoor dat de API minder vlot draait.

Gevolg is wel dat ik een hele hoop zaken moet aanpassen en ook een hoop data van anderhalf jaar dat ik met HA bezig ben verlies (oa energiedashboard).
Je kan dat wel overzetten, maar da's dan weer een hele hoop werk en die data kan ik extern nog steeds ophalen via de soliscloud...

Waar ik wel mee struggle is de "reports".
Meestal krijg ik een foutmelding (internal server error - ValueError: NaTType does not support strftime) heel uitzonderlijk lukt het wel eens, maar ook dan blijft het instabiel: als ik dan bijvoorbeeld een andere periode wil of van tabel naar charts wil overschakelen krijg ik terug die error.

Ik heb al zitten zoeken in dit forum en heb 1 gelijkaardige melding gevonden, daar bleek het om een soort bug te gaan.

@KC27: ik hoop dat ik hieronder genoeg info uit de debug-log voor je aanlever om dit te kunnen uitzoeken. Het stelt verder geen problemen, de berekeningen werken, dit is voor mij geen noodzakelijke feature. Ik snap dat jullie dit allemaal vrijwillig doen, kijk zelf maar wanneer je hier tijd voor zou kunnen vinden, ik ga je zeker niet opjagen.

code:

Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 340, in menu
    return reports("reports")
  File "/root/dao/webserver/app/routes.py", line 731, in reports
    report_df = report.get_grid_data(active_period, _tot=tot)
  File "/root/dao/prog/da_report.py", line 2214, in get_grid_data
    df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
  File "/root/dao/prog/da_report.py", line 3054, in get_price_data
    df_da = self.db_da.get_column_data(
        "values", "da", start=start, end=end, agg_func=agg_func
    )
  File "/root/dao/lib/db_manager.py", line 491, in get_column_data
    end = end.strftime("%Y-%m-%d %H:%M")
  File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime
ValueError: NaTType does not support strftime
[2026-09-30 16:19:39,005] fout in app: Exception on / [POST]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 340, in menu
    return reports("reports")
  File "/root/dao/webserver/app/routes.py", line 731, in reports
    report_df = report.get_grid_data(active_period, _tot=tot)
  File "/root/dao/prog/da_report.py", line 2214, in get_grid_data
    df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
  File "/root/dao/prog/da_report.py", line 3054, in get_price_data
    df_da = self.db_da.get_column_data(
        "values", "da", start=start, end=end, agg_func=agg_func
    )
  File "/root/dao/lib/db_manager.py", line 491, in get_column_data
    end = end.strftime("%Y-%m-%d %H:%M")
  File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime

De voorspellingshorizon verlengen heeft ook mijn voorkeur
De vraag is voor mij wel in welke mate 4 dagen vooruit kijken met bovendien nog een onzekerheidsfactor veel invloed heeft op de actie voor komend kwartier / uur.
Volgens mij is anderhalve dag meer dan voldoende: dus tussen middernacht en het moment dat je de epex prijs voor morgen terug hebt.
Maar ik ga jullie niet tegenhouden

[ Voor 4% gewijzigd door oscaarbasgitaar op 03-10-2026 09:59 ]

[simnet]

oscaarbasgitaar schreef op zaterdag 3 oktober 2026 @ 09:52:
Helemaal eens dat "mooie plaatjes met een fancy strik errond" bijkomstig zijn aan het doel van de Add-on: kosten besparen.

Na een weekje monitoren snap ik best wel dat deze add-on mijn thuisbatterij beter zou aansturen dan de Solis-"AI"-EMS. Dus ben ik overgeschakeld van de solis-API-integratie naar de modbusversie om zo de batterij te sturen. De API heeft namelijk wel af en toe wat issues met stabiliteit. De twee naast elkaar draaien heeft geen zin: veel modbus requests zorgen ervoor dat de API minder vlot draait.

Gevolg is wel dat ik een hele hoop zaken moet aanpassen en ook een hoop data van anderhalf jaar dat ik met HA bezig ben verlies (oa energiedashboard).
Je kan dat wel overzetten, maar da's dan weer een hele hoop werk en die data kan ik extern nog steeds ophalen via de soliscloud...

Waar ik wel mee struggle is de "reports".
Meestal krijg ik een foutmelding (internal server error - ValueError: NaTType does not support strftime) heel uitzonderlijk lukt het wel eens, maar ook dan blijft het instabiel: als ik dan bijvoorbeeld een andere periode wil of van tabel naar charts wil overschakelen krijg ik terug die error.

Ik heb al zitten zoeken in dit forum en heb 1 gelijkaardige melding gevonden, daar bleek het om een soort bug te gaan.

@KC27: ik hoop dat ik hieronder genoeg info uit de debug-log voor je aanlever om dit te kunnen uitzoeken. Het stelt verder geen problemen, de berekeningen werken, dit is voor mij geen noodzakelijke feature. Ik snap dat jullie dit allemaal vrijwillig doen, kijk zelf maar wanneer je hier tijd voor zou kunnen vinden, ik ga je zeker niet opjagen.

code:

Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 340, in menu
    return reports("reports")
  File "/root/dao/webserver/app/routes.py", line 731, in reports
    report_df = report.get_grid_data(active_period, _tot=tot)
  File "/root/dao/prog/da_report.py", line 2214, in get_grid_data
    df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
  File "/root/dao/prog/da_report.py", line 3054, in get_price_data
    df_da = self.db_da.get_column_data(
        "values", "da", start=start, end=end, agg_func=agg_func
    )
  File "/root/dao/lib/db_manager.py", line 491, in get_column_data
    end = end.strftime("%Y-%m-%d %H:%M")
  File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime
ValueError: NaTType does not support strftime
[2026-09-30 16:19:39,005] fout in app: Exception on / [POST]
Traceback (most recent call last):
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/root/dao/venv/day_ahead/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/root/dao/webserver/app/routes.py", line 340, in menu
    return reports("reports")
  File "/root/dao/webserver/app/routes.py", line 731, in reports
    report_df = report.get_grid_data(active_period, _tot=tot)
  File "/root/dao/prog/da_report.py", line 2214, in get_grid_data
    df_prices = self.get_price_data(vanaf, last_moment, interval="1hour")
  File "/root/dao/prog/da_report.py", line 3054, in get_price_data
    df_da = self.db_da.get_column_data(
        "values", "da", start=start, end=end, agg_func=agg_func
    )
  File "/root/dao/lib/db_manager.py", line 491, in get_column_data
    end = end.strftime("%Y-%m-%d %H:%M")
  File "pandas/_libs/tslibs/nattype.pyx", line 54, in pandas._libs.tslibs.nattype._make_error_func.f
ValueError: NaTType does not support strftime

De voorspellingshorizon verlengen heeft ook mijn voorkeur
De vraag is voor mij wel in welke mate 4 dagen vooruit kijken met bovendien nog een onzekerheidsfactor veel invloed heeft op de actie voor komend kwartier / uur.
Volgens mij is anderhalve dag meer dan voldoende: dus tussen middernacht en het moment dat je de epex prijs voor morgen terug hebt.
Maar ik ga jullie niet tegenhouden

Misschien net te laat, maar je kunt met deze de metingen van sensoren migreren:
https://github.com/mayerwin/HA-Merge-Sensor-History

[KC27]

Wellicht ten overvloede voor gebruikers die mooie plaatjes willen in HA:
Met Power Flow Card Plus krijg je inzicht in de actuele vermogens van je woning:

[Doopy-X-]

KC27 schreef op zaterdag 3 oktober 2026 @ 13:51:
Wellicht ten overvloede voor gebruikers die mooie plaatjes willen in HA:
Met Power Flow Card Plus krijg je inzicht in de actuele vermogens van je woning:
[Afbeelding]

Check, die heb ik van de week ook voor alle verdiepingen toegevoegd

[ Voor 9% gewijzigd door Doopy-X- op 03-10-2026 16:29 ]

[hemertje]

KC27 schreef op vrijdag 2 oktober 2026 @ 23:34:
[...]
Tenslotte ben ik zelf afgelopen maand druk geweest met het implementeren van het verleggen van de planningshorizon m.b.v. prijsvoorspellingen (diverse bronnen) voorlopig tot 96 uur voorbij de door epex vastgestelde prijshorizon.
Sneak-preview:
[Afbeelding]

Als jullie dit allemaal niet snel/geil/sexy genoeg vinden: er zijn genoeg andere goede alternatieven (emhass, evcc, gbb) voor DAO.

Hoi @KC27 , mooi dat de horizon wordt verlengd.

Een sterilisatierun is voor mij precies het geval dat dat nodig heeft. Bij mij is het een warmtepompboiler (Panasonic Aquarea, 300 L):
tot circa 52 °C draait alleen de compressor (gemiddeld 1,9 kW, COP circa 3), daarboven schakelt de backup-heater van 3 kW bij, en een sterilisatierun naar 65 °C is bijna volledig weerstandsverwarming.
Nu draait hij via Ed's Node-RED scheduler elke vrijdag 12:30, dus los van de prijs.

Zou dit in DAO planbaar kunnen worden, met een interval (bijvoorbeeld 7 dagen), een eindtemperatuur, een vermogen en COP voor de heater, en een entiteit die de run start?
Ik meet volgende week de energie van een run en lever de cijfers graag aan.
Ik heb ook een concept met metingen over de modellering van de tank (gelaagdheid, variabel vermogen) dat ik graag deel als dat nuttig is.

[simnet]

hemertje schreef op zaterdag 3 oktober 2026 @ 19:25:
[...]


Hoi @KC27 , mooi dat de horizon wordt verlengd.

Een sterilisatierun is voor mij precies het geval dat dat nodig heeft. Bij mij is het een warmtepompboiler (Panasonic Aquarea, 300 L):
tot circa 52 °C draait alleen de compressor (gemiddeld 1,9 kW, COP circa 3), daarboven schakelt de backup-heater van 3 kW bij, en een sterilisatierun naar 65 °C is bijna volledig weerstandsverwarming.
Nu draait hij via Ed's Node-RED scheduler elke vrijdag 12:30, dus los van de prijs.

Zou dit in DAO planbaar kunnen worden, met een interval (bijvoorbeeld 7 dagen), een eindtemperatuur, een vermogen en COP voor de heater, en een entiteit die de run start?
Ik meet volgende week de energie van een run en lever de cijfers graag aan.
Ik heb ook een concept met metingen over de modellering van de tank (gelaagdheid, variabel vermogen) dat ik graag deel als dat nuttig is.

Heel eerlijk: ik zou dit soort risicovolle veiligheidsdingen nooit willen proberen te sturen. Legionellabacterien / veteranenziekte is echt geen grapje en daar gaan mensen aan dood.

Ik zou het ook niet op mn geweten willen hebben dat het fout gaat door een wel bedoeld, maar verkeerd advies.

[workzone]

simnet schreef op zaterdag 3 oktober 2026 @ 19:43:
[...]


Heel eerlijk: ik zou dit soort risicovolle veiligheidsdingen nooit willen proberen te sturen. Legionellabacterien / veteranenziekte is echt geen grapje en daar gaan mensen aan dood.

Ik zou het ook niet op mn geweten willen hebben dat het fout gaat door een wel bedoeld, maar verkeerd advies.

Mijn WPB reset de legionella run timer als ik het vat zelf naar de juiste temperatuur opstook.
Je zou haast verwachten dat andere boilers dit ook op deze manier doen.

[oscaarbasgitaar]

simnet schreef op zaterdag 3 oktober 2026 @ 11:05:
[...]


Misschien net te laat, maar je kunt met deze de metingen van sensoren migreren:
https://github.com/mayerwin/HA-Merge-Sensor-History

vriendelijk bedankt, maar te laat inderdaad.

[Oilman]

simnet schreef op zaterdag 3 oktober 2026 @ 19:43:
[...]


Heel eerlijk: ik zou dit soort risicovolle veiligheidsdingen nooit willen proberen te sturen. Legionellabacterien / veteranenziekte is echt geen grapje en daar gaan mensen aan dood.

Ik zou het ook niet op mn geweten willen hebben dat het fout gaat door een wel bedoeld, maar verkeerd advies.

Volledig off-topic. Ik heb nog nooit gelezen dat er iemand uberhaupt een legionella besmetting thuis heeft opgelopen op het boilervat niet vaak genoeg opgestookt werd. Net alsof iedereen die terug komt van zomervakantie netjes z'n leidingen doorspoelt, terwijl dan de kans op een hoge concentratie legionella een stuk hoger is dan een vat dat regelmatig 'leeg' getapt wordt.

Bij mijn eigen analyse van het stookgedrag van mijn boilervat met de WP, kwam ik tot de conclusie dat gewoon domweg iedere middag (bijna) forceren om 1300 uur het voordeligste uitpakt. Meeste kans op PV opbrengst, normaliter de hoogste temperatuur, vaak acceptabele kWh prijzen. Vooral voorkomen dat het ding 's avonds te leeg gaat en dan op de duurste uren van de dag een DHW run gaat draaien + WAF . Gaan schuiven met het tijdstip op de dag leverde praktisch niets op bij de analyse van afgelopen jaar. Dat is als captain hindsight, met een voorspelling erbij gaat het ook wel eens fout, bijv dat de zon op het voorspelde moment het af laat weten.

[hemertje]

simnet schreef op zaterdag 3 oktober 2026 @ 19:43:
[...]


Heel eerlijk: ik zou dit soort risicovolle veiligheidsdingen nooit willen proberen te sturen. Legionellabacterien / veteranenziekte is echt geen grapje en daar gaan mensen aan dood.

Ik zou het ook niet op mn geweten willen hebben dat het fout gaat door een wel bedoeld, maar verkeerd advies.

Hoi SImnet,

los van het feit dat ik ook twijfel aan een legionelle besmetting thuis, kan je wanneer je deze toch wekelijks draait deze het beste optimaal plannen ipv ongecontroleerd draaien tijdens de dure uren?

[hemertje]

Oilman schreef op zaterdag 3 oktober 2026 @ 20:21:
[...]

Volledig off-topic. Ik heb nog nooit gelezen dat er iemand uberhaupt een legionella besmetting thuis heeft opgelopen op het boilervat niet vaak genoeg opgestookt werd. Net alsof iedereen die terug komt van zomervakantie netjes z'n leidingen doorspoelt, terwijl dan de kans op een hoge concentratie legionella een stuk hoger is dan een vat dat regelmatig 'leeg' getapt wordt.

Bij mijn eigen analyse van het stookgedrag van mijn boilervat met de WP, kwam ik tot de conclusie dat gewoon domweg iedere middag (bijna) forceren om 1300 uur het voordeligste uitpakt. Meeste kans op PV opbrengst, normaliter de hoogste temperatuur, vaak acceptabele kWh prijzen. Vooral voorkomen dat het ding 's avonds te leeg gaat en dan op de duurste uren van de dag een DHW run gaat draaien + WAF . Gaan schuiven met het tijdstip op de dag leverde praktisch niets op bij de analyse van afgelopen jaar. Dat is als captain hindsight, met een voorspelling erbij gaat het ook wel eens fout, bijv dat de zon op het voorspelde moment het af laat weten.

nadeel is dat een WP globaal tot een 52GrC warmwater maakt via de compressor met een hogere COP, daarboven tot bv 65GrC draait het volledig op de elektrische element van de backup heater met een COP van 1.

[hemertje]

Hoi Corné, @KC27 e.a.

nu de winter eraan komt, een vraag van mij over verwarmen met de warmtepomp.

Ik heb een Panasonic 7kW lucht/water warmtepomp die ik nu aanstuur met Ed's Node Red.
Tot nu toe gebruik ik DAO voor het laden en ontladen van de Zendure accu's en sinds kort ook voor de boiler (warm water, via Ed's Node Red).

Ik wil graag in de winterperiode de lage dynamische stroomprijzen (overdag en 's nachts) gebruiken om het huis een beetje extra op te warmen, zodat de warmtepomp tijdens de dure uren uit kan.
Het huis werkt dan als een soort warmteaccu.
Voordat ik iets instel wil ik graag zeker weten dat ik begrijp wat DAO nu al doet.

Hieronder een opsomming zoals ik nu snap hoe DAO werkt (zeg het aub als ik het fout heb):

• DAO rekent per dag uit hoeveel warmte het huis nodig heeft (op basis van de graaddagen) en zet de warmtepomp vooral in de goedkoopste uren aan?
• De stooklijn kan met de prijs meeschuiven: bij een dure prijs iets lager, bij een lage prijs iets hoger?
• DAO weet niet wat de temperatuur in huis is. Het weet dus ook niet hoe lang de pomp uit kan voordat het te koud wordt?

Nu mijn vragen:

1. Klopt dit, of is er al een manier om het huis als warmtebuffer te gebruiken die ik gemist heb?

2. Staat het op de planning dat DAO rekening houdt met de binnentemperatuur, met een grens naar boven en naar beneden?
Dan kan DAO op lage prijzen extra verwarmen en de pomp in de dure uren uit laten, zonder dat het te koud wordt. Past dat misschien bij de langere planning waar je aan werkt?

3. Zo niet: is een simpele tussenstap mogelijk?
Bijvoorbeeld: boven een bepaalde prijs, of in vaste uren in de avondpiek, mag de pomp niet verwarmen (warm water blijft gewoon mogelijk), met een veiligheidsgrens op de binnentemperatuur.

4. Een vraag over het verbruik van de warmtepomp. Ik heb de vermogenssensor van de pomp in de DAO-instellingen staan, maar de pompsturing van DAO staat uit. Klopt het dat het pompverbruik dan van de netafname wordt afgetrokken en dus niet in de basislast terechtkomt? Of komt het er juist wel in?

5. Een vraag over de instelling adjustment factor (de stooklijn die met de prijs meeschuift). In de documentatie staat "K/10%": zoveel graden verschuiving als de prijs 10% van het daggemiddelde afwijkt. In de code (utils.py, calc_adjustment_heatcurve) staat:

code:

adjustment = round(-adjustment_factor * (price_act - price_avg) * 100 / price_avg, 1)

en in het commentaar "0,4 K per 10% = 0.04 K/%".

Dat is graden per procent, dus 10 keer zoveel als de documentatie zegt.
Voorbeeld: met adjustment_factor: 2.0 (gelezen als 2 graden per 10%) geeft de code -20 graden als de prijs 10% boven het gemiddelde zit.

Mijn schuifregelaar in Home Assistant gaat maar van -3 tot +3. Welke van de twee is de bedoeling, de documentatie of de code?
En zou een melding in de log kunnen komen als de berekende waarde buiten die schuifregelaar valt?

Bij mij staat de warmtepompsturing van DAO nog uit, dus er is nog niets mis gegaan.

Wat achtergrondinformatie die ik gevonden heb:
Onderzoek met echte woningen laat zien dat slim sturen van een warmtepomp op stroomprijs (in de literatuur "MPC" genoemd: een regeling die met een rekenmodel van het huis en voorspellingen vooruit plant) ongeveer 2 tot 6% kan besparen, en dat het grootste deel daarvan al komt van het uitzetten van de pomp in de avondpiek.
Een proef van 125 dagen gaf 9%, terwijl een korte proef van een paar dagen 34% liet zien.
Ik verwacht dus geen wonderen, maar de avondpiek-stap lijkt me een mooie eerste stap. Ik denk graag mee en test mee, en meet dan met vergelijkbare dagen, wanneer er eventueel een testversie komt.

Een vergelijkbaar project dat het huis zelf leert kennen uit meetdata (warmteverlies, thermische massa, zon), is NeedForHeat van Windesheim (CC BY 4.0):
https://github.com/energi...orheat-diagnosis-software

Alvast hartelijk dank voor jullie reacties...

[thomvh]

@KC27
Ik heb twee PR's geopend op Gitlab:

• PV EV entiteit. Deze geeft aan of DAO verwacht dat de PV surcharge naar de auto gaat.https://github.com/corneel27/day-ahead/pull/874
• Soort van Zonnebonus toegevoegd aan de berekening. https://github.com/corneel27/day-ahead/pull/876

Feedback is welkom!

[Wilin]

hemertje schreef op zaterdag 3 oktober 2026 @ 19:25:
[...]


Hoi @KC27 , mooi dat de horizon wordt verlengd.

Een sterilisatierun is voor mij precies het geval dat dat nodig heeft.

...

Zou dit in DAO planbaar kunnen worden, met een interval (bijvoorbeeld 7 dagen), een eindtemperatuur, een vermogen en COP voor de heater, en een entiteit die de run start?


...

Ik heb mijn legionella run op de volgende manier ingepland:

• het is een machine in DAO
• op zaterdag om 17 loopt er een automatisatie die de window correct inplant op zondag en het programma aanzet.
• wanneer DAO aangeeft dat de run best begint, zet een automatisatie de boiler aan op 60C
• wanneer het verbruik terugvalt wordt het programma terug uit gezet.

[mgroen81]

hemertje schreef op vrijdag 2 oktober 2026 @ 21:35:
[...]


volgens mij is er geen systeem dat boven de 86-90% RTE uit komt?

Jazeker wel. Hoe hoger het voltage, hoe hoger het potentiële efficiëntie. Bij 800v nog iets hoger. Eigenlijk is dit het grote nadeel van de 48v systemen.

Ik gebruik zelf een Fronius Symo 10.0 en een 52kWh 400V battery. 98℅ eff.

[ Voor 8% gewijzigd door mgroen81 op 04-10-2026 00:10 ]

[workzone]

mgroen81 schreef op zondag 4 oktober 2026 @ 00:07:
[...]

Jazeker wel. Hoe hoger het voltage, hoe hoger het potentiële efficiëntie. Bij 800v nog iets hoger. Eigenlijk is dit het grote nadeel van de 48v systemen.

Ik gebruik zelf een Fronius Symo 10.0 en een 52kWh 400V battery. 98℅ eff.

De meeste accu cellen blijven alleen al steken bij een efficiency van max 97%, dus een RTE van 98% lijkt me niet haalbaar. Als je systeem heel erg efficient is zit je misschien rond de 90 tot 92%.

[simnet]

hemertje schreef op zaterdag 3 oktober 2026 @ 20:37:
[...]


Hoi SImnet,

los van het feit dat ik ook twijfel aan een legionelle besmetting thuis, kan je wanneer je deze toch wekelijks draait deze het beste optimaal plannen ipv ongecontroleerd draaien tijdens de dure uren?

Uiteindelijk moet je het zelf weten, maar hou op zijn minst rekening met gelaagdheid van je vat en zorg dat het hele vat, inclusief de onderste lagen op temperatuur komen en die ook lang genoeg aanhouden.

ISSO 55.1 is een leuke om te lezen. Gaat over gehele installaties en niet in een particuliere opzet, maar het geeft wel de diepte van de wetgeving aan.

Ik laat in ieder geval mijn boiler dat lekker zelf uitzoeken.

Ow en spoelen is leuk, maar legionella zit grotendeels in de biofilm in de leidingen en niet los in het water. Dus dat heeft beperkt nut.

[ Voor 19% gewijzigd door simnet op 04-10-2026 00:33 ]

[Torch1969]

hemertje schreef op zaterdag 3 oktober 2026 @ 20:37:
[...]


Hoi SImnet,

los van het feit dat ik ook twijfel aan een legionelle besmetting thuis, kan je wanneer je deze toch wekelijks draait deze het beste optimaal plannen ipv ongecontroleerd draaien tijdens de dure uren?

Die optimale planning, zonder omkijken en fancy aansturingen, is er. Elke zondagmiddag om 13u.

[buiter]

KC27 schreef op zaterdag 3 oktober 2026 @ 13:51:
Wellicht ten overvloede voor gebruikers die mooie plaatjes willen in HA:
Met Power Flow Card Plus krijg je inzicht in de actuele vermogens van je woning:
[Afbeelding]

Die hebben we al ;-) Maar dat is over het actueel verbruik.

Over de keuze bij DAO ben ik het eens met het principe eens "functie boven vorm". En misschien heb ik de indruk gewekt dat het mij om de grafieken gaat. Maar dat klopt niet.

Mijn belangrijkste punt is dat de configuratie van DAO met een JSON file een zeer hoge drempel opwerpt. Als de JSON vervangen zou worden door een normaal configuratiepagina met alle onderdelen dan is de plugin al een stuk toegankelijker.

En naar mijn idee werkt de plugin heel goed dus leek het me tijd om de visuals een keer bespreekbaar te maken.

[DaBit]

simnet schreef op zondag 4 oktober 2026 @ 00:26:
ISSO 55.1 is een leuke om te lezen. Gaat over gehele installaties en niet in een particuliere opzet, maar het geeft wel de diepte van de wetgeving aan.

Die zit uiteraard weer achter een paywall, grmbl. 109 euro.

Aangezien jij verstand van zaken lijkt te hebben: ik heb een COP=1 electrische boiler voor de gasketel staan die ik inschakel als het uitkan (electriciteit goedkoper dan gas; staat in DAO als 'electrische auto'). De gasketel verwarmt na tot 58C indien nodig.

Bovenop de prijsberekenening zit logica die zegt 'als het een week of meer geleden is dat de boiler de 65C aangetikt heeft en het is zondag dan is het setpoint minimaal 60C'. Dan staat die boiler dus de hele zondag op hoge temperatuur en ben ik er zeker van dat alles goed doorverwarmd is.
In de winter doet die boiler niet veel en dan heb ik zo wekelijks op zondag toch de beestjeskoken-run. Waait het nou op maandag heel hard dan kan het met deze simpele logica zijn dat de volgende legionellarun 2 weken min een dag op zich laat wachten. Daar staat dan weer tegenover dat het water in de boiler dan ook maar 10-15 graden is.

Ik ga je niet vragen om te zeggen of het zo goed is, maar ik kan wel vragen of je problemen ziet, toch?

[hemertje]

Wilin schreef op zaterdag 3 oktober 2026 @ 23:48:
[...]

Ik heb mijn legionella run op de volgende manier ingepland:

• het is een machine in DAO
• op zaterdag om 17 loopt er een automatisatie die de window correct inplant op zondag en het programma aanzet.
• wanneer DAO aangeeft dat de run best begint, zet een automatisatie de boiler aan op 60C
• wanneer het verbruik terugvalt wordt het programma terug uit gezet.

goedeorgen @Wilin

wil jeje code hier ter inspiratie eens delen?

[hemertje]

Torch1969 schreef op zondag 4 oktober 2026 @ 08:59:
[...]

Die optimale planning, zonder omkijken en fancy aansturingen, is er. Elke zondagmiddag om 13u.

dan laadt de EV hier ook al op

[simnet]

DaBit schreef op zondag 4 oktober 2026 @ 09:21:
[...]
Ik ga je niet vragen om te zeggen of het zo goed is, maar ik kan wel vragen of je problemen ziet, toch?

Haha, vragen kan altijd
En ik wil zeker niet zeggen dat ik er verstand van heb. Ik ben geen bioloog of waterbeheer deskundige. Ik weet dit toevallig doordat een van mijn klanten waterbeheer doet.

Het enige waar ik je op kan wijzen is te zorgen dat je (hele) vat lang genoeg op temperatuur blijft. Mijn boiler meet en regelt dat zelf, conform wetgeving en veiligheidsnormen. Ik ga als leek mijn boiler niet overrulen en denken dat ik het beter weet.
Ik stuur ook puur de compressor en electrisch element aan, maar alleen als energy buffer. Ik zet het smartgrid contact aan als het voordelig is of als ik over heb. De rest laat ik het regelsysteem van de boiler oplossen.
Beetje vergelijkbaar met dat ik mijn battery de NoM laat regelen als dat nodig is, in plaats van zelf een PID controller gebruiken.

[Isdatzo]

Enigszins offtopic maar m.i. is er bij normaal gebruik voldoende doorspoeling van het boilervat en is daarmee het risico op een besmetting minimaal. Daarnaast zijn de personen die onder mijn douche staan gezond en behoren niet tot een risicogroep.

Derhalve doe ik dus niet actief aan legionellapreventie, tenzij er gedurende een langere periode geen of weinig gebruik is gemaakt van warm water (denk aan vakantieperioden). Verder moet iedereen natuurlijk doen waar ze zich prettig bij voelen, maar persoonlijk zie ik geen noodzaak om de boel wekelijks tot 60 graden op te stoken.

[Wilin]

hemertje schreef op zondag 4 oktober 2026 @ 09:34:
[...]


goedeorgen @Wilin

wil jeje code hier ter inspiratie eens delen?

YAML: options.json

  "machines": [
    {
    "name" : "Boiler legionella",
    "programs" : [
      {
        "name": "Uit",
        "power": []
      },
      {
        "name": "Aan",
        "power": [1050, 1050, 1050, 1050, 1050, 1050, 1050]
      }
    ],
    "entity start window" : "input_datetime.dao_legionella_start_slot_vraag",
    "entity end window" : "input_datetime.dao_legionella_eind_slot_vraag",
    "entity selected program" : "input_select.dao_legionella_modus_vraag",
    "entity calculated start" : "input_datetime.dao_legionella_start_berekend",
    "entity calculated end" : "input_datetime.dao_legionella_eind_berekend"
    }
  ]

[oscaarbasgitaar]

Het klopt dat legionella een aandachtspunt is, maar het is ook waar dat er weinig tot geen gevallen van besmetting zijn in woningen waar doorgaande wekelijks voldoende gebruik is en er dus geen lang stilstaand water tussen 25 en 45° is.

Wat een volledige sterilisatie-run zou moeten zijn: boilervat lang boven 65° én álle warm water leidingen 3 minuten spoelen met heet water.

Dat eerste kan je nog wel inplannen. Dat tweede doet werkelijk niemand.

De dag dat iemand in het huis woont die respiratoir gevoelig is (de bacteriën verspreiden zich via verneveling, besmet water drinken kan theoretisch geen kwaad) of een verzwakte gezondheid heeft zou ik er zelf ook aandacht zal schenken. Maar vooralsnog staat ons boilervat op 56° ingesteld.

[mgroen81]

workzone schreef op zondag 4 oktober 2026 @ 00:25:
[...]

De meeste accu cellen blijven alleen al steken bij een efficiency van max 97%, dus een RTE van 98% lijkt me niet haalbaar. Als je systeem heel erg efficient is zit je misschien rond de 90 tot 92%.

Dat zei ik niet. Ik had het over 98% efficiëntie. Dus ongeveer 95%RTE. Ook na gemeten natuurlijk.

[Doopy-X-]

konehead schreef op vrijdag 2 oktober 2026 @ 20:08:
[...]

[Afbeelding][Afbeelding] Vanmiddag een update gemaakt: Actual vs FC en Vandaag en Morgen. Goed idee qua github, laat maar weten of dit voorbeeld waardig is :)

Veel dank voor het delen via de mail, hopelijk snel ook voor anderen te gebruiken via de wiki.
Ik miste de verschillende entiteiten nog die nodig waren voor een goede planning dus ik ben best een tijdje met AI bezig geweest deze op te zetten en ik heb hier en daar nog wat aan je voorbeeld getweaked maar het is gelukt

Ik heb het nu als dashboard opgenomen in Home Assistant:

[konehead]

Doopy-X- schreef op zondag 4 oktober 2026 @ 19:33:
[...]


Veel dank voor het delen via de mail, hopelijk snel ook voor anderen te gebruiken via de wiki.
Ik miste de verschillende entiteiten nog die nodig waren voor een goede planning dus ik ben best een tijdje met AI bezig geweest deze op te zetten en ik heb hier en daar nog wat aan je voorbeeld getweaked maar het is gelukt

Ik heb het nu als dashboard opgenomen in Home Assistant:
[Afbeelding]

Kijk hem gaan!!! hahaha, die SOC lijn is ook vet! Samen maken we het beter. Ik ben wel bang dat ik de verkeerde versie heb gestuurd. Ik heb ook een knopje vandaag en morgen en Werkelijk / Plan. Heb zelf 24uur gedaan, past precies als pop-up op mijn tablet in de woonkamer.

[ Voor 12% gewijzigd door konehead op 04-10-2026 21:05 ]

[Frankvbr]

Wilin schreef op zaterdag 3 oktober 2026 @ 23:48:
[...]

Ik heb mijn legionella run op de volgende manier ingepland:

• het is een machine in DAO
• op zaterdag om 17 loopt er een automatisatie die de window correct inplant op zondag en het programma aanzet.
• wanneer DAO aangeeft dat de run best begint, zet een automatisatie de boiler aan op 60C
• wanneer het verbruik terugvalt wordt het programma terug uit gezet.

Ik heb een andere warmtepomp maar zelfde probleem met verwarmingsrun op elektrisch element.
Ik heb het nu anders opgelost:
- Automation die 1x per week (zaterdagavond 20.00) de doeltemperatuur omhoog zet naar 70 graden (vanwege gelaagdheid vat better safe then sorry).
- DAO houdt dan rekening met de huidige temperatuur van het vat (wat normaliter schommelt tussen de 42 en 50 graden) en plant hem ergens tussen zaterdag 20.00 uur en zonder 20.00 uur in.
(Zondag leek mij gunstigste als combinatie van kinderen die uitgebreid in bad gaan i.c.m. dat tarieven op zondag altijd goedkoper zijn. Als DAO week vooruit kan plannen wordt het wellicht anders).
DAO pakt dan het juiste tijdstip, maar het verbruik zal in praktijk alleen iets hoger liggen.
- Een losse automation die een alert stuurt als het tapwater niet boven 67 graden is geweest in de afgelopen 7 dagen.


Voor het vat regulier verwarmen alsvolgt gedaan:
- Vat zelf ingesteld op 44 graden oid met hysterese van 3 graden.
- DAO werkt met doeltemperatuur van 50 graden met hysterese van 3 graden oid.
- In praktijk zorgt DAO dat vat elke dag op gunstig tijdstip naar 50 graden gaat. Mocht temperatuur teveel dalen, verwarmt warmtepomp alsnog op ongunstigere tijd (geen warmwatertekort). Mocht dat te vaak gebeuren dan wordt doeltemperatuur hoger.

DAO kent natuurlijk hier en daar wat beperkingen, maar daar is omheen te werken, verder is het fantastisch dat mensen hier tijd in steken.
Verder gewoon fijn om met elkaar ervaringen te delen hoe mensen dit aanpakken (misschien kunnen we daar in helpen door verschillende situatie's + aanpak in de wiki te zetten).

Ben wel eens dat de config file soms complex is (alsin een foutje is snel gemaakt), maar het zijn hier tweakers. Zelf een beetje tijd in steken mag ook wel.

[ Voor 3% gewijzigd door Frankvbr op 05-10-2026 12:50 ]

[DaBit]

simnet schreef op zondag 4 oktober 2026 @ 12:30:
Het enige waar ik je op kan wijzen is te zorgen dat je (hele) vat lang genoeg op temperatuur blijft. Mijn boiler meet en regelt dat zelf, conform wetgeving en veiligheidsnormen. Ik ga als leek mijn boiler niet overrulen en denken dat ik het beter weet.

Ik laat mijn subsystemen ook zoveel mogelijk autonoom hun werk doen, maar dat was met de boiler expliciet niet de bedoeling. Die was en is goedkope overtollige-energie opslag (250 euro voor 6kWh). Maar 'lang genoeg op temperatuur' word gegarandeerd door 'de hele zondag op minstens 60C setpoint'
(in theorie kan iemand nog telkens wat water tappen en zo voorkomen dat het boilervat de temperatuur haalt, maar het is niet realistisch dat dat een heel etmaal lang gebeurt)

Isdatzo schreef op zondag 4 oktober 2026 @ 12:36:
maar persoonlijk zie ik geen noodzaak om de boel wekelijks tot 60 graden op te stoken.

Het is net zoiets als een kunstmestfabriek als buurman. Het risico dat het misgaat is klein, maar de gevolgen zijn groot mocht het een keer gebeuren.

Wat er aan extra energie voor die anti-legionella-en-andere-beestjes-run nodig is valt reuze mee en werk heb je er ook niet aan, dus waarom zou je het risico lopen....

Dat concept 'hou apparaat nog een tijd X op setpoint geactiveerd' wat je voor dingen als boilers, EV's, en thuisbatterijen enzo wel wil (batterijen moeten cellen balanceren, boilers moeten doorwarmen) doe ik nu vanuit logica buiten DAO. Zou geen kwaad kunnen als DAO de operating_mode/charge_switch zelf langer actief zou kunnen houden. Maar volgens mij is dat nog best harig om te maken.

[Beekforel]

@DaBit dat kun je toch prima oplossen met een extra "program" voor de "machine"?

[hemertje]

hemertje schreef op zaterdag 3 oktober 2026 @ 21:38:
Hoi Corné, @KC27 e.a.

nu de winter eraan komt, een vraag van mij over verwarmen met de warmtepomp.

Ik heb een Panasonic 7kW lucht/water warmtepomp die ik nu aanstuur met Ed's Node Red.
Tot nu toe gebruik ik DAO voor het laden en ontladen van de Zendure accu's en sinds kort ook voor de boiler (warm water, via Ed's Node Red).

Ik wil graag in de winterperiode de lage dynamische stroomprijzen (overdag en 's nachts) gebruiken om het huis een beetje extra op te warmen, zodat de warmtepomp tijdens de dure uren uit kan.
Het huis werkt dan als een soort warmteaccu.
Voordat ik iets instel wil ik graag zeker weten dat ik begrijp wat DAO nu al doet.

Hieronder een opsomming zoals ik nu snap hoe DAO werkt (zeg het aub als ik het fout heb):

• DAO rekent per dag uit hoeveel warmte het huis nodig heeft (op basis van de graaddagen) en zet de warmtepomp vooral in de goedkoopste uren aan?
• De stooklijn kan met de prijs meeschuiven: bij een dure prijs iets lager, bij een lage prijs iets hoger?
• DAO weet niet wat de temperatuur in huis is. Het weet dus ook niet hoe lang de pomp uit kan voordat het te koud wordt?

Nu mijn vragen:

1. Klopt dit, of is er al een manier om het huis als warmtebuffer te gebruiken die ik gemist heb?

2. Staat het op de planning dat DAO rekening houdt met de binnentemperatuur, met een grens naar boven en naar beneden?
Dan kan DAO op lage prijzen extra verwarmen en de pomp in de dure uren uit laten, zonder dat het te koud wordt. Past dat misschien bij de langere planning waar je aan werkt?

3. Zo niet: is een simpele tussenstap mogelijk?
Bijvoorbeeld: boven een bepaalde prijs, of in vaste uren in de avondpiek, mag de pomp niet verwarmen (warm water blijft gewoon mogelijk), met een veiligheidsgrens op de binnentemperatuur.

4. Een vraag over het verbruik van de warmtepomp. Ik heb de vermogenssensor van de pomp in de DAO-instellingen staan, maar de pompsturing van DAO staat uit. Klopt het dat het pompverbruik dan van de netafname wordt afgetrokken en dus niet in de basislast terechtkomt? Of komt het er juist wel in?

5. Een vraag over de instelling adjustment factor (de stooklijn die met de prijs meeschuift). In de documentatie staat "K/10%": zoveel graden verschuiving als de prijs 10% van het daggemiddelde afwijkt. In de code (utils.py, calc_adjustment_heatcurve) staat:

code:

adjustment = round(-adjustment_factor * (price_act - price_avg) * 100 / price_avg, 1)

en in het commentaar "0,4 K per 10% = 0.04 K/%".

Dat is graden per procent, dus 10 keer zoveel als de documentatie zegt.
Voorbeeld: met adjustment_factor: 2.0 (gelezen als 2 graden per 10%) geeft de code -20 graden als de prijs 10% boven het gemiddelde zit.

Mijn schuifregelaar in Home Assistant gaat maar van -3 tot +3. Welke van de twee is de bedoeling, de documentatie of de code?
En zou een melding in de log kunnen komen als de berekende waarde buiten die schuifregelaar valt?

Bij mij staat de warmtepompsturing van DAO nog uit, dus er is nog niets mis gegaan.

Wat achtergrondinformatie die ik gevonden heb:
Onderzoek met echte woningen laat zien dat slim sturen van een warmtepomp op stroomprijs (in de literatuur "MPC" genoemd: een regeling die met een rekenmodel van het huis en voorspellingen vooruit plant) ongeveer 2 tot 6% kan besparen, en dat het grootste deel daarvan al komt van het uitzetten van de pomp in de avondpiek.
Een proef van 125 dagen gaf 9%, terwijl een korte proef van een paar dagen 34% liet zien.
Ik verwacht dus geen wonderen, maar de avondpiek-stap lijkt me een mooie eerste stap. Ik denk graag mee en test mee, en meet dan met vergelijkbare dagen, wanneer er eventueel een testversie komt.

Een vergelijkbaar project dat het huis zelf leert kennen uit meetdata (warmteverlies, thermische massa, zon), is NeedForHeat van Windesheim (CC BY 4.0):
https://github.com/energi...orheat-diagnosis-software

Alvast hartelijk dank voor jullie reacties...

wil iemand mij verder op weg helpen?

[hemertje]

Beste allemaal,

nog een aantal vragen voor de overgang na 1 januari (wanneer het salderen stopt):

1. Tax refund
In mijn instellingen staat "tax refund": true. Per 1 januari moet dat false. Komt er een datumtabel (zoals bij de tarieven), of moet ik hem op 1 januari met de hand omzetten?

2. Strategie
In de code zie ik dat "minimize consumption" eerst de levering aan het net minimaliseert en daarbinnen de kosten.
Klopt dat?
Is "minimize cost" met de tarieven voor 2027 (teruglevering zonder belasting) in de praktijk bijna hetzelfde?
Mijn prioriteit is zelfconsumptie en CO2, minder het handelen.

3. Balance switch
Ik gebruik "entity balance switch" voor kwartieren waarin DAO nul op de meter wil.
Kan DAO die kwartieren aan elkaar laten vastzitten (minimaal bijvoorbeeld 30 minuten), zodat mijn regelaar niet elk kwartier opnieuw begint?

4. Nachtlast
Mijn plan houdt de accu 's nachts op 71% terwijl het huis circa 0,5 kW afneemt.
De laagste trap in mijn stages is 500 W met rendement 0,88.
Kan het zijn dat DAO daarom de nachtlast niet uit de accu dekt, en kan ik dat beïnvloeden met de stages?

5. Proefrun
Is er een manier om DAO een plan te laten berekenen met andere opties zonder dat het naar HA schrijft?
Ik wil graag zien wat het plan zonder saldering doet, voordat het zover is.

Wederom bedankt en gegroet,

Hemertje

[KC27]

hemertje schreef op zaterdag 3 oktober 2026 @ 21:38:
Hoi Corné, @KC27 e.a.

nu de winter eraan komt, een vraag van mij over verwarmen met de warmtepomp.

Ik heb een Panasonic 7kW lucht/water warmtepomp die ik nu aanstuur met Ed's Node Red.
Tot nu toe gebruik ik DAO voor het laden en ontladen van de Zendure accu's en sinds kort ook voor de boiler (warm water, via Ed's Node Red).

Ik wil graag in de winterperiode de lage dynamische stroomprijzen (overdag en 's nachts) gebruiken om het huis een beetje extra op te warmen, zodat de warmtepomp tijdens de dure uren uit kan.
Het huis werkt dan als een soort warmteaccu.
Voordat ik iets instel wil ik graag zeker weten dat ik begrijp wat DAO nu al doet.

Hieronder een opsomming zoals ik nu snap hoe DAO werkt (zeg het aub als ik het fout heb):

• DAO rekent per dag uit hoeveel warmte het huis nodig heeft (op basis van de graaddagen) en zet de warmtepomp vooral in de goedkoopste uren aan?
• De stooklijn kan met de prijs meeschuiven: bij een dure prijs iets lager, bij een lage prijs iets hoger?
• DAO weet niet wat de temperatuur in huis is. Het weet dus ook niet hoe lang de pomp uit kan voordat het te koud wordt?

Nu mijn vragen:

1. Klopt dit, of is er al een manier om het huis als warmtebuffer te gebruiken die ik gemist heb?

Nee nog niet echt, staat wel op mijn todo-lijst

2. Staat het op de planning dat DAO rekening houdt met de binnentemperatuur, met een grens naar boven en naar beneden?
Dan kan DAO op lage prijzen extra verwarmen en de pomp in de dure uren uit laten, zonder dat het te koud wordt. Past dat misschien bij de langere planning waar je aan werkt?

Ja maar waarschijnlijk niet zo gedetailleerd met een warmteverliesberekening.

3. Zo niet: is een simpele tussenstap mogelijk?
Bijvoorbeeld: boven een bepaalde prijs, of in vaste uren in de avondpiek, mag de pomp niet verwarmen (warm water blijft gewoon mogelijk), met een veiligheidsgrens op de binnentemperatuur.

Lijkt mij meer iets voor een automation in HA

4. Een vraag over het verbruik van de warmtepomp. Ik heb de vermogenssensor van de pomp in de DAO-instellingen staan, maar de pompsturing van DAO staat uit. Klopt het dat het pompverbruik dan van de netafname wordt afgetrokken en dus niet in de basislast terechtkomt? Of komt het er juist wel in?

Als het verbruik (niet het vermogen) bij de wp-sensoren hebt staan (onder kopje "reports") dan wordt het wp-verbruik van de basislast afgetrokken.

5. Een vraag over de instelling adjustment factor (de stooklijn die met de prijs meeschuift). In de documentatie staat "K/10%": zoveel graden verschuiving als de prijs 10% van het daggemiddelde afwijkt. In de code (utils.py, calc_adjustment_heatcurve) staat:

code:

adjustment = round(-adjustment_factor * (price_act - price_avg) * 100 / price_avg, 1)

en in het commentaar "0,4 K per 10% = 0.04 K/%".

Dat is graden per procent, dus 10 keer zoveel als de documentatie zegt.
Voorbeeld: met adjustment_factor: 2.0 (gelezen als 2 graden per 10%) geeft de code -20 graden als de prijs 10% boven het gemiddelde zit.

Je stelt in K/%
Dus als je 2 ingeeft dan betekent dat 2 K/% dus 20 K bij 10% afwijking.

Mijn schuifregelaar in Home Assistant gaat maar van -3 tot +3. Welke van de twee is de bedoeling, de documentatie of de code?
En zou een melding in de log kunnen komen als de berekende waarde buiten die schuifregelaar valt?

DAO kan de grenzen van de schuifregelaar (nog) niet uitlezen.
Je kunt deze beter zelf ruim instellen en met een automation in HA deze begrenzen voordat je hem doorzet naar de wp.

Bij mij staat de warmtepompsturing van DAO nog uit, dus er is nog niets mis gegaan.

Wat achtergrondinformatie die ik gevonden heb:
Onderzoek met echte woningen laat zien dat slim sturen van een warmtepomp op stroomprijs (in de literatuur "MPC" genoemd: een regeling die met een rekenmodel van het huis en voorspellingen vooruit plant) ongeveer 2 tot 6% kan besparen, en dat het grootste deel daarvan al komt van het uitzetten van de pomp in de avondpiek.
Een proef van 125 dagen gaf 9%, terwijl een korte proef van een paar dagen 34% liet zien.
Ik verwacht dus geen wonderen, maar de avondpiek-stap lijkt me een mooie eerste stap. Ik denk graag mee en test mee, en meet dan met vergelijkbare dagen, wanneer er eventueel een testversie komt.

Een vergelijkbaar project dat het huis zelf leert kennen uit meetdata (warmteverlies, thermische massa, zon), is NeedForHeat van Windesheim (CC BY 4.0):
https://github.com/energi...orheat-diagnosis-software

Alvast hartelijk dank voor jullie reacties...

[KC27]

hemertje schreef op maandag 5 oktober 2026 @ 22:18:
Beste allemaal,

nog een aantal vragen voor de overgang na 1 januari (wanneer het salderen stopt):

1. Tax refund
In mijn instellingen staat "tax refund": true. Per 1 januari moet dat false. Komt er een datumtabel (zoals bij de tarieven), of moet ik hem op 1 januari met de hand omzetten?

Er komt geen datum/tijd bij "tax refund".
Deze instelling gaat met de eerstvolgende versie na 1-1-2027 vervallen.
Je kunt wel alvast "energy_taxes_production" op 1-1-2027 op "0.00" zetten

2. Strategie
In de code zie ik dat "minimize consumption" eerst de levering aan het net minimaliseert en daarbinnen de kosten.
Klopt dat?
Is "minimize cost" met de tarieven voor 2027 (teruglevering zonder belasting) in de praktijk bijna hetzelfde?
Mijn prioriteit is zelfconsumptie en CO2, minder het handelen.

Ik denk dat in de praktijk die twee elkaar na 1-1-2027 niet veel zullen ontlopen.

3. Balance switch
Ik gebruik "entity balance switch" voor kwartieren waarin DAO nul op de meter wil.
Kan DAO die kwartieren aan elkaar laten vastzitten (minimaal bijvoorbeeld 30 minuten), zodat mijn regelaar niet elk kwartier opnieuw begint?

Dat zou dan een instelling moeten worden.
Staat voorlopig niet op de planning.
De verwachting is dat de meeste perioden van NOM een langere aaneengesloten periode zullen zijn.

4. Nachtlast
Mijn plan houdt de accu 's nachts op 71% terwijl het huis circa 0,5 kW afneemt.
De laagste trap in mijn stages is 500 W met rendement 0,88.
Kan het zijn dat DAO daarom de nachtlast niet uit de accu dekt, en kan ik dat beïnvloeden met de stages?

Ik denk dat het nu nog niet loont om de nachtlast uit de accu te halen.

5. Proefrun
Is er een manier om DAO een plan te laten berekenen met andere opties zonder dat het naar HA schrijft?
Ik wil graag zien wat het plan zonder saldering doet, voordat het zover is.

Je kunt heel eenvoudig tussen de reguliere berekeningen door je instellingen aanpassen en een "Optimaliseringsberekening met debug" doen. Niet vergeten om alles weer goed terug te zetten voor de volgende reguliere berekening.

Wederom bedankt en gegroet,

Hemertje

[Doopy-X-]

Ik wil even van de gelegenheid gebruik maken om de ontwikkelaars van deze geweldige tool wat veren in de achterste te stoppen.

Ik heb vorige week mijn AlphaESS SMILE G3-T10, 18,6 kWh geïnstalleerd gekregen en ik ben de hele week al een beetje aan het spelen met verschillende opties van AlphaESS zelf zoals de pas toegevoegde AI mode en de Price-Based Control mode. Deze laatste werkt aardig maar hiervoor moet je vooraf parameters instellen (hoogte & laagste 10% bijvoorbeeld) wanneer hij mag gaan laden en ontladen. Dit kan per dag heel verschillende uitwerking hebben.

DAO werkt een stuk beter. Ik ben gisteren op kwartierprijzen overgeschakeld en het resultaat van vandaag is verbluffend:


De laadacties per kwartier komen heel mooi uit in deze grafiek en DOA zorgt ervoor dat exact op de goede momenten wordt geladen en ontladen.

voor jullie geweldige model en tool.

Keep up the good work!

P.S. Ik ben nog wel aan het nadenken of ik de limits bijvoorbeeld naar 15/10 wil zetten ipv de 20/15 nu. Dit geeft natuurlijk iets betere opbrengsten maar zorgt er wel voor dat er iets minder speelruimte is qua moment van bijladen?

[ Voor 9% gewijzigd door Doopy-X- op 06-10-2026 00:12 ]

[thomvh]

Sinds dat wij over gaan van Tibber naar Zonneplan loop ik wat te stoeien met de EV's in DAO. De rekentijd wordt namelijk zo lang dat hij of niet tot een oplossing komt of het gewoon echt minuten duurt.

Hierbij heb ik de volgende dingen al gedaan:
- Charge stages verminderd naar 6 / 10 / 16.
- Max gap proberen te verhogen naar 0.05 maar dan krijg ik raar gedrag, waarbij hij besluit uit de accu te gaan laden bijvoorbeeld.

Zolang 1 auto actief staat is er niks aan de hand. Maar ik wilde eigenlijk 3 autos actief in de planning hebben, waarbij de auto's die geen doel hebben constant aan het einde van de horizon geplaatst worden zodat ze wel zo goedkoop mogelijk laden. Eventueel met zonnestroom.

[DikDikkie]

Doopy-X- schreef op dinsdag 6 oktober 2026 @ 00:10:
Ik wil even van de gelegenheid gebruik maken om de ontwikkelaars van deze geweldige tool wat veren in de achterste te stoppen.

Ik heb vorige week mijn AlphaESS SMILE G3-T10, 18,6 kWh geïnstalleerd gekregen en ik ben de hele week al een beetje aan het spelen met verschillende opties van AlphaESS zelf zoals de pas toegevoegde AI mode en de Price-Based Control mode. Deze laatste werkt aardig maar hiervoor moet je vooraf parameters instellen (hoogte & laagste 10% bijvoorbeeld) wanneer hij mag gaan laden en ontladen. Dit kan per dag heel verschillende uitwerking hebben.

DAO werkt een stuk beter. Ik ben gisteren op kwartierprijzen overgeschakeld en het resultaat van vandaag is verbluffend:
[Afbeelding]

De laadacties per kwartier komen heel mooi uit in deze grafiek en DOA zorgt ervoor dat exact op de goede momenten wordt geladen en ontladen.

voor jullie geweldige model en tool.

Keep up the good work!

P.S. Ik ben nog wel aan het nadenken of ik de limits bijvoorbeeld naar 15/10 wil zetten ipv de 20/15 nu. Dit geeft natuurlijk iets betere opbrengsten maar zorgt er wel voor dat er iets minder speelruimte is qua moment van bijladen?

Ziet er goed uit. Ik kom er maar niet aan toe om DAO goed te configureren voor mijn Alpha ESS. Zou je jouw configuratie willen delen? En waar heb je jouw visualisatie in gemaakt? Grafana?

[Dogooder]

thomvh schreef op dinsdag 6 oktober 2026 @ 08:50:
Sinds dat wij over gaan van Tibber naar Zonneplan loop ik wat te stoeien met de EV's in DAO. De rekentijd wordt namelijk zo lang dat hij of niet tot een oplossing komt of het gewoon echt minuten duurt.

Hierbij heb ik de volgende dingen al gedaan:
- Charge stages verminderd naar 6 / 10 / 16.
- Max gap proberen te verhogen naar 0.05 maar dan krijg ik raar gedrag, waarbij hij besluit uit de accu te gaan laden bijvoorbeeld.

Zolang 1 auto actief staat is er niks aan de hand. Maar ik wilde eigenlijk 3 autos actief in de planning hebben, waarbij de auto's die geen doel hebben constant aan het einde van de horizon geplaatst worden zodat ze wel zo goedkoop mogelijk laden. Eventueel met zonnestroom.

Ik vind dit wel een interessante usecase en zou graag onderzoeken waarom de solver hier de weg kwijt raakt. De huidige test suite heeft 24 EV scenario's, maar met 2 EV's max. Maar die scenario's leiden niet tot bovengenoemd gedrag.
Kan jij mij, al dan niet via DM, wat meer uitleg geven over dit specifieke scenario. En hoe goed ben jij met "docker exec -it dao /bin/bash"?

[Wilin]

Hoe moet ik "minimum power" bij de batterijen interpreteren? Ik heb dit voor beide batterijen die ik heb geconfigureerd op 100 staan, maar DAO vraagt nog regelmatig om te ontladen met 35W etc. Ik zou dit willen kunnen uitzetten. mijn batterij kan hier niet echt mee overweg met zulke lage vraag. De batterij blijft in dat geval meestal uit.

[simnet]

DaBit schreef op maandag 5 oktober 2026 @ 14:26:
Ik laat mijn subsystemen ook zoveel mogelijk autonoom hun werk doen, maar dat was met de boiler expliciet niet de bedoeling. Die was en is goedkope overtollige-energie opslag (250 euro voor 6kWh). Maar 'lang genoeg op temperatuur' word gegarandeerd door 'de hele zondag op minstens 60C setpoint'
(in theorie kan iemand nog telkens wat water tappen en zo voorkomen dat het boilervat de temperatuur haalt, maar het is niet realistisch dat dat een heel etmaal lang gebeurt)

Dit is ook precies wat ik bedoel. Er is niets op tegen om je boiler te gebruiken als energieopslag. Dat is ook exact zoals ik het doe. Maar dat is alleen EXTRA energie toevoegen. Ik ga het reguliere legionella programma (wat de boiler zelf bijhoudt en inpland) niet uitzetten of uitstellen alleen maar om een paar centen te besparen.

Ik weet ook eerlijk niet of het regelmatige gebruik van het electrisch element om stroom overschot te dumpen in de boiler invloed heeft op dat legionella programma. Als hij er rekening mee houd; mooi. Zo niet; ach, zoals ik zei, centenwerk. Daar maak ik me niet druk om.

[thomvh]

Dogooder schreef op dinsdag 6 oktober 2026 @ 12:04:
[...]

Ik vind dit wel een interessante usecase en zou graag onderzoeken waarom de solver hier de weg kwijt raakt. De huidige test suite heeft 24 EV scenario's, maar met 2 EV's max. Maar die scenario's leiden niet tot bovengenoemd gedrag.
Kan jij mij, al dan niet via DM, wat meer uitleg geven over dit specifieke scenario. En hoe goed ben jij met "docker exec -it dao /bin/bash"?

Ik denk dat in DM even wat makkelijker is. Ik red me prima met docker. Ik zal je er een sturen!

[The Source]

Ik zag andere ook hierover posten.

Ik gebruik deye_total_production in entities_solar_production_dc. Echter wordt DC niet meegenomen in de baseload calculatie waardoor ik negatieve waardes krijg in de baseload.

Claude stelde voor om deze van DC naar AC te verhuizen en per aparte string op te nemen (sensor.deye_pvx_power_kwh) omdat die ook een hogere resolutie hebben. Nadeel is dat het converter loss (~5% of 1kWh/dag) ook in de baseload komt.

"entities_solar_production_ac": [
"sensor.solaredge_i1_ac_energy",
"sensor.deye_pv1_power_kwh",
"sensor.deye_pv2_power_kwh"
],
"entities_solar_production_dc": [],

Is dit aan te raden of zie ik iets over het hoofd?

[ Voor 9% gewijzigd door The Source op 06-10-2026 16:48 ]

[Doopy-X-]

DikDikkie schreef op dinsdag 6 oktober 2026 @ 11:05:
[...]

Ziet er goed uit. Ik kom er maar niet aan toe om DAO goed te configureren voor mijn Alpha ESS. Zou je jouw configuratie willen delen? En waar heb je jouw visualisatie in gemaakt? Grafana?

Ik heb mbt tot DAO 2 grafieken gemaakt:

code:

type: custom:apexcharts-card
header:
  show: true
  title: Frank prijs + DAO batterij SoC + PV forecast
  show_states: false
graph_span: 24h
span:
  start: day
now:
  show: true
  label: Nu
yaxis:
  - id: price
    min: '|-1|'
    max: '|+1|'
    decimals: 0
    opposite: false
    apex_config:
      offsetX: -45
      tickAmount: 10
      title:
        text: PRIJS
      labels:
        formatter: |
          EVAL:function(value) {
            return value.toFixed(0) + " ct";
          }
  - id: soc
    min: 0
    max: 100
    decimals: 0
    opposite: true
    apex_config:
      title:
        text: SOC
      labels:
        formatter: |
          EVAL:function(value) {
            return value.toFixed(0) + "%";
          }
  - id: zon
    min: 0
    decimals: 1
    opposite: true
    apex_config:
      offsetX: 35
      title:
        text: ZON
      labels:
        formatter: |
          EVAL:function(value) {
            return value.toFixed(1) + " kW";
          }
series:
  - entity: sensor.frank_prices_today
    name: Frank prijs
    yaxis_id: price
    type: line
    curve: stepline
    color: '#00B7FF'
    stroke_width: 2
    opacity: 1
    unit: ct/kWh
    float_precision: 2
    data_generator: |
      return entity.attributes.prices.map(p => [
        new Date(p.from).getTime(),
        p.total_price_eur_kwh * 100
      ]);
    show:
      legend_value: false
  - entity: sensor.dao_battery_soc
    name: DAO SoC
    yaxis_id: soc
    type: line
    curve: stepline
    color: '#A0C770'
    stroke_width: 2
    opacity: 1
    unit: '%'
    float_precision: 0
    data_generator: |
      return entity.attributes.data.map(p => [
        new Date(p.time).getTime(),
        parseFloat(p.value)
      ]);
    show:
      legend_value: false
  - entity: sensor.solcast_pv_forecast_voorspelling_vandaag
    name: Zon voorspelling
    type: line
    yaxis_id: zon
    color: '#FABF00'
    opacity: 0.7
    stroke_width: 2
    curve: stepline
    data_generator: |
      const data = entity.attributes.detailedForecast;
      const result = [];

      data.forEach(p => {
        const t = new Date(p.period_start).getTime();
        const value = Number(p.pv_estimate);

        result.push([t, value]);
        result.push([t + 15 * 60 * 1000, value]);
      });

      return result;
    show:
      legend_value: false
apex_config:
  chart:
    height: 400px
  tooltip:
    shared: true
    intersect: false
grid_options:
  columns: full

code:

type: custom:apexcharts-card
update_interval: 30sec
graph_span: 24h
span:
  start: day
now:
  show: true
  color: red
header:
  show: true
  title: Energie vandaag
  show_states: false
  colorize_states: true
apex_config:
  chart:
    height: 600px
  tooltip:
    intersect: false
    custom: |
      EVAL:function({series, seriesIndex, dataPointIndex, w}) {

        const hoverX = w.globals.seriesX[seriesIndex][dataPointIndex];

        function nearestIndex(xValues, target) {
          if (!xValues || xValues.length === 0) {
            return -1;
          }

          let bestIndex = 0;
          let bestDiff = Math.abs(xValues[0] - target);

          for (let i = 1; i < xValues.length; i++) {
            const diff = Math.abs(xValues[i] - target);

            if (diff < bestDiff) {
              bestDiff = diff;
              bestIndex = i;
            }
          }

          return bestIndex;
        }

        function previousIndex(xValues, target) {
          if (!xValues || xValues.length === 0) {
            return -1;
          }

          let index = 0;

          for (let i = 0; i < xValues.length; i++) {
            if (xValues[i] <= target) {
              index = i;
            } else {
              break;
            }
          }

          return index;
        }

        function formatValue(name, value) {
          if (
            value === null ||
            value === undefined ||
            Number.isNaN(Number(value))
          ) {
            return '—';
          }

          if (name === 'Battery') {
            return `${Number(value).toFixed(0)} %`;
          }

          if (name === 'Frank prijs') {
            return `${Number(value).toFixed(2)} ct/kWh`;
          }

          return `${Number(value).toFixed(2)} kW`;
        }

        const rows = [];

        for (let i = 0; i < w.globals.seriesNames.length; i++) {

          const name = w.globals.seriesNames[i];
          const xValues = w.globals.seriesX[i];

          let index;

          if (name === 'Frank prijs') {
            index = previousIndex(xValues, hoverX);
          } else {
            index = nearestIndex(xValues, hoverX);
          }

          const value =
            index >= 0 && w.globals.series[i]
              ? w.globals.series[i][index]
              : null;

          let markerColor = '#999999';

          if (name === 'Battery') {
            markerColor = '#A0C770';
          } else if (name === 'Huis') {
            markerColor = '#9B59B6';
          } else if (name === 'PV') {
            markerColor = '#FABF00';
          } else if (name === 'Netimport') {
            markerColor = '#C18349';
          } else if (name === 'Netexport') {
            markerColor = '#FF5722';
          } else if (name === 'Frank prijs') {
            markerColor = '#00B7FF';
          }

          rows.push(`
            <div style="
              display:flex;
              align-items:center;
              justify-content:space-between;
              gap:18px;
              margin:4px 0;
              white-space:nowrap;
            ">
              <span style="
                display:flex;
                align-items:center;
                gap:6px;
              ">
                <span style="
                  width:9px;
                  height:9px;
                  border-radius:50%;
                  background:${markerColor};
                  display:inline-block;
                "></span>
                ${name}
              </span>

              <strong>
                ${formatValue(name, value)}
              </strong>
            </div>
          `);
        }

        const date = new Date(hoverX);

        const timeText = date.toLocaleString('nl-NL', {
          day: '2-digit',
          month: '2-digit',
          hour: '2-digit',
          minute: '2-digit'
        });

        return `
          <div style="
            padding:10px 12px;
            min-width:210px;
          ">
            <div style="
              font-weight:600;
              margin-bottom:8px;
              border-bottom:1px solid rgba(128,128,128,0.25);
              padding-bottom:6px;
            ">
              ${timeText}
            </div>

            ${rows.join('')}
          </div>
        `;
      }
  grid:
    padding:
      left: 10
      right: 10
      bottom: 20
  stroke:
    width: 2
  dataLabels:
    enabled: false
  legend:
    show: true
    position: bottom
    horizontalAlign: center
    offsetY: 5
  annotations:
    yaxis:
      - 'y': 0
        strokeDashArray: 0
        borderWidth: 2
all_series_config:
  type: area
  stroke_width: 2
  opacity: 0.9
  curve: smooth
series:
  - entity: sensor.alphaess_inverter_battery_state_of_charge
    name: Battery
    yaxis_id: battery
    type: area
    color: '#A0C770'
    extend_to: now
    curve: smooth
    fill_raw: last
    stroke_width: 3
    opacity: 0.18
    group_by:
      func: avg
      duration: 5min
    show:
      legend_value: false
  - entity: sensor.alphaess_inverter_current_house_load
    name: Huis
    yaxis_id: power
    type: area
    color: '#9B59B6'
    unit: kW
    float_precision: 2
    transform: return x / 1000;
    extend_to: now
    curve: smooth
    fill_raw: last
    stroke_width: 2.5
    opacity: 0.15
    group_by:
      func: avg
      duration: 5min
    show:
      legend_value: false
  - entity: sensor.alphaess_inverter_current_pv_production
    name: PV
    yaxis_id: power
    type: area
    color: '#FABF00'
    unit: kW
    float_precision: 2
    transform: return x / 1000;
    extend_to: now
    curve: smooth
    fill_raw: last
    stroke_width: 2.5
    opacity: 0.15
    group_by:
      func: avg
      duration: 5min
    show:
      legend_value: false
  - entity: sensor.alphaess_inverter_grid_power
    name: Netimport
    yaxis_id: power
    type: area
    color: '#C18349'
    unit: kW
    float_precision: 2
    transform: 'return x > 0 ? x / 1000 : 0;'
    extend_to: now
    curve: smooth
    fill_raw: last
    stroke_width: 1.5
    opacity: 0.22
    group_by:
      func: min
      duration: 5min
    show:
      legend_value: false
  - entity: sensor.alphaess_inverter_grid_power
    name: Netexport
    yaxis_id: power
    type: area
    color: '#FF5722'
    unit: kW
    float_precision: 2
    transform: 'return x < 0 ? Math.abs(x) / 1000 : 0;'
    extend_to: now
    curve: smooth
    fill_raw: last
    stroke_width: 1.5
    opacity: 0.22
    group_by:
      func: avg
      duration: 5min
    show:
      legend_value: false
  - entity: sensor.frank_prices_today
    name: Frank prijs
    yaxis_id: price
    type: line
    curve: stepline
    color: '#00B7FF'
    stroke_width: 4
    opacity: 1
    unit: ct/kWh
    float_precision: 2
    data_generator: |
      return entity.attributes.prices.map(p => [
        new Date(p.from).getTime(),
        p.total_price_eur_kwh * 100
      ]);
    show:
      legend_value: false
yaxis:
  - id: power
    min: 0
    max: 15
    decimals: 2
    apex_config:
      tickAmount: 15
      title:
        text: POWER
      labels:
        formatter: |
          EVAL:function(value) {
            return value.toFixed(2) + " kW";
          }
  - id: price
    min: '|-1|'
    max: '|+1|'
    decimals: 0
    opposite: false
    apex_config:
      offsetX: -45
      tickAmount: 10
      title:
        text: PRIJS
      labels:
        formatter: |
          EVAL:function(value) {
            return value.toFixed(0) + " ct";
          }
  - id: battery
    min: 0
    max: 100
    decimals: 0
    opposite: true
    apex_config:
      tickAmount: 10
      title:
        text: BAT
      labels:
        formatter: |
          EVAL:function(value) {
            return value.toFixed(0) + " %";
          }
grid_options:
  columns: full

Rondom de config:

DAO config battery

code:

  "battery": [
  {
    "name": "AlphaESS SMILE G3-T10",
    "capacity": 18.6,
    "entity actual level": "sensor.alphaess_inverter_battery_state_of_charge",
    "upper limit": 98,
    "lower limit": 15,
    "optimal lower level": 20,
    "charge stages": [
      { "power": 0, "efficiency": 1 },
      { "power": 10000, "efficiency": 0.95 }
    ],
    "discharge stages": [
      { "power": 0, "efficiency": 1 },
      { "power": 10000, "efficiency": 0.95 }
    ],
    "dc_to_bat efficiency": 1.0,
    "bat_to_dc efficiency": 1.0,
    "minimum power": 200,
    "cycle cost": 0.0175,
    "entity set power feedin": "input_number.simulatie_batterij_vermogen",
    "entity set operating mode": "input_select.dao_batterij_operating_mode"
  }
]

2 helpers aangemaakt:
input_number.simulatie_batterij_vermogen
-10000
10000
stapgrootte 1
Meeteenheid W

input_select.dao_batterij_operating_mode
Aan
Uit

Modbus-integratie toegevoegd:
https://github.com/senalse/ha-alphaess-modbus

Deze voegt deze entiteiten toe:
switch.alphaess_inverter_dispatch
select.alphaess_inverter_dispatch_mode
number.alphaess_inverter_dispatch_power
number.alphaess_inverter_dispatch_duration
number.alphaess_inverter_dispatch_stop_at_soc

Entiteiten die meetwaarden opleveren:
sensor.alphaess_inverter_battery_state_of_charge
sensor.alphaess_inverter_battery_power
sensor.alphaess_inverter_grid_power
sensor.alphaess_inverter_current_house_load
sensor.alphaess_inverter_current_pv_production

Automatisering die de batterij aanstuurt:

code:

alias: DAO naar AlphaESS
description: Stuurt DAO operating mode en vermogenssetpoint naar AlphaESS Dispatch
triggers:
  - trigger: state
    entity_id:
      - input_select.dao_batterij_operating_mode
      - input_number.simulatie_batterij_vermogen
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_select.dao_batterij_operating_mode
            state: Uit
        sequence:
          - action: switch.turn_off
            target:
              entity_id: switch.alphaess_inverter_dispatch
      - conditions:
          - condition: state
            entity_id: input_select.dao_batterij_operating_mode
            state: Aan
        sequence:
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_duration
            data:
              value: 480
          - action: select.select_option
            target:
              entity_id: select.alphaess_inverter_dispatch_mode
            data:
              option: State of Charge Control (2)
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_power
            data:
              value: >
                {% set dao = states('input_number.simulatie_batterij_vermogen')
                | float(0) %} {% set power = dao * -0.001 %} {{ [10, [-10,
                power] | max] | min }}
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_stop_at_soc
            data:
              value: >
                {% set dao = states('input_number.simulatie_batterij_vermogen')
                | float(0) %} {% if dao > 0 %}
                  100
                {% else %}
                  15
                {% endif %}
          - action: switch.turn_on
            target:
              entity_id: switch.alphaess_inverter_dispatch
mode: restart

De trigger kijkt naar:
input_select.dao_batterij_operating_mode
input_number.simulatie_batterij_vermogen

en de automatisering zorgt ervoor dat wanneer DAO zijn planning aanpast, de AlphaESS opnieuw wordt aangestuurd.

AlphaESS Self-Consumption setting:
AlphaESS in de Self-Consumption mode gezet, zodat wanneer DAO niet specifiek aan het laden of ontladen is, de batterij gewoon gebruikt wordt voor huisgebruik en opgeladen kan worden via zonnepanelen.

In het kort:
DAO stuurt de 2 helpers aan, de automatisering reageert op de helpers, de automatisering stuurt de batterij aan via modbus

Ik hoop dat je hier iets aan hebt, ik heb deze hele setup samen met AI gedaan en dit voorzichtig aangepakt, bij elke stap enkele testen gedaan om te kijken of een simulatie daadwerkelijk het gewenste resultaat had. Veel succes, het kost wat tijd maar het is écht de moeite waard.

[DikDikkie]

Doopy-X- schreef op dinsdag 6 oktober 2026 @ 19:32:
[...]

In het kort:
DAO stuurt de 2 helpers aan, de automatisering reageert op de helpers, de automatisering stuurt de batterij aan via modbus

Ik hoop dat je hier iets aan hebt, ik heb deze hele setup samen met AI gedaan en dit voorzichtig aangepakt, bij elke stap enkele testen gedaan om te kijken of een simulatie daadwerkelijk het gewenste resultaat had. Veel succes, het kost wat tijd maar het is écht de moeite waard.

Heel erg bedankt! Ik heb de hillview modbus al aan de praat maar ga deze ook eens bekijken.

[KC27]

Doopy-X- schreef op dinsdag 6 oktober 2026 @ 19:32:
[...]


Ik heb mbt tot DAO 2 grafieken gemaakt:

[...]


[...]


Rondom de config:

DAO config battery

code:

  "battery": [
  {
    "name": "AlphaESS SMILE G3-T10",
    "capacity": 18.6,
    "entity actual level": "sensor.alphaess_inverter_battery_state_of_charge",
    "upper limit": 98,
    "lower limit": 15,
    "optimal lower level": 20,
    "charge stages": [
      { "power": 0, "efficiency": 1 },
      { "power": 10000, "efficiency": 0.95 }
    ],
    "discharge stages": [
      { "power": 0, "efficiency": 1 },
      { "power": 10000, "efficiency": 0.95 }
    ],
    "dc_to_bat efficiency": 1.0,
    "bat_to_dc efficiency": 1.0,
    "minimum power": 200,
    "cycle cost": 0.0175,
    "entity set power feedin": "input_number.simulatie_batterij_vermogen",
    "entity set operating mode": "input_select.dao_batterij_operating_mode"
  }
]

2 helpers aangemaakt:
input_number.simulatie_batterij_vermogen
-10000
10000
stapgrootte 1
Meeteenheid W

input_select.dao_batterij_operating_mode
Aan
Uit

Modbus-integratie toegevoegd:
https://github.com/senalse/ha-alphaess-modbus

Deze voegt deze entiteiten toe:
switch.alphaess_inverter_dispatch
select.alphaess_inverter_dispatch_mode
number.alphaess_inverter_dispatch_power
number.alphaess_inverter_dispatch_duration
number.alphaess_inverter_dispatch_stop_at_soc

Entiteiten die meetwaarden opleveren:
sensor.alphaess_inverter_battery_state_of_charge
sensor.alphaess_inverter_battery_power
sensor.alphaess_inverter_grid_power
sensor.alphaess_inverter_current_house_load
sensor.alphaess_inverter_current_pv_production

Automatisering die de batterij aanstuurt:

code:

alias: DAO naar AlphaESS
description: Stuurt DAO operating mode en vermogenssetpoint naar AlphaESS Dispatch
triggers:
  - trigger: state
    entity_id:
      - input_select.dao_batterij_operating_mode
      - input_number.simulatie_batterij_vermogen
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_select.dao_batterij_operating_mode
            state: Uit
        sequence:
          - action: switch.turn_off
            target:
              entity_id: switch.alphaess_inverter_dispatch
      - conditions:
          - condition: state
            entity_id: input_select.dao_batterij_operating_mode
            state: Aan
        sequence:
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_duration
            data:
              value: 480
          - action: select.select_option
            target:
              entity_id: select.alphaess_inverter_dispatch_mode
            data:
              option: State of Charge Control (2)
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_power
            data:
              value: >
                {% set dao = states('input_number.simulatie_batterij_vermogen')
                | float(0) %} {% set power = dao * -0.001 %} {{ [10, [-10,
                power] | max] | min }}
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_stop_at_soc
            data:
              value: >
                {% set dao = states('input_number.simulatie_batterij_vermogen')
                | float(0) %} {% if dao > 0 %}
                  100
                {% else %}
                  15
                {% endif %}
          - action: switch.turn_on
            target:
              entity_id: switch.alphaess_inverter_dispatch
mode: restart

De trigger kijkt naar:
input_select.dao_batterij_operating_mode
input_number.simulatie_batterij_vermogen

en de automatisering zorgt ervoor dat wanneer DAO zijn planning aanpast, de AlphaESS opnieuw wordt aangestuurd.

AlphaESS Self-Consumption setting:
AlphaESS in de Self-Consumption mode gezet, zodat wanneer DAO niet specifiek aan het laden of ontladen is, de batterij gewoon gebruikt wordt voor huisgebruik en opgeladen kan worden via zonnepanelen.

In het kort:
DAO stuurt de 2 helpers aan, de automatisering reageert op de helpers, de automatisering stuurt de batterij aan via modbus

Ik hoop dat je hier iets aan hebt, ik heb deze hele setup samen met AI gedaan en dit voorzichtig aangepakt, bij elke stap enkele testen gedaan om te kijken of een simulatie daadwerkelijk het gewenste resultaat had. Veel succes, het kost wat tijd maar het is écht de moeite waard.

@Torch1969 heb jij (of iemand anders) tijd om deze setup op te nemen in de Wiki?

[Doopy-X-]

DikDikkie schreef op dinsdag 6 oktober 2026 @ 19:53:
[...]


Heel erg bedankt! Ik heb de hillview modbus al aan de praat maar ga deze ook eens bekijken.

Hillview is de bron van veel AlphaESS modbus-integraties, de modbus-aansturing is onder water ook hetzelfde. Senalse heeft deze doorontwikkeld naar een echte HA-integratie die te installeren is via HACS waarbij je out-of-box een grote set aan entiteiten krijgt en deze reageren ook erg snel, wat bijvoorbeeld weer goed is voor de grafieken.

[TheMystery]

Doopy-X- schreef op dinsdag 6 oktober 2026 @ 19:32:
[...]


Ik heb mbt tot DAO 2 grafieken gemaakt:

[...]


[...]


Rondom de config:

DAO config battery

code:

  "battery": [
  {
    "name": "AlphaESS SMILE G3-T10",
    "capacity": 18.6,
    "entity actual level": "sensor.alphaess_inverter_battery_state_of_charge",
    "upper limit": 98,
    "lower limit": 15,
    "optimal lower level": 20,
    "charge stages": [
      { "power": 0, "efficiency": 1 },
      { "power": 10000, "efficiency": 0.95 }
    ],
    "discharge stages": [
      { "power": 0, "efficiency": 1 },
      { "power": 10000, "efficiency": 0.95 }
    ],
    "dc_to_bat efficiency": 1.0,
    "bat_to_dc efficiency": 1.0,
    "minimum power": 200,
    "cycle cost": 0.0175,
    "entity set power feedin": "input_number.simulatie_batterij_vermogen",
    "entity set operating mode": "input_select.dao_batterij_operating_mode"
  }
]

2 helpers aangemaakt:
input_number.simulatie_batterij_vermogen
-10000
10000
stapgrootte 1
Meeteenheid W

input_select.dao_batterij_operating_mode
Aan
Uit

Modbus-integratie toegevoegd:
https://github.com/senalse/ha-alphaess-modbus

Deze voegt deze entiteiten toe:
switch.alphaess_inverter_dispatch
select.alphaess_inverter_dispatch_mode
number.alphaess_inverter_dispatch_power
number.alphaess_inverter_dispatch_duration
number.alphaess_inverter_dispatch_stop_at_soc

Entiteiten die meetwaarden opleveren:
sensor.alphaess_inverter_battery_state_of_charge
sensor.alphaess_inverter_battery_power
sensor.alphaess_inverter_grid_power
sensor.alphaess_inverter_current_house_load
sensor.alphaess_inverter_current_pv_production

Automatisering die de batterij aanstuurt:

code:

alias: DAO naar AlphaESS
description: Stuurt DAO operating mode en vermogenssetpoint naar AlphaESS Dispatch
triggers:
  - trigger: state
    entity_id:
      - input_select.dao_batterij_operating_mode
      - input_number.simulatie_batterij_vermogen
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_select.dao_batterij_operating_mode
            state: Uit
        sequence:
          - action: switch.turn_off
            target:
              entity_id: switch.alphaess_inverter_dispatch
      - conditions:
          - condition: state
            entity_id: input_select.dao_batterij_operating_mode
            state: Aan
        sequence:
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_duration
            data:
              value: 480
          - action: select.select_option
            target:
              entity_id: select.alphaess_inverter_dispatch_mode
            data:
              option: State of Charge Control (2)
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_power
            data:
              value: >
                {% set dao = states('input_number.simulatie_batterij_vermogen')
                | float(0) %} {% set power = dao * -0.001 %} {{ [10, [-10,
                power] | max] | min }}
          - action: number.set_value
            target:
              entity_id: number.alphaess_inverter_dispatch_stop_at_soc
            data:
              value: >
                {% set dao = states('input_number.simulatie_batterij_vermogen')
                | float(0) %} {% if dao > 0 %}
                  100
                {% else %}
                  15
                {% endif %}
          - action: switch.turn_on
            target:
              entity_id: switch.alphaess_inverter_dispatch
mode: restart

De trigger kijkt naar:
input_select.dao_batterij_operating_mode
input_number.simulatie_batterij_vermogen

en de automatisering zorgt ervoor dat wanneer DAO zijn planning aanpast, de AlphaESS opnieuw wordt aangestuurd.

AlphaESS Self-Consumption setting:
AlphaESS in de Self-Consumption mode gezet, zodat wanneer DAO niet specifiek aan het laden of ontladen is, de batterij gewoon gebruikt wordt voor huisgebruik en opgeladen kan worden via zonnepanelen.

In het kort:
DAO stuurt de 2 helpers aan, de automatisering reageert op de helpers, de automatisering stuurt de batterij aan via modbus

Ik hoop dat je hier iets aan hebt, ik heb deze hele setup samen met AI gedaan en dit voorzichtig aangepakt, bij elke stap enkele testen gedaan om te kijken of een simulatie daadwerkelijk het gewenste resultaat had. Veel succes, het kost wat tijd maar het is écht de moeite waard.

Ik zie dat je de alpha aanstuurt via dao via de power feedin (grid) optie, maar de hillview integratie stuurt de inverter aan met laden en ontladen en niet op grid niveau.

Ik stuur hem juist aan met from battery om hem volledig aan de dao planning te kunnen houden.

[Doopy-X-]

TheMystery schreef op dinsdag 6 oktober 2026 @ 20:33:
[...]


Ik zie dat je de alpha aanstuurt via dao via de power feedin (grid) optie, maar de hillview integratie stuurt de inverter aan met laden en ontladen en niet op grid niveau.

Ik stuur hem juist aan met from battery om hem volledig aan de dao planning te kunnen houden.

Check, volgens mij werken beide opties prima. Ik zal als ik ooit zin heb eens jouw optie testen

[Dogooder]

Doopy-X- schreef op zondag 4 oktober 2026 @ 19:33:
Ik heb het nu als dashboard opgenomen in Home Assistant:
[Afbeelding]

Is dit geweldige dashboard al ergens open source?

[ Voor 30% gewijzigd door Dogooder op 06-10-2026 22:19 ]

[TheMystery]

Doopy-X- schreef op dinsdag 6 oktober 2026 @ 21:35:
[...]


Check, volgens mij werken beide opties prima. Ik zal als ik ooit zin heb eens jouw optie testen

Ik draai nu al maanden met deze configuratie en automations:

JSON:

  "battery": [
    {
      "name": "AlphaEss G3 Smile T10",
      "entity actual level": "sensor.alphaess_soc_battery",
      "capacity": 46.5,
      "upper limit": "input_number.dao_upper_limit",
      "lower limit": "input_number.dao_lower_limit",
      "optimal lower level": "input_number.dao_optimal_lower_level",
      "entity min soc end opt": "input_number.dao_min_soc_einde",
      "entity max soc end opt": "input_number.dao_max_soc_einde",
      "charge stages": [
        {"power": 0,     "efficiency": 1.0},
        {"power": 2500,  "efficiency": 0.945},
        {"power": 5000,  "efficiency": 0.958},
        {"power": 7500,  "efficiency": 0.955},
        {"power": 10000, "efficiency": 0.950}
      ],
      "discharge stages": [
        {"power": 0,     "efficiency": 1.0},
        {"power": 2500,  "efficiency": 0.945},
        {"power": 5000,  "efficiency": 0.958},
        {"power": 7500,  "efficiency": 0.955},
        {"power": 10000, "efficiency": 0.945}
      ],
      "minimum power": 100,
      "dc_to_bat efficiency": 1.0,
        "dc_to_bat max power" : 10000.0,
      "bat_to_dc efficiency": 1.0,
      "bat_to_dc max power" : 10000.0,
      "cycle cost": 0.015,
      "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_inverter",
      "entity from battery": "input_number.dao_from_battery",
      "entity from ac": "input_number.dao_from_ac",
      "entity from pv": "input_number.dao_from_pv",
      "entity calculated soc": "input_number.dao_calculated_soc"
    }
  ],

YAML:

alias: 'DAO: AlphaESS Mode 2'
description: Elk kwartier DAO planning doorsturen naar Hillview dispatch mode 2
triggers:
  - minutes: /15
    seconds: '15'
    trigger: time_pattern
conditions:
  - condition: template
    value_template: |
      {{ states('input_select.dao_set_operating_mode') != 'Uit' }}
  - condition: template
    value_template: |
      {{ not (states('input_select.dao_set_operating_mode') == 'Aan' 
         and states('input_boolean.dao_balance_switch') == 'on') }}
actions:
  - variables:
      dao_power: '{{ states(''input_number.dao_from_battery'') | float(0) }}'
      stop_time: '{{ states(''input_datetime.dao_stop_inverter'') }}'
      duration: |-
        {% if stop_time == '2000-01-01 00:00:00' %}15 {% else %}
          {% set stop = strptime(stop_time, '%Y-%m-%d %H:%M:%S') | as_local %}
          {% set now_dt = now().replace(second=0, microsecond=0) %}
          {% set diff = (stop - now_dt).total_seconds() / 60 %}
          {% if diff < 1 or diff > 15 %}15
          {% else %}{{ diff | int }}
          {% endif %}
        {% endif %}
      hillview_power: |-
        {% set dur = duration | int(15) %} {% if dur < 15 %}
          {% set power = (dao_power / 1000 * 15 / dur) | round(1) %}
          {{ [[power, 10.0] | min, -10.0] | max }}
        {% else %}
          {{ (dao_power / 1000) | round(1) }}
        {% endif %}
      hillview_soc: >-
        {% set base_soc = states('input_number.dao_calculated_soc') | int(0) %}
        {% set p = hillview_power | float(0) %} {% if p > 0 %}
          {{ [base_soc - 2, 15] | max }}
        {% elif p < 0 %}
          {{ [base_soc + 2, 100] | min }}
        {% else %}
          {{ base_soc }}
        {% endif %}
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: 1
    action: input_number.set_value
  - delay: '00:00:01'
  - target:
      entity_id: number.alphaess_template_dispatch_power
    data:
      value: '{{ hillview_power }}'
    action: number.set_value
  - target:
      entity_id: input_number.alphaess_helper_dispatch_cutoff_soc
    data:
      value: '{{ hillview_soc }}'
    action: input_number.set_value
  - target:
      entity_id: input_select.alphaess_helper_dispatch_mode
    data:
      option: State of Charge Control (2)
    action: input_select.select_option
  - delay: '00:00:01'
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: '{{ duration }}'
    action: input_number.set_value
  - condition: state
    entity_id: input_boolean.alphaess_helper_dispatch
    state: 'off'
  - target:
      entity_id: input_boolean.alphaess_helper_dispatch
    action: input_boolean.turn_on
mode: single

YAML:

alias: 'Dao: Dispatch off'
description: Mode 2 met power 0 als DAO dispatch uit gaat
triggers:
  - trigger: state
    entity_id:
      - input_boolean.alphaess_helper_dispatch
    to:
      - 'off'
conditions:
  - condition: template
    value_template: >-
      {% set trigger_id = trigger.to_state.context.id %} {% set veroorzaker =
      states.automation
         | selectattr('context.id', 'eq', trigger_id)
         | map(attribute='entity_id') | first %}
      {{ veroorzaker != 'automation.dao_alphaess_mode_2_from_ac_and_duration_1'
         and veroorzaker != 'automation.dao_dao_off' }}
  - condition: not
    conditions:
      - condition: state
        entity_id: input_select.dao_set_operating_mode
        state: Uit
  - condition: state
    entity_id: input_boolean.dao_balance_switch
    state: 'off'
actions:
  - target:
      entity_id: number.alphaess_template_dispatch_power
    data:
      value: 0
    action: number.set_value
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: 15
    action: input_number.set_value
  - target:
      entity_id: input_number.alphaess_helper_dispatch_cutoff_soc
    data:
      value: '{{ states(''input_number.dao_calculated_soc'') | int(0) }}'
    action: input_number.set_value
  - target:
      entity_id: input_select.alphaess_helper_dispatch_mode
    data:
      option: State of Charge Control (2)
    action: input_select.select_option
  - target:
      entity_id: input_boolean.alphaess_helper_dispatch
    action: input_boolean.turn_on
mode: single

YAML:

alias: 'Dao: DAO off'
description: Mode 2 met power 0 als DAO uitgeschakeld is
triggers:
  - minutes: /15
    seconds: '15'
    trigger: time_pattern
conditions:
  - condition: template
    value_template: |
      {{ states('input_select.dao_set_operating_mode') == 'Uit' }}
  - condition: template
    value_template: |
      {{ states('input_number.dao_from_pv') | float(0) < 50 }}
actions:
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: 1
    action: input_number.set_value
  - delay: '00:00:01'
  - target:
      entity_id: number.alphaess_template_dispatch_power
    data:
      value: 0
    action: number.set_value
  - target:
      entity_id: input_number.alphaess_helper_dispatch_cutoff_soc
    data:
      value: '{{ states(''input_number.dao_calculated_soc'') | int(0) }}'
    action: input_number.set_value
  - target:
      entity_id: input_select.alphaess_helper_dispatch_mode
    data:
      option: State of Charge Control (2)
    action: input_select.select_option
  - delay: '00:00:01'
  - target:
      entity_id: input_number.alphaess_helper_dispatch_duration
    data:
      value: 15
    action: input_number.set_value
  - condition: state
    entity_id: input_boolean.alphaess_helper_dispatch
    state: 'off'
  - target:
      entity_id: input_boolean.alphaess_helper_dispatch
    action: input_boolean.turn_on
mode: single

uitleg:
DAO → AlphaESS Mode 2 via Hillview — automatiseringstoelichting
Achtergrond

De Day Ahead Optimizer (DAO) berekent elk kwartier een optimaal laad/ontlaadplan voor de batterij op basis van day-ahead stroomprijzen. De AlphaESS wordt aangestuurd via de Hillview integratie in Home Assistant, specifiek Mode 2: State of Charge Control, waarbij je Power, Duration en Cutoff SoC instelt.

Automatisering 1: DAO → Mode 2

Trigger: Elke 15 minuten op :00:15 (15 seconden na het kwartier, zodat DAO zijn berekening heeft afgerond).

Condities:

DAO moet actief zijn (operating_mode != Uit)
Als DAO aan staat én de balance switch aan staat, wordt niks gedaan — de omvormer regelt dan zelf nul-op-de-meter

Vermogen (dao_from_battery):
DAO geeft het gewenste batterijvermogen als kwartiergemiddelde. Bij een korte dispatch (bijv. 8 minuten) wordt dit vermogen omgerekend: vermogen × 15 / duration, zodat de juiste hoeveelheid energie in de kortere tijd wordt geleverd. Begrensd op ±10 kW.

Duration:
Berekend op basis van dao_stop_inverter. Als DAO geen stoptijd heeft ingesteld staat deze op 2000-01-01, dan wordt 15 minuten gebruikt als fallback.

Cutoff SoC:
DAO's berekende SoC ±2% marge, zodat de omvormer iets verder laadt/ontlaadt dan het exacte target. Minimaal 15% bij ontladen.

Dispatch herstart:
De duration wordt eerst op 1 minuut gezet, dan na een korte delay op de echte waarde. Dit forceert altijd een state change waardoor Hillview de dispatch herstart — ook als de duration niet verandert. De boolean wordt alleen aangezet als hij uit staat.

Automatisering 2: Dispatch off → batterij stilzetten

Trigger: Als alphaess_helper_dispatch op off gaat.

Doel: Als de dispatch afloopt (target SoC bereikt of timer verlopen) valt de omvormer terug naar zijn standaard modus. Als de balance switch uit staat betekent dit vrij laden/ontladen zonder sturing. Door Mode 2 opnieuw in te stellen met power 0 blijft de batterij stil totdat de volgende DAO-berekening op het kwartier een nieuwe opdracht geeft.

Conditie: Alleen als de dispatch niet door de DAO-automatisering zelf of de DAO off-automatisering werd uitgeschakeld, DAO actief is, en de balance switch uit staat — als de balance switch aan staat regelt de omvormer zelf nul-op-de-meter en hoeft er niets te gebeuren.

Automatisering 3: DAO uit → batterij stilzetten

Trigger: Elke 15 minuten.

Doel: Als DAO uitgeschakeld is wil je voorkomen dat de omvormer de batterij vrij laadt of ontlaadt. Power 0 houdt de batterij stil zodat PV ongestoord naar het net of huis gaat.

Conditie op PV: dao_from_pv < 50W — bij hoge PV-productie op DC-installaties kan dit anders interfereren.

[thomvh]

The Source schreef op dinsdag 6 oktober 2026 @ 16:45:
Ik zag andere ook hierover posten.

Ik gebruik deye_total_production in entities_solar_production_dc. Echter wordt DC niet meegenomen in de baseload calculatie waardoor ik negatieve waardes krijg in de baseload.

Claude stelde voor om deze van DC naar AC te verhuizen en per aparte string op te nemen (sensor.deye_pvx_power_kwh) omdat die ook een hogere resolutie hebben. Nadeel is dat het converter loss (~5% of 1kWh/dag) ook in de baseload komt.


[...]


Is dit aan te raden of zie ik iets over het hoofd?

Ik heb bij mij de DC aan de battery production toegevoegd. Toen was het ook gefixt. Maar ik heb inderdaad hetzelfde probleem.

[Doopy-X-]

Dogooder schreef op dinsdag 6 oktober 2026 @ 22:19:
[...]

Is dit geweldige dashboard al ergens open source?

Volgens mij nog niet. Hij wordt binnenkort aan de wiki toegevoegd geloof ik.

[konehead]

Dogooder schreef op dinsdag 6 oktober 2026 @ 22:19:
[...]

Is dit geweldige dashboard al ergens open source?

Ik ga hem WIKI ready maken, working on it. Met @Torch1969 afgesproken dat het dashboard netjes gedocumenteerd moet worden. Als je echt niet kan wachten, stuur mij even een DM. Dan stuur ik de ruwe code