SMLIGHT SLZB-06 Setup: Zigbee2MQTT Over Ethernet & PoE

If you’re moving off a USB Zigbee stick, the SLZB-06 is probably the coordinator you’ve landed on. It connects over Ethernet instead of USB, which fixes a specific annoyance. USB 3.0 ports are known interferers for 2.4GHz radios, and a coordinator crammed into the back of a mini PC is rarely where you’d actually want your mesh’s root node sitting. This is a configuration walkthrough, not a buying guide. If you’re still deciding between Zigbee2MQTT and ZHA in the first place, our ZHA vs Zigbee2MQTT breakdown is a better starting point.

What makes an Ethernet coordinator different

A USB stick like the ZBDongle-E or ConBee III is dumb hardware. The radio chip, its firmware, and a serial connection to whatever host it’s plugged into. All the intelligence lives in Zigbee2MQTT itself.

The SLZB-06 puts a small computer in the middle of that relationship. It runs on an onboard ESP32, and that ESP32 runs SMLIGHT’s own SLZB-OS, a web-based configuration layer that handles OTA firmware updates, network and radio-mode configuration, and a Home Assistant integration, all separate from anything Zigbee2MQTT itself does. Bare USB dongles have none of this. There’s no management layer to log into, no firmware update path outside of flashing the stick directly.

Practically, that means you’re managing two things instead of one. There’s the SLZB-OS web interface, reachable at the device’s own IP, and there’s Zigbee2MQTT’s frontend, which now talks to the coordinator over the network rather than through a serial device path.

The SLZB-06 also carries a stronger radio than most USB alternatives — a +20dB amplifier paired with a +5dB antenna. Whether that translates to a meaningfully bigger mesh in your specific house depends on layout and interference sources more than the spec sheet does, but it’s a real hardware difference worth knowing before you assume all coordinators perform the same.

SLZB-06 vs SLZB-07: don’t buy the wrong one

SMLIGHT sells two coordinator lines and it’s an easy mix-up. The SLZB-06 is the Ethernet/PoE line covered here, with the onboard ESP32 and SLZB-OS web UI described above. The SLZB-07 line is USB-connected instead, and drops the onboard computer and web interface entirely. It also ships with a lower-gain antenna than the SLZB-06’s +5dB.

If the listing you’re looking at doesn’t mention Ethernet or PoE, you’re probably looking at the SLZB-07 line, and you won’t get the web-based OTA and configuration layer this guide is partly about. Neither is a wrong choice on its own. They’re different products, and confusing which one you ordered is the actual failure mode here.

Physical setup: PoE or USB-C

The SLZB-06 takes power one of two ways: Power over Ethernet (802.3af), or a separate USB-C connection if you don’t have a PoE switch or injector. The box itself doesn’t include a PoE injector — you get the coordinator, its antenna, mounting screws, and a Micro-USB-to-USB-C adapter — so PoE means supplying your own 802.3af switch or injector, and USB-C is the fallback when you’d rather not.

Because it isn’t tethered to a USB port on your HA host, you get real placement freedom for the first time. Coordinator placement matters for mesh health. Central, away from thick concrete and major Wi-Fi APs, roughly mid-height, are the usual guidelines for any Zigbee coordinator. An Ethernet run (or PoE) lets you actually act on that advice instead of being stuck wherever your server happens to live.

Zigbee2MQTT configuration: TCP vs mDNS

This is the part most existing guides skip or bury in a forum thread. As of Zigbee2MQTT’s current adapter-settings documentation, the serial.port setting in configuration.yaml supports a TCP adapter syntax for exactly this kind of networked coordinator, using the SLZB-06’s default port, 6638.

serial:
  port: tcp://192.168.10.50:6638

The alternative is mDNS/Zeroconf autodiscovery, which points at the device’s hostname instead of a hardcoded IP.

serial:
  port: mdns://slzb-06

The tradeoff comes down to what you’re already running. A hardcoded IP is easy to reason about, but breaks silently if that address ever changes. mDNS survives a DHCP lease change without you touching the config file, at the cost of depending on mDNS actually working on your network, which isn’t guaranteed once VLANs are involved (more on that below).

I think mDNS is the better default here unless you’ve already given the coordinator a DHCP reservation, in which case a hardcoded IP is just as reliable and one less protocol in the chain to troubleshoot.

One setting the port line doesn’t cover: Zigbee2MQTT also has to know which radio it’s talking to. On the base SLZB-06 that’s a Texas Instruments CC2652P, so set adapter: zstack under the same serial: block as the port above. The newer EFR32/MG24-based models in the range (the SLZB-06M variants) use adapter: ember instead. Point the port at the right address but leave the adapter wrong and the connection either won’t come up or behaves erratically — so it’s worth confirming before you start chasing network problems that aren’t there.

