2.9.7 — settings untranslated, controls greyed out, a device for the settings

Options dialog: the labels are back

Every field of the settings dialog showed its raw key (ip_address, port, ...). The fields live in sections, and Home Assistant looks a label up inside its section — options.step.init.sections.connection.data.ip_address — while the files only had a flat options.step.init.data block. The labels are now in their sections in English, German, French and Norwegian, and the missing strings.json was added.

The integration is called "Hansgrohe Pontos"

Home Assistant and HACS now show Hansgrohe Pontos. The domain stays pontos, so entity ids, unique ids, device registry entries and existing config entries are unaffected, and the config entry keeps the device name you entered.

Controls work again (clear alarms, profile selection)

The alarm button and the profile dropdown were permanently greyed out: they looked the sensor they mirror up in the entity registry, with a unique id that never matched the sensor's own id — and the button/select platforms are set up before the sensor platform anyway. They now read the value from the coordinator, and a sensor reference resolves by key or by name (the device configurations use both spellings). This also fixes the microleakage schedule, the microleakage time, the regeneration mode/interval/time and the buzzer controls, which used the same broken lookup.

A device for the settings

Each meter now creates a second device, "<device name> configuration", for its settings: the profile limits (volume, time, flow, return time), the microleakage schedule and time, the regeneration mode/interval/time and the buzzer. It is linked to the meter, so it shows up as a sub device of it; the buttons and the profile selection stay on the meter. Entity ids and unique ids are unchanged — the settings only moved to another device card.

Tooling

• New testing/check_translations.py derives the labels the flows, entities and services need from the code and fails when one is missing; it also fails when strings.json drifts from translations/en.json.
• The offline smoke test now asserts that every control is available, finds its sensor and lands on the expected device.

Verified

All five device families set up offline, create their entities, answer every service and unload: Pontos 53 entities / 22 controls, Trio 54 / 14, SafeTech+ 66 / 19, SafeTech+ old firmware 45 / 10, NeoSoft 51 / 7 — two devices each.

No Home Assistant runtime is available on this machine (2026.9 needs Python 3.14), so this is offline verification of the real code paths, not an end-to-end test with a device.

Full changelog: v2.9.6...v2.9.7

2.9.6

2.9.6 — setup failed, services deadlocked

Fixed

• Setup never completed: no entities were created. async_register_services stored a dict
  where a set was expected and raised
  AttributeError: 'dict' object has no attribute 'add' on every start. Home Assistant logged
  Error setting up entry Pontos for pontos and never reached the platforms, so the entry had no
  entities at all. This stayed hidden because the config flow could not create an entry before 2.9.4.
• Every service call deadlocked. The service handler called coordinator.async_refresh() while
  holding the command lock — the same lock the poller uses, and an asyncio.Lock is not reentrant.
  The command waited for itself forever and kept the lock, so polling stopped as well. The refresh now
  happens after the lock is released, and a command waits at most 30 s for a running poll before it is
  reported as device is still busy.
• Booleans were sent as True/False instead of the true/false the device expects, e.g.
  set/pa1/True, set/sld/True. They are now formatted correctly.

Added

• testing/offline_smoke.py — runs the real setup path without Home Assistant (stubbed imports,
  the simulated payloads): coordinator refresh, device registration, service registration, every
  platform, all entity properties, every service of a device type with the URL it builds, and unload,
  for all five device types.

  python3 testing/offline_smoke.py
  

  All three bugs above were found by it, not by a linter. Current result: 53 entities / 23 services for
  the Pontos Base, 54 entities for the Trio, 66 for the SafeTech+, 45 for the old SafeTech+ firmware
  and 51 for the NeoSoft, each with a clean unload.

Verified

• offline_smoke.py passes for every device type; the options form still receives all 14 stored
  values; all device URL lists and all service templates format.
• Endpoint names and values were checked against upstream's hardware-tested configurations and the
  documented command table (set/ab/false opens, set/ab/true closes, set/dex, set/ala/255,
  set/slp/{days}, set/sld/true, set/rmo/{mode}, set/buz/true).
• Still no Home Assistant runtime on this machine (2026.9 needs Python >= 3.14), so this is offline
  verification of the real code paths, not an end-to-end test with a device.

2.9.5

2.9.5 — the settings dialog showed no values

Fixed

