Predictive Advisor
The Predictive Advisor is a strictly read-only analysis and recommendation layer for your heat pump. It observes the measured data, learns how your plant behaves and turns that into explainable recommendations — it never changes anything on the heat pump by itself.
The Navigator controller remains the leading regulator at all times. The advisor advises; every change to the plant is your explicit action on the regular control entities.
The advisor is part of the Smart Energy and Comfort profile. It works entirely locally; no data leaves your Home Assistant.
Enable, disable and what it needs
- Where: integration → Configure → Presentation and additional features → Enable predictive advisor (also part of the guided setup as its own page). On by default with the Smart Energy & Comfort profile.
- Turning it off removes every
advisor_*entity after a reload; the collected statistics are kept and return when you re-enable it. - No AI required. Everything is deterministic statistics — baselines, regressions and window searches — computed locally on your Home Assistant. It does not use, need or offer any cloud or LLM. The Experimental AI plant adviser is a completely separate feature; the predictive advisor works without it.
- Optional inputs: a weather entity (already used by the weather advice), a PV forecast sensor and a dynamic electricity price sensor. Every one of them is optional — missing inputs simply disable the affected recommendation, nothing is invented.
After installing an update you will find a one-time notice in Settings → Repairs ("What's new since 0.20.1") summarizing what was added — dismiss it there once you have seen it. It appears exactly once per installed update: never on a fresh installation, never again on restarts or reloads, and only again when the next update is installed.
Room temperature without a wired sensor
Circuits that have no room sensor wired to the Navigator report
uninitialized memory on the hc_x_room_temp register (observed as
-327.33 on a Navigator 2.0, #504). The advisor
ignores such values. If the integration options enable the predictive
advisor, the options walk offers one read-only Home Assistant
temperature sensor per heating circuit as the advisor's room temperature
source. Nothing is written to the heat pump; the sensor value feeds the
advisor's models, data quality and capability detection under the same
plausibility range (0-50 °C) as the register. A configured source that
is unavailable counts as an unavailable sample - it never falls back to
the garbage register value.
Entities
Shared evidence and optimization review
The Predictive Advisor, measurement reports and local Assist share one numerical history and the same period comparisons. The history collects while either the Predictive Advisor or experimental AI adviser is enabled; it needs no model or cloud provider. It retains up to 28 days, capped independently at 4 MiB by removing the oldest details. Collection stops on disable/reload; stored data is retained. There is no Recorder backfill, and existing AI report history remains separate.
- Advisor changes (
advisor_changes) counts changed comparison metrics; attributes explain energy, COP, compressor starts, DHW operating-time share, room deviation, weather context and missing evidence. Unknown means a suitable comparison is unavailable; zero means no marked change in comparable windows. - Advisor optimization review (
advisor_optimization_review) records observed heating-curve readback changes and evaluates the latest stable change. This cannot establish who made a change or whether it was manual. It never writes. - Recommendation attributes include localized observations, supporting reasons, current/suggested values, confidence interpretation, missing evidence and a first check. Confidence is not a probability that the plant has a defect.
- Since 0.27.0-b1 the recommendation titles are localized too: the sensor
attributes and local Assist render them in German or English following the
Home Assistant language, with German decimal commas. The
titlefield itself stays the documented English data field — events, stored records and diagnostics remain language-independent, and recommendations persisted before the update keep working and render their stored title. - Regenerate the plant dashboard to add the available Advisor view and explanation cards. Existing dashboards are not modified automatically.
Review needs 72 hours before the change and 72 hours after a six-hour settling period. Both windows need at least 80% observed energy-counter coverage. Only pure heating intervals are compared within two-degree outdoor-temperature bins: at least six matched hours and 60% matching of the larger heating history are required. Changed room targets, missing comfort readings or overlapping changes leave the result open. A COP difference of at least 5% is reported as an observed change; worsening absolute room deviation by more than 0.3 K or increasing starts by more than both 0.2 per hour and 20% prevents a simple improvement verdict. These are conservative descriptive thresholds, not statistical significance or proof of cause. Other influences such as occupancy and solar gains remain unknown.
Assist examples: What changed?, Why is consumption higher?, How is cycling developing?, What data is missing?, Did it help?. The last question reviews the latest recorded heating-curve change; it does not change settings or acknowledge a recommendation as applied.
Mapped room sensors are converted from Fahrenheit or Kelvin to Celsius before quality checks and model fitting; a missing unit retains the Celsius assumption. Unavailable or mismatched mapped sources do not fall back to register values. Failed coordinator updates break learning intervals instead of repeating cached measurements. Only exact heating or hot-water modes feed dedicated COP domains.
Operating explanations prioritize explicit controller demand over temperature inferences. A cool DHW tank alone does not override reported heating operation, and a tank already above target is described accordingly.
The 24-hour heat-demand estimate requires 24 distinct consecutive forecast hours; short or gapped forecasts do not produce a full-day estimate. Warm hours cannot cancel heating demand in cold hours. PV period energy is split at hour boundaries and duplicate timestamps are counted once. PV recommendations describe forecast generation, not confirmed surplus after household consumption.
The local Assist agent uses these corrected operation explanations. It accepts subzero outdoor temperatures, identifies instantaneous COP explicitly, and does not claim a fault-free plant when alarm readings are missing. Failed updates produce an unavailable-state explanation instead of cached live values.
All entities appear under the Smart profile and become meaningful as the advisor collects data. Sensors that depend on not-yet-learned models stay unavailable instead of guessing.
| Entity | Meaning |
|---|---|
sensor.<device>_advisor_status |
Observation stage: Collecting data (day 1), Early hints (days 1–7), Recommending (from day 7), Established (from day 30). Attributes show detected plant capabilities, data quality and the current confidence |
sensor.<device>_advisor_recommendations |
Number of active recommendations; each one is published with its full explanation (reasons, values, confidence) as an attribute |
sensor.<device>_advisor_confidence |
Framework confidence in percent with its level |
sensor.<device>_advisor_operation_reason |
Why the heat pump runs right now (PV surplus, hot water, a requesting heating circuit, controller demand reason), with the numbers behind it |
binary_sensor.<device>_advisor_anomaly_detected |
On while an anomaly recommendation is active |
sensor.<device>_advisor_health_score |
Plant health 0–100 from documented components (hydraulics, compressor, hot water, efficiency); each component exists only with baseline data |
sensor.<device>_advisor_expected_cop / advisor_efficiency_score |
COP the learned outdoor/flow map expects at the current operating point, and how the observed 7-day heating COP compares (the observed hot-water COP of the same window is published as an attribute; mixed or defrost intervals stay out of both per-mode values) |
sensor.<device>_advisor_building_heat_loss |
Building heat loss in W/K from the thermal-power regression |
sensor.<device>_advisor_building_thermal_inertia |
Effective heat capacity (kWh/K) from observed cooldown episodes |
sensor.<device>_advisor_optimal_flow_temp |
Flow temperature the learned curve produced at the current outdoor temperature while rooms held their setpoint |
sensor.<device>_advisor_hc_X_curve_recommendation |
Heating-curve recommendation per circuit — at most one documented 0.02 step at a time, only after 7 baseline days of room-temperature deviation |
sensor.<device>_advisor_dhw_recommendation |
Best hot-water charging window from the PV forecast (preferred) or the cheapest heat cost (price ÷ expected COP — the observed 7-day hot-water COP when available). Window times are shown in your Home Assistant time zone; the stored timestamps stay UTC |
sensor.<device>_advisor_predicted_heat_demand |
Predicted thermal demand for the next 24 hours (heat loss × forecast temperature difference) |
sensor.<device>_advisor_next_24h |
The joined plan: expected PV, expensive hours, and a conflict warning when the hot-water window overlaps them |
binary_sensor.<device>_advisor_optimization_available |
On while at least one unhandled recommendation is active |
Where the external inputs come from
- Weather: the existing Weather entity option (hourly forecast via
weather.get_forecasts). - PV forecast: optional sensor in the options
(Predictive advisor PV forecast sensor (optional)). The field may be
left empty — the advisor works fully without it; the sensor is only the
basis for the PV-based hot-water window recommendations. PVForecast-style
detailed_forecastattributes and Solcast-styleforecastlists are understood, and a sensor of the core Forecast.Solar integration is read through itsget_forecastservice (hourlywh_period) — its own sensors carry no hourly attributes. - Electricity price: the existing Dynamic electricity price sensor
option; future hourly prices are read from common attribute shapes
(
today/tomorrow/data/priceslists).
Missing or unparsable inputs leave the affected recommendation out — the advisor never falls back to invented numbers.
Events
Every new, changed or acknowledged recommendation fires an
idm_advisor_recommendation event you can use in automations:
event_type: idm_advisor_recommendation
data:
action: new # new | updated | status
id: heating_curve_a_20261007
category: heating_curve
severity: info
confidence: 0.91
confidence_level: very_high
current_value: 0.35
recommended_value: 0.32
reasons:
- room_temperature_above_target
- flow_temperature_above_estimated_requirement
How confidence works
Each recommendation carries a confidence value with four levels — low, medium, high, very high — instead of pseudo-exact percentages. The score is a documented formula: 60 % observation coverage (complete after 14 days) plus 40 % share of usable samples. Bad data (unavailable, implausible or frozen sensors) lowers the confidence instead of producing recommendations.
Data quality
Before anything is analyzed, every input is classified sample by sample: unavailable, implausible (outside the documented range), frozen (a nonzero power or flow reading that has not moved for three hours) or usable. Recommendations are never built on bad data.
Building-model learning
Heat loss and optimal flow temperature learn only during exclusive space
heating (hp_operating_mode == 1) with an actively heating circuit. An explicit
circuit active mode must be heating; if it is absent, a positive circuit flow
setpoint is required. DHW, cooling, defrost, mixed or unknown modes and inactive
circuits cannot feed these regressions. Heat loss uses a room temperature from
an active heating circuit. General operating metrics and COP learning continue
independently.
After upgrading from the earlier learning logic, the heat-loss and flow-curve regressions and their derived thermal-capacity estimate restart once: old aggregates cannot distinguish space heating from DHW. Those sensors remain unavailable until enough new heating samples exist. Other analytics, including daily baselines, COP data and cooldown observations, are preserved.
What the advisor will never do
- Change setpoints, heating curves, modes, schedules or power limits
- Activate PV boost or priority charging on its own
- Write registers, coils or web settings
- "Apply" a recommendation without your explicit confirmation
Accepting a recommendation in a future UI records only that you consider it sensible. Applying a value remains a separate, confirmed user action, with the previous value journalled so it can be restored.