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 → no preset, and hvac_mode is off. The live bitfield is authoritative: a cached off-like timer schedule no longer forces off while the appliance reports a live mode. The schedule is only consulted when the appliance reports no modes at all.
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. An off-like TimerMode (2 or 3) counts as "off" for hvac_mode only when the appliance reports no live modes at all — with a bitfield present, the bits win, so a heater the app shows as Manual is heat even while its cached schedule still says frost. Turning a heater back on restores USER_TIMER, but only for appliances that report no live mode bits: rewriting the schedule over a live Manual hold is what kept converting Manual heaters to user timers.

The sensor always shows the active profile's periods, but periods refresh on a fifteen-minute cadence (plus immediately after a profile change or a Home Assistant-side edit). Editing the same profile's periods in the official app can therefore take up to fifteen minutes to appear here — the state name updates on the next status poll, while the period list waits out the cache.

The bit-64 probe¶

QRAD firmware 28 reports ApplianceModes: 64 (ECO) while the official app shows the heater as Manual, with the setpoint behaving as a manual hold. The library maps 64 to ECO and 128 to MANUAL, and the integration follows the library rather than special-casing 64 in code: the Operating mode sensor reports the raw integer and the flag names faithfully, and the operating-mode select maps only 128 to manual.

If you can test what bit 64 actually drives on real hardware — whether it heats like Manual, follows a schedule, or does something else — that result belongs here and in #273, and only then should the mapping change.

"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: the operating-mode select deliberately does not offer it, because its behaviour on real hardware has not been established — see the bit-64 probe.

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¶

Four ways, in increasing detail:

1. The Operating mode sensor — the live bitfield decoded to flag names, with the raw integer alongside. The lossless view that never guesses.
2. The four diagnostic binary sensors — boost, away, frost protection, advance. Disabled by default; enable them in the entity registry.
3. A diagnostics download — decodes ApplianceModes into mode names, so you do not have to do the arithmetic. See diagnostics & bug reports.
4. 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