Short Answer: Keep Stock Shelly Unless You Need a Specific ESPHome-Only Win

For most Home Assistant homes, the right default is to keep Shelly on stock firmware. Home Assistant's official Shelly integration supports auto-discovery, talks directly to the device, and explicitly says a cloud connection is not needed. Shelly's own current docs also show that Gen 3 devices can disable the cloud while still exposing local features such as Bluetooth gateway, MQTT, RPC, local actions, and scripts.

Flash ESPHome when you have a concrete requirement that stock Shelly does not meet well: on-device fallback logic for important relays, custom sensors or entities, a fully YAML-defined fleet, or a true ESPHome Bluetooth proxy that supports active GATT connections. That is a real engineering reason. "Because ESPHome is cooler" is not usually a strong enough reason once the relay is already in the wall.

Important boundary: this is a firmware-architecture guide, not a mains-wiring tutorial. In-wall relay installation may require a qualified electrician depending on your region.

Why This Question Keeps Coming Up

This is one of the most persistent Shelly questions in the Home Assistant world because Shelly sits in a confusingly strong middle ground. It is already local-friendly, yet it is also hackable enough that people wonder if leaving the stock firmware in place means leaving capability on the table.

The demand signal is easy to defend. On April 26, 2025, a Home Assistant Community thread asked the exact beginner question: why flash ESPHome onto a Shelly when the Shelly is already smart? On January 29, 2026, another forum thread asked how to back up or restore Gen 4 Shelly firmware before flashing, which is the more advanced version of the same uncertainty. On Reddit, a July 2025 Works with Home Assistant discussion asked what the benefit of ESPHome over Shelly firmware actually is, while a March 2026 large-deployment thread showed why some users standardize on ESPHome for fleet management and why others push back that network design may be the real issue.

Inference from those sources: people are not asking because Shelly lacks local control. They are asking because both paths are plausible, and the wrong reason to flash is easy to confuse with the right one.

What Stock Shelly Already Gives You

1. Local Home Assistant control

The official Shelly integration is not a cloud wrapper. Home Assistant says it communicates directly with the device, and for Gen 2+ hardware it uses Shelly's RPC model. If all you want is stable local switching, power monitoring, cover control, detached-mode events, and normal Home Assistant automations, stock Shelly is already on the correct side of the local-vs-cloud line.

2. Local logic on the device

A lot of people assume ESPHome is required for local device-side behavior. That is not true. Shelly's current scripting docs say Shelly devices run JavaScript directly on-device for local automations and integrations, with no cloud or external server required. The Gen 3 control docs also expose local actions, scripts, schedules, detached mode, and webhooks from the device UI itself.

That does not mean stock Shelly and ESPHome feel the same to build on. They do not. It means the baseline question is not "local or cloud?" The real question is "which local toolchain fits the job better?"

3. Bluetooth, MQTT, and RPC options without reflashing

Stock Shelly can do more than plain switch control. The Home Assistant integration says Gen 2 and newer non-battery Shelly devices can act as Bluetooth proxies for advertisement forwarding, and Shelly's own device settings expose Bluetooth gateway, MQTT, outbound WebSocket, and RPC-over-UDP controls. So if your goal is simply more integration options, you may already have them without touching the firmware.

When ESPHome Is Actually Worth It

1. You need the relay to behave intelligently when Home Assistant is down

This is the strongest reason to flash. In the April 2025 forum thread, multiple examples centered on home-down resilience: detached smart-bulb fallbacks, boiler control that still works if Wi-Fi or Home Assistant disappears, and input-to-output logic that should continue without the central server.

If the device is part of something that must remain sane during outages, ESPHome's device-side automations can be the cleaner long-term path, especially if you already build the rest of your edge logic in YAML.

2. You want custom I/O, sensors, or entity behavior

Community examples here are concrete, not theoretical: attaching extra sensors, exposing a more suitable entity type, tuning dimming behavior more precisely, or building a custom cover/fan abstraction instead of accepting the stock device model. If the relay is becoming a small general-purpose embedded node instead of just a relay, ESPHome starts to make much more sense.

3. You want one repeatable, backup-friendly configuration method across a fleet

A recent Reddit discussion from a large Shelly deployment described a familiar benefit: config files instead of a web interface, easy reuse of common snippets, and easier restore when something goes wrong. Home Assistant's ESPHome integration also highlights the native ESPHome API, persistent connections, and near-real-time push updates. If you already manage many ESPHome devices, putting Shelly into the same operational model can reduce cognitive friction.

4. You specifically need a true ESPHome Bluetooth proxy role

