Over the last few decades home automation, or domotica, has become increasingly popular. People wanted more than a manually operated switch on the wall and technology vendors saw their opportunity. Soon they were competing with one another, overwhelming homeowners with new ideas, technologies, services and products.
Each came with its own promises, benefits and concerns. Unfortunately, comparing them was often confusing because they were not always addressing the same problems. Sometimes the innovation concerned a wireless communication protocol, sometimes the architecture, cloud services, hubs, apps, speech recognition, intelligence, transparency or interoperability. And then there were all the other fancy technologies vendors used to promote their products.
For homeowners, adopting new technology frequently meant abandoning some of what they already had and moving on to the next generation. Many vendors also tried to protect their products through proprietary technology, preventing devices from different manufacturers or generations from communicating with one another.
This article takes a brief look at some of these technologies, explaining their benefits and concerns.
X10. One of the earliest widely available technologies for automating lights and other appliances using switches, timers and sensors was X10. Its communication travels over the existing electrical wiring in your home. No dedicated cables and no wireless dead spots, although a home with three-phase power needs a phase coupler between the phases. Just the power lines every home already has. A central controller, sometimes receiving radio signals from a remote control or motion sensor, could send commands through the power lines to automated switches elsewhere in the house.
You might be surprised how many homes still have functioning X10 wall dimmers. The large plug-in switches usually ended up in a box in the garage. Too bad, because despite occasional reliability problems caused by electrical interference, many of these devices still work perfectly after more than 40 years. The hardware was relatively simple and the protocol was documented, allowing third-party implementations. However, programming and integrating X10 into more sophisticated systems was not particularly convenient. Its intelligence was limited and communication was slow, with little feedback from devices.
KNX. Where X10 used the existing power lines, KNX took the opposite approach: a dedicated bus cable to every switch, sensor and actuator in the house. It grew out of the European Installation Bus of the early 1990s and became an international standard supported by hundreds of manufacturers. KNX is decentralised. Every device carries its own small piece of intelligence, so there is no central controller that can fail. That makes it extremely reliable, and many installations have worked faultlessly for decades.
The price is considerable, however. The cabling has to be laid during construction or a major renovation, and the components cost several times more than their wireless equivalents. The installation is configured with dedicated software, the ETS tool, usually by a certified installer. As a result, the homeowner often depends on that installer for every change, even moving a single switch to another lamp. KNX excels at doing the same thing reliably for thirty years. It is less suited to a homeowner who wants to change their mind next week, and more sophisticated logic generally requires additional modules or a separate server.
Wi-Fi. When laptops and smartphones brought Wi-Fi into almost every home, vendors naturally introduced home automation devices using the same wireless infrastructure. Again a great promise: the network was already there.
However, there was often a catch. Many bulbs, thermostats and other devices were not designed to communicate directly with a local controller. Instead, they used your Wi-Fi network and internet connection to communicate with the manufacturer’s cloud servers. The apps on your phone connected to those same servers, meaning that much of your home’s automation could actually be running somewhere else. This introduced obvious privacy, security and reliability concerns. What happens when the internet connection fails or the vendor decides to discontinue its service?
Fortunately, not all Wi-Fi devices work this way. Some provide local interfaces and can operate entirely without internet access. Wi-Fi itself is simply a communication technology. Cloud dependency is a vendor’s architectural choice. The intelligence of these systems varies considerably but is often limited by the capabilities of the manufacturer’s software.
Bluetooth, Zigbee, Z-Wave, Thread. These are alternative wireless technologies, generally designed for relatively short-range communication. An important benefit, particularly for Zigbee, Z-Wave, Thread and Bluetooth Low Energy, is their low power consumption. This allows battery-operated sensors to function for months or even years. Zigbee, Z-Wave and Thread also support mesh networking, where powered devices can relay messages and extend the network’s reach.
These technologies frequently require a separate hub or controller. The hub connects to your home network, either allowing local communication with an app or forwarding everything to a cloud server. Unfortunately, many manufacturers developed their own hubs and apps, often with limited support for competing products. Consequently, homeowners could end up with a cupboard full of hubs and a phone full of apps.
Interoperability has improved considerably over the years, although compatibility between products is still not guaranteed. An interesting example is Homey, which combines several wireless technologies including Zigbee, Z-Wave and Bluetooth in a single platform.
Matter. Matter was supposed to provide the answer to this fragmentation: a common standard that manufacturers could adopt to make their products interoperable. Although the initiative received enthusiastic support from major technology companies, bringing a substantial number of compatible products to market took several years.
Publicly, everyone welcomed a worldwide standard. Behind the scenes, however, manufacturers faced the challenge of replacing existing proprietary ecosystems, adapting products and supporting a common architecture. Such changes require investment and can undermine established business models. Matter is now gaining traction and represents an important step towards interoperability.
Technically, Matter is more than a communication protocol. It defines a common application layer, device models and mechanisms for discovering and controlling devices across different networks including Wi-Fi, Ethernet and Thread. However, Matter is not an automation engine. It allows devices and controllers to understand one another but it does not determine what your home should actually do, when or why.
Speech-driven home automation. Speech recognition was promoted as the next big step towards intelligent home automation. In our opinion, it has so far delivered considerably less than promised. Speech is a natural expression of human intelligence but communication between humans is not without errors either. Issuing commands in a noisy room with several people talking or a television playing can be surprisingly unreliable. And for the substantial part of humanity that is deaf or hard of hearing, speech control may be impractical or completely useless.
More importantly, speech recognition should not be confused with intelligence. For years, commands such as “Turn off the living room lights” or “Play some Beatles music” represented much of what these systems could reliably accomplish. Recent developments in artificial intelligence, particularly large language models, are changing this. Natural-language interfaces are becoming much more capable of understanding complex requests.
Nevertheless, translating a homeowner’s complicated procedure into a reliable sequence of actions remains difficult. Understanding a request is one thing. Executing it correctly and consistently is quite another.
Apple Home, Google Home and other big players. These platforms attempt to solve the integration problem by bringing devices from different manufacturers together under one software environment. The idea is excellent and both ecosystems work reasonably well. They provide convenient apps, automation features and integration with their respective operating systems and services. However, they remain largely proprietary platforms. Although Matter has improved interoperability, the manufacturers still determine which features, device categories and integrations their platforms support.
Google also entered the hardware market with Nest thermostats, cameras, speakers and other products. These remain part of its smart-home ecosystem although Google has changed products, services and integration policies over time.
Apple focuses strongly on integrating home automation into its existing ecosystem of iPhones, iPads, Macs, Apple TVs and HomePods. Recently it introduced HomeView (not yet in the EU), a dedicated smart-home display with facial recognition and an AI-powered Siri. An impressive device but primarily an extension of Apple’s existing ecosystem rather than a fundamentally new approach to home automation.
Both platforms provide a polished user experience, particularly for homeowners already invested in their ecosystems. The concern is that the homeowner ultimately depends on the platform provider’s decisions, software updates, supported features and long-term commitment.
Home Assistant. Home Assistant is the answer from the more technically oriented community. It is an open-source software platform that can run on a dedicated home server, a small computer, a virtual machine or inside a Docker container. Its greatest strengths are its open architecture, large installed base and active community. Thousands of devices and services are supported through an enormous collection of integrations.
Its ecosystem also includes HACS, a community-driven store for additional integrations and extensions. Home Assistant provides sophisticated automation, dashboards and local control. It offers considerable freedom to combine otherwise incompatible technologies and even supports complex automation through scripts, templates and external programming tools.
However, this flexibility comes at a price. The platform has grown into a large and sometimes overengineered environment with numerous components, dependencies and configuration options. Its preferred Home Assistant OS installation provides the most integrated experience while Docker installations require more manual management and lack the same add-on infrastructure. For technically skilled homeowners, Home Assistant offers tremendous possibilities. For others, the learning curve and maintenance requirements may be more than they bargained for.
A lighter alternative is Domoticz, an open-source platform with Dutch roots that has been running quietly on Raspberry Pis in Dutch meter cupboards for more than a decade, but its automation still comes down to the same choice between blocks and Lua scripts.
And what about intelligence? Most home automation products offer some form of intelligence but it is often limited to relatively simple rules. A sensor detects movement and a light switches on. A timer closes the curtains. A temperature threshold activates the heating. Of course, these rules can be combined and some platforms offer much more sophisticated possibilities. But what if a homeowner wants to define a procedure involving more than a handful of sensors, variables, conditions and time-dependent decisions? What if the behaviour of one device depends on the state of several others or on events that happened earlier?
Some platforms have addressed this by introducing existing scripting languages.
Homey offers its Flow editor where cards are connected into “when … and … then” rules. That works well for simple rules but as the procedures grow, the flows become a tangle of cards and lines that is hard to follow. For anything beyond that Homey offers HomeyScript, which is JavaScript. At that point the homeowner is no longer configuring a home but programming a computer with all the syntax, asynchronous calls and debugging that comes with it.
Fibaro chose Lua for its Home Center controllers. Lua is a compact and capable language, but a Fibaro scene is not written in terms of the home. It is written in terms of the controller, where devices are often addressed by numbers instead of names. A line like fibaro.call(54, "turnOn") means something to the person who wrote it, and only for as long as they remember which device 54 was. When Fibaro moved from the Home Center 2 to the Home Center 3, the scripting interface changed and many carefully written scenes had to be rewritten. Once again, homeowners paid for the next generation with what they had already built.
Both approaches have their limitations. A general programming language is often a bridge too far for the average homeowner, while visual editors become cumbersome as procedures grow.
There is also a growing interest in systems that observe user behaviour and attempt to predict what the homeowner wants. Apple has experimented with this for years, offering suggestions based on routines and location. Interesting technology, but not necessarily desirable. A system that predicts when I will arrive home does not know whether I actually intend to go there. And a continuous stream of well-intended notifications can quickly become an annoyance rather than a benefit.
Perhaps the real challenge is not to build a home that makes decisions for its occupants but to give homeowners the means to express their own decisions. Not necessarily through complex programming with general languages and certainly not by surrendering control to an artificial intelligence.
That is precisely the challenge Homylon was designed to address. Keeping what you already have, adding what you want, and a simple, versatile language homeowners already spoke but never could write.