Intelligent Preheating (Physics-based Pilot)

Share your Projects! Custom Integrations
1

:rocket: New Integration: Intelligent Preheating (Physics-based Pilot) - Beta Test

Hi everyone! :wave:

I’m excited to share a project I’ve been working on, and I’m looking for beta testers to help me torture-test the physics engine.

:open_book: The Story: From Blueprint to Integration

This started as a simple idea for our office: We wanted it warm at 05:00, but didn’t want to waste energy heating too early. I originally built this as a Blueprint. Ideally, it worked, but it was a pain to set up—requires tons of Helpers, the logic was rigid, and the “learning” part was extremely rudimentary.

Then I saw the amazing work by @Some-dude on my Virtual MRT Sensor. His dedication motivated me to stop hacking around with Templates and do it properly: In Python.

The result is Intelligent Preheating. It’s no longer just a script; it’s a full physics simulation that learns your room’s thermal properties.

:brain: What it does

This integration acts as a Pilot for your existing thermostat. It learns:

  1. Thermal Mass: How long does it take to heat up?
  2. Thermal Loss: How fast does heat escape?
  3. Deadtime: Critical for Floor Heating.

:sparkles: Key Features

  • :dart: Finish on Time: Hits the target temp exactly when you need it.
  • :chart_with_downwards_trend: Optimal Stop (Exclusive): Turns the heating OFF before you leave. It knows the room will stay warm for another 45 minutes, so it saves you that energy cost.
  • :electric_plug: Stand-Alone: Works with any thermostat entity.
  • :cloud_with_lightning_and_rain: Weather Aware: Adjusts for incoming cold fronts.

:warning: Beta Warning

Current Status: Beta Test :construction: I am actively adding features and tweaking the physics engine.

  • Please expect updates.
  • There might be Breaking Changes as I refine the config flow.
  • I really need feedback from people with different hearing systems (Radiators vs. Floor Heating) to validate the “Self-Learning” algorithms.

:package: Installation

It is not yet in the default HACS list.

  1. Open HACS → Integrations.
  2. Top right menu → Custom Repositories.
  3. URL: https://github.com/Ecronika/ha-preheat
  4. Category: Integration.

:handshake: The Perfect Companion

This integration handles the TIMING (When to start/stop). For the SCHEDULING (What temp at what time), it pairs perfectly with my original Smart Setpoint Blueprint. They are designed to work hand-in-hand.

:point_right: Blueprint: EN 16798-1 Smart Setpoint Blueprint

Happy Heating! :fire:

6 Likes
2

:rocket: Intelligent Preheating v2.6.0: Shift Work & Intelligent Pattern Recognition

Hi everyone,

I’m excited to introduce the major update to v2.6.0! This release focuses on one feature: Support for irregular schedules (Shift Work, Hybrid Work, Weekly Rotations).

NOTE

Pre-Release Status Please be aware that v2.6.0 is currently a Pre-Release. Automated Pattern Recognition is one of the more challenging tasks in machine learning. While our tests show great results, real-world habits vary wildly. I am releasing this now specifically to gather your feedback. If the system misinterprets your schedule, please let me know!

What’s New?

:brain: Multi-Modal Clustering

The system no longer just learns “one time per day” but detects multiple patterns.

  • Shift Work: Do you alternate between an early shift (06:00) and a late shift (14:00)? Intelligent Preheating identifies both clusters and learns which shift is likely for the upcoming day.
  • Week Parity: Work from the office on odd weeks and from home on even weeks? The system detects this rhythm (Odd/Even Week Detection).

:stop_sign: Optimal Stop (from v2.5)

The heating now intelligently shuts off before the end of the day (“Coast-to-Stop”) to utilize residual heat and save energy without sacrificing comfort.

:bar_chart: New Sensors

The sensor.next_event now provides detailed information about the prediction:

  • pattern_type: What pattern was detected? (e.g., single_mode, weekly_parity)
  • confidence: How confident is the system?
  • detected_modes: Which clusters were found (e.g., {'early': 5, 'late': 4}).

:warning: Important Note on the Learning Phase

Since this pattern recognition is based on statistical significance, the system needs data.

  • After the update, the system starts in “Hybrid Mode”: It uses your old data as a fallback while learning new patterns in the background.
  • It may take a few weeks to collect enough data points (at least 3-4 per weekday) to reliably predict complex patterns like shift rotations.
2 Likes
3

very nice.

4

:rocket: Coming Soon: Intelligent Preheating v3.0 – The Road to Autonomy

Hi everyone! :wave:

I’ve been working hard on the next big leap for Intelligent Preheating, and I wanted to share my vision for what’s coming next.

