You are using the built-in Zigbee chip (MG21) as Zigbee router, not Zigbee coordinator (adapter). The v4.0.x firmware doesn’t support this mode.
If you want to manage Zigbee devices with Zigbee2MQTT, and also want to utilize the built-in Zigbee chip of NSPanel Pro, my proposal is:
Use the built-in Zigbee chip as Zigbee coordinator as it is. Which means NSPanel Pro has its own Zigbee network and Zigbee devices.
Export these Zigbee devices from NSPanel Pro to Home Assistant through MQTT. You are using Zigbee2MQTT, so you should already have MQTT broker running on Home Assistant.
The feature described in the second point of the above is under development right now. We will release it on November, probably before the second half.
Update on 2025-10-18: My bad! NSPanel Pro v4.0.x firmware does support Zigbee Router mode, and we will continue to support it.
thank you for the response. How does this work with multiple panels if they are all a coordinator? If I have 3 different panels would I have 3 different networks that all need to be exported? Doesn’t that defeat the purpose of what a zigbee network is supposed to be?
Yes, @jam3 has pointed out, you will have 3 Zigbee networks (4 if you count Zigbee2MQTT), and they work side by side. One could even argue that using 3 separate small Zigbee networks performs better than using only one big Zigbee network.
Since they are all managed by Home Assistant’s MQTT Integration, you can see all your Zigbee devices (including Zigbee devices from your Zigbee2MQTT instance) on the same webpage (http://homeassistant.local:8123/config/devices/dashboard?domain=mqtt). You won’t tell the difference between using 3 separate small Zigbee networks and using only one big Zigbee network from that webpage.
Running multiple Zigbee coordinators via MQTT might be a recipe for chaos. Splitting your Zigbee setup into multiple networks (ZHA, Zigbee2MQTT, deCONZ, etc.) and stitching them together with MQTT might sound modular and elegant, like building a smart home with Lego bricks. But in practice, it can feel more like juggling chainsaws in a wind tunnel.
Each coordinator creates its own Zigbee network with its own channel, routing logic, and quirks. That means more manual configuration, more points of failure, and more chances for your devices to ghost you when you need them most.
And let’s talk latency. Zigbee devices from different networks don’t talk directly. They rely on MQTT and Home Assistant to play matchmaker. So every cross-network automation takes the scenic route: Zigbee → Coordinator → MQTT → Home Assistant → MQTT → Other Coordinator → Zigbee.
Depending on traffic and broker performance, this can introduce delays that make your “instant” light switch feel more like a polite suggestion.
Then there’s the 2.4 GHz spectrum, already a battlefield thanks to Wi-Fi, Bluetooth, and ESPHome. Each Zigbee network grabs its own channel, and if you don’t plan carefully, you’ll end up with radio spaghetti and signal dropouts. Think of it as hosting four rock concerts in adjacent rooms and hoping no one complains.
Also, Zigbee doesn’t do cross-network routing. Devices in separate networks won’t help each other out, even if they’re physically touching. So your mesh becomes a bunch of isolated islands not great for resilience or coverage.
Sure, Home Assistant pulls all the MQTT entities into one dashboard, but each network might use different naming conventions, entity types, and behaviors. Debugging automations becomes a game of “guess which coordinator messed up this time.” By contrast, a setup based on ZHA (Zigbee Home Automation) is much cleaner and more straightforward — especially if you value simplicity, consistency, and minimal middleware. Of course, ZHA doesn’t support multiple coordinators or split networks, but that’s part of its charm: one mesh, one brain, fewer headaches.
Unless you have a very large number of devices or a compelling reason to isolate environments, a single well-planned Zigbee network - whether via ZHA or Zigbee2MQTT - will be more stable, predictable, and easier to maintain than a multi-coordinator circus.
Sorry for the rambling, but it kind of makes sense, doesn’t it?
fw ver 4 will be surely great and I like it a lot already now. Just a few bugs i am noticing. S-Mate works somehow incorrectly (one click generates a lot of clicks in the system) and i have also one 4CH 7-32V zigbee switch which can be seen in ewelynk app, but timeout appears always after clicking on any button in the app. Could you please check? 1001893437
Indeed, it does not support this mode. However, the eWeLink app does not reflect this change, which may be misleading. Especially when the purpose and status of version 4.X are overlooked
Yes, I have app 30 Zigbee devices and everything works just fine. Also another 7-32V 2ch zb switch works fine so I have problem only with the 4ch and 2 s-mates which both behave in same way.
I have already submitted log several days ago so may be you can find it in history otherwise I can send a new one tomorrow evening.
There may be bugs with Zigbee Router mode but we do have kept this feature in v4.0.x firmwre. So submitting the log could help us solve the issue more quickly.
Hi, this is a bit off topic, but I’d like to know if you have any official plans for a LAN addon for Home Assistant. I’m currently pairing my Zigbee and WiFi devices via Metter over the Zigbee Bridge Ultra, but sometimes Metter can cause issues. 2) I’m pairing my Sonoff buttons (SNZB-01-SNZB-01P) to Home Assistant via the Zigbee Bridge Ultra, but it only shows the battery percentage in the automation. This isn’t very good. Are you working on a solution? 3) Is it possible to access the internal speaker of the Zigbee Bridge Ultra and NS Panel Pro on Home Assistant?
I already moved them back to hub mode but can switch them back and try to rebind them. Additionally I am noticing devices just go offline and there’s to really way to get to Home Screen to submit feedback when running fdroid home assistant in full screen:
After updating to 4.0.7, I can no longer swipe between screens both ways. In addition, the default screen order can’t be changed — my default screen is stuck at the end and I can’t move it closer to the Main screen. Also, on that screen the NSPanel cameras (RTSP added in device) are auto-placed first and can’t be moved to the back in the app.
Steps to reproduce:
- Open NSPanel Pro on 4.0.7
- Try swiping left/right between screens → only one direction works
- Try reordering screens → default screen stays at the end, cannot move it
- Open the screen that shows cameras → cameras appear first and cannot be reordered
NSPanel Pro reports “No camera added”, even though two RTSP cameras are already added and fully functional through the menu or device tile. They can be opened and viewed normally, but the main screen still displays the “no camera” message. This worked correctly in the previous version.
How do you run Home Assistant in full screen? Did you set Home Assistant as the Home App(Launcher)? NSPanel Pro App won’t run if it is not the Home App after NSPanel Pro reboot (we are working on solutions for this issue).
