Devices we do not recommend

Alarm.com access control hardware is licensed to an Alarm.com for Business account. The controllers are standard HID Aero and Mercury boards, but as sold their configuration and credential database live in Alarm.com's cloud, with no local API for Home Assistant.

This is the most reversible lock-in in the range, which is worth knowing. HID Aero and Mercury are open controller platforms that many access control vendors build on, so the panels, readers and wiring are not wasted if a client later changes software. What is bought from Alarm.com is the licence and the cloud, not the boards. For an install that needs door state and unlock events in Home Assistant, choose an access platform with a local API or an on-premise controller, and keep the same Mercury or Aero hardware underneath it.

The dongle reports over its own LTE connection to Alarm.com's cloud and never touches the local network, so there is no local API, no Home Assistant integration, and nothing on site to read.

Vehicle arrival is a useful automation trigger, but this is the most closed way to obtain it: a separate cellular subscription for a device that reports to one vendor. Many cars now expose location and lock state through a manufacturer integration Home Assistant already supports, and a phone or a Bluetooth beacon covers arrival detection for the rest without any extra hardware.

A stream video recorder is the storage half of Alarm.com's closed video platform. It records only Alarm.com cameras, is administered from the Alarm.com account rather than on the box, and exposes no share, no ONVIF, and no export that another system can read.

An NVR is the one piece of a video system that ought to be neutral: cameras come and go, and the recordings should outlive both the cameras and the monitoring contract. These do not. Because the recorder is bound to the account, ending the Alarm.com relationship ends access to the footage already on the client's own hardware. We specify Frigate on the client's server, or a VMS that speaks ONVIF, so the archive stays readable whoever is monitoring it.

A certified fire signalling device on a regulated path. It exposes no interface to integrate, and equipment placed in a listed fire signalling path has to be part of the listed configuration and accepted by the authority having jurisdiction, which general-purpose automation equipment is not.

This is the one entry in the Alarm.com range where the closed design is right. Fire signalling is certified end to end, and a listing covers the chain from panel to central station. Home Assistant's role, if any, is downstream and read-only: a status signal taken through a listed interface or a supervised relay output, used for convenience responses. Life safety sequences, door release and HVAC shutdown included, belong in the fire alarm system's own cause-and-effect matrix, specified by the fire contractor and approved by the authority having jurisdiction. Never place automation equipment in the reporting path.

A standalone cellular sensor that reports only to Alarm.com over LTE. It never joins the local network, so no local integration is possible and the automation logic lives in Alarm.com's cloud.

The problem it solves is real and awkward: monitoring something too far away for a house radio. The objection is that the answer routes a gate contact or a tank level through a vendor cloud and a second cellular plan, with a relay on the far end that the same cloud controls. Where the site has any connectivity, an ESPHome node on a long-range link or a small LTE gateway keeps both the sensing and the decision on the client's own system.

Handheld commissioning equipment for the ADC-SDS2001 sensor. It has no network interface and nothing to integrate, and it is listed only so the range is complete.

Nothing is wrong with it and there is nothing to integrate. It is flagged rather than recommended because it is dealer test equipment for a system we do not specify, not because of any defect.

Specialist life safety equipment reporting to the Alarm.com for Business cloud on a supervised path. There is no local interface, and putting automation equipment inside a shooter detection chain would be wrong even if there were.

Listed for completeness and so an installer meeting one on a commercial site recognises it. The same boundary applies as for fire: the detection and reporting path stays closed and supervised, and any building response Home Assistant drives should hang off a status output from that system rather than sit inside it.

This is a single-band access point dedicated to Alarm.com cameras, with no smart home radios, no Home Assistant integration, and nothing it does that a properly configured access point and VLAN does not already do better.

Adding an isolated Wi-Fi network for one vendor's cameras is a workaround for dealers who do not control the site network. On an install where we do control it, the cameras belong on a camera VLAN behind the access points the house already has, which gives the same isolation with one radio estate to manage and no extra box on a shelf.

Alarm.com video has no local path: the camera serves no RTSP or ONVIF stream, and needs a video plan bought through a dealer. A picture can be coaxed into Home Assistant through an unofficial community integration, but only by way of Alarm.com's servers on a reverse-engineered API.

A maintained community fork does now expose Alarm.com cameras in Home Assistant, streaming over WebRTC and rendered by a custom Lovelace card it ships. That makes the picture reachable, which is worth knowing on a takeover, but it does not make the camera local: the stream is fetched from Alarm.com with short-lived tokens, so it depends on the paid plan, the vendor cloud, and an unofficial project Alarm.com can break at any time. Recordings still cannot be held on hardware the client owns. We specify cameras that serve RTSP and ONVIF directly, so Frigate or an on-site NVR holds the footage and Home Assistant gets the detections without a subscription in the path.

