The decision framework
Choose a device or protocol by the outcome you need—not by marketing labels.
| Need | Usually a good fit | Why |
|---|---|---|
| Battery sensor / button | Zigbee or Thread | Low power, mesh-friendly |
| Mains switch or plug | Zigbee, Thread, or Wi-Fi local | Reliable power enables router/mesh roles |
| Camera / high bandwidth | Ethernet or Wi-Fi | Zigbee/Thread are not video transports |
| Custom sensor/controller | ESPHome or Arduino/ESP32 | Local logic and flexible hardware |
| Cross-platform device interoperability | Matter | Standardised application layer |
| Local automation messaging | MQTT | Decoupled publisher/subscriber model |
Protocols are layers, not rivals
Zigbee
A low-power mesh protocol. Battery devices are endpoints; many mains-powered devices act as routers and improve the mesh. Your Zigbee system is managed through Zigbee2MQTT and a Sonoff coordinator.
Strengths: mature device choice, local control, good battery life.
Watch: coordinator backup, channel planning, mains-router density, link quality, permit-join exposure.
Thread
A modern IPv6 mesh transport for low-power devices. It needs a border router to connect the Thread mesh to the rest of your network. Your Google TV Streamer provides that role; a separate OTBR instance is not needed without a dedicated Thread radio and a reason to operate one.
Matter
Matter is an interoperability standard above the network layer. A Matter device may communicate over Thread, Wi-Fi, or Ethernet. Matter does not make every feature universal: vendor-specific capabilities and ecosystem limitations still matter.
Wi-Fi
Best for higher bandwidth, mains-powered devices, appliances, speakers, cameras, and ESP devices. It is not automatically bad for IoT—but it benefits from stable Wi-Fi, sensible segmentation, and devices with local APIs.
MQTT
A local publish/subscribe messaging bus. A sensor publishes a topic; HA or another consumer subscribes. It is excellent for decoupling device firmware from automation logic.
Local-first purchase checklist
Before buying:
[ ] Does it work locally without an internet account after setup?
[ ] Is there a documented Home Assistant integration?
[ ] Does it expose standard protocols: Zigbee, Matter, MQTT, ESPHome, ONVIF, local API?
[ ] Is firmware support and security-update history credible?
[ ] Is its power/network requirement appropriate for the location?
[ ] Can manual control still work if HA is down?
[ ] Is data access proportionate to the device’s function?Mesh health
Zigbee
- Put the coordinator away from USB 3 noise and Wi-Fi radios.
- Add reliable mains-powered routers before blaming distant battery sensors.
- Pair devices in their intended final location when practical.
- Keep permit join off except during controlled pairing.
- Back up coordinator data before replacing hardware or changing channels.
Wi-Fi
- Prefer DHCP reservations for infrastructure and servers, not arbitrary hard-coded device IPs.
- Use a dedicated IoT network/VLAN where policy and complexity justify it.
- Keep SSIDs and security settings stable; IoT devices can be fragile during Wi-Fi changes.
- Do not put critical local control behind a cloud-only dependency.
Troubleshooting flow
Device unavailable
→ power/battery?
→ network/mesh path?
→ integration healthy?
→ entity disabled/renamed?
→ logs and last-seen time?
→ service call manually?
→ automate only after root cause is understoodDevice lifecycle
- Record device, room, protocol, power source, and manual fallback.
- Pair/onboard during a deliberate maintenance window.
- Rename device/entity meaningfully and assign an area.
- Add availability/battery reporting where useful.
- Create the simplest safe dashboard control.
- Add automation only after manual operation is proven.
- Document recovery and remove any unnecessary cloud permissions.
When to use ESPHome versus Arduino/ESP32 code
| ESPHome | Arduino/ESP-IDF |
|---|---|
| Fast HA-native sensors/actuators | Custom protocol/timing/library requirements |
| YAML configuration, OTA, common components | Full code control and deeper embedded learning |
| Best first choice for standard home devices | Best when ESPHome cannot model the requirement |
Architecture principle
Do not chase one protocol for every device. Your reliable path is coexistence: Zigbee2MQTT for a proven Zigbee mesh, Google TV Streamer as Thread border router, Matter where it adds interoperability, Wi-Fi/Ethernet for capable devices, and MQTT/ESPHome for local customisation.