docs: release 2.2.0 - single zone device, updated README, info, SDD, ADD and workflows

README: 2.2.0 release block (zone entities on one device, entity ids unchanged, retired devices cleaned up). info.md: features, device registry section and the wizard order (the real order is connection -> areas -> outputs -> zones, all zones on one page), plus a 2.2.0 changelog entry. SDD: version/status and the device layout and alignment sections for the single device. ADD: front matter on master/2.2.0, entry_id in the runtime data, and a new DEC-7 recording why all zone entities live on one device. WORKFLOWS: branch/version on master and a release flow without the retired dev branch. manifest 2.2.0.

Author: acdcnow

CHANGELOG.md

@@ -1,8 +1,9 @@
 # Changelog
 
-## [2.2.0-beta.1] - 2026-10-10
+## [2.2.0] - 2026-10-10
 
-> ⚠️ **Pre-release - enable *Show beta versions* in HACS to test it.**
+The promotion of `2.2.0-beta.1` to stable - same behaviour, no configuration change. The beta was
+published for testing and is superseded by this release.
 
 **All zone entities now live on one device** (`Crow Alarm Sensors`) instead of one device per zone
 type. Home Assistant links an entity to a device only when it is registered for the very first time,

README.md

@@ -8,11 +8,13 @@ This is a custom integration for **Home Assistant** to control **Crow Runner**,
 
 Unlike previous solutions, this integration uses a **direct local TCP implementation** (the driver is vendored inside the integration, so no external Python dependency is installed) to ensure robust connection handling, specific command sequences (`Code` -> `Command` -> `Enter`), and accurate status parsing.
 
-> **Current release: `2.1.4`.** Targets Home Assistant 2026.9.3.
+> **Current release: `2.2.0`.** Targets Home Assistant 2026.9.3.
 > Users on Home Assistant 2026.8 or older should stay on `2.0.0`.
-> The `2.1.0-beta.1` / `2.1.0-beta.2` pre-releases are superseded - update to `2.1.4`
+> `2.2.0` reworks the zone devices: **all zone entities now live on one device**
+> (*Crow Alarm Sensors*) and the retired per-type devices are cleaned up automatically.
+> Existing entity ids are left untouched, so no dashboard or automation needs editing.
+> The `2.1.0-beta.*` and `2.2.0-beta.1` pre-releases are superseded - update to `2.2.0`
 > (HACS shows it without enabling *Show beta versions*).
-> `2.2.0-beta.1` is available for testing with *Show beta versions* enabled.
 
 ## ✅ Requirements
 

custom_components/crowipmodule/manifest.json

@@ -9,5 +9,5 @@
   "integration_type": "hub",
   "iot_class": "local_push",
   "issue_tracker": "https://github.com/acdcnow/Crow-AAP-Alarm-System-for-Home-Assistant/issues",
-  "version": "2.2.0-beta.1"
+  "version": "2.2.0"
 }

docs/ADD.md

@@ -2,10 +2,10 @@
 
 **Project:** Crow/AAP Alarm IP Module for Home Assistant
 **Integration domain:** `crowipmodule`
-**Branch:** `HA2026_09_dev`
-**Version:** `2.1.0-beta.1`
-**Status:** Pre-release, implementation complete
-**Last updated:** 2026-09-21
+**Branch:** `master`
+**Version:** `2.2.0`
+**Status:** Released
+**Last updated:** 2026-10-10
 
 ---
 
@@ -49,7 +49,7 @@ Out of scope:
 | G3 | Stay usable when the panel or network is unavailable | Availability driven by real connection state; supervised reconnect with backoff |
 | G4 | Report every panel signal the protocol exposes | 16 zones, 2 areas, 8 outputs, 21 system statuses |
 | G5 | Be diagnosable from a user's Home Assistant instance | Downloadable diagnostics with redaction, plus a "System Status" text sensor |
