Unifi Doorbell -> BlueIris

Getting a UniFi Doorbell into Blue Iris (the hard way, because the easy way broke)

I use Blue Iris as my primary CCTV platform, but like many home lab tinkerers, I also have some UniFi kit in the mix. In this case, a UniFi doorbell camera managed by UniFi Protect on a UDM-Pro.

On paper, this should be easy. UniFi cameras can expose RTSP streams. Blue Iris can ingest RTSP streams. Job done.

Except, as usual, it wasn't quite that simple.

The wider CCTV architecture

My main CCTV recording platform is Blue Iris running on a dedicated Windows utility machine in the garage rack.

That machine handles:

• Primary recording for all cameras
• Motion/event handling
• Alerting and automation hooks
• Longer retention storage

The UDM-Pro also runs UniFi Protect, but in my setup that serves a secondary role:

• Native management for the UniFi doorbell
• Local camera access and health monitoring
• A minimal fallback recording platform if the Blue Iris machine is unavailable

That fallback capability is genuinely useful;

If I lose the Blue Iris host, need to shut systems down during maintenance, or have a power event where only core network gear remains online, the UDM-Pro can still provide a basic recording capability.

Not enterprise-grade resilience for sure, but perfectly reasonable for a home setup.

Why not just add the camera directly?

That was the first attempt.

UniFi Protect exposes a "Secure RTSPS Output" URL that looks like this:

rtsps://192.168.1.1:7441/token_here?enableSrtp

Blue Iris should theoretically be able to consume this.

In practice, I could not get stable direct ingest.

Blue Iris would either fail to connect or behave inconsistently depending on stream settings.

Even when apparently working, I wasn't convinced it was a reliable long-term solution.

The core issue is that UniFi's implementation is not plain RTSP. It is secure RTSPS with SRTP negotiation layered on top, and Blue Iris is not always thrilled with vendor-specific implementations.

The proxy approach

Rather than fight with Blue Iris directly, I inserted a translation layer.

The architecture became:

UniFi Protect
    ↓
FFmpeg
    ↓
MediaMTX local RTSP proxy
    ↓
Blue Iris

The thinking:

• Let UniFi do whatever odd protocol negotiation it wants
• Use FFmpeg as the compatibility layer
• Expose a clean local RTSP stream to Blue Iris
• Keep Blue Iris configuration simple and stable

Blue Iris then just connects to:

rtsp://127.0.0.1:8554/doorbell

Which is entirely under my control.

The implementation

MediaMTX runs locally on the Blue Iris Windows machine as a lightweight RTSP server.

A simple config exposes a named path:

paths:
  doorbell:

FFmpeg then pulls from Protect and republishes locally.

Originally:

rtsps://192.168.1.1:7441/[token]?enableSrtp

Republished to:

rtsp://127.0.0.1:8554/doorbell

Using stream copy:

-c copy

Which avoids unnecessary transcoding overhead.

This matters because the Blue Iris machine already has enough to do.

Making it resilient

A working proof of concept wasn't going to cut it though. I wanted this to survive:

• Windows reboots
• camera disconnects
• temporary Protect issues
• general home lab chaos

So the solution was hardened with Windows Task Scheduler.

MediaMTX starts automatically at boot.

FFmpeg starts automatically at boot.

FFmpeg runs inside a reconnect loop so temporary stream failures trigger automatic retry.

A daily scheduled restart forces a clean recycle.

Logs are written for troubleshooting.

The daily restart might seem unnecessary, but it protects against a common failure mode where a process remains alive while no longer actually doing useful work.

The Protect update that broke everything

Naturally, once everything was stable, UniFi Protect updated to v7.0.x

The doorbell disappeared from Blue Iris.

Blue Iris still pointed to:

rtsp://127.0.0.1:8554/doorbell

So the local configuration looked fine.

Checking the FFmpeg logs showed:

Failed to read handshake response
Error opening input: End of file

That immediately pointed upstream.

Blue Iris wasn't failing. MediaMTX wasn't failing. FFmpeg could no longer negotiate the Protect secure stream.

Testing directly in VLC confirmed the same problem.

The Protect-generated RTSPS URL simply no longer worked.

The fix

The workaround was to stop using the secure RTSPS endpoint entirely.

Instead, use UniFi's plain RTSP endpoint format:

rtsp://192.168.1.1:7447/[newtoken]

The token came from Protect's regenerated stream URL, but:

• change rtsps:// to rtsp://
• change port 7441 to 7447
• remove ?enableSrtp

Once FFmpeg was updated to use this instead:

set "IN_URL=rtsp://192.168.1.1:7447/[token]"

everything came straight back.

One bonus bug

During testing, I discovered my scheduled daily restart wasn't working.

Why?

Because I'd named the scheduled task:

FFmped Doorbell

Yes.

That typo meant the restart script was trying to restart a task that didn't exist.

Classic home lab problem.

The upside is that this was found before it became a real issue.

Final thoughts

Would I recommend running UniFi cameras directly in Blue Iris?

Maybe.

If direct RTSP works cleanly in your environment, keep it simple.

But if you're dealing with Protect-specific secure stream weirdness, the FFmpeg + MediaMTX proxy approach is solid.

It isolates Blue Iris from vendor quirks and gives you full control of the ingest layer.

Combined with UniFi Protect on the UDM-Pro as a minimal fallback recorder, it gives a nice layered approach without buying more hardware.

And if a vendor update breaks something, at least you'll know where to look.