Verifying the connection

Once configured, Zigbee2MQTT’s startup log is where you confirm it actually reached the coordinator over the network. A healthy start shows zigbee-herdsman initialising and the coordinator’s firmware version being read back, with no connection errors following it. A wrong IP, a wrong port, or a blocked route usually surfaces as a TCP connection error — a refused or timed-out connection — rather than a Zigbee-level failure. That distinction is useful: it points you at the network path, not the radio. The frontend’s network map is the other useful check. If devices show up and the mesh renders, the network path is working end to end.

Firmware and OTA through SLZB-OS

Firmware updates for the coordinator itself run through the SLZB-OS web UI rather than anything in Zigbee2MQTT or Home Assistant, and SLZB-OS gives you two paths. The online method fetches the latest image directly from SMLIGHT’s servers, so the device needs internet access at update time (there’s also an optional automatic-check schedule that does the same in the background — you can leave it off). The manual method lets you download a .bin on another machine and upload it through the web UI, which updates the coordinator with no internet access from the device at all. If you’re keeping the SLZB-06 on a locked-down VLAN with no outbound access, that offline sideload path is the one you want.

Worth knowing: some SLZB-06 hardware revisions use a CP2102 USB/UART chip that needs the Silicon Labs CP210x driver if your OS doesn’t auto-detect it. This only matters if you’re falling back to a direct USB connection, for flashing or recovery, since normal day-to-day operation is entirely over Ethernet. It’s not something you’ll hit setting the coordinator up for the first time, but it’s the kind of detail that eats twenty minutes if you do end up needing the USB fallback path and didn’t know it existed.

Running two Zigbee networks at once

If you’re migrating gradually rather than cutting over in one go, you may end up running the SLZB-06 alongside an existing coordinator for a while, each driving its own Zigbee2MQTT instance. That’s supported, but each instance needs its own MQTT base topic, its own PAN ID, and its own Zigbee channel. Skip any one of those and the two networks will interfere with each other rather than coexist. This is worth planning before you start pairing devices to the new coordinator, not something to discover after your existing mesh starts dropping packets.

The network side: give it a real address

Because the SLZB-06 is now a networked device with its own IP rather than a USB peripheral, it’s worth treating it like the rest of your IoT infrastructure instead of an afterthought. A DHCP reservation and a spot on a segmented IoT VLAN (iot.lan, or whatever your equivalent is) keeps it from wandering to a new address and keeps it out of the same broadcast domain as your general-purpose devices. Our guide to putting Aqara and Xiaomi devices on an IoT VLAN covers the segmentation approach in more detail. If you’re using mDNS discovery rather than a hardcoded IP, confirm multicast traffic actually crosses your VLAN boundary first. It doesn’t by default on a lot of consumer router setups, and that’s a more likely cause of a “coordinator not found” error than anything wrong with the SLZB-06 itself.

A few common questions

Does the SLZB-06 work with Zigbee2MQTT out of the box? Yes, once you point serial.port at it using either the TCP or mDNS syntax above and set the matching adapter for your model. There’s no separate driver install for normal operation, that’s a USB-fallback-only concern covered above.

Does it need a cloud account to function? No. Zigbee2MQTT talks to it over your LAN, and SLZB-OS’s own web UI is local too. There’s no login, no account, no vendor cloud in the control path. The only time the device reaches outward is an online firmware fetch from SMLIGHT’s servers — and even that has an offline manual-upload alternative, so you can run the coordinator fully cut off from the internet if you choose.

How do I find it if the IP changes? That’s what the mDNS option (mdns://slzb-06) is for. If you’d rather not depend on mDNS, a DHCP reservation on your router keeps the IP fixed instead.

An Ethernet-connected coordinator with its own onboard OS still only speaks Zigbee on one side and your LAN on the other. No Tuya- or Aqara-style cloud account shows up anywhere in this setup, which is the point of running one in the first place.

SMLIGHT’s SLZB-07 line strips the onboard ESP32 and web UI back out, betting that buyers who plug a coordinator straight into their Home Assistant host just want SMLIGHT’s radio and antenna quality in a plain USB dongle, without another management interface to run. It’s USB rather than Ethernet, so the PoE and placement freedom that justify the SLZB-06 aren’t part of that trade. Whether that split holds up as SMLIGHT’s coordinator range matures, or whether SLZB-OS features migrate into the plain USB line, is worth watching the next time they refresh the model lineup.