Skip to content

Feature request: Hybrid heating source #539

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
snauwaertc opened this issue May 13, 2025 · 1 comment
Open

Feature request: Hybrid heating source #539

snauwaertc opened this issue May 13, 2025 · 1 comment

Comments

@snauwaertc
Copy link

Is it possible to build functionality to control a hybrid heating system (e.g., gas and heat pump), taking into account gas EUR/kWh and implied electrical EUR/kWh (based on predicted internal price, COP/heat differential etc.)?
There may be a circular dependency for heat source and implied electrical energy price.

@snauwaertc snauwaertc changed the title Hybrid heating source Feature request: Hybrid heating source May 16, 2025
@snauwaertc
Copy link
Author

Here's a proposal to build the feature (high-level). Any thoughts?

The core idea is to treat the heat pump (HP) and gas boiler (GB) as entities contributing to a unified thermal demand, each with its own energy source and cost.

Conceptual Treatment:

  • Heat Pump (HP): Acts as both an electrical load (its consumption factored into the main electricity optimization) and a heat source (or sink, if cooling). Its efficiency (COP for heating, EER for cooling) will be crucial.
  • Gas Boiler (GB): Acts as a heat source with a separate fuel (gas) cost, which needs to be added to the overall objective function.
  • Cooling (Negative P_heating): If the system needs to cool the indoor space, only electrically powered devices (like a reversible HP or a dedicated AC unit) can contribute. The GB cannot provide cooling.

Key Source Code Modification Areas:

  1. Parameter Configuration (options.json/YAML, utils.py, command_line.py):

    • New parameters will be needed to define the characteristics of the HP and GB (heating/cooling rates, COP/EER tables or calculation methods, lockout temperatures, efficiency, gas price forecasts/constants), thermal model parameters (if not fully covered by existing thermal_config), comfort band setpoints, and initial indoor temperature.
    • Functions like utils.get_yaml_parse and utils.treat_runtimeparams will need to handle these new configurations.
    • The src/emhass/data/associations.csv might require updates for mapping any new list-based or complex parameters.
  2. Core Optimization Logic (src/emhass/optimization.py - Optimization class, primarily perform_optimization):

    • Decision Variables: Introduce binary variables for Activate_HP_Heating[t], Activate_GB_Heating[t], and (if cooling) Activate_HP_Cooling[t]. A continuous variable for Indoor_Temperature[t] will track the thermal state.
    • Constraints:
      • Add Heat Input Calculation constraints: Heat_Input_from_System[t] = (HP_Heat[t] + GB_Heat[t]) - HP_Cool[t].
      • Enforce Comfort Constraints: Min_Desired_Comfort_Temp <= Indoor_Temperature[t] <= Max_Desired_Comfort_Temp, potentially with slack variables for penalties.
      • Include System Operational Constraints: HP lockout temperatures, prevention of simultaneous HP heating/cooling, and rules for simultaneous HP/GB operation.
    • Electrical Load Integration: The HP's electrical consumption (calculated from its thermal output and COP/EER) must be added to the main power balance equation that EMHASS solves.
    • Objective Function Modification: The cost of gas consumed by the GB (Activate_GB_Heating[t] * (GB_Heating_Rate_kW / GB_Efficiency) * Timestep_Duration_hours * Gas_Price_per_kWh_input[t]) must be added to the existing electricity-focused objective function.
  3. Data Preparation (src/emhass/forecast.py - Forecast class):

    • If HP COP/EER values are dependent on forecasted outdoor temperatures, this class will handle their calculation.
    • Forecasting or retrieving gas prices (if dynamic) would also occur here.
    • Preparation of Solar_Gains[t] and Internal_Gains[t] if these are incorporated into the model.
  4. Publishing Results (src/emhass/retrieve_hass.py, command_line.py - publish_data):

    • Extend functionality to publish new sensor data to Home Assistant, such as:
      • Predicted indoor temperature.
      • Thermal power output for HP (heating/cooling) and GB.
      • Electrical power consumption of HP.
      • Gas consumption of GB.
      • Activation status (binary sensors) for HP heating, HP cooling, and GB heating.
    • This will require defining new entity IDs in the EMHASS parameters.

Workflow Summary:

  1. EMHASS loads configurations, including new hybrid heating parameters.
  2. Forecasts for weather, electricity prices, gas prices, COP/EER, and thermal gains are prepared.
  3. The Optimization module constructs an MILP incorporating the unified thermal model, HP and GB characteristics, comfort requirements, and both electricity and gas costs.
  4. The solver determines the optimal activation schedule for the HP and GB, alongside other EMHASS-managed devices (like batteries).
  5. The comprehensive results, including new thermal and heating system states, are published.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant