Appliance support¶

This page says plainly what is verified against real hardware, what is inferred from reading the official app, and what is untested. The underlying library does the same in its decompiled API reference, and it matters here for the same reason: an untested feature that looks supported wastes somebody's evening.

The integration is developed against the hardware its authors and reporters own. Nobody has access to the full Dimplex range.

By family¶

If you own something in the untested rows and are willing to try it, say so on an issue — a diagnostics download alone is genuinely useful.

Quantum and other storage heaters¶

Charge-based heaters store heat overnight at the cheap rate and release it during the day. Two consequences that repeatedly confuse people:

A target does nothing until there is stored charge. Set 22 °C at midday on a heater that has exhausted its charge and nothing observable happens — not because the write failed, but because there is no heat to release. Two of the tests in #163 came back inconclusive for exactly this reason.

Some units reject remote writes. SetApplianceSetpointTemperature and SetTimerMode can come back HTTP 403. The integration handles this:

• Setpoint writes fall back to the older schedule-rewrite path, so you keep the capability.
• If that is refused too, you get a readable error naming the appliance rather than a generic "unknown error" — this was #149.

When comparing behaviour, compare against the official app at the same moment, not against what a panel heater would do.

Hot water cylinders¶

The library implements the hot water surface — read state, set target, schedules, hygiene — and every endpoint is confirmed from the official app. None of it has been run against hardware, so this is what the integration does with it:

• A Hot water available diagnostic sensor, disabled by default, reading the cloud's AvailableHotWater. It has no unit: that field is a bare number and nothing in the app or the API reference says whether it is °C, litres or a percentage. Turn it on and tell us what it shows.
• Two actions, dimplex.set_hot_water_temperature and dimplex.set_hot_water_hygiene, gated on the hot_water and hygiene flags.
• No number or select entity, deliberately. Nothing reads the normal, boost or hygiene values back, so such an entity could be set and could never show what it was actually set to — worse than no entity.
• The capability matrix marks cylinder-only appliances as climate: false, so they get no thermostat and no advance (there is no "next comfort period" to jump to).
• Library callers can reach the endpoints directly and are warned in every docstring.

How capabilities are decided¶

The matrix resolves the flags from four sources, in increasing specificity:

flowchart TB
    T["Type / model / name tokens<br/>quantum · storage · qrad · charge<br/>cylinder · dhw · hotwater<br/>ashw · heatpump"]
    P["Product catalogue row<br/>GET /Appliances/GetProductModels"]
    A["AUTOMATIC_PROVISIONING<br/>charge_capacity · rated_power"]
    S["Live status fields<br/>BoostTemperature · AwayDateTime<br/>AvailableHotWater · RoomTemperature"]
    C["Capability flags"]

    T --> C
    P --> C
    A --> C
    S --> C

The catalogue is fetched once per account and matched to each appliance on its model, then its type. It carries the AUTOMATIC_PROVISIONING metadata — and it is the only place storage, energy_meter, hot_water and heat_pump come from, which is why the integration calls it rather than guessing from the appliance's own name. An account whose catalogue cannot be read falls back to the type tokens and is retried on the next poll.

• charge_capacity > 0, or a storage-ish token → storage
• rated_power > 0, or a storage-ish token → energy meter
• a cylinder token, or AvailableHotWater present → hot water, and climate: false unless a room temperature also appears
• an ashw / heat-pump token → heat pump (and hot water)

Control flags — boost, away, advance, open window, EcoStart, frost, timer, setpoint writes — default to enabled. That is deliberate: the cloud exposes these generically, and guessing "unsupported" would lock people out of endpoints that work. The cost is that an unsupported call fails at the cloud rather than being hidden, which is why control errors are surfaced with a readable message.

Your appliance's resolved flags are in a diagnostics download under capabilities.

Confirmed but deliberately not exposed¶

SetSetbackTemperature used to be on this list. It is now written by the setback target number entity, gated on the capability matrix's setback_write — treated as inferred from the app until someone confirms it against a real appliance.

Schedule writes are exposed as two actions rather than a full editor — copy a schedule and edit one period. Creating, deleting or reordering periods still needs the official app.

Temperature ranges¶

Only two are confirmed:

Away turning out to be an exception means the 7–30 figures should not be fully trusted. dimplex-controller-py#98 tracks re-reading each mode's range.

Next¶

• Modes & presets — what each mode does
• Diagnostics — see your own appliance's resolved capabilities
• Troubleshooting