The control screen

The control screen

One unit per screen — swipe left/right to switch. Each unit fills the screen, no scrolling, tinted to the active mode.

• Temperature — a big readout with a stepped slider (0.5° steps) and − / + buttons on each side for single steps.
• Indoor / outdoor — I: 27.0 °C / O: 33.0 °C when the unit has an outdoor probe, above a bar showing how the three temperatures relate. See the temperature bar below.
• Mode — a colourful segmented picker: auto · cool · dry · heat · fan.
• Fan — a Low→High slider that detaches to Auto.
• Flap — one big pill split in two, vertical and horizontal, each toggled on its own: neither, either, or both.
• Eco / Turbo — large, colourful switches.
• Power — a big switch in the header: faintly red when off, faintly green when on, so the unit's state is never in doubt.

How it stays in sync

Every change is optimistic with haptic feedback: it reflects instantly, then reconciles with the server. The screen never flickers while refreshing — state merges in place, and a small indicator appears only while you have triggered a command.

On Breeze Core ≥ 3.0.0 the app receives live updates over SSE, so the server pushes changes — including ones made by a schedule or another client — and the phone stops polling. Against an older server, or if the stream drops, it falls back to a 5-second poll and retries. An offline banner appears with backed-off polling when the server is unreachable.

The app reopens on the unit you last viewed, remembered by unit rather than by position, so it survives adding, removing or reordering units.

Haptics

Feedback is named by meaning rather than intensity, so it stays consistent as things get added:

	when
tick	a notch moved — temperature ±, a slider detent, swiping to another unit
select	a setting chosen — mode, fan, a flap half, eco/turbo
toggle	power on/off, deliberately the heaviest: the one action with a physical result you might be across the room from
success / failure	pairing accepted, or a rejected key — failure is two beats, so it is distinguishable without looking

The temperature slider ticks only when the value crosses a notch, not on every pixel of the drag.

The temperature bar

Your units report an outdoor temperature and the app used to throw it away. The bar could be described as three separate behaviours, which is how such things drift apart, so it is implemented as one rule:

The warmest of indoor / outdoor / target sets the top of the scale. The other two are drawn from the floor as overlapping fills — the warmer of them lighter, the cooler darker on top.

• Cooling (outdoor 33, indoor 27, target 24) — outdoor is the ceiling, indoor the lighter fill, target the darkest.
• Heating (outdoor 5, indoor 20, target 23) — the target becomes the ceiling and the outdoor reading the darkest fill.
• Indoor below target — the shades swap by themselves, because warmer is always lighter. No special case.

A temperature sensor has many ways to lie, and each of these is covered by a test:

• A unit without an outdoor probe may report a sentinel rather than null, so anything outside −50…80 °C is treated as missing. A bar scaled to 255 °C renders as an empty sliver with no clue why.
• NaN and infinities are dropped the same way.
• Below-zero outdoors extend the scale floor beneath 0 °C rather than clamping the reading to nothing, which would look like a dead sensor every winter.
• Fewer than two real readings is not a relationship: the numbers still show, the bar does not.
• Two readings draw a single full-strength fill; the pale shade only makes sense with something darker on it.
• Identical readings still get a 1 °C span, so nothing divides by zero.
• Genuine extremes are kept — 45 °C on a sun-baked outdoor unit and −30 °C in a real winter are weather, not faults.

Geometry is computed in Celsius whatever the display unit, so °F users see identical proportions.