Hi Zdenda,
Thank you for such a thorough report and for testing all six channels. The exact NVR, door-station firmware and the distinction between local and remote playback are particularly useful. It is good to hear that discovery, motion, snapshots, disk status and the clock check are working on your DS-7608NI-I2.
I have gone through your four points and checked how version 5.0.1 currently handles them. Here is what I found and what I would like to investigate next.
1. DS-KD8003 door station and RTSP-only operation
Your request makes sense. The standalone Doorbell driver currently expects an ISAPI response from /ISAPI/System/deviceInfo during pairing, then uses ISAPI for the snapshot and event connection. A working RTSP stream alone is therefore not enough for that path today. The statusCode 3 you see is useful evidence, but it is not enough on its own to establish why this firmware rejects those requests.
I would like to add an explicit RTSP-only option: test the video connection, allow the door station to remain usable for live view without treating missing ISAPI as a broken video connection, and clearly show which features are unavailable. I would keep event and ISAPI health checks separate from video health, rather than repeatedly polling endpoints the device does not support.
For snapshots there is one important detail: the current standalone snapshot comes from an ISAPI picture endpoint, so RTSP-only video does not automatically give us a JPEG. I would investigate whether the NVR’s channel-6 snapshot can be reused, whether your unit has a separate working picture endpoint, or whether a frame can be extracted from RTSP within Homey’s limits. I cannot promise a standalone snapshot until one of those routes is confirmed.
For now, since your door station is already channel 6 on the NVR, could you check whether that existing Camera via recorder device provides its own live view and snapshot? If it does, it may already give you the picture without adding a second standalone device.
For the button press, I agree that RTSP video alone does not carry a ring event. It is still worth checking whether the NVR forwards a separate event: if convenient, press the doorbell once and look in this app’s Recent events for an event at that time. If the recorder sends one, I can investigate mapping it; if nothing arrives there, I would need another supported event source before promising a ring trigger.
One detail that would help: did the standalone Doorbell finish pairing and then become unavailable, or did the connection test fail during pairing? My current pairing code expects deviceInfo, so your exact sequence will help me pinpoint where the behaviour differs. If you already have a redacted response, the HTTP status plus statusString and subStatusCode from one failing request would be useful; please remove addresses, account details and serial numbers.
2. Black live view on mobile data
Thank you for already checking the H.264 substream and stream encryption. The same symptom in the ONVIF app is a valuable comparison. Homey’s newer video system uses a WebRTC proxy for supported front ends and remote viewing, so the remote connection or player is one possible area to investigate. It is not enough yet to conclude that Homey itself is the cause: stream selection, audio/codec details, the phone and the network path could also matter.
If you have a few minutes, could you compare the same camera and explicitly selected H.264 substream in these situations?
- Homey mobile app on your home Wi-Fi: does it show moving video?
- The same phone with Wi-Fi off on mobile data: does it stay black, and is there audio or an error?
- If convenient, the same phone on another Wi-Fi network outside your home: does it behave like mobile data or like home Wi-Fi?
Please also let me know your Homey firmware, mobile app version, phone model and iOS/Android version, and whether a VPN is active on the phone. No need to open ports or post your RTSP URL or credentials. If both camera apps fail on the same remote network, those comparisons will give us a much better case to take to Homey support.
For reference, Homey’s video documentation describes the WebRTC proxy and remote-viewing path. Its direct-RTSP option bypasses that proxy, so it is useful as a local comparison but is not, by itself, a fix for viewing outside the local network.
3. H.265 warning in “Test everything”
You have spotted a real limitation in my check. It currently probes the main stream of the first camera; it does not independently check its H.264 substream and it does not take the experimental H.265 option into account in that checklist. That explains why it can warn even though your H.264 substream or experimental main stream works.
I would change the report to show main and sub separately, including each reported video and audio codec, and make the H.265 message reflect the experimental setting. The test would still be an RTSP connection/codec check, not proof that Homey’s local or remote player can actually render the video.
4. Prefer the substream
I agree: a per-camera preference for the substream would be useful. At present the app registers separate Main stream and Sub stream entries. I would look at making the H.264 substream the preferred opening stream while retaining access to the main stream and keeping existing device/widget references stable. I need to verify how Homey chooses the default on both mobile and web before promising the exact behaviour.
Report and next steps
If you are happy to share it, open this app’s settings, go to Check and report, run Test everything, and then use Copy report. Please review the text before posting and remove any addresses, credentials, tokens or other details you would rather keep private. The local-versus-remote results above and the pairing sequence for the door station are the most valuable extra details.
Thank you again for taking the time to test and for offering a report. I do not own this exact door station, so your results would be especially helpful in checking any changes against real hardware.
Best regards,
Wisse
