NSPanel Pro 4.3.0: Zigbee stack becomes unstable, devices randomly go offline and MQTT bridge stops working

NSPanel Pro
1

@JoJo @Milk

After updating NSPanel Pro to firmware 4.3.0, the Zigbee subsystem becomes unstable. Zigbee devices randomly switch to offline state and then reconnect after a few seconds. This happens without any identifiable trigger and affects different devices at different times.

After several such events, the Zigbee stack appears to stop functioning entirely:

  • all Zigbee devices show as offline,
  • the list of synchronized devices becomes empty,
  • MQTT bridge stops publishing Zigbee data,
  • In the eWeLink app, under NSPanel Pro → Home Assistant/MQTT, every action fails, indicating that the internal MQTT bridge stops working once the Zigbee stack crashes.,
  • only a full reboot of NSPanel Pro restores functionality.

This strongly suggests a regression or memory/queue issue in the Zigbee stack introduced in firmware 4.3.0.

Impact:

  • Zigbee devices become unreliable,
  • automations fail unpredictably,
  • MQTT integration becomes unusable until reboot,
  • NSPanel Pro cannot be used as a stable Zigbee gateway.

Expected behavior:
Zigbee network should remain stable, devices should not randomly disconnect, and MQTT bridge should continue to operate without requiring manual reboot.

Suggested direction:
Investigate Zigbee stack stability in firmware 4.3.0, especially memory leaks, task starvation, or watchdog resets affecting the Zigbee coordinator and MQTT bridge.

I have sent several reports from the NSPanel Pro: 1001ea2549.

2 Likes
2

I apologize for the issue. We have also identified this problem and are currently working on a resolution. A new version addressing this issue is expected to be deployed to your device tomorrow.

1 Like
3

Hi, a dedicated version 4.3.2 has been deployed for your device. You can now proceed with the upgrade. If you encounter any issues, please feel free to contact me.

4

Thank you very much. I will :slight_smile:

5

I just installed 4.3.0. all zigbee devices (22) are disconnected … :disappointed_face::grimacing: Restarting the panel doesn’t help. What now?

Edit: They are connected, but They randomly disconnect and reconnect after a significant amount of time

6

I know this from my own experience. Version 4.3.2 fixes this bug, but I’m not sure whether it’s publicly available. It probably isn’t.

2 Likes
7

@Milk After updating the NSPanel Pro firmware (4.3.2) that was intended to fix Zigbee stack issues, the device has once again started publishing raw internal data structures to MQTT, which should not be sent in any production build. Home Assistant, using MQTT Discovery, interprets these payloads as valid sensors and automatically creates dozens of incorrect entities.

This behavior existed in older firmware versions, was partially fixed in the previous release, and has now returned - this appears to be a clear regression.

Examples of incorrect payloads published by NSPanel Pro
The device is sending, among others:

  1. Raw configuration structures
{'dry_threshold': 4000, 'damp_threshold': 6000}
{'hot_threshold': 2700, 'cold_threshold': 1900}
  1. Internal schedule format
monday: '00:00/16 06:00/24 09:00/18 17:00/19 21:00/18'
tuesday: '00:00/16 06:00/24 09:00/18 17:00/19 21:00/18'
  1. Diagnostic data for the valve motor, like:
  • Valve closing limit voltage: 2454 mV
  • Valve running voltage: 1447 mV
  • Valve opening limit voltage: 1638 mV
  • Closing steps: 307
  • Idle steps: 242

image
image315Ă—591 23.3 KB

image
image308Ă—408 14.1 KB

These values appear to be debug telemetry, not data intended for MQTT.

Expected behavior
NSPanel Pro should publish only:

  • actual device state,
  • sensor values,
  • user‑relevant events (i.e. schedules)
  • data consistent with the documented MQTT interface.

Internal structures, thresholds, motor voltages, and step counters should not be published.

Why this is a problem?

  • Home Assistant automatically creates entities for every key in the JSON payload → the device page becomes cluttered with invalid sensors.
  • Users cannot disable this behavior on the NSPanel Pro side.
  • MQTT integrations are not designed to handle debug payloads.

The behavior changes between firmware versions, making system maintenance difficult.

Please:

  • Disable publishing of raw internal data structures to MQTT in production builds.
  • Restore the behavior from the previous firmware, where debug telemetry was suppressed.

(Optional) Add a setting in NSPanel Pro: “Enable verbose MQTT telemetry (debug)” – default OFF.

Additional information
Full MQTT logs can be provided if needed.
The issue is fully reproducible after updating to the latest firmware.

1 Like
8

All my zigbee devices are disconnected again. Only restarting NsPanel helps for a short time. Will I get a fix?

9

And are you a good boy? :smiley:

Jokes aside, the version with the Zigbee fix is already available or should be available soon.

1 Like
10

Gooood :grimacing::rofl::rofl::rofl:, I’m waiting

11

Apologies for this issue. This issue has been fixed in v4.3.2. Please send us your device ID via private message, and we will push this targeted update to you.

1 Like
13

What does the fix cover
Inhave spent many (too many) hours trying to install the SNZB 02DR2

App is V5.22
NS panel is V4.3
SNZB is 1.0.3 ( after a very difficult upgrade process)

1 The graph in EWElink shows no hourly figures
2 The device shows as not supported in Ewelink Web
3. There is only one sensor in HA to display in that app - no temperature

Extremely disappointed with this device

14

I also experience that the Zigbee devices randomly disconnect. When this happens, I restart it, and then it works fine again for a while. The automations are not reliable, so I would also try version 4.3.2.
My device ID: 10026564ee

15

After several days on firmware 4.3.2, I can confirm that the Zigbee stability issues have been resolved. This also results in stable MQTT server operation - stable enough for reliable, production use.

However, on 2 or 3 occasions the NSPanel Pro unexpectedly stopped working in a way that suggests the watchdog triggered a reboot, after which the device got stuck on the CUBE startup screen. The screensaver with the clock remained visible, and only touching the screen revealed the problem. After “waking up” the device, CUBE loaded normally and everything returned to proper operation, including Zigbee.

Today I also submitted feedback from the NSPanel Pro [1001ea2549], right after functionality was restored.

Regards.

16

Same issue on my end. Very annoying and frustrating.

1 Like