-| G6 | Present as a first-class integration | Local `brand/` assets, UI config flow, 5 translations, device registry grouping |
+| G6 | Present as a first-class integration | Local `brand/` assets, UI config flow, 5 translations, device registry (hub + one zone device) |
 
 ### 2.2 Non-goals
 
@@ -184,15 +184,17 @@ untyped, unnamespaced, and leaks if a platform fails to unload.
 @dataclass
 class CrowRuntimeData:
     controller: CrowIPAlarmPanel
+    entry_id: str | None = None    # config entry id, to scope registry lookups
     device_id: str | None = None   # device registry id of the hub, for via_device_id
     firmware: str | None = None    # "<version> (<date>)", for sw_version
 ```
 
 **Consequences.**
 
-* ✔ Lifetime is tied to the entry; unload cannot leak.
-* ✔ One object carries every shared dependency, so platform setup is a single attribute read.
-* ✔ `device_id` gives the zone sub-devices a valid `via_device_id` (see DEC-5).
+* ✔ Lifetime is tied to the entry; unload cannot leak.
+* ✔ One object carries every shared dependency, so platform setup is a single attribute read.
+* ✔ `device_id` gives the zone sub-devices a valid `via_device_id` (see DEC-5).
+* ✔ `entry_id` scopes the entity-registry lookups of the zone alignment (see DEC-7).
 
 ### 5.5 DEC-5 — Register the hub device before forwarding platforms
 
@@ -226,7 +228,33 @@ drops and recover on reconnect.
 * ✔ Users and automations can distinguish "disarmed" from "unknown".
 * ✔ `Diagnostics` and the System Status sensor expose `connected` explicitly.
 * ✘ A brief network blip marks entities unavailable, which some automations treat as a state change.
+### 5.7 DEC-7 — One device for all zone entities
+
+**Context.** Releases 2.1.x gave every zone type its own device (*Crow Alarm Windows*, *Crow Alarm
+Doors*, *Crow Alarm Motion*, ...) so that the type became part of the entity name and entity id.
+That turned out to be a trap: Home Assistant links an entity to a device **only when the entity is
+registered for the very first time**. An entity created while a zone still had another type stayed on
+the device of that former type, and re-configuring the zone in the UI did not move it - the device
+list kept showing a door zone under *Windows* with no way to correct it from the UI.
+
+**Decision.** All zone entities are registered on the single *Crow Alarm Sensors* device
+(`const.IDENTIFIER_ZONE`). The zone type still selects the binary-sensor **device class** (the icon:
+door, window, motion, smoke, ...), but never the device. `binary_sensor._async_align_zone_entities()`
+re-links existing zone entities to that device on every setup, so an installation that has been
+through the split layout is corrected by a restart, and
+`_remove_retired_zone_devices()` deletes the retired per-type devices once nothing is registered on
+them.
 
+**Consequences.**
+
+* ✔ There is no second device left for a zone to be stuck on, whatever order zones were configured
+  or re-typed in.
+* ✔ Entity ids are never rewritten by the integration: they are stable handles for dashboards and
+  automations, and a zone that keeps its id keeps working after the move.
+* ✘ An entity id may still name a device the entity no longer hangs off
+  (`binary_sensor.crow_alarm_windows_terrassentur` on *Crow Alarm Sensors*). That is cosmetic; the
+  diagnostics `zone_registry` report shows the real device link.
+* ✘ The type is no longer visible in the device name, so the icon and the entity name carry it.
 ---
 
 ## 6. Runtime view
@@ -347,7 +375,7 @@ Verified against the real 2026.9.3 sources; each row is asserted by
 ```
 <config>/custom_components/crowipmodule/
 ```
-Installed by HACS from GitHub release archive `2.1.0-beta.1` (or the branch), or copied manually.
+Installed by HACS from GitHub release archive `2.2.0` (or the branch), or copied manually.
 Home Assistant imports the package at startup; the config entry lives in
 `.storage/core.config_entries`, not in YAML. Per-entry runtime objects are constructed at setup and
 released at unload.

docs/SDD.md

@@ -2,7 +2,7 @@
 
 **Project:** Crow/AAP Alarm IP Module for Home Assistant
 **Integration domain:** `crowipmodule`
-**Branch:** `master` · **Version:** `2.2.0-beta.1` · **Status:** pre-release
+**Branch:** `master` · **Version:** `2.2.0` · **Status:** released
 **Last updated:** 2026-10-10
 
 This document specifies **how** the integration is built: modules, signatures, data shapes,

docs/WORKFLOWS.md

@@ -1,8 +1,8 @@
 # Workflows and Diagrams
 
 **Project:** Crow/AAP Alarm IP Module for Home Assistant
-**Branch:** `HA2026_09_dev` · **Version:** `2.1.0-beta.1`
-**Last updated:** 2026-09-21
+**Branch:** `master` · **Version:** `2.2.0`
+**Last updated:** 2026-10-10
 
 Every diagram below is **Mermaid**, so it renders natively on GitHub, in the wiki, and in any
 Mermaid-capable viewer. The narrative companion is the [ADD](ADD.md); the module-level detail is the
@@ -271,7 +271,7 @@ needs Python 3.14.2+.
 > **Important limitation.** GitDiagram analyses the repository's **default branch only**. At the time
 > of writing that is `master`, which still depends on the external `pycrowipmodule` package — the tool
 > said so itself: *"the external pycrowipmodule implementation was not provided."*
-> The diagram therefore describes the **legacy** architecture, not `HA2026_09_dev`.
+> The diagram therefore describes the **legacy** architecture, not `master`.
 
 Re-generate or explore it interactively at:
 **https://gitdiagram.com/acdcnow/crow-aap-alarm-system-for-home-assistant**
@@ -318,7 +318,7 @@ flowchart TD
     class CC legacy
 ```
 