Until now, this integration has been all about predictive control—figuring out the best time to stop heating based on your schedule. With v3.0, I am moving towards Autonomous Operation.

My goal? Zero Config. The system shouldn’t just learn when to heat your home; it should learn when you leave and when to turn it off, automatically optimizing your energy usage without you having to touch a schedule.

:hatching_chick: Phase 1: The “Invisible” Update (v2.7)

Before I hand over control to the “AI”, I need to trust it. And for that, I need data.

Version 2.7.0-beta (available now!) introduces the Shadow Mode. In this mode, the system will run its new autonomous engine in the background. It will predict when your heating session should end and calculate how much energy you could have saved—but it won’t actually touch your thermostat yet.

Why join the Beta?

It helps to train the model! :brain: By running v2.7, you start building a history of your home’s heating cycles.

  • Zero Risk: Your current schedule and automations remain 100% in charge.
  • Data Collection: The system learns your “session lengths” (e.g., how long you usually keep the living room warm).
  • Be Ready: When v3.0 arrives, users with v2.7 history will be “Promotion Ready” immediately. The system will already know your home well enough to take over safely.

:robot: Phase 2: Autonomous Intelligence (v3.0)

Once the Shadow Mode has proven itself in your home (by meeting strict quality gates), you will unlock the Control Mode.

  • Smart Departure: The system detects when a heating session typically ends and stops the heating early (“Continuous Coasting”) to save energy while keeping you comfortable.
  • Safety First: I’ve built in strict “Safety Gates.” If the system isn’t 100% sure, or if your home cools down too fast, it hands control back to your schedule instantly.
  • Transparent: A new “Decision Trace” will show you exactly why a decision was made (or blocked), so you always know what’s happening.

:lock: Privacy & Local Control

As always, all data stays local on your Home Assistant. The learning happens on your machine. No cloud, no subscription, no data sharing.

:point_right: What can you do right now?

If you want to be part of the autonomous future:

  1. Download v2.7.0-beta from GitHub.
  2. Install it and let it run in the background.
  3. Check the Decision Trace attributes to see what the AI would have done.

I am incredibly excited to take this next step with you. Let’s make our homes smarter, together! :house_with_garden::sparkles:

Feedback, as always, is very welcome!

5

:brain: New Feature: Autonomous Engine Cockpit (Shadow Mode Debugging)

(Requires v2.7.0-beta4 or higher, beta3 minimum)

We are excited to introduce the Decision Trace feature! As we move towards a fully autonomous preheating engine, it’s crucial to understand why the AI makes certain decisions.

With v2.7.0-beta4, we’re exposing the internal logic of the “Shadow Mode” engine directly to your dashboard. This allows you to verify the safety gates, check the confidence of the thermal models, visualize learned time clusters, and see exactly why the AI might currently be blocked from taking control.

:bar_chart: Features

  • Signal Quality: See Thermal Confidence, Pattern Confidence, and Data Maturity (Session Counts) at a glance.
  • Provider Status: Compare what your Schedule wants vs. what the AI wants.
  • Detected Patterns: Visualize the V3 time clusters the AI has learned from your habits.
  • Block Reasons: If the AI isn’t ready, see exactly why (e.g., “Insufficient Sessions”, “Low Savings Predicted”).
  • Shadow Metrics: Track how much energy the AI would have saved in the background.

:hammer_and_wrench: How to setup the Card

This is currently a manual “Markdown” card for your Lovelace dashboard.

  1. Go to your Dashboard → Edit Dashboard.
  2. Click Add Card → Search for “Manual” (YAML) or “Markdown”.
  3. Paste the code below.
  4. IMPORTANT: Replace sensor.office_status in the first two lines (trace and patterns variables) with your actual preheat sensor entity ID (e.g., sensor.living_room_status).

:clipboard: The Code (YAML)

