Cloud control vs local control: What to choose for your home automation

Cloud may be more convenient, but local control gives you more privacy and other options in your Home Assistant ecosystem.
95 readers like this.
clouds in windows CC BY-SA 4.0

There are a lot of factors to consider when investing in a home automation ecosystem. In my first article in this series, I explained why I picked Home Assistant, and in this article, I'll explain some of the foundational issues and technologies in home automation, which may influence how you approach and configure your Internet of Things (IoT) devices.

Cloud connectivity

Most devices you can buy today are tied to some type of cloud service. While the cloud brings a certain level of convenience, it also opens a host of problems. For starters, there are privacy issues related to a company having access to your personal habits—when you are home, what shows you watch, what time you go to bed, etc. Although most people are not as concerned about these issues as I am, privacy should still be a consideration, even if it is a small one.

Cloud access also creates issues around being reliant on something outside your control. In 2019, Sonos came under fire for remotely bricking older smart speakers. Speakers usually continue to work for years after their warranty ends; in fact, they usually function until they physically break. There's also the case of Automatic, which produced a cloud-based car tracker. When it announced in May 2020 that it would be shutting down its services, it advised customers to "please discard your adapter by following standard electronic recycling procedures."

Being dependent on a third-party provider for critical functionality can come back to bite you. IFTTT, a popular service for programming events based on external conditions, recently altered its free plan's terms and conditions to severely limit the number of events you can create—from an unlimited number to three. This is even though IFTTT charges device manufacturers for certification with its system, which allows products like Meross smart bulbs to proudly display their compatibility with IFTTT.

Some of these decisions are purely financial, but there are more than a few anecdotal cases where a company blocks a person's access to a device they purchased simply because they did not like what the user said about them. How crazy is that?

Another consideration with cloud connectivity is a device's responsivity if its signals must travel from your home to a cloud server (which may be halfway around the world) and then back to the device. This can lead to a two-second (or more) delay on any action. For some people, this is not a deal-breaker. For others, that delay is unbearable.

Finally, what happens if there is an internet outage? While most modern home internet connections are quite reliable, they do happen. Some large, well-known cloud service providers have experienced outages this year. Are you OK trading convenience for possibly having your automations break and losing control of your smart devices for periods of time?

Local control

There are several ways you can regain control over your smart devices. Commercially, you could try something like Hubitat, which is a proprietary platform that emphasizes local control. I have no experience with these devices, as I don't like to rely on an intermediary.

In my home, I standardized on WiFi (although I may branch out to Zigbee in the future) and Home Assistant. Using WiFi means I need to buy or make my devices based on their compatibility with alternative open source firmware, such as Tasmota or ESPHome. I admit that neither of these options is "plug-and-play friendly" unless you buy devices from sources like Shelly, which is very friendly to the community, or CloudFree, which has Tasmota installed by default.

