Modes & presets¶

Almost everything confusing about this integration follows from one fact:

That mismatch is why #163 needed a decompiler to diagnose: the integration asked for boost, the appliance engaged advance, and the dashboard had no way to say so.

What the appliance reports¶

The full bitfield, as recovered from the official app. The integration reads four of these and ignores the rest.

How it maps into Home Assistant¶

flowchart LR
    subgraph AP["Appliance — ApplianceModes bitfield"]
        direction TB
        B["BOOST (2)"]
        A["AWAY (4)"]
        AD["ADVANCE (16)"]
        F["FROST_PROTECT (32)"]
    end

    subgraph ES["Separate setting"]
        E["EcoStartEnabled"]
    end

    subgraph HA["Home Assistant"]
        direction TB
        HM["hvac_mode<br/>heat / off"]
        PM["preset_mode<br/>one value only"]
        BS["4 diagnostic sensors<br/>one per bit"]
    end

    F --> HM
    B --> PM
    A --> PM
    E --> PM
    B --> BS
    A --> BS
    AD --> BS
    F --> BS

    AD -. "not represented<br/>in preset_mode" .-> PM

The four diagnostic sensors are the lossless view. preset_mode is the convenient one.

Why preset_mode can disagree with reality¶

The entity resolves the bitfield to a single preset in a fixed order, and stops at the first match:

1. Frost protection engaged, or the timer is in a frost/off mode → no preset, and hvac_mode is off
2. BOOST set → boost
3. AWAY set → away
4. EcoStartEnabled → eco
5. Otherwise → comfort

So an appliance holding both boost and away reports boost, and one holding advance reports comfort — because advance has no preset of its own. Neither is a bug in the reporting; there is simply nowhere for the second value to go.

Automate on the diagnostic sensors, not on preset_mode, whenever you care about a specific mode:

triggers:
  - trigger: state
    entity_id: binary_sensor.living_room_advance_active
    to: "on"

Setting a preset clears the others¶

Home Assistant treats a preset as a single mutually exclusive state, so selecting one engages exactly what that preset owns and clears the rest.

Clearing happens before engaging, so the appliance never briefly holds two conflicting modes.

Before 4.1.0 each preset only added its own state. Switching from away to eco enabled EcoStart but left away engaged, and because the resolution order above puts away ahead of EcoStart, the entity kept reporting away and nothing appeared to happen — that was #173.

Presets are also gated by appliance capability: one your appliance does not support is not offered in preset_modes and is skipped rather than sent blindly.

Temperature range per mode¶

The ranges genuinely differ, and only one is exposed as a climate limit.

Away is the one that surprises people: 18 is the ceiling in the official app's Away picker too, and the cloud silently reduces anything higher. See #174.

Which modes stack¶

• Frost protection wins over everything. It is the app's "off", and while it is engaged the integration reports hvac_mode: off and no preset, whatever else is set.
• Boost and away can both be set at the appliance. The integration will not put them there — presets clear each other — but a change made in the official app can, and the diagnostic sensors will show it.
• Advance stacks with anything. It affects the next schedule period, so it coexists with whatever is happening now.
• EcoStart is orthogonal. It is a separate boolean, not a bit in this field, so it can be on alongside any mode.

Timer modes are a different field¶

TimerMode is a small enum, not part of the bitfield, and it says how the appliance treats its schedule:

The integration exposes this as the diagnostic Schedule sensor, and treats modes 2 and 3 as "off" for hvac_mode, because that is how the official app presents them for most heaters. Turning a heater back on restores USER_TIMER for appliances an earlier release left parked in mode 2 or 3.

"Off" is frost protection¶

There is no off mode. Turning a Dimplex appliance off, in the official app or here, engages frost protection at 7 °C — an anti-freeze floor that stops rooms and pipework freezing.

So after climate.turn_off the entity reports a 7 °C target, hvac_mode: off and hvac_action: off. That is correct. Full detail in why "off" reports 7 °C.

The eco preset is not Eco mode¶

Two different things share the name, and the integration uses only one of them.

The eco preset drives EcoStart. The cloud's separate Eco mode bit is read but never written and has no entity, because its behaviour on real hardware has not been established.

This ambiguity is worth knowing about precisely because the new mode sensors sit next to a preset called eco that has nothing to do with the ECO bit.

Seeing the real state¶

Three ways, in increasing detail:

1. The four diagnostic binary sensors — boost, away, frost protection, advance. Disabled by default; enable them in the entity registry.
2. A diagnostics download — decodes ApplianceModes into mode names, so you do not have to do the arithmetic. See diagnostics & bug reports.
3. The raw value — ApplianceModes appears in diagnostics as an integer. 8198 is BOOST | AWAY | NORMAL (2 + 4 + 8192)… which is exactly the sort of sum nobody should have to do by hand, hence the decoding above.

Next¶

• Temperature & schedules — how a setpoint write reaches the appliance
• Actions — boost, away and advance with their fields
• Entities — the diagnostic mode sensors
• Automations — triggering on the real mode