type: markdown
content: >-
  {% set trace = state_attr('sensor.office_status', 'decision_trace') %}
  {% set patterns = state_attr('sensor.office_status', 'pattern_data') %}
  {% if trace %}
    ### 🧠 Autonomous Engine Cockpit
    
    | | |
    |---|---|
    | **Evaluated** | {{ as_timestamp(trace.evaluated_at) | timestamp_custom('%H:%M:%S') }} |
    | **Controller** | `{{ trace.provider_selected | upper }}` |
    | **Candidates** | {{ trace.provider_candidates | join(', ') | upper }} |
    
    #### 📡 Signal Quality
    
    | Metric | Value | Status |
    |---|---|---|
    | **Thermal Confidence** | {{ ((trace.gate_inputs.tau_conf or 0) * 100)|round }}% | {% if (trace.gate_inputs.tau_conf or 0) > 0.6 %}✅{% else %}⚠️{% endif %} |
    | **Pattern Confidence** | {{ ((trace.gate_inputs.pattern_conf or 0) * 100)|round }}% | {% if (trace.gate_inputs.pattern_conf or 0) > 0.7 %}✅{% else %}⚠️{% endif %} |
    | **Data Maturity** | {{ trace.gate_inputs.session_count | default(0) }} Samples | {% if (trace.gate_inputs.session_count or 0) >= 3 %}✅{% else %}⚠️{% endif %} |
    | **Potential Savings** | {{ (trace.gate_inputs.savings or 0)|round(1) }} min | {% if (trace.gate_inputs.savings or 0) > 15 %}✅{% else %}⚪{% endif %} |
    
    {% if patterns %}
    #### 🧩 Detected Patterns (V3)
    
    | Time | Weight |
    |---|---|
    {% for time_str, count in patterns.items() %}
    | **{{ time_str }}** | {{ count }}x |
    {% endfor %}
    {% endif %}
    #### 🤖 Provider Status
    
    *   **Schedule**: 
        {% if 'schedule' in trace.provider_candidates %}
          ✅ Ready
        {% elif trace.providers_invalid.schedule in ['off', 'no_next_event'] %}
          💤 Idle ({{ trace.providers_invalid.schedule | replace('_', ' ') | title }})
        {% else %}
          ❌ Invalid ({{ trace.providers_invalid.schedule | replace('_', ' ') | title }})
        {% endif %}
    
        *   *Action*: {% if trace.providers.schedule.should_stop %}🛑 STOP{% else %}▶️ RUN{% endif %}
        *   *Savings*: {{ (trace.providers.schedule.savings or 0)|round(1) }} min
    
    *   **Learned (AI)**: {% if 'learned' in trace.provider_candidates %}✅ Ready{% else %}❌ Blocked{% endif %}
        {% if 'learned' not in trace.provider_candidates and trace.providers_invalid and trace.providers_invalid.learned %}
        *(Reason: {{ trace.providers_invalid.learned | replace('_', ' ') | title }})*
        {% endif %}
        *   *Action*: {% if trace.providers.learned.should_stop %}🛑 STOP{% else %}▶️ RUN{% endif %}
        *   *Mode*: {% if trace.providers.learned.is_shadow %}👻 Shadow{% else %}🚀 Control{% endif %}
    
    #### 🛡️ Active Gates & Constraints
    {% if trace.gates_failed and trace.gates_failed | length > 0 %}
      **⚠️ Blocks preventing AI Control:**
      {% for gate in trace.gates_failed %}
      * **{{ gate | replace('_', ' ') | title }}**
      {% endfor %}
    {% else %}
      ✅ **All Safety Gates Passed** (Promotion Ready)
    {% endif %}
    
    #### 👻 Shadow Performance
    | Metric | Value |
    |---|---|
    | **Accumulated Savings** | {{ (trace.metrics.cumulative_shadow_savings or 0) | round(1) }} min |
    | **Safety Violations** | {{ trace.metrics.safety_violations }} |
    
  {% else %}
    *(No decision trace available for sensor.office_status)*
  {% endif %}
title: Autonomous Engine Debug
6

Hey @Ecronika, I’ve set this up for a couple of rooms to see how it works. Would you prefer feedback/bugs reported on here or via github issues?

1 Like
7

Looks like a really useful integration, nice work!!

I have a slightly modified need for a similar integration and I’m wondering if it can be made to suit my needs.

Since I have floor heating (slow) and a heat pump (relatively low power and thus slow as well), we have our set point always at the same temperature (especially since most days there is someone at home for at least the morning or afternoon).

However, I’m not happy with the temperature control of my HP (Panasonic Aquara).

Ideally, I need to take available solar power, outside temperature (including forecast!), thermal mass and heat up delay into account to intelligently start and stop the heat pump (it doesn’t modulate perfectly).
For instance, on a sunny winter day (where outside temp is higher then at night, so COP is higher) we might want to heat up the home to setpoint+x degrees to allow it to coast the light the night accepting a setpoint-y minimum temp.
Hot water preparation planning would be a phase-2 step…

Can I tweak/use your integration for this as a starting point?

Thanks for your efforts!

8

Hi @JeeCee ! Thanks for the kind words and the detailed feedback. :raised_hands:

Your use case (Floor Heating + Heat Pump + Solar Optimization) matches perfectly with my long-term vision “Phase 4: Optimization beyond Comfort” (Dynamic Tariffs/PV-Integration), but I am not quite there yet.

