Integrating Smart Home with Existing CCTV, Alarm and Video Intercom

Answer up front — There is generally no supported public API on consumer CCTV, NVR or alarm gear, so treat API integration as unverified until the manufacturer confirms it in writing. What works reliably, and has for decades, is point-to-point: a dry contact from the alarm panel's relay output or the NVR's alarm output, into a relay on the smart side. No cloud, no subscription, no firmware dependency. Build on that, and be honest with the client about what is wired and what is not.

Start by establishing what the client actually has

Walk the site and write down the make, model and firmware of everything, because "my alarm guy installed it" is not a specification. The integration surface you get depends on which of four things you are looking at.

• Alarm panel. Most domestic and small commercial panels expose programmable relay outputs and zone inputs. That is the useful part. Whether a specific output can be assigned to a specific event is a programming question for that panel's manual, not a guess.
• NVR or DVR. Most have a physical alarm output that can be wired to close a contact on an event, and many have a trigger-in on the channel. The number and the assignability vary by model.
• IP camera with an NVR. Video streaming is not event integration. Pulling a stream to detect motion is a fragile technique that will break on the next firmware update and should not be sold as an integration.
• Video intercom. Two common shapes: a dry contact that reports "door pressed" as a binary, and a door strike that the intercom energises. The unlock-from-your-phone case needs an IP API the intercom may not have.

What interlocks well

The first five are the same technique. A dry contact, a wire, a relay. That is the honest answer when a client asks "can you make them talk" — yes, and here is exactly how, and here is what it will not do.

What does not work, and how you get into trouble with it

The failure mode is not a bad install. It is a promise made on the strength of somebody else's forum post.

• "There is an ONVIF API on the NVR." Some NVRs do expose a profile of it. What a given model exposes, and whether the vendor permits third-party use of it, is a commercial and licensing question that the installer is not the right party to answer. Do not build a job on it without written confirmation from the manufacturer.
• "The camera has an RTSP stream, so I can watch the stream." You can. That is streaming, not triggering, and polling a video stream to detect an event is a support liability with a short fuse.
• "Aqara integrates with it." We checked. We could not verify an official, Aqara-supported integration with any specific CCTV, NVR, alarm or intercom brand, and the only material on this topic in the vendor's own community forum is an owner asking the same question, unanswered. Aqara does publish a developer platform for its own devices — that is a different thing entirely, and it does not make third-party video or alarm systems compatible. Vendor support varies by brand and model. Confirm with the manufacturer before you commit it to a quote, and get the answer in writing.
• "I'll cut power to the camera to make it look at the door." Technically fine, practically poor: you drop the feed, the NVR shows a signal loss, and any recording rule keyed to that channel may do something you did not plan for.

State plainly in the quotation which integrations are wired point-to-point and which, if any, depend on a vendor interface you have not verified. A client who is told that up front does not dispute the invoice later.

Avoiding nuisance automation

The classic failure is a curtain that opens every time a car passes, or a light that comes on at 6pm for the fifteenth unrelated event. Nobody switches it off, because the automation still looks like it works. Seven rules that prevent it:

1. Trigger on a state, not on an event. Require the event to be true for a dwell time, or require a change in state. A momentary pulse from a passing object is an event; a car sitting in the drive is a state; a single relay click is not.
2. Debounce and lock out. After any trigger, ignore further triggers for a window. Most nuisances are a burst.
3. Gate on time and daylight. A gate at night is not a nuisance detector. It is a different thing, and it should be a separate automation the client can see.
4. One camera, one action, no cascade. The moment a single event fans out across lights, curtains, aircon and locks, the blast radius of a bad trigger is the whole house.
5. Test at the actual traffic time, not at 3pm on a quiet Tuesday. Drive past it when it actually happens. Go and watch.
6. Bind the automation to the alarm state. Armed means live, disarmed means dormant. This alone removes most of the complaints, because the client stops being startled by their own house while they are at home.
7. Make the disable visible. Give the automation a name that says what it does, and make it a two-tap turn-off in the app. An automation that is quietly wrong and quietly disabled will be discovered on the day it matters.

Also confirm who is allowed to be notified. A relay that cuts a zone or unlocks something is an automation with a security consequence — it deserves the same treatment as a door, not the same treatment as a lamp.

Documenting the handoff

This is where the job is won or lost, and it is the part installers skip. One page, signed, dated, kept by the client and a copy in your file.

Keep the page to one side. If it needs three pages, the scope is too big for a home and should have been quoted as a different job.