An accessory for the ADC-V731B battery camera, which is itself locked to the Alarm.com video service, so it has no function in a Home Assistant system.

Nothing is wrong with the accessory. It is listed so the range is complete and so an installer meeting one on site knows what it belongs to. The reason not to specify it is entirely the camera it attaches to.

These commercial cameras are PoE and otherwise conventional, but they are provisioned against an Alarm.com for Business account and expose no ONVIF or RTSP endpoint, so a Frigate or VMS deployment on the same network cannot record them and the analytics stay licensed to Alarm.com.

Being PoE makes the cabling ordinary, which is the frustrating part: the same cable run would feed an ONVIF camera that any video management system could use. As sold, the stream and the analytics are licensed to the Alarm.com platform, recordings land on an Alarm.com stream video recorder or the camera's own SD card, and neither is readable by other software. The community Home Assistant integration covers residential cameras rather than this commercial line, so even the cloud workaround does not apply here. We specify ONVIF cameras for commercial work so the client owns the footage and can change platform without rewiring.

A single-purpose accessory for putting Alarm.com PoE cameras on Wi-Fi, with no function outside that platform and no Home Assistant presence of its own.

It is only ever bought to work around a missing data run to an Alarm.com camera. Since we do not specify those cameras, the accessory has nothing to attach to. Where a wireless uplink for a wired camera really is unavoidable, a general-purpose wireless bridge does the same job without tying the solution to one vendor.

The chime pairs only with Alarm.com doorbells over Alarm.com's own path, so Home Assistant can neither see the press that rings it nor ring it from an automation.

Announcing a door press is one of the things a local system does best, routing it to speakers, lights, or a phone depending on who is home and what time it is. A chime that answers exactly one vendor's doorbell and nothing else forecloses all of that. A local doorbell hands Home Assistant the press event, and any speaker or media player in the house becomes the chime.

A cellular signalling device for the Alarm.com platform. It adds a monitoring path rather than a local interface, so it exposes nothing for Home Assistant to read or control.

These exist to get alarm signals to a monitoring centre, which is a different job from automation and a reasonable one. They are listed so the range is complete. The thing to understand on a takeover is that fitting one does not bring the panel's sensors into Home Assistant: it brings them to Alarm.com. Getting the zones locally needs an interface to the panel itself.

Chamberlain cut off third-party API access to myQ in November 2023 and has held that position since, which removed the Home Assistant integration in the 2023.12 release and broke every automation built on it.

There is no local API and no supported cloud path, so a myQ hub is a dead end for any system that is not Chamberlain's own app. Nothing about the hardware is broken, but a vendor that has already revoked integration access once is not one we will build a client's garage automation on. For openers already installed we fit a local ESPHome controller to the existing motor, which restores door state, open and close control, and the obstruction sensor without touching myQ.

A September 2026 Gamers Nexus investigation caught LG webOS sets logging microphone audio with the screen off and sweeping the LAN to fingerprint phones, watches, and every other device in the house, with the harvest feeding LG's advertising arm.

The webostv integration is not the problem: it stays local and it still works. The panel behind it is the problem, and it is not something we will hand a client unmanaged. On sets already installed we block internet access at the firewall and move the TV to an isolated VLAN, which cuts the telemetry while leaving Home Assistant control intact. On new work we specify a different panel and drive it from an external streaming player. The same investigation documented webOS remote code execution bugs still moving through responsible disclosure.

Home Assistant reaches Samsung appliances only through the SmartThings cloud API, and Samsung is putting that API behind a paid plan from October 2026, so door alerts and setpoints on a fridge the client already owns turn into a recurring subscription.

There is no local path to Samsung refrigerators. Free SmartThings API access ends in October 2026: individual developers move to a $4.99/month plan and commercial use moves to separate paid tiers, so the fridge's automations come to depend both on a subscription and on Samsung's cloud staying up. The Family Hub screen and AI Vision camera add nothing on the Home Assistant side. Where the client wants a kitchen screen, pair an LG ThinQ refrigerator with a separate display such as a Nest Hub running a Home Assistant dashboard.

Home Assistant reaches Samsung audio only through the SmartThings cloud API, and Samsung is putting that API behind a paid plan from October 2026, so controlling a bar an installer already fitted turns into a recurring subscription.

Unlike Samsung's televisions, which answer the local samsungtv integration, the soundbars have no local path at all. Free SmartThings API access ends in October 2026: individual developers move to a $4.99/month plan and commercial use moves to separate paid tiers, so a client's soundbar automation comes to depend both on a subscription and on Samsung's cloud staying up. Where a bar is already installed, pair it to the TV over eARC with Q-Symphony and automate the TV's local media_player instead, which keeps evening scenes working with no SmartThings account in the loop.