WiFi Devices.

The WiFi device landscape.

Unlike BLE, Zigbee, or LoRa, WiFi is not a dedicated IoT protocol. It's a general-purpose networking protocol that IoT devices use. This has implications.

Power.

WiFi radios consume substantial power compared to low-power protocols. A WiFi sensor running continuously uses watts; a BLE sensor uses milliwatts. Battery-powered WiFi devices therefore either accept short battery life (weeks to months on the largest practical batteries) or operate in deep-sleep modes that compromise response time.

For mains-powered devices, this is a non-issue. Smart plugs, bulbs, and wired controllers run on the building's power; WiFi's power consumption is irrelevant.

Range.

WiFi range is limited to the WiFi network's coverage — typically 100-200 feet indoors for consumer access points, further for commercial ones. For operations with good WiFi coverage, WiFi devices work where the network reaches; for operations with marginal coverage, WiFi devices struggle at the edges.

Scale.

Consumer WiFi access points handle 20-50 devices well; beyond that, performance degrades. Commercial access points handle hundreds of devices but cost more. For operations with many WiFi devices, the access-point capacity can become the bottleneck.

Security.

WiFi devices, especially cheap consumer ones, have highly variable security. Some run outdated firmware with known vulnerabilities. Some phone home to cloud services with questionable data handling. A deployment of cheap WiFi devices without careful network segmentation creates security risks.

Cloud dependency.

Many commercial WiFi devices require internet access and cloud services to work. The device talks to the vendor's cloud; the cloud talks to the phone app or Home Assistant integration. When the cloud service is down or the internet fails, the device is useless. For critical monitoring, this is unacceptable.

Local control.

Devices with local control (no cloud dependency) are preferable. Some commercial WiFi devices support local control natively; others can have their firmware replaced with Tasmota, ESPHome, or similar to achieve local-only operation.

WiFi devices that work well.

Specific categories where WiFi is the right protocol.

Smart plugs and power monitoring devices.

A WiFi smart plug controls a mains-powered device — a pump, fan, light, heater. Many models also monitor power consumption. Useful for remote control and energy monitoring of existing equipment without rewiring.

The specific product matters. Some brands require cloud services; others support local control. Tasmota-compatible devices (Sonoff, and many older Kasa/TP-Link) can be flashed with Tasmota firmware for fully local operation.

ESPHome-based custom devices.

Covered in detail in [ESPHome](/home-assistant/integrations/esphome). ESPHome devices use WiFi as their communication medium. For mains-powered custom controllers, sensors near power, or anywhere WiFi coverage is good, ESPHome over WiFi is reliable.

IP cameras.

Most IP cameras use WiFi (or Ethernet, which is more reliable for cameras). Cameras generate substantial network traffic; dedicated wired connections or well-planned WiFi capacity matters. [Frigate and Computer Vision](/home-assistant/ai/frigate) covers camera integration in depth.

Commercial WiFi equipment.

Some commercial agricultural and industrial equipment has WiFi interfaces — specific environmental controllers, thermostats, irrigation timers. Quality and integration maturity vary substantially by manufacturer.

WiFi-to-Modbus gateways.

Devices that expose Modbus RTU over WiFi, allowing a host to reach a remote Modbus bus through the network. Useful for isolated equipment locations where running Modbus wiring back to the Home Assistant host is impractical.

WiFi devices that don't work well.

Categories where WiFi is usually the wrong choice.

Battery-powered sensors.

Short battery life (weeks to a few months on the largest practical batteries). For sensors that should run for years on a battery, BLE or Zigbee is appropriate; WiFi is not.

Devices in marginal WiFi coverage.

WiFi's coverage is sharply bounded. A device at the edge of coverage works intermittently. For distant or partially-shielded locations, BLE proxies, Zigbee mesh, or LoRa are more reliable.

Cloud-dependent devices for critical monitoring.

A commercial WiFi temperature sensor that requires the vendor's cloud service fails when the cloud service fails, the internet fails, or the vendor discontinues the service. For monitoring that matters, local-capable devices are better.

