NSPanel Pro is described as a Zigbee gateway. As we all know, a Zigbee gateway is a central device that connects and manages Zigbee-enabled devices. It plays a crucial role in forming the network and controlling operations, serving as the primary point of communication between the Zigbee network and other networks or systems, such as a Wi-Fi network.
NSPanel Pro supports LAN mode, which raises the expectation that Zigbee entities would be accessible on the local network to other devices supporting LAN mode. Unfortunately, this is not the case. When, for some reason, there is no contact with the eWeLink server, control of Zigbee devices connected to NSPanel Pro is limited to this panel alone. For instance, sensors such as SNZB-02P or SNZB-06P become unavailable. This raises the question: is NSPanel Pro truly a gateway? Could someone at Sonoff/eWeLink provide clarification?
Another issue concerns the eWeLink Remote functionality in NSPanel Pro. Devices like R5 or S-Mate cease to operate as soon as communication with the eWeLink cloud is lost. Interestingly, this limitation does not affect devices like M5(M), NSPanel, or MINIR4. What is the underlying issue, and can it be resolved?
Additionally, could eWeLink Remote entities be made available in LAN mode? If not, why is this the case? A detailed explanation would be appreciated.
When NSPanel Pro loses connection to the eWeLink server, commands sent from the eWeLink app to control Zigbee sub-devices cannot reach NSPanel Pro. As a result, app-based control of these devices will fail. However, since NSPanel Pro serves as a Zigbee gateway, it can still directly control the Zigbee sub-devices that have been added to it via the Zigbee protocol.
Similarly, R5 and S-Mate can be directly added to NSPanel Pro via Bluetooth and can also be controlled via LAN. (For local scenes: IF R5/S-Mate Clicked/Double Clicked/Long pressed, THEN devices or scenes. If the actioning devices or devices associated with the scenes are NSPanel Pro sub-devices, these will be marked as local scenes.)
Plus, when cloud connection is lost, eWeLink Remote devices added via NSPanel Pro will appear offline(turn gray) in the eWeLink app—this is expected behavior.
On the other hand, devices like M5(M), NSPanel, and MINIR4 remain controllable because they support and have enabled the LAN control feature in the eWeLink app. When the necessary conditions for LAN control are met, the app sends control commands directly to these devices through the router, bypassing the need for an internet connection.
I hope this explanation helps resolve your concerns.
In part it explains this and that, but not entirely. I will therefore ask you to be more specific.
If the NSPanel Pro operates in LAN mode, it should allow control of Zigbee devices within the same local network without requiring cloud access—similar to other devices. However, if the NSPanel Pro serves only as a Zigbee gateway for the eWeLink platform, this limitation needs to be clearly stated in the product description. Currently, this critical detail appears to be missing. If it can operate fully in LAN mode without cloud access isn’t explicitly clarified in the product descriptions I reviewed.
Given that LAN mode functionality is available with devices like the M5 and NSPanel, it raises the question: why is NSPanel Pro unable to support the same operation for eWeLink Remote? Your explanation is not convincing.
I wonder if other NSPanel Pro users share my concerns. Please feel free to comment.
NSPanel Pro, as a Zigbee gateway, can add and locally control other Zigbee sub-devices. This is not limited to eWeLink-supported Zigbee sub-devices—devices from other brands can also be added, as long as they use the standard Zigbee protocol.
Regarding eWeLink Remote:
Currently, the eWeLink Remote devices that can be added to NSPanel Pro are R5 and S-MATE. These devices operate by creating scenes.
For example:
If Scene A is set as follows:
IF S-MATE Clicked
THEN Perform Scene B, Perform Scene C
In this case, Scene A is a cloud-based scene. Because any scene that includes another scene as an action requires cloud processing and cannot be executed locally via LAN.
However, if Scene A is set as follows:
IF S-MATE Clicked
THEN Zigbee Curtain (directly added to NSPanel Pro) opens to 50%
Then, since the action involves only NSPanel Pro’s directly paired Zigbee sub-devices, Scene A is categorized as a local scene and can be executed over LAN without relying on the cloud.
It’s not that NSPanel Pro cannot control eWeLink Remote devices via LAN, but rather that it depends on how the associated scenes are structured.
Right, it can. But when it loses connection to the eWeLink cloud, none of the Zigbee devices are available in LAN mode. That is, NSPanel Pro does not have the ability to expose these devices locally. For example, it is not possible to control a Zigbee switch paired with NSPanel Pro using the widget in NSPanel (both in LAN mode).
When R5 is connected to NSPanel Pro and a local scene is created, it does not function as you have described or claimed it should. I have tested this multiple times. For example, with ZBMINIR2 and R5 connected to NSPanel Pro, a local scene was configured: if R5 Channel 1 is clicked once, then ZBMINIR2 reverses. However, when the internet connection is blocked, the scene fails to execute. The NSPanel Pro screen displays “Channel 1 clicked,” but no further actions occur. Control via the tile on the screen remains functional. The same issue is with WiFi devices in LAN mode (e.g., with M5-1C), where control through eWeLink Remote is not available. So, contrary to your view, it cannot be done over a LAN without relying on the cloud.
How would you comment on the scenarios described?
I think this requires a deeper investigation. Could you please submit the panel’s logs for further analysis?(Setting>About page of NSPro)
Before submitting the logs, please disconnect the cloud connection and then manually control each of your Zigbee sub-devices from the panel. This will help us determine from the logs whether the control commands are being sent from the panel to the sub-devices and, if not, identify the cause.
Could you provide a screenshot of the scene configuration for R5?
One more thing I forgot to mention: after restoring internet access, the NSPanel Pro does not automatically connect to the eWeLink cloud—a reboot is required. Interestingly, and quite unexpectedly, the update from version 3.8.2 to 3.8.4 had already downloaded and was ready to install. However, this update was not notified by either the eWeLink App or the eWeLink Web. Well, I decided to take advantage of this generous offer. What the hell, you live only once
After restarting, the NSPanel Pro entered a loop, repeatedly rebooting and halting at a startup screen displaying either the CUBE or RUBIK logo. Eventually, a prompt appeared, indicating that the NSPanel application had failed to start and requiring a ‘Click to…’ action. And finally the system booted up, the application loaded and the Panel was usable again. Is this really how it was supposed to work? I sent another log so you can see this bizarre behaviour for yourselves.
NSPro will reboot twice after upgrading to version 3.8.4, this is due to the underlying app update logic of the system, after that it can be used normally.
@songal Has anything been established from the information provided or is the investigation still ongoing? Any prospects for improvements in the future?
We looked into the logs and found that on 2025-03-27 at 17:13:39, a control command was successfully executed on a Zigbee device (device ID: a480095da9, named ZBMicro) while the NSPanel Pro was disconnected from the internet. This suggests that the panel was still able to send control commands locally to its Zigbee sub-device even in offline mode.
There are specific device-type requirements for local scenes triggered by eWeLink Remote devices. As of now, ZBMINIR2 is not among the supported devices for such local scenes. This explains why the scene involving R5 and ZBMINIR2 did not function as a local scene and therefore failed when cloud connectivity was lost. I’ve forwarded this as a feature request to the team, and we hope this compatibility can be improved in future updates.
The behavior is not expected. We’re currently looking into it, but there is no confirmed cause at this time.
At this moment, this is not supported. I’ve passed this on as a suggestion to the product team for evaluation—thank you for pointing it out.
