Integrating a commercial device means connecting its protocol or its account with Home Assistant to create usable entities.
The vast majority of us arrived at advanced home automation after having bought a few stray plugs or light bulbs on Amazon or AliExpress. Therefore, our first practical step will be to “hijack” these commercial WiFi devices (which currently live isolated in their manufacturers’ apps) and centralize them on our server.
We are going to technically analyze how to integrate the three major families of WiFi devices on the market: Shelly, Sonoff (eWeLink) and Tuya (SmartLife). Each one represents a different level of architectural difficulty.
Before Integrating: Take Inventory
Before starting to install integrations left and right, it is worth taking a quick inventory of what we already have at home. We note down the brand, exact model, the app it uses, protocol, and location.
This isn’t bureaucracy for the love of Excel. It’s because many times two devices that look the same on the outside have completely different chips or firmware on the inside. A Tuya plug bought in 2020 might be quite friendly to integrate, and another bought in 2025 might be much more locked down.
If you already have several devices working in their original apps, don’t unlink them just yet. First, check that Home Assistant can see them, control them, and read their status. Later, we’ll decide if it’s worth cutting the cloud, flashing firmware, or leaving them as a hybrid integration.
The Ideal Ecosystem: Shelly and Native Local Integration
We start with the most rewarding scenario. As we saw in the first articles, Shelly devices (Allterco Robotics) are designed with the technical user in mind.
The Shelly integration in Home Assistant is native, official, and 100% local. Home Assistant includes in its core an official integration maintained by the community itself and the brand’s engineers.
Auto-discovery via Zeroconf and mDNS
When you connect a Shelly device to your home WiFi network, it uses a protocol called mDNS (Multicast DNS) or Zeroconf to announce its presence on the local network.
Home Assistant is constantly listening for these broadcast packets. Therefore, the integration process is trivial:
- Connect the Shelly to your router from its own app (or from its internal web server).
- Open Home Assistant and go to Settings > Devices & Services.
- You will see that Home Assistant has automatically “discovered” the device.
- Click “Configure,” and you’re done.
Older generations of Shelly use CoAP/CoIoT for status updates. Newer models use RPC over WebSockets. The integration communicates locally and offers fast response without depending on the cloud.
A Necessary Digression: What is HACS?
Before tackling Sonoff and Tuya, we need to make a technical stop. The official integrations that Home Assistant provides for these Asian brands are usually limited to the Cloud.
To be able to squeeze the hardware and seek local control, community engineers have developed Custom Components. To install these third-party components cleanly, we use HACS.
HACS (Home Assistant Community Store) is basically an unofficial package manager. Once installed (it requires a GitHub account, as it downloads repositories from there), it adds an alternative “app store” to our sidebar, from which we can install community-developed integrations that far surpass the official ones.
Sonoff and eWeLink: The Hybrid Route
For Sonoff devices linked to eWeLink, one of the most used options is SonoffLAN, a community component developed by AlexxIT and available through HACS. It is not part of the official integrations included in the Home Assistant core.
This integration is fascinating because it uses a hybrid architecture (Cloud + Local) transparently for the user.
How SonoffLAN Works
To configure it, we simply install the integration from HACS and enter our eWeLink application username and password.
From there, the integration does two things simultaneously:
- Cloud Connection: Downloads the complete list of your devices and their cryptographic keys from eWeLink’s servers via their HTTP API.
- Local Discovery (mDNS/Zeroconf): Scans your local WiFi network for those devices’ IP addresses.
If the Sonoff device supports LAN mode (most modern modules based on ESP8266/ESP32 do), Home Assistant will communicate with it directly over your local network, bypassing the cloud. Depending on the configured mode and device capabilities, the integration may use local communication, the cloud, or both. It’s advisable to check the specific model’s support before relying on LAN mode.
It’s a very convenient solution because it gives us local control in many cases without having to flash custom firmware.
If you are going to rely on local control for WiFi devices, it is usually a good idea to reserve them an IP address on your router via DHCP. It’s not mandatory in all cases, but it helps immensely when an integration needs to always locate the same device at the same address.
Tuya and Smart Life: The Most Delicate Integration
Now we come to the most delicate case. Integrating Tuya is, by far, the most tedious process, due to its extreme dependence on the cloud and its business model oriented towards businesses (B2B), not end users.
We have two radically different paths for integrating Tuya/SmartLife devices.
Route 1: The Official Integration
Home Assistant includes an official Tuya integration. It depends on Tuya’s cloud services, but its current configuration no longer requires manually creating a developer project.
The current process is much simpler:
- Add the devices to the Smart Life or Tuya Smart app.
- In Home Assistant, go to Settings > Devices & Services and add the Tuya integration.
- Obtain the user code from the mobile app when the wizard requests it.
- Scan the QR code shown by Home Assistant with the app.
This route depends on the Internet and Tuya’s servers. Furthermore, the official integration does not necessarily expose all the functions available in Smart Life, because it depends on the SDK provided by the manufacturer.
Route 2: LocalTuya or Tuya Local
To solve this mess, the community created components in HACS like LocalTuya or Tuya-Local.
These integrations speak directly with compatible devices on our network. However, the process and available functions depend on the model, the local protocol, and the component version. Many devices require obtaining a local key specific to the device.
How to obtain that key has changed several times and may require tools or a Tuya developer account. Before starting, consult the current documentation of the chosen component and its list of compatible devices. Local control is worth it when it works, but it is not guaranteed for the entire Tuya catalog.
A Purposeful WiFi Network
With these three strategies (Native Shelly, SonoffLAN, and LocalTuya), we can absorb practically 90% of the market for low-cost WiFi plugs, relays, and lights, turning them into standardized Entities within our state machine.
However, as we warned in the theory of protocols, filling the house with WiFi devices is a bad networking engineering practice.
For true invisible home automation (dozens of battery-powered motion sensors, door contacts, push buttons, and water leak detectors), we need to deploy our own mesh network.
In the next article, we will leave WiFi behind and configure the true heart of our system: Integrating our Zigbee network (ZHA vs. Zigbee2MQTT).