This is the most common technical misunderstanding. Stock Shelly Bluetooth proxying is not the same thing as an ESPHome proxy. Home Assistant's Shelly docs say Shelly forwards Bluetooth advertisements but does not support active GATT connections. The general Home Assistant Bluetooth docs, by contrast, say remote adapters can handle both advertisement data and active connections, and ESPHome's Bluetooth proxy docs say the default proxy provides three active GATT slots.

So if your goal is BTHome-style passive listening, stock Shelly may be enough. If your goal is broader BLE device support that needs active connections, ESPHome is the right answer.

If you need... Keep stock Shelly Flash ESPHome
Basic relay control, energy monitoring, detached-mode events, and local Home Assistant automations Usually yes. You already have the core value without reflashing. Usually unnecessary.
Logic that still behaves correctly when Home Assistant or Wi-Fi is having a bad day Possible in some cases through Shelly scripts and local actions. Often better. This is one of ESPHome's clearest wins.
Active Bluetooth GATT connections for BLE-heavy device support No. Shelly's proxy path does not support active GATT. Yes. ESPHome proxying is the cleaner fit.
External sensors, unusual entity models, or custom hardware behavior Limited compared with ESPHome. Yes. This is exactly where ESPHome shines.
The easiest first-time deployment and the least risk of regretting the choice later Yes. Leave the proven local firmware alone. No, unless the added capability is already justified.
A standardized YAML-based fleet with reusable config patterns Not its strength. Often yes for large or highly customized installs.

When You Probably Should Not Flash

1. The device's job is simple and already works

If the Shelly is just turning a light, fan, or pump on and off while reporting energy cleanly to Home Assistant, community replies keep landing in the same place: there is usually no sense changing the firmware. That is especially true after the relay is installed and hidden behind a switch plate.

2. You are assuming rollback will be effortless

Do not plan around a carefree "I'll just switch it back later" workflow. The January 2026 Gen 4 forum thread exists because people still worry about how to back up and restore newer Shelly firmware safely before experimenting. And on the ESPHome side, a feature request opened on June 10, 2024 asked for factory-fresh Shelly devices to be flashed over the air instead of opening and soldering, with the stated alternative still being to open the device and flash it over serial. That is not the profile of a no-risk toggle.

3. Your real problem may be Wi-Fi or network topology, not firmware

One of the more useful recent Reddit conversations involved a user frustrated with a very large Shelly deployment. Several replies immediately challenged whether the root problem was firmware at all, or simply a Wi-Fi design that had outgrown the network around it. That is a good instinct.

If your Shelly fleet is spread across weak access points, bad channel planning, or awkward VLAN rules, firmware swapping can become a way to misdiagnose a network problem. That is why articles like Should Home Assistant Be on an IoT VLAN? matter more than brand arguments once the device count gets high.

Tara's Take

Tara's default would be:

  • Leave Shelly on stock firmware for straightforward relay, cover, and energy-monitoring jobs.
  • Flash ESPHome on purpose when the device needs to be more than a relay: richer edge logic, custom sensors, or a proper BLE proxy role.
  • Fix architecture before firmware when the pain smells like Wi-Fi coverage, VLAN policy, or role confusion rather than missing device features.

That keeps the house boring in the good way. Boring means the lights still work, the fan still works, the relay still reports power, and nobody has to remember which clever experiment is hiding behind which switch.

If this firmware decision is part of a bigger local-control plan, these guides cover the adjacent choices that usually matter next.

FAQ

Does Shelly already work locally with Home Assistant?

Yes. Home Assistant's Shelly integration communicates directly with the device and says the cloud is not required. For a normal local Home Assistant install, stock Shelly is already a local-control path.

Does flashing ESPHome make a Shelly more private?

Not automatically. Stock Shelly can already run with the cloud disabled, plus local RPC, Bluetooth gateway, MQTT, scripts, and local actions. ESPHome is mainly about customization and operational consistency, not fixing a cloud dependency that must exist.

Can stock Shelly act as a Bluetooth proxy?

Yes, but with an important limit. Home Assistant says Shelly Gen 2 and newer non-battery devices can forward Bluetooth advertisements, but they do not support active GATT connections. If your BLE device needs active connections, use ESPHome.

Can I go back to Shelly firmware later?

Possibly, but treat that as real work. Current community threads still ask how to back up and restore newer Shelly firmware before experimenting, and the initial-factory OTA flash story in ESPHome is still not effortless enough to assume zero-risk reversal.

Do I need MQTT with Shelly or ESPHome in Home Assistant?

No. Shelly integrates directly with Home Assistant, and ESPHome uses its native API. MQTT is still available if you deliberately want that architecture, but it is not the default requirement for either route.