v1.12.1

Siren temperature fix. Consolidates the 1.12.1-beta series.

Fixed

• Siren temperature is no longer stuck and now matches the Ajax app (#312). The HomeSiren/StreetSiren temperature was read once at startup and then frozen for the lifetime of the integration (both the per-device gRPC refresh and the HTS path skipped any device that already had a value), and the gRPC source was the internal board sensor, which reads a few degrees high on a sun-exposed StreetSiren. Sirens are now sourced from the same live internal-temperature value the Ajax app shows (HTS sub-key 0x02), so the reading matches the app and updates over the push channel. The freeze is fixed for every per-device temperature source, so the Curtain Outdoor family also updates live now.

v1.12.1-beta.1

Fixed

• Siren temperature is no longer stuck and now matches the Ajax app (#312). The HomeSiren/StreetSiren temperature was read once at startup and then frozen for the lifetime of the integration (both the per-device gRPC refresh and the HTS path skipped any device that already had a value), and the gRPC source was the internal board sensor, which reads a few degrees high on a sun-exposed StreetSiren. Sirens are now sourced from the same live internal-temperature value the Ajax app shows (HTS sub-key 0x02), so the reading matches the app and updates over the push channel. The freeze is fixed for every per-device temperature source, so the Curtain Outdoor family also updates live now.

v1.12.0

WaterStop valve open/close control. Consolidates the 1.12.0-beta series.

Added

• WaterStop valves can now be opened and closed from Home Assistant (#308). The Ajax WaterStop (and WaterStop Fibra) valve entity was read-only; it now supports open and close, so you can shut off or restore the water supply from the dashboard or an automation. State, transition and the stuck attribute keep working as before.

v1.12.0-beta.1

Added

• WaterStop valves can now be opened and closed from Home Assistant (#308). The Ajax WaterStop (and WaterStop Fibra) valve entity was read-only; it now supports open and close, so you can shut off or restore the water supply from the dashboard or an automation. State, transition and the stuck attribute keep working as before.

v1.11.5

LifeQuality air-quality sensors, NVR-bridged camera fixes, and groundwork for camera support. Consolidates the 1.11.5-beta series.

Added

• LifeQuality now exposes temperature, humidity and CO₂ sensors (#302). Previously the LifeQuality air-quality monitor only surfaced battery and signal. Its temperature (°C), humidity (%) and CO₂ (ppm) readings are now created as standard Home Assistant sensors, confirmed against the Ajax app on real hardware. Any sensor threshold/fault flags the device reports are included in the diagnostics download.
• Diagnostics now probe each VideoEdge camera's ONVIF/RTSP settings and LAN address (#282). As a step towards camera support, the diagnostics download now reports, per VideoEdge, whether ONVIF/RTSP are reachable and on which ports (auth flag and user count, never usernames) plus the device's LAN IP and MAC — the connection details needed to point Home Assistant's native ONVIF integration at the camera. Read-only and best-effort; it never affects normal operation, and the video stream itself stays local RTSP/ONVIF, not carried over the Ajax cloud.

Fixed

• An Ajax NVR no longer makes a doorbell or camera appear twice, with the activity on the empty card (#290). When an NVR (e.g. the NVR HAC) is added, it re-publishes an existing camera/doorbell channel as a second device. That republished twin carries no sensors and no doorbell event entity, yet the doorbell-ring and motion pushes attributed to it — so after 1.11.4 named the NVR channel properly, the doorbell card showed all the sensors but no activity, while a second bare card had the activity. The republished channel is now recognised (via the channel-source linkage exposed in 1.11.4) and collapsed into the primary device, and its pushes are redirected there, so a single card shows both the sensors and the ring/motion activity. A genuine NVR-native channel (one that isn't a republish of an existing device) is unaffected. Motion in particular is now attributed correctly on an NVR-bridged camera: such a camera has no Jeweller "twin" device, so the push's hardware id (the camera's primary video id) had nothing to resolve against and motion was dropped — the doorbell ring still showed only because it has a single-doorbell fallback that motion doesn't. That hardware id now maps to the camera, so motion lands too.

v1.11.5-beta.6

Added

• LifeQuality now exposes temperature, humidity and CO₂ sensors (#302). Previously the LifeQuality air-quality monitor only surfaced battery and signal. Its temperature (°C), humidity (%) and CO₂ (ppm) readings are now created as standard Home Assistant sensors, confirmed against the Ajax app on real hardware. Any sensor threshold/fault flags the device reports are included in the diagnostics download.
• Diagnostics now probe each VideoEdge camera's ONVIF/RTSP settings and LAN address (#282). As a step towards camera support, the diagnostics download now reports, per VideoEdge, whether ONVIF/RTSP are reachable and on which ports (auth flag and user count, never usernames) plus the device's LAN IP and MAC — the connection details needed to point Home Assistant's native ONVIF integration at the camera. Read-only and best-effort; it never affects normal operation, and the video stream itself stays local RTSP/ONVIF, not carried over the Ajax cloud.

Fixed

• An Ajax NVR no longer makes a doorbell or camera appear twice, with the activity on the empty card (#290). When an NVR (e.g. the NVR HAC) is added, it re-publishes an existing camera/doorbell channel as a second device. That republished twin carries no sensors and no doorbell event entity, yet the doorbell-ring and motion pushes attributed to it — so after 1.11.4 named the NVR channel properly, the doorbell card showed all the sensors but no activity, while a second bare card had the activity. The republished channel is now recognised (via the channel-source linkage exposed in 1.11.4) and collapsed into the primary device, and its pushes are redirected there, so a single card shows both the sensors and the ring/motion activity. A genuine NVR-native channel (one that isn't a republish of an existing device) is unaffected. Motion in particular is now attributed correctly on an NVR-bridged camera: such a camera has no Jeweller "twin" device, so the push's hardware id (the camera's primary video id) had nothing to resolve against and motion was dropped — the doorbell ring still showed only because it has a single-doorbell fallback that motion doesn't. That hardware id now maps to the camera, so motion lands too.

v1.11.5-beta.5

Added

• LifeQuality now exposes temperature, humidity and CO₂ sensors (#302). Previously the LifeQuality air-quality monitor only surfaced battery and signal. Its temperature (°C), humidity (%) and CO₂ (ppm) readings are now created as standard Home Assistant sensors, confirmed against the Ajax app on real hardware. Any sensor threshold/fault flags the device reports are included in the diagnostics download.
• Diagnostics now probe the VideoEdge ONVIF/RTSP settings (#282). As a first step towards real camera support, the diagnostics download now reports, per VideoEdge, whether ONVIF/RTSP are reachable and on which ports (the auth flag and user count, never usernames). This is read-only and best-effort — it maps what's available for a future camera entity and never affects normal operation; the video stream itself is local RTSP/ONVIF, not carried over the Ajax cloud.

Fixed

• An Ajax NVR no longer makes a doorbell or camera appear twice, with the activity on the empty card (#290). When an NVR (e.g. the NVR HAC) is added, it re-publishes an existing camera/doorbell channel as a second device. That republished twin carries no sensors and no doorbell event entity, yet the doorbell-ring and motion pushes attributed to it — so after 1.11.4 named the NVR channel properly, the doorbell card showed all the sensors but no activity, while a second bare card had the activity. The republished channel is now recognised (via the channel-source linkage exposed in 1.11.4) and collapsed into the primary device, and its pushes are redirected there, so a single card shows both the sensors and the ring/motion activity. A genuine NVR-native channel (one that isn't a republish of an existing device) is unaffected. Motion in particular is now attributed correctly on an NVR-bridged camera: such a camera has no Jeweller "twin" device, so the push's hardware id (the camera's primary video id) had nothing to resolve against and motion was dropped — the doorbell ring still showed only because it has a single-doorbell fallback that motion doesn't. That hardware id now maps to the camera, so motion lands too.

v1.11.5-beta.4

Added

• Diagnostics now surface LifeQuality's environmental readings for triage (#302). LifeQuality currently only exposes battery and signal — its temperature, humidity and CO₂ aren't shown as sensors yet. The diagnostics download now reports those raw values (and any sensor threshold/fault flags) so the data path and units can be confirmed against a real device before the sensors are added. Read-only; no change to existing entities.
• Diagnostics now probe the VideoEdge ONVIF/RTSP settings (#282). As a first step towards real camera support, the diagnostics download now reports, per VideoEdge, whether ONVIF/RTSP are reachable and on which ports (the auth flag and user count, never usernames). This is read-only and best-effort — it maps what's available for a future camera entity and never affects normal operation; the video stream itself is local RTSP/ONVIF, not carried over the Ajax cloud.

Fixed

• An Ajax NVR no longer makes a doorbell or camera appear twice, with the activity on the empty card (#290). When an NVR (e.g. the NVR HAC) is added, it re-publishes an existing camera/doorbell channel as a second device. That republished twin carries no sensors and no doorbell event entity, yet the doorbell-ring and motion pushes attributed to it — so after 1.11.4 named the NVR channel properly, the doorbell card showed all the sensors but no activity, while a second bare card had the activity. The republished channel is now recognised (via the channel-source linkage exposed in 1.11.4) and collapsed into the primary device, and its pushes are redirected there, so a single card shows both the sensors and the ring/motion activity. A genuine NVR-native channel (one that isn't a republish of an existing device) is unaffected. Motion in particular is now attributed correctly on an NVR-bridged camera: such a camera has no Jeweller "twin" device, so the push's hardware id (the camera's primary video id) had nothing to resolve against and motion was dropped — the doorbell ring still showed only because it has a single-doorbell fallback that motion doesn't. That hardware id now maps to the camera, so motion lands too.

v1.11.5-beta.3

Added

• Diagnostics now probe the VideoEdge ONVIF/RTSP settings (#282). As a first step towards real camera support, the diagnostics download now reports, per VideoEdge, whether ONVIF/RTSP are reachable and on which ports (the auth flag and user count, never usernames). This is read-only and best-effort — it maps what's available for a future camera entity and never affects normal operation; the video stream itself is local RTSP/ONVIF, not carried over the Ajax cloud.

Fixed

• An Ajax NVR no longer makes a doorbell or camera appear twice, with the activity on the empty card (#290). When an NVR (e.g. the NVR HAC) is added, it re-publishes an existing camera/doorbell channel as a second device. That republished twin carries no sensors and no doorbell event entity, yet the doorbell-ring and motion pushes attributed to it — so after 1.11.4 named the NVR channel properly, the doorbell card showed all the sensors but no activity, while a second bare card had the activity. The republished channel is now recognised (via the channel-source linkage exposed in 1.11.4) and collapsed into the primary device, and its pushes are redirected there, so a single card shows both the sensors and the ring/motion activity. A genuine NVR-native channel (one that isn't a republish of an existing device) is unaffected. Motion in particular is now attributed correctly on an NVR-bridged camera: such a camera has no Jeweller "twin" device, so the push's hardware id (the camera's primary video id) had nothing to resolve against and motion was dropped — the doorbell ring still showed only because it has a single-doorbell fallback that motion doesn't. That hardware id now maps to the camera, so motion lands too.

v1.11.5-beta.2

Added

• Diagnostics now probe the VideoEdge ONVIF/RTSP settings (#282). As a first step towards real camera support, the diagnostics download now reports, per VideoEdge, whether ONVIF/RTSP are reachable and on which ports (the auth flag and user count, never usernames). This is read-only and best-effort — it maps what's available for a future camera entity and never affects normal operation; the video stream itself is local RTSP/ONVIF, not carried over the Ajax cloud.

Fixed

• An Ajax NVR no longer makes a doorbell or camera appear twice, with the activity on the empty card (#290). When an NVR (e.g. the NVR HAC) is added, it re-publishes an existing camera/doorbell channel as a second device. That republished twin carries no sensors and no doorbell event entity, yet the doorbell-ring and motion pushes attributed to it — so after 1.11.4 named the NVR channel properly, the doorbell card showed all the sensors but no activity, while a second bare card had the activity. The republished channel is now recognised (via the channel-source linkage exposed in 1.11.4) and collapsed into the primary device, and its pushes are redirected there, so a single card shows both the sensors and the ring/motion activity. A genuine NVR-native channel (one that isn't a republish of an existing device) is unaffected.