Devices in high-interference environments.

2.4 GHz WiFi shares the band with many other devices. In greenhouses with many WiFi clients, BLE sensors, and Zigbee devices, 2.4 GHz WiFi can struggle. 5 GHz WiFi has less interference but shorter range.

Tasmota and alternative firmware.

Many WiFi devices ship with vendor firmware that requires cloud services. Replacing that firmware with Tasmota or similar open-source firmware enables fully-local operation.

What Tasmota does.

Tasmota is open-source firmware that replaces vendor firmware on ESP-based WiFi devices (ESP8266 and ESP32, which many commercial WiFi smart plugs and similar use internally). Tasmota exposes the device's capabilities through MQTT, HTTP, and web interface — all locally, no cloud required. Home Assistant integrates with Tasmota devices via MQTT.

What Tasmota enables.

- Fully local operation (no cloud dependency). - Home Assistant integration through MQTT. - Access to detailed device state and control beyond what vendor apps expose. - Consistent configuration across many devices. - Long-term viability (Tasmota is maintained; vendor firmware sometimes isn't).

Compatible devices.

Sonoff (many models), older Kasa/TP-Link, Shelly (with some models), some budget brands. The Tasmota project maintains a compatibility database. Before purchasing WiFi devices specifically for Tasmota-flashing, check the database for the specific model.

The flashing process.

Over-the-air (OTA) flashing. Some devices can be flashed over WiFi using tools that exploit known firmware features (Tuya-Convert historically, though vendor countermeasures have reduced its applicability).

Serial flashing. Connect a USB-to-serial adapter to the device's internal UART pins (usually requires opening the device). Flash via serial. Reassemble. This works reliably but requires disassembly.

Pre-flashed devices. Some vendors sell devices pre-flashed with Tasmota or with ESPHome. Saves the flashing step. Options include Athom, Shelly, and others.

ESPHome as an alternative.

ESPHome can also be flashed onto many of the same devices that accept Tasmota. For growers already using ESPHome for custom devices, using it for flashed commercial devices keeps a single firmware approach across the deployment. The capabilities are similar; the configuration languages differ.

Commercial WiFi products.

Some commercial products targeted at agriculture or smart home have Home Assistant integrations.

Shelly.

A Swiss company producing WiFi-based smart switches, relays, and sensors. Well-regarded for reliability and local-control support. Many models support local MQTT and have native Home Assistant integrations. Pricing mid-range for the quality.

Sonoff.

Budget-oriented WiFi smart devices. Many models are Tasmota-compatible (community firmware) or officially ESPHome-compatible. The cheapest path to basic WiFi smart switching. Quality varies; firmware-replacement usage extends useful life and capability.

Shelly Plus series and similar.

Newer generations of WiFi relays and sensors with improved hardware and firmware. Often include Bluetooth for configuration; some models support Zigbee or Matter alongside WiFi.

Vendor-specific WiFi thermostats and controllers.

Commercial WiFi thermostats (Ecobee, Nest, and many others) often have Home Assistant integrations. Most require vendor cloud services for the integration; some offer local APIs. For agricultural control, these are more commonly used in packhouses and work areas than in growing zones.

IP cameras.

Reolink, Amcrest, Dahua, Hikvision, Unifi Protect, and many others. Integration quality varies. For serious camera deployments, [Frigate and Computer Vision](/home-assistant/ai/frigate) covers the specific considerations.

WiFi network considerations.

A deployment with many WiFi devices needs the underlying network to support them.

Access point capacity.

Consumer access points (the one that came with the router) typically handle 20-30 active clients well, more with degradation. Enterprise-grade access points handle 100-200 clients each. Operations with many WiFi devices benefit from commercial-grade networking hardware.

Coverage.

A single access point covers a limited area. Operations with multiple buildings or large coverage areas need multiple access points (mesh WiFi consumer-grade, or proper multi-AP enterprise WiFi). Coverage planning matters.

VLAN segmentation.

For security, IoT devices are often placed on a separate VLAN from personal devices and critical computer equipment. The Home Assistant host is reachable from the IoT VLAN (to talk to devices) but devices are restricted from reaching other networks.

This limits the damage from compromised IoT devices. A cheap WiFi sensor that turns out to have a vulnerability, when isolated to an IoT VLAN, can't reach financial systems or personal data.

2.4 GHz vs 5 GHz.

Most IoT WiFi devices only support 2.4 GHz. This is problematic when many WiFi clients also use 2.4 GHz (phones, laptops, tablets). Moving personal devices to 5 GHz where possible leaves 2.4 GHz clearer for IoT.

Guest networks.

Some operations put IoT devices on a "guest" SSID. This is usually a form of VLAN segmentation implemented differently. The effect is similar.

WiFi device failure modes.

Specific problems.

The cloud service that went down. Commercial WiFi devices that depend on vendor cloud services became unavailable when the cloud service had an outage. Local-only operation wasn't possible. Fix: prefer local-capable devices; flash with Tasmota/ESPHome when possible.

The vendor that discontinued cloud support. A vendor decided to stop supporting a product's cloud service. Devices became e-waste despite hardware being fine. Fix: prefer devices with local control; accept that cloud-only devices have limited lifetimes.

The WiFi access point that couldn't handle the load. A consumer AP started dropping devices when the operation added many WiFi sensors. Fix: upgrade to higher-capacity AP, or split devices across multiple APs.

The device that only connected to 2.4 GHz. Device wouldn't connect because the network was 5 GHz. Had to join to a 2.4 GHz network first. Fix: ensure a 2.4 GHz SSID is available for IoT; don't expect 5 GHz-only networks to work.

The IoT VLAN misconfiguration. IoT VLAN was configured but the Home Assistant host couldn't reach devices on it. Fix: firewall rules allowing the Home Assistant host to reach the IoT VLAN (while restricting IoT devices from reaching other networks).

The firmware update that disabled local API. A cloud-backed device's firmware update removed a local API that Home Assistant depended on. Integration broke. Fix: avoid cloud-backed devices for critical functions; monitor for firmware changes that may affect integrations.

The device that kept reconnecting. Marginal WiFi coverage caused a device to reconnect repeatedly. Each reconnect briefly made the device unavailable to Home Assistant. Fix: improve coverage (AP placement, additional APs) or move the device to a better location.

The Tasmota flash that went wrong. Flashing via serial with incorrect wiring destroyed a device. Fix: verify wiring carefully before flashing; practice on a throwaway device first.

The many-device WiFi congestion. A fleet of 50 WiFi devices reporting frequently saturated the AP. Everything became intermittent. Fix: reporting frequency tuning, enterprise AP, or migration to a more scalable protocol (Zigbee for the specific devices).

The device that spied on the network. A cheap WiFi camera phoned home to a server in a country with questionable data handling. Fix: VLAN isolation preventing device-initiated external connections; review of device network traffic before deployment.

What not to do.

Don't use WiFi for battery-powered sensors if battery life matters. BLE or Zigbee are substantially better for battery-powered sensing.

Don't deploy cloud-dependent devices for critical monitoring. A cooler temperature monitor that depends on vendor cloud is a cooler without monitoring when the cloud fails.

Don't skip network segmentation. IoT devices on the same network as personal and business computing equipment is a security problem. VLANs or guest networks contain the risk.

Don't overload consumer WiFi. A cheap AP pretending to serve 50+ IoT devices drops connections. Upgrade the network before blaming the devices.

Don't expect 5 GHz-only to work. Most IoT WiFi is 2.4 GHz only. Ensure 2.4 GHz is available even if primary devices use 5 GHz.

Don't flash firmware without research. Flashing the wrong firmware, using wrong wiring, or flashing a non-compatible device bricks devices. Know what you're doing before starting.

Don't ignore firmware updates. WiFi device firmware often has security updates. Cloud-backed devices auto-update; local-controlled devices need manual update discipline.

Don't assume all commercial WiFi products are equivalent. Integration quality, local-control capability, security practices, and long-term support vary substantially. Research specific models before committing.