Currently, I am heavily focused on finalizing v3.0 (“The Autonomous Brain”). The goal right now is to perfect the Learning Mechanisms (Detecting when you are home and learning the thermal properties of the house accurately). Until this core logic is rock-solid, I’m holding off on adding external optimization variables like energy prices or solar excess to avoid complexity explosion.

My recommendation for you right now:

I wouldn’t recommend forking/modifying the core code deeply at this moment, as the internal architecture is changing rapidly towards v3.0. However, you can already use the integration today effectively for 50% of your problem without any changes:

1. What works now (The “Stop” part): The Optimal Stop feature (Coast-to-Vacancy) does exactly what you described for the evening. If you overheat/boost your house during a sunny day (e.g., via a simple HA automation that raises the setpoint), this integration will automatically detect the excess heat. It calculates the coasting time based on your thermal mass and outside temperature forecast and will shut off the heating early (e.g., at 4 PM) while keeping the temperature above the minimum until your scheduled sleep time. It handles the “inertia” math for you.

2. What is missing (The “Start” part): For the “Sunny Winter Day” logic (deciding when to start overheating based on Solar/COP), I would suggest using standard Home Assistant automations for now. Let an automation boost the target temperature based on your solar production, and let this integration simply react to it.

Future (v4+): Once v3 is complete (Autonomous Pattern Recognition), “Optimization Providers” (like Solar/Tariff) are definitely on the roadmap to integrate this logic natively.

So, feel free to install it to get the Physics Models and Optimal Stop benefits today, but I’d suggest handling the “Solar Trigger” externally for now until we reach Phase 4! :blush:

9

Hi @spencerwebb189! GitHub Issues are definitely preferred for bug reports and specific feature requests – it helps me keep track of everything and ensures nothing gets lost in the forum thread.

For general questions, “how-to” discussions, or just sharing your experience, posting here in the thread is perfect!

Thanks for testing! :rocket:

1 Like
10

I’ve set this up for a couple of rooms to see what it would do in those. My evohome heating system does have similar in-built functionality so it would be interesting to compare. The pre-stop/start on evohome does seem to always kick-in at the maximum pre-start time which doesn’t seem ideal so this will be an interesting test.

It also won’t call for heat if the external temperature if external temps are similar to internal, they call it warm weather saver. Here’s the blurb… I presume this/MRT blueprint kind of replciate this functionality?

Warm Weather saver
automatically turns the boiler
off to save energy. As outside
temperature rise, the need for
heat reduces. This intelligently
limits low demand without
reducing comfort.
Cold Weather Boost is for rooms
that are less comfortable when
its cold, because draughts can
affect the comfort of a room.
When selected it automatically
adjusts the set point so the
normal temperature doesn’t
have to be as high.

11

Hello @spencerwebb189! That is a very interesting comparison. Evohome is often considered the “Gold Standard” for hardware controllers, but as you noticed, it tends to be very conservative (often simply triggering at the maximum configured pre-heat time to be “safe”).

Here is how Intelligent Preheating compares to those specific features:

1. Dynamic Start vs. “Max Start”

You hit the nail on the head. The primary goal of this integration is to solve exactly what you described with Evohome. Instead of guessing or using a fixed time, this integration Learns your room’s specific properties:

  • Thermal Mass: How fast does the room heat up?
  • Heat Loss: How fast does it cool down compared to the outside world?
  • Result: If your room only needs 25 minutes to reach temperature today, the integration will only start 25 minutes early. It constantly auto-corrects (if it was 2 minutes late today, it adds 2 minutes to the model for tomorrow).

2. Warm Weather Saver

We handle this natively via the Physics Model. The calculation considers both the Indoor Delta (how much to heat) and the Outdoor Delta (how much is leaking out).

  • If the weather is warm (Outdoor Temp ≈ Indoor Temp), the “Heat Loss” factor drops to zero.
  • If the room is already close to temperature (as is common in warm weather), the calculated “Required Duration” effectively becomes 0 minutes.
  • Result: The pre-heating simply doesn’t trigger, effectively acting as a warm weather saver.

3. Cold Weather Boost (The Difference)

This is where the approach differs slightly:

  • Evohome’s Approach: It automatically raises the Target Temperature (e.g., from 21°C to 22°C) to compensate for the “Chill Factor” (drafts from windows/walls making 21°C feel like 19°C).
  • Our Approach: We don’t touch your Target (Setpoint), but we compensate for the Feeling.
    • Virtual MRT sees the low outdoor temperature and calculates that the room will feel colder.
    • It compensates by giving you the operative temperature (or MRT to compensate) to fight that feeling.
    • Goal: We ensure the room actually feels 21°C, even if it’s -5°C outside.

Let us know how the comparison goes—real-world data is always the best test!

1 Like