The Sonoff S26R2ZB shows up in two different contexts these days. Some readers already have one running from years back and just want it working again on Zigbee2MQTT or ZHA after a network rebuild. Others are looking at a secondhand listing, because ITead discontinued the S26R2ZB in favor of the newer S60ZB series, but the older unit still circulates widely enough to be worth documenting on its own.
Before writing this I went through Zigbee2MQTT’s official device page, its network-stability guide, a GitHub discussion with the blunt title “Sonoff S26R2ZB terrible performance,” and two Home Assistant Community threads. The setup itself is short. The two things worth knowing before you commit one of these to your network take longer to explain: a device-type inconsistency that can hand you a light entity instead of a switch, and a mesh-routing problem that’s specific to this plug rather than to Zigbee smart plugs generally.
What the S26R2ZB is, and why it’s discontinued but still around
The S26R2ZB is a mains-powered Zigbee smart plug. No battery, one relay, one status LED. It shares a shell with Sonoff’s more commonly reviewed S26 Wi-Fi/eWeLink plug, but the R2ZB is a separate, Zigbee-only board.
ITead has discontinued this model and now points buyers toward the S60ZB line. Units continue to turn up through third-party marketplaces and secondhand channels.
Discontinued doesn’t mean unsupported here. It means ITead isn’t manufacturing new stock through its own channels. Zigbee2MQTT and ZHA support has nothing to do with whether the vendor is still selling the thing.
Pairing and Zigbee2MQTT setup
Pairing follows Sonoff’s standard hold-and-flash procedure. Hold the physical button on the plug for about 5 seconds until the LED starts flashing, then put your coordinator into pairing mode. Zigbee2MQTT and ZHA pick it up identically, since pairing happens at the Zigbee protocol layer, before either integration is involved.
Once paired, Zigbee2MQTT’s official device page exposes exactly one capability, a switch with a state property that accepts ON, OFF, and TOGGLE. That’s the whole core function. Two optional properties extend it, and both are sent in the payload alongside state rather than configured per device. on_time turns the plug on and then automatically off again after a set number of seconds. off_wait_time sets a cooldown during which the plug will not answer further timed-off commands. The device page is upfront that support for both depends on the plug’s own firmware, and some units reportedly need both properties set together before the timed-off behavior works at all.
{
"state": "ON",
"on_time": 10,
"off_wait_time": 2
}
There’s no action expose by default. An optional state_action device setting can be turned on to also publish state changes as an action event, but out of the box you’re just working with state.
ZHA quirk: some units report as a light, not a switch
One Home Assistant Community thread documents something that has nothing to do with either integration’s own code. Some S26R2ZB units report a raw Zigbee device_type of 0x0100, the on/off light type, while other units of the same model report 0x0009, the mains power outlet type that ZHA renders as a switch. That’s a difference tied to the plug’s own hardware or firmware batch, not a bug in ZHA or Zigbee2MQTT.
ZHA reads that field and builds its entity accordingly, so a plug reporting 0x0100 becomes a light entity in Home Assistant instead of a switch. The thread’s participants didn’t land on a firmware fix, since the device_type value comes from the plug itself rather than from anything ZHA interprets. Their workaround was manually recreating the entity through customization.
Zigbee2MQTT sidesteps the whole problem. Its device page for the S26R2ZB defines a single switch expose regardless of what the underlying device_type field says, so every S26R2ZB looks the same to Home Assistant through Z2M. That’s a genuine, if narrow, case where Zigbee2MQTT’s own abstraction layer buys you something ZHA’s more literal device-type mapping doesn’t, and it fits the broader pattern in our ZHA vs Zigbee2MQTT comparison.
If you’re on ZHA and this plug lands as a light entity, any automation written expecting a switch-domain entity will need rewriting. There’s no known firmware fix on record, only the workaround of correcting the entity manually in Home Assistant.
Should you use it as a Zigbee router? The mesh-routing complaint
Mains-powered Zigbee devices generally act as routers on your mesh, extending range for battery-powered end devices nearby. That’s usually a point in a smart plug’s favor, and it’s the logic behind most router vs end device planning. It’s also where the S26R2ZB’s most substantive complaint shows up.
This one is not just a forum grievance. Zigbee2MQTT’s own network range and stability guide names the device directly, stating that some versions of the S26R2ZB are known to be limited routers of mediocre quality that may not work well within a network. A GitHub discussion titled “Sonoff S26R2ZB terrible performance” fills in the detail: end devices failing to join through the plug even at close range, with very low LQI numbers on links to and from it. Participants tie the behavior to the plug’s CC2652-based radio module and report that ITead treated it as firmware-level. They also found the hardware isn’t uniform across production runs, which is presumably why the documentation hedges with “some versions.”
The documentation also publishes a remedy, which is the part worth acting on. Add one or more better-quality routers to the network, then re-pair the affected end devices with permit-join restricted to the good router so they bind to it rather than to the plug. It doesn’t repair the S26R2ZB; it routes around it.
Before assuming the plug is carrying its share, check the LQI on any device routing through it against your other routers. Our guide to reading the Zigbee2MQTT network map covers what those numbers do and don’t tell you.
Treat this plug as a device you’re happy to power, not as network infrastructure. Zigbee2MQTT’s own documentation classes some versions as limited routers of mediocre quality. If you already depend on one, the documented fix is to add a better router and re-pair your end devices onto it, not to wait for a firmware update on a discontinued product.
Other known issues: dropouts and pairing
Two more Home Assistant Community threads round out the picture. One reports the plug becoming unavailable intermittently, a different symptom from the routing complaint above since it describes an already-paired device losing contact rather than a new device failing to join through the S26R2ZB as a router. The other covers pairing failures, S26R2ZB units that won’t complete the join process at all.
Zigbee2MQTT’s issue tracker carries the same dropout symptom under its own reports, including units leaving the network shortly after joining and others disconnecting after a day or two, and entries naming this plug have continued to appear well after the routing discussion went quiet. The honest summary is that this plug has accumulated more open, unresolved reports than a typical Zigbee smart plug of similar simplicity, without one cause tying them together.
If a Tuya-brand plug on your network is showing comparable flakiness, our TS011F troubleshooting guide covers a similar pattern on a different chipset, worth comparing notes against before assuming it’s the same problem.
Should you still use one in 2026?
For the existing owner, yes. Nothing here is disqualifying if you already have one running. The core switch function is basic and well-supported through Z2M’s official device page, the device-type quirk is a one-time entity fix if you hit it, and the routing complaint only matters if this specific plug is one of your mesh’s routers.
For anyone shopping new, honestly, I wouldn’t reach for an S26R2ZB in 2026 when ITead’s own successor line exists and the project that supports it names it in the documentation as a mediocre router. That’s not a verdict on the S60ZB itself, which isn’t covered here.
Frequently asked questions
Why does my Sonoff S26R2ZB show up as a light instead of a switch?
Some units report a raw Zigbee device_type of 0x0100 (on/off light) instead of 0x0009 (mains power outlet, which ZHA renders as a switch), a difference tied to the plug’s hardware or firmware batch. ZHA reflects that value directly, so the entity type follows it. Zigbee2MQTT normalizes every S26R2ZB to a single switch expose regardless.
Is the Sonoff S26R2ZB a good Zigbee router?
No. Zigbee2MQTT’s own network-stability documentation classes some versions as limited routers of mediocre quality, and a GitHub discussion documents end devices failing to join through it at close range. The documented remedy is to add a better-quality router and re-pair your end devices onto it.
Is the Sonoff S26R2ZB discontinued?
Yes. ITead has discontinued it in favor of the S60ZB series. Units still circulate through third-party marketplaces and secondhand.
Why does my Sonoff S26R2ZB keep going unavailable?
Both the Home Assistant forums and Zigbee2MQTT’s issue tracker carry dropout reports separate from the mesh-routing complaint. No single root cause has been confirmed, so there’s no one fix to point to.
Does the Sonoff S26R2ZB work with ZHA and Zigbee2MQTT?
Yes, both support it. Pairing is identical either way since it happens at the Zigbee protocol layer. The practical difference is the entity-type quirk above. Zigbee2MQTT normalizes it away, ZHA does not.
What this covers, and what it doesn’t
This is built from Zigbee2MQTT’s official device page and network-stability guide, one GitHub discussion, and Home Assistant Community and Zigbee2MQTT issue reports. No S26R2ZB was paired or tested for this piece, and the routing and dropout claims above are exactly as sourced, not independently confirmed. Everything covered here runs on your own Zigbee network and MQTT broker. Neither Zigbee2MQTT nor ZHA needs to reach the eWeLink cloud, built by CoolKit rather than by ITead itself, for any of it to work, whatever the plug’s Wi-Fi sibling might expect.
If you’re running one as a router today, checking its LQI numbers periodically costs nothing and tells you fast whether it’s the weak link in your mesh.