Hello!
Is it possible to make zigbee pairing like in zigbee2mqtt? In zigbee2mqtt there is an option to enable zigbee pairing only for 1 device in the network. It is very useful, when the new device can see more router devices, and in many cases it will pair with a router woth worse signal.(it will not change to better router later). If You enable pairing only for the preferred router, the new device is forced to the preferred router.
I see on port 8080 there is z2m running. If we can get full access to z2m, it will be a much better, it will also solve my request…is that possible? I see no reason to lock it for users…
I’ve been using Z2M for years, and this doesn’t change anything—especially since the mesh network tends to shift constantly. I currently save a snapshot of the mesh every week, and some devices never stay connected to the same point where they were initially paired; they usually end up changing. It’s not an issue for me, though, because I have a solid mesh network running on my ZbUltra and NSPanel.
It is not locked. It hasn’t been implemented because it offers no clear, lasting benefit for the average user. eWeLink is designed to be simple to use, and adding a router selection option would introduce extra complexity without guaranteeing any meaningful improvement in network stability. So there is a reason it hasn’t been implemented.
I’ve experienced this many times with ZHA. Pairing through the preferred router sometimes doesn’t work at all, and even when it does, the device may later choose a different parent. Zigbee is a dynamic mesh network, and the topology can change after pairing.
So, while this feature might help in some cases during initial joining, I wouldn’t expect it to provide lasting control over which router a device uses. The network doesn’t necessarily keep the topology we intended when pairing the device.
That was my expectation too, but in many cases, for example with 2 Sonoff Smart water valves, only pairing with preferred routers solved the connection problems, these devices never switched to better signal
If z2m is running in background, why dont You allow access to z2m interface for advanced users, and keep ewelink interface for basic users?
The valve likely won’t switch to a router located next to it—unless that router happens to be a ZBMINI-R2. If it’s an Aqara device, there might be an incompatibility (a known issue in Z2M; most users avoid Aqara routers). If it’s a generic Tuya device, it might simply be that it doesn’t identify that router as the best path. The point is, nothing is locked; what you want to achieve is entirely possible—just click the button next to the “join” button.
I wouldn’t worry too much about signal readings as long as the devices work reliably. RSSI and LQI are just indicators, and higher values don’t automatically mean a more stable connection. If a device responds consistently and doesn’t drop off the network, there’s little reason to force it to use a different router just because another one shows better numbers.
As @Unnamedi and me mentioned before, Zigbee is a dynamic network, and trying to micromanage its topology is unlikely to provide a reliable, long-term solution. Pairing with a preferred router may have helped in your particular case, but it doesn’t guarantee that the device will stay connected through that router or that the network will remain more stable.
Could you share a bit more detail about your setup? Which SONOFF hub or gateway are you using, how are the two water valves and their routers positioned in relation to each other, and how did you determine that pairing through a preferred router solved the problem? Did the valves actually disconnect or become unresponsive when connected to other routers, or was the difference mainly in RSSI/LQI readings?
Also, regarding port 8080, which device did you find it on, and how did you identify the service as Zigbee2MQTT? SONOFF’s eWeLink ecosystem uses its own proprietary Zigbee implementation, so the assumption that Z2M is running in the background and that its frontend could simply be exposed needs clarification.
One final point: perhaps this question would be better suited to a Zigbee2MQTT or general Zigbee networking forum. This discussion is specifically about SONOFF/eWeLink solutions, so we can only comment on the assumptions about Z2M in that context.
The ZBBridge Ultra, NSPanel Pro, and iHost all use Z2M under the hood. Of these, the iHost is the only one that does not provide access to the Z2M interface, whereas the other two do. However, for Sonoff Zigbee devices, they use their own proprietary drivers—distinct from those used in the standard Z2M version. At the very least, all Sonoff devices appear as if they are using an external converter.
Currently I have HA installation with z2m, this pairing option is working there. My NSpanel Pro is in router mode now. I would like to use NSPanel as a coordinator, but with “central” pairing it is unstable. The devices are compatible because they are working together with the current z2m coordinator. I saw zigbee2mqtt logo on zigbee map page on port 8080, thats why I think there is a z2m in bakground:
Could you clarify how you verified that Z2M runs under the hood on all three devices? Is this documented somewhere, or did you inspect their firmware or running processes? In particular, do you have evidence that the stock firmware on the ZBBridge Ultra and NSPanel Pro uses Zigbee2MQTT, rather than SONOFF’s own Zigbee implementation? And could you point to examples of the external converters you mentioned?
The zigbee map, running on NSPanel Pro is a z2m site…
In the update logs, they usually indicate when Z2M has been updated.
You can only see this because your nspainel is set as a router, not as a coordinator.
NSPanel Pro can expose paired Zigbee devices via MQTT, but that doesn’t mean its stock firmware uses Zigbee2MQTT. The screenshot shows the Z2M frontend, but it doesn’t explain how it was installed or what role it plays in the overall setup.
I think you’re drawing too broad a conclusion about the architecture of SONOFF’s stock firmware based on this evidence alone.
Just read the device update changelogs; all three mention Z2M.
That’s an interesting clue, but update logs alone don’t necessarily establish how Z2M is integrated. Could you share an example of the update log mentioning Zigbee2MQTT, and specify which device it refers to? That would help clarify whether Z2M is part of the stock firmware or a separately managed component.
iHost
New Features:
Added support for shutting down the device from the local web interface.
Added support for intelligent temperature control feature of SONOFF TRVZB.
Added support for the SONOFF MINI-ZBD intelligent dry contact module.
Upgraded the Matter Bridge SDK to V1.5.0.
Optimizations:
Optimized the default gateway naming when pairing with SmartThings and Alexa through Matter Bridge.
Optimized the settings for the power-on state feature of third-party brand devices.
Upgraded the Zigbee firmware to 8.0.2 to improve Zigbee device connection stability.
Upgraded the Z2M version to support more Zigbee sub-devices.
Bug Fix:
Fixed an issue where syncing the gateway to Alexa through Matter Bridge could fail.
Fixed the issue of timeout when adding ONVIF/RTSP cameras.
ZBULTRA
V1.21.0（2026/05/11)
New Features:
Beta users will get early access to new features. You can enroll in the Beta Program via the Local Web Portal or the eWeLink App.
Beta builds will start at version 3.1.0, with later Beta releases using odd-numbered middle versions.
To restore the Stable version, perform a factory reset on the bridge while it is connected to the internet.
Note: A factory reset will erase all data. Please proceed with caution.
Optimizations:
Bug Fixes:
The NSPanel Pro is the same. As mentioned, everything is accessible via the device’s URL at port 8080; the only exception is the iHost, which does not provide access to that screen—though if you examine the iHost logs, you will find the information there. All of this is included in the device firmware updates.
As mentioned, they use the Z2M codebase to access devices from other brands. However, they typically do not use the latest version of Z2M; instead, they use a version that has been tested and validated by them. That is why it is necessary to know which version is installed on the hub—it is usually a version from 6 to 8 months ago.
The point is simply that the user doesn’t have access to modify Z2M itself; however, for the average user, what has been implemented and is currently in use is more than sufficient for this purpose.
As for the configuration the colleague is asking about, it’s accessible to everyone; the only reason he doesn’t have access is that his NSPanel isn’t set as the coordinator. Consequently, he doesn’t have the “JOIN” option.