(As a small aside, I have both flashed my own devices and purchased them from CloudFree. There are some savings with the DIY approach, but I buy pre-flashed devices for my father's house because this eliminates a lot of hassle.)

I won't go into more detail about alternative firmware, how to flash it, and so on. I simply want to introduce you to the idea that there are options for local control.

Achieving local control with MQTT

A local control device probably uses either a direct API call, where Home Assistant talks directly to the device, or Message Queuing Telemetry Transport (MQTT).

MQTT is one of the most widely used protocols for local IoT communication. I'll share some of the basics, but the Hook Up has an in-depth video you can watch if you want to learn more, and HiveMQ has an entire series on MQTT essentials.

MQTT uses three components for communication. The first, the sender, is the component that triggers the action. The second, the broker, is kind of like a bulletin board where messages are posted. The final component is the device that will perform the action. This process is called the publish-subscribe model.

Say you have a button on the wall that you want to use to turn on the projector, lower the blinds, and turn on a fan. The button (sender) posts the message ON to a specific section of the broker, called a topic. The topic might be something like /livingroom/POWER. The fan, the projector, and the blinds subscribe to this topic. When the message ON is posted to the topic, all of the devices activate their respective functions, turning on the projector, lowering the blinds, and starting the fan.

Unlike a message board, messages have different Quality of Service (QoS) states. The HiveMQ website has a good explanation of the three QoS levels. In short:

  • QoS 0: The message is sent to the broker in a fire-and-forget way. No attempt is made to verify that the broker received the message.


(© 2015 HiveMQ, reused with permission)

  • QoS 1: The message is posted, and the broker replies once the message is received. Multiple messages can be sent before the broker replies. For example, if you are trying to raise the projector's brightness, multiple brightness bars may be inadvertantly adjusted before the broker tells the sender to stop publishing messages.


© 2015 HiveMQ, reused with permission

  • QoS 2: This is the slowest but safest level. It guarantees that the message is received only once. Similar to TCP, if a message is lost, the sender will resend the message.


(© 2015 HiveMQ, reused with permission)

In addition, MQTT has a retain flag that can be enabled on the messages, but it is not set by default. Going back to the bulletin board analogy, it's like if someone posts a message to a bulletin board, but another person walks up to the board, takes the message down, reads it, and throws it away. If a third person looks at the bulletin board five minutes later, they would have no knowledge of the message. However, if the retain flag is set to true, it's like leaving the message pinned on the board until a new message is received. This means that no matter when people come to read messages, they will all know the latest message.

In home automation terms, whether or not the retain flag is set depends completely on the use case.

In this series, I will use Home Assistant's Mosquitto MQTT broker add-on. Most of my devices use MQTT; however, I do have a couple of non-critical Tuya devices that require a cloud account. I may replace them with locally controllable ones in the future.

Wrapping up

Home Assistant is a large, wonderful piece of software. It is complex in some areas, and it will help you to be familiar with these fundamental technologies when you need to troubleshoot and coordinate your setup.

In the next article, I will talk about the "big three" wireless protocols that you are likely to encounter in smart devices: Zigbee, Z-Wave, and WiFi. Don't worry—I'm almost done with the underlying theories, and soon I'll get on with installing Home Assistant.

What to read next
User profile image.
Steve is a dedicated IT professional and Linux advocate. Prior to joining Red Hat, he spent several years in financial, automotive, and movie industries. Steve currently works for Red Hat as an Architect in the Solutions and Technology Practice. He has certifications ranging from the RHCA (in DevOps), to Ansible, to Containerized Applications and more.


Oh I could nerd out on this at length.

My old house was 100% HomeKit based and I had a lot of regrets. And so did my family, who had to share the house with the really primitive home automation. There were many nuances to the automations that were wanted but not available on this really bare bones home automation platform.

Earlier this year we all moved to a bigger home. I decided right up front to put in the extra work to build something more sophisticated, and more locally controlled. What I ended up with was Home Assistant based.

There's a little bit of WiFi accessories, but mostly to communicate with MQTT. Also some Z-Wave and some Zigbee. I'm not sure you can ever have just one of these options and get very far. For example, while there's a plethora of cheap-and-good temperature & humidity sensors out there for Zigbee, as well as smart light bulbs and switches... if you want recessed door sensors, you're probably stuck with Z-wave. Same is true in a number of other niche areas.

Home Assistant is proving very capable of giving me the sophisticated, nuanced automations that I always wanted. But it does come at a cost. The learning curve is high. And the architecture is still... dated. Monolithic. It's getting better. There's a push to move Z-wave integration natively into MQTT which will help. But like every time you make a config change, you have to restart it. Many of the useful config changes still force you to edit yaml files and deal with the very opinionated whitespacing therein.

I think there's a lot of room in this project and the surrounding community to create looser couplings between HA and its integrations (the MQTT model being an excellent one). There's a lot of room to simplify the UX without "dumbing down" HA's capabilities. Take it for a spin, see what you think, but be ready for a bit of a learning curve!

What a well thought out reply. I suppose since I didn't have any prior knowledge I didn't find the learning curve too steep. Particularly when I adopted NodeRED.

I have only recently gotten a Zigbee Home (a Sonoff ZB Hub that I flashed with Tasmota) so 98% of the things I use are still WiFi based and that works quite well for us. We have some problem with WiFi interference during the peak hours of 19:00-21:00 because we are in an apartment building. Overall, I like the direction HA is heading

In reply to by magnus919

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.