Smart home devices are usually sold on convenience. Control the lights from your phone. Turn down the thermostat from bed. Get a camera notification when someone walks up to the porch. Automate the boring stuff and feel like you are living slightly closer to the future.
That future gets a lot less fun when the device only works because a company’s cloud service is still around.
My rule for buying new smart home gear has become pretty simple: if the core functionality depends on a proprietary cloud service, I’m probably not interested. The manufacturer’s app can be useful. Cloud features can be useful. But the device should support an open, local-first protocol out of the box.
For most smart home devices, that means looking for Matter. For cameras, that usually means looking for RTSP and/or ONVIF support. There are also good exceptions outside of Matter, like Zigbee, Z-Wave, MQTT, ESPHome, and other local integrations. The important part is not that every device has to use the same protocol. The important part is that the device should not become useless just because the manufacturer gets bored, pivots, gets acquired, changes its subscription model, or shuts down a server.
Not Bricked, But Definitely Worse
Google’s support changes for older Nest Learning Thermostats are a good example of the problem. Starting October 25, 2025, Google says 1st- and 2nd-generation Nest Learning Thermostats no longer connect to or work in the Nest app or Google Home app. Those thermostats can still be controlled directly on the device, and existing schedules can continue to run.
So, no, they were not turned into wall-mounted paperweights. That part matters.
But a lot of what made them “smart” went away: remote control from the app, notifications, phone-based settings changes, third-party assistants, Home/Away Assist, multi-device Eco mode control, and software/security updates. That is not nothing. If you bought the device because it was connected, programmable, and integrated with the rest of your home, losing those features is a meaningful downgrade.
This is the smart home trap. The physical device can still function, while the product you thought you bought quietly stops existing.
The App Should Be a Bonus, Not the Foundation
I do not think every smart home device needs to be fully open source, and I do not think every manufacturer app is bad. Sometimes the app is the easiest way to set up the device. Sometimes it exposes extra features. Sometimes it handles firmware updates in a clean way.
That is fine.
The problem starts when the app and cloud service are the only way to use the device. At that point, you are not just buying hardware. You are buying hardware plus an ongoing promise that the company will continue to care about that hardware.
That promise has a shelf life.
A better model is “cloud optional.” Use the manufacturer’s app if it helps. Use the cloud feature if it gives you something valuable. But the basic control path should still exist locally. A light switch should still switch lights. A thermostat should still integrate with your home. A camera should still expose a video stream. Your house should not need to ask a remote server for permission to behave like your house.
Why Matter Helps
Matter is not magic, but it is a useful step in the right direction. It gives smart home devices a common language that can work across ecosystems. Instead of buying something that only really belongs to Apple Home, Google Home, Amazon Alexa, SmartThings, or some vendor-specific app, you can buy something designed to be understood by multiple controllers.
That flexibility matters.
Maybe today you use Apple Home. Maybe next year you want to move more automations into Home Assistant. Maybe you have family members who prefer Alexa. Maybe you just do not want to make a 10-year device purchase based on your current phone brand. Matter makes that less painful.
This is where Home Assistant is especially useful. It is very good at acting as the central place where different devices, protocols, and automations meet. If your devices support local standards, Home Assistant can often become the hub that ties them together without forcing everything through one company’s cloud.
Atomic Spin has covered this general direction before in Home Automation in 2024: What’s New?, especially around Matter, Thread, and the slow move away from piles of vendor-specific apps. That post also points out an important reality: vendor apps are still here, and Matter does not expose every possible feature for every device. Energy monitoring, RGB animations, and firmware updates may still require a manufacturer app.
That is annoying. It is not a deal-breaker.
The goal is not perfection. The goal is an exit path.
Cameras Are Their Own Special Case
Security cameras deserve separate treatment because they are often some of the most cloud-dependent devices in the house. Video storage, event detection, person recognition, package alerts, and remote viewing are all obvious places for companies to sell subscriptions.
Again, cloud features are not automatically bad. But a camera that only works through a proprietary app is a risky purchase.
For cameras, I want to see RTSP and/or ONVIF support. RTSP gives other systems a way to consume the camera’s video stream. ONVIF helps with discovery, camera control, and integration. Together, they make the camera much more likely to work with Home Assistant, a local NVR, Frigate, Blue Iris, Synology Surveillance Station, or tools like Scrypted.
That last one is a good example of why open video paths matter. Scrypted can take camera feeds and make them available to other smart home ecosystems. But that only works if there is something useful to ingest in the first place. If the camera’s only output is “open our app,” your options are much thinner.
A camera should be a camera, not just a viewing window into a subscription service.
The Counterarguments Are Real
There are fair arguments against being this picky.
The first is convenience. The manufacturer app is usually easier. You scan a QR code, tap through a few screens, and the device appears. No hub decisions. No protocol research. No fiddling with integrations. That is true, and I do not think convenience should be dismissed. But easy setup and local control are not opposites. A good smart home device should have both: a pleasant setup flow and a durable local control path underneath it.
The second argument is that cloud services often provide better features. Also true. A cloud-backed camera may have better object recognition. A thermostat may have better weather-aware scheduling. A vendor app may provide cleaner dashboards than a generic hub. But those should be enhancements, not load-bearing walls. If the cloud goes away, the device should degrade gracefully. Losing fancy object detection is one thing. Losing the ability to view your own camera feed locally is another.
The third argument is that Matter is still imperfect. Very true. Device support is still uneven. Some categories are better covered than others. Some manufacturers technically support Matter but still keep their best features in their own app. Thread networks can introduce their own troubleshooting fun. Anyone who has spent time with home automation knows that “standard” does not always mean “effortless.”
Still, imperfect interoperability is better than no interoperability. I would rather have a device that exposes 80% of its functionality through a local standard than one that exposes 100% through a cloud service that can disappear.
What to Look For on the Box
When buying new smart home gear, I’d treat these as positive signs:
- Matter support for lights, plugs, switches, sensors, locks, thermostats, and similar devices.
- Thread support for low-power devices, as long as Matter is also supported.
- Zigbee or Z-Wave support if you already have a compatible hub.
- Clear Home Assistant compatibility, especially for local integrations.
- MQTT or ESPHome support for more DIY-friendly devices.
- RTSP and/or ONVIF support for security cameras.
- A local API or explicit local control mode.
- Setup codes, QR codes, or pairing flows that work with standard hubs.
And I’d treat these as warning signs:
- “Works with our app” is the only integration listed.
- Remote control requires an account with no local fallback.
- The camera feed cannot be accessed outside the vendor app.
- Basic automations require a subscription.
- The product page talks a lot about AI features but says nothing about local control.
- Reviews mention that the device stops working when the internet is down.
This does not mean you have to turn every purchase into a research project. Just add one more question before buying: “What happens if this company’s service shuts down?”
If the answer is, “The device keeps doing its main job,” that is a good sign.
If the answer is, “I guess I’ll buy a replacement,” keep walking.
Buy Devices That Can Outlive Their Apps
Smart home devices live in weird territory. They are physical objects installed in your home, but many of them behave like rented software. That mismatch is where the trouble starts.
A light switch should last a long time. A thermostat should last a long time. A camera should not need to be replaced just because a product team decided the old app is inconvenient to maintain.
Open, local-first protocols are not just a hobbyist preference. They are a practical way to protect yourself from product churn. They let you change hubs, mix ecosystems, move more control into Home Assistant, or keep basic functionality running when a cloud service goes away.
The best smart home device is not the one with the flashiest app. It is the one that still makes sense five years from now, after you change phones, rebuild your automations, switch platforms, or the manufacturer moves on.
Your smart home should belong to you. Not to a server you do not control.