-The same shape in the current (`HA2026_09_dev`) architecture, for comparison — the differences are
+The same shape in the current (`master`) architecture, for comparison — the differences are
 the local driver, the extra sensor/button platforms, `runtime_data`, the hub device and diagnostics:
 
 ```mermaid
@@ -349,12 +349,11 @@ Green nodes mark what the 2026.9 development branch added or changed.
 
 ```mermaid
 flowchart LR
-    Dev["Commit to<br/>HA2026_09_dev"] --> Ver{"All four<br/>checks pass"}
+    Dev["Commit to<br/>master"] --> Ver{"All four<br/>checks pass"}
     Ver -->|no| Dev
     Ver -->|yes| Bump["Bump manifest version<br/>and CHANGELOG"]
-    Bump --> Tag["Annotated tag<br/>no v prefix"]
-    Tag --> Push["Push branch and tag"]
-    Push --> Rel["GitHub pre-release<br/>with release notes"]
-    Rel --> HACS["HACS offers it<br/>when betas are enabled"]
-    Rel --> PR["PR stays open<br/>until promotion to stable"]
+    Bump --> Tag["Tag<br/>no v prefix"]
+    Tag --> Push["Push master and tag"]
+    Push --> Rel["GitHub release<br/>prerelease: true for a beta"]
+    Rel --> HACS["HACS offers it = tag<br/>(betas need Show beta versions)"]
 ```

info.md

@@ -6,12 +6,18 @@ It communicates directly with the IP module over the local network to provide re
 
 ## ✨ Features
 
-* **Config Flow:** Fully configurable via the Home Assistant UI (no YAML required).
+* **Config Flow:** Fully configurable via the Home Assistant UI (no YAML required). All zones are
+  configured in a single step - one name/type pair per zone.
 * **Alarm Control Panel:** Arm (Away/Stay), Disarm, and Trigger panic alarms for up to 2 Areas (Partitions).
-* **Zones:** Binary sensors for up to 16 zones (Motion, Door, Window, Smoke, etc.).
+* **Zones:** Binary sensors for up to 16 zones. The **type** you pick (Motion, Door, Window, Smoke, ...)
+  sets the icon and device class of the sensor and is selected from a translated dropdown.
 * **Outputs:** Control up to 2 switchable outputs (e.g., Garage Door, Gates).
 * **System Status:** Diagnostic sensors for Mains Power, Battery, Tamper, Phone Line, and Dialler status.
-* **Device Registry:** All entities are grouped under a single "Crow Alarm System" device.
+* **Device Registry:** every zone entity lives on the single **Crow Alarm Sensors** device; the panel
+  itself and the system status sensors live on **Crow Alarm System**. The per-type devices of older
+  releases (Windows, Doors, Motion, ...) are removed automatically once nothing is registered on them.
+* **Diagnostics:** *Download diagnostics* includes a per-zone report of the configured type and the
+  device the entity is really registered on.
 * **Dashboard:** a ready-to-use Lovelace dashboard with a standard and an expert view ships in [`dashboards/`](dashboards/README.md).
 
 ## 📋 Requirements
@@ -47,27 +53,27 @@ This integration uses a 4-step configuration wizard.
 
 ### The Setup Wizard
 
-* **Step 1: Areas**
+* **Step 1: Connection**
+* **IP Address:** The local IP of your alarm module.
+* **Port:** Usually `5002`.
+* Pick the firmware build, how the panel is armed, and how many areas / outputs / zones you have.
+
+
+* **Step 2: Areas**
 * Name your partitions (e.g., "House", "Garage").
 * (Optional) Enter a default code if you want to arm/disarm without typing it every time.
 
 
-* **Step 2: Switches (Outputs)**
+* **Step 3: Switches (Outputs)**
 * Name your controllable outputs (Output 3 & 4), e.g., "Garage Door".
 
 
-* **Step 3: Zones**
-* Name your 16 zones.
-* Select the type for each zone (Motion, Door, Window, Smoke, etc.) from the dropdown.
+* **Step 4: Zones**
+* All zones are on one page: name each zone and pick its type (Motion, Door, Window, Smoke, ...).
+* The type sets the sensor icon; it does not decide which device the sensor lives on.
 * *Tip: Leave unused zones empty.*
 
 
-* **Step 4: Connection**
-* **IP Address:** The local IP of your alarm module.
-* **Port:** Usually `5002`.
-
-
-
 ### Migration from YAML
 
 If you previously used the YAML configuration, the integration will automatically import your settings (Zones, Areas, IP) upon the first restart. Once the device appears in the "Integrations" dashboard, you can safely remove the `crowipmodule:` section from your `configuration.yaml`.
@@ -96,6 +102,22 @@ Here is a detailed **CHANGELOG** summarizing the refactoring from the original Y
 
 # Changelog
 
+## [2.2.0] - Zone devices reworked
+
+**All zone entities now live on one device, *Crow Alarm Sensors*.** Home Assistant links an entity to a
+device only when it is registered for the very first time, so the previous per-type devices (Windows,
+Doors, Motion, ...) could leave a zone on the device of a type it no longer had - and re-configuring
+the zone never moved it.
+
+* Every existing zone entity is moved onto *Crow Alarm Sensors* on the next restart.
+* **Entity ids are left exactly as they are**, so dashboards and automations keep working. Entities
+  created from scratch get `binary_sensor.crow_alarm_sensors_<name>`.
+* The retired per-type devices are removed automatically once nothing is registered on them.
+* The zone **type** still sets the sensor icon and device class (Fenster, Tür, Bewegung, Rauch, ...).
+* *Download diagnostics* now reports, per zone, the configured type and the device the entity is
+  really registered on.
+* No configuration change is needed.
+
 ## [2.0.0] - Refactoring for Home Assistant 2026.09+
 
 This release marks a complete rewrite of the integration to support modern Home Assistant standards, introducing UI configuration (Config Flow) and removing the dependency on YAML configuration files.