Why Wi-Fi at all?
Pros: no extra hub or coordinator, devices talk directly to your network, and there is a huge range of cheap hardware. Cons: Wi-Fi devices use more power than low-power mesh radios, so battery sensors need careful design (deep sleep, long reporting intervals) or mains power. They also add clients to your router and depend on signal strength. Mains-powered devices (power monitoring plugs, relay modules, environment sensors on USB power) are the sweet spot.
Three common families
- ESPHome (DIY firmware). You flash an ESP32/ESP8266 board from a YAML config and attach sensors (the BME280 temperature/pressure/humidity sensor is a classic). Devices talk to Home Assistant through the native API, with optional encryption. You own the firmware, so you decide the update interval, behaviour when Wi-Fi drops, and so on. See the companion project thread in this forum.
- Shelly. Ready-made relays, power meters, sensors. Home Assistant's Shelly page lists the integration as Local Push. For battery-powered Shelly devices the docs have specific notes: Gen1 battery devices need the CoIoT peer set to your Home Assistant IP and port 5683 (unicast) and a manual restart; Gen2+ battery devices may need the outbound WebSocket pointed at Home Assistant; battery devices must be woken by pressing the button before setup, and firmware updates cannot be triggered from HA while they are asleep. Read the page for your generation first.
- Tuya / Smart Life devices. Very cheap and widely sold under many brand names. The HA Tuya integration is Cloud Push: you sign in via the Tuya Smart or Smart Life app by scanning a QR code, and new devices need the integration reloaded to appear. That means it depends on Tuya's cloud. If the internet or the vendor is down, control may stop. Some people use local-only community options instead; I have not verified any here, so please share what works for you.
- 2.4 GHz coverage: most of these devices only use 2.4 GHz. Check signal at the sensor location before committing.
- Reserve an IP address in your router for each device (DHCP reservation). It makes troubleshooting, firewall rules and static integrations far easier.
- Use a separate IoT SSID or VLAN. ESPHome's security guide says its devices are designed for trusted networks behind a perimeter and notes that mDNS discovery does not cross VLANs. Its suggested approach for VLAN setups is to dual-home the Home Assistant host (one interface on each network) rather than rely on a mDNS reflector, or to use static IPs and add devices by address.
- Do not use open or WEP networks. ESPHome's guide recommends WPA2 at minimum and WPA3 if every device supports it, and Ethernet where practical.
- Know what each device does when Wi-Fi fails. For example, will a Shelly relay still work from its wall switch? Will an ESPHome board reboot in a loop or keep running?
- Plan for battery life if you go battery-powered: long update intervals, and test with real readings over weeks rather than the spec sheet.
- Change any default password, and set a password on any local web page the device exposes.
- Turn on API/OTA encryption where available (ESPHome supports both).
- Prefer local control over cloud where you can, and block devices from the internet if they do not need it. Test first, because some devices misbehave when blocked.
- Keep firmware updated. Cheap devices often have no update path, which is a reason to prefer devices you can reflash.
Question for the group: which Wi-Fi sensors have been the most reliable for you, and which ones did you give up on? Do you keep them on a separate IoT network?