Entities¶

This page lists the entity types exposed by the Dimplex Hub integration.

Entity names use Home Assistant’s has_entity_name pattern: the device is the appliance (or hub), and each entity has a short name such as “Room temperature” or “EcoStart”.

Climate¶

One climate entity per appliance.

Presets¶

A preset is a single, mutually exclusive state: selecting one engages what that preset owns and clears the others, so switching straight from away to eco works as you would expect. Why a preset cannot always show what the appliance is doing: Modes & presets.

Actions¶

• climate.set_temperature — writes the target through the cloud's dedicated setpoint endpoint, so your schedule is left intact. Appliances that reject it fall back to a schedule rewrite. See setting a target.
• climate.set_preset_mode — boost / away / eco / comfort.
• climate.turn_on / climate.turn_off — off engages frost protection and clears boost/away; on clears it again. See why "off" reports 7 °C.
• dimplex.set_advance / dimplex.clear_advance — skip forward to the next schedule period, bringing its setpoint on early.

Full field reference: Actions.

Climate (and most status entities) are unavailable when the cloud returns an empty appliance overview (common when heaters have not telemetered recently).

Sensors¶

Energy attributes¶

Energy data is daily kWh history from the cloud, not live watts. Sensors are unavailable (not 0) when there are no points, and T1 and T2 are never combined — they are separate dual-rate registers.

See Energy monitoring for adding these to the Energy Dashboard, the tariff mapping, and the automatic poll back-off when history stays empty.

Binary sensors¶

The appliance mode bitfield is also broken out as four diagnostic binary sensors — Boost active, Away active, Frost protection, Advance active.

These exist because the climate entity folds the whole bitfield into one preset, which is precisely what hid the mode mismatch behind #163: the integration asked for Boost and the heater engaged Advance, with nothing on the dashboard to say so.

Several bits can be set at once, so these four sensors can disagree with preset_mode — the sensors are the appliance's actual state and are the better thing to automate on. See Modes & presets for the whole model. A diagnostics download also lists the engaged modes by name.

Switches¶

Numbers¶

Created only for appliances whose capability matrix says both setback_read and setback_write — a write that could never be read back would leave the entity showing a stale number forever. The Setback binary sensor reports whether setback is currently engaged, and the Setback temperature sensor reports the same value read-only.

The range offered is the capability matrix's own 7-30 °C. That range is inferred from the app rather than measured — see appliance support.

Schedule¶

Diagnostic Schedule sensor per appliance. Its state is the timer mode — manual, user_timer, frost_protection or off — and its periods attribute lists the programme as day / start / end / temperature.

The sensor is read-only. The programme can be copied to other appliances, and one period's target edited, through actions — see edit the weekly schedule.

Zones¶

Zone devices appear in the device registry (via hub; appliances via zone when zone id is known). A disabled diagnostic zone sensor anchors each zone device.

Automations¶

Worked examples using these entities live in Automations & blueprints. The diagnostic mode sensors are usually a better trigger than preset_mode, because the appliance can hold several modes at once while the preset can only report one.