Skip to content

Upgrading

Restart Home Assistant after any HACS update. Notes are newest first; you only need to read the entries between your current version and the one you are moving to.

To 4.1.0

Behaviour fixes plus new control surface. Everything in the first list is a correction — if you were working around any of it, stop. The new entities and actions at the end change no existing configuration.

The declared Home Assistant floor is now 2026.9

Earlier releases claimed 2025.1 in hacs.json. That was wrong, not conservative: since the appliance-to-hub device links moved to the device-registry APIs introduced in Home Assistant 2026.8 (via_device_id and async_get_device_by_identifier), setting up the integration on an older release creates no entities at all. HACS will now hold the update back on Home Assistant below 2026.9 instead of offering an install that cannot work.

Check your Energy Dashboard if you used an \"Energy lifetime\" sensor

Those sensors were a rolling 30-day window declared total_increasing, so every time the window dipped by more than 10% — routine in spring and autumn — Home Assistant read it as a meter reset and added the whole 30-day total to long-term statistics again. Your dashboard may show considerably more energy than the heaters used.

They are renamed Energy last 30 days and now carry no state class, so Home Assistant will not offer them as a consumption source at all. Existing entities keep their old entity ID; only the display name changes. To clean up inflated history, go to Developer tools → Statistics, find the entity and delete its statistic. The Energy today sensors were always correct and need nothing.

  • Setting a target no longer rewrites your schedule. Writes go through the cloud's dedicated setpoint endpoint, with the old schedule rewrite kept only as a fallback for appliances that reject it. See setting a target.
  • HVAC off engages frost protection at 7 °C, which is how the official app turns a heater off. The entity will report a 7 °C target when off — this is correct. See why "off" reports 7 °C.
  • Boost and away actually engage the right modes. Earlier releases assumed boost was mode bit 16 and away bit 32; those are in fact Advance and FrostProtect. Asking for boost engaged advance instead. The corrected values are listed in Modes & presets.
  • Presets are mutually exclusive. Selecting one now clears the others, so switching straight from away to eco works. Previously each preset only added its own state, and because the entity resolves boost before away before EcoStart, the change appeared to do nothing.
  • Away is capped at 18 °C, the range the cloud actually accepts. Values above 18 are clamped with a log warning instead of being silently reduced.
  • Away accepts a duration — days or until.
  • Advance is controllable via dimplex.set_advance / dimplex.clear_advance.
  • Four new diagnostic sensors expose the engaged modes individually: boost, away, frost protection, advance.
  • A dropped connection can no longer wipe your schedule. The schedule-rewrite fallback now runs only when the appliance genuinely refuses the setpoint endpoint (HTTP 403, 405, 501). A timeout or a server error is reported as an error and writes nothing, and when the fallback does run it says so in the log. See setting a target.
  • Room temperature no longer shows 255 °C. The cloud's 0xFF "no value" sentinel was being passed through by the climate entity, while the room-temperature sensor beside it correctly showed nothing.
  • Failed switches and actions explain themselves. A refused EcoStart toggle or dimplex.set_boost used to surface a raw traceback; every control now produces the same readable message the thermostat has given since 4.0.2, and distinguishes "this appliance will not do this" from "the cloud was unreachable".

New entities and actions

New control surface; no configuration changes, and nothing existing is removed.

  • Controls are gated on the cloud's own capability matrix. The integration now fetches the account's product catalogue, so an appliance the library says cannot take a control no longer offers it — and the hot-water / heat-pump flags are derivable for the first time. An appliance affected by this gains or loses an entity it could not have used anyway; diagnostics list the resolved flags per appliance, which is the place to look if a control is missing.
  • Setback is writable. A new Setback target number entity per capable appliance writes the reduced temperature instead of only reporting it. See Entities.
  • The weekly schedule can be edited from Home Assistant, through two actions: dimplex.copy_schedule applies one appliance's programme to others, and dimplex.set_period_setpoint changes one period's target. See Actions.
  • Hot water cylinders have a control surface for the first time. Two actions, dimplex.set_hot_water_temperature and dimplex.set_hot_water_hygiene, plus a disabled-by-default diagnostic sensor. All of it is untested against real hardware — see appliance support.
  • The Boost preset's length now follows the appliance when the Boost duration option has never been set, instead of always using a fixed 60 minutes. If you set that option, nothing changes.

After upgrading

  • Confirm the config entry loaded without requirement errors in the log.
  • If you had automations working around boost engaging the wrong mode, remove the workaround.
  • If any appliance is stuck reporting off, toggle it on once — this restores user-timer mode on appliances an earlier release parked in the frost/off timer mode.
  • Enable the new mode binary sensors if you want them on a dashboard; they are diagnostic and off by default.
  • And if you have a hot water cylinder: enable its Hot water available diagnostic sensor and compare the number it shows against the official app. It is deliberately unitless because nothing documents what that field measures, so what it reports is genuinely useful — please say so on the issue rather than assuming.
  • If an Energy lifetime sensor was a consumption source, remove it, add Energy today instead, and delete the old statistic if the history looks inflated.

To 3.0.0

A major release relative to 2.0.0.

Breaking and behavioural changes

  • Climate entities are created per appliance. Prefer them for setpoints and for the boost / away / eco presets.
  • Energy became two sensors: Energy lifetime and Energy today (local calendar day from midnight). Prefer Energy today for the Energy Dashboard.

The "lifetime" half of that claim was wrong — it was still a 30-day window, and declaring it a rising meter is what corrupted statistics. Corrected in 4.1.0, where it is named Energy last 30 days and carries no state class; see the 4.1.0 notes above.

  • Entity unique IDs and names may change. EcoStart gained a stable _ecostart suffix, and open-window detection became a switch as well as a binary sensor. Expect some renamed entities and a one-off orphan cleanup.
  • Polling is split into a short status interval and a longer energy interval, both configurable in options.
  • Diagnostic entities — error and warning codes, last telemetry, rated power, charge capacity, Energy T2 — exist but are disabled by default. Enable them in the entity registry if you need them.

After upgrading

  • Confirm the config entry is loaded, with no import or requirement errors in the log.
  • Review the new climate.* entities and the energy sensors.
  • Re-point automations that used old entity IDs.
  • For the Energy Dashboard use Energy today. (In 4.1.0 the window sensors can no longer be selected as a consumption source at all.)

Requirements

Any recent version needs:

If an upgrade goes wrong

Full detail for every release is in the changelog.