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.