• The settings dialog opened with empty fields. Home Assistant only fills the fields of a
  sectioned form when the suggested values are nested under the section name
  (add_suggested_values_to_schema copies a section's schema only if the section key is present).
  The options flow passed the values flat, so no field received the stored value: the dialog showed
  empty boxes and the first entry of the device-type list, and pressing Update wrote those empty
  values back.
  If you submitted that dialog on 2.9.3/2.9.4, check Create diagnostic entities and Enable control
  entities — they may be stored as off, which hides all diagnostic and control entities.
• The dialog now keeps what you typed when it has to be shown again after a validation error.
• Host names are accepted (e.g. pontos.fritz.box), not only IP literals — 2.9.3/2.9.4 rejected
  them with invalid IP address.
• Port, interval and timeout keep their integer values (2.9.4).

Added

• testing/diagnose.py — a dependency-free probe that talks to the device without Home Assistant and
  reports which device type answers, the HTTP status and the first payload keys. Run it when the
  integration reports cannot connect or shows no entities:

  python3 diagnose.py 192.168.1.100
  python3 diagnose.py pontos.fritz.box --make "SYR SafeTech+"
  

Verified

• The options form now receives all 14 stored values, checked against Home Assistant 2026.9.3's own
  add_suggested_values_to_schema; with the previous flat mapping 0 of 14 were filled.
• Every platform creates its entities for all five device types, using the payload of the bundled
  simulator.
• Still no Home Assistant runtime available here (2026.9 needs Python >= 3.14), so this is static and
  offline verification, not an end-to-end test.

2.9.4

2.9.4 — fix: the integration could not connect

Fixed

• Setup failed with "Failed to connect" — this was the blocking bug. The TCP port is now coerced to an integer before it is used in a device URL. The Home Assistant number selector always returns a float, so 2.9.3 requested
  http://<ip>:5333.0/pontos-base/... — a port that cannot exist — and every request failed.
• Polling with retries could raise TypeError — the retry count reached range() as a float.
• The settings dialog could not be opened — _make_schema() was called with an argument, raising TypeError in the options flow.
• The connection test no longer requires a payload key starting with get; any non-empty response is accepted and the device's answer is logged at debug level.
• configuration_url now shows the port without a trailing .0.
• __pycache__ and *.pyc are ignored repo-wide (24 bytecode files that slipped into an earlier commit were removed).

Upgrade

Nothing to do: update through HACS (or replace custom_components/pontos) and restart Home Assistant.

Already added the device with 2.9.3? No reconfiguration is needed — the stored port is corrected when read, so the integration connects on the next start.

Verified

• URL building, option coercion and both config/options schemas were executed against the real modules with stubbed Home Assistant imports (local Python 3.11 cannot run HA 2026.9, which requires 3.14).
• All five device configurations' URL lists and all service endpoint templates format correctly with an integer port.
• hassfest and the HACS validation pass on this commit.

2.9.3

2.9.3 — rename to pontos, HA 2026.9 fixes, new options and features

⚠️ Upgrade note

2.9.3 renames the integration domain from hass_pontos to pontos. Delete custom_components/hass_pontos before installing this version, restart Home Assistant and add the integration again — the setup dialog detects the old configuration and takes over IP, port, interval, device name and model automatically. The old config entry and its entities are removed, so entity ids stay the same and history/long-term statistics survive.

Rename

• integration domain, folder and manifest are now pontos
• the config flow imports an existing hass_pontos configuration
• documentation, services and manifests point at acdcnow/pontos

Bug fixes

• Setup — async_forward_entry_setups is awaited (the previous fire-and-forget could raise OperationNotAllowed and leave the platforms unloaded)
• Options — changing the options now reloads the entry (async_reload_entry was dead code)
• Services — services.yaml field names did not match the endpoint placeholders; calling a service from the UI raised KeyError: 'data'
• Services — the handler ignored entry_id and sent every command to all devices; services can now target a single device
• Polling — one failing endpoint discarded the data of all other endpoints; HTTP timeout and retry attempts/delay are configurable
• Sensors — numeric signals were reported as strings ("8,30", "268289"), which breaks the recorder and statistics
• Data quality — a negative or implausible cumulative volume poisoned the statistics; the last valid value is kept, the rejected raw value is exposed in the invalid_value attribute, and the sensor becomes unavailable after the configured tolerance
• Sensors — water_conductivity now has the conductivity device class; profile sensors are limited to the number the device reports (getPRN)
• Device — a missing serial/MAC no longer aborts setup, the MAC is validated, configuration_url and hw_version are set
• Translations — de/fr/nb used profile_name_* keys that did not match the entity translation keys

New options

connection (port, HTTP timeout, retry attempts/delay), polling interval, data quality (ignore implausible values, keep last valid value for n minutes, display unit L/m³), device name and model, diagnostic/control entity toggles, debug logging — grouped into sections in the UI.

New features

• number entities for the profile limits (volume, time, flow, return time) per profile
• binary sensors: leakage alarm, alarm/warning/notification active, wifi connected, microleakage test active
• self-study phase: start, delete, determined volume/time/flow, remaining time
• profile availability (PAx) and leakage warning (PWx) per profile, plus services
• network diagnostics: SSID, scan list, WLAN/LAN IP and gateway, MAC2
• alarm history attribute, profile count (PRN) and code number (CNO) sensors
• brand assets, MIT licence, info.md, updated README and endpoint coverage documentation

Repository

HACS validation: topics, issues and licence are fixed. Check Version now fails only on a lowered version or when the integration changed without a version bump.