NSPanel Pro v4.2.0 Officially Released: New Features & Enhancements

NSPanel Pro
207

Already registered. Devuce ID: 10023a8cee

208

Today after reboot, successfully updated all three nspanels, thanks!

1 Like
209

i test to pair again with v4.3 and latest ewelink app , all went fine

210

Hi Milk, hope you are doing well. Have just upgraded to FW 4.3 and the NS Panel PRO thermostat works great with the 4CH Zigbee relay card now. Thanks very much for your help !!!

1 Like
211

Hi, in version 4.3.0, you simply need to go to Settings → Display → select the auto-lock time , and the screen will automatically enter sleep mode (this setting will apply to all pages). If you do not want the clock to be displayed, please turn off the screen saver on that page.

1 Like
212

I can see that you took the criticism of the MQTT payload sent to Home Assistant into account. Thank you — it’s finally clean, and HA now receives only what’s actually useful. The NSPanel Pro itself looks pretty sexy in MQTT :slight_smile:

Phew! It really looks good and promising now.

I’ll keep testing it thoroughly, and once I have something meaningful, I’ll share my feedback. @MichaelLearnsToCode For now, I have one request: could you describe the entities generated for the TRVZB? Some of them are named in an obvious way, but others are still a bit of a mystery. I hope that with a short guide from eWeLink it will be easier to understand.

By the way, regarding the TRVZB — do you plan to add support for schedules stored directly on the device? I know it’s not a trivial feature, but maybe you already have some ideas. I’ll try to help and think about how this could be handled.

Congratulations on the spectacular progress, and warm regards :+1:

1 Like
213

Two minor issues I have noticed with the version 4.3 (MQTT), is that NS Panel cannot pick the inbuilt HA Media options..I am struggling to use it as a speaker for text to voice announcements that I have typed through Google AI, or Chat GPT. for example. I cannot get it to announce that the Alarm.System is Armed, or there is somebody outside on the fron door (if the front porch camera picks somebody outside the door.

Unless I am missing something, the easiest way you an use its speaker is to use tit just foe various alarm options in it.

Also, another anomalyis that,my NS Panel is connected to both Sonoff LAN and MQTT. While Sonoff LAN easily picks up alarm.modes (Home, Night, Away) MQTT is stuck to disarmed mode.

214

Suggestion: Improve MQTT Discovery for Zigbee Entities in NSPanel Pro
NSPanel Pro correctly detects Zigbee devices and provides Home Assistant with accurate device‑level information, including:

  • manufacturer (e.g., SONOFF),
  • model (e.g., SNZB‑02P),
  • firmware version,
  • device type.

As a result, the device page in Home Assistant displays proper metadata such as:

“Temperature and humidity sensor (SNZB‑02P) by SONOFF”

This part works very well.

What is missing
The issue appears at the entity level.
Entities created from MQTT messages still receive generic, technical names derived from the IEEE address, for example:

sensor.0x142d41fffe428404_temperature

sensor.0x142d41fffe428404_humidity

Although the entities have correct device_class, units, and state values, they lack:

  • friendly, human‑readable names,
  • consistent naming conventions,
  • optional metadata that would make them immediately usable without manual editing.

This forces users to rename each entity manually, which becomes time‑consuming in larger Zigbee networks.

Proposed improvement
Add MQTT Discovery for entities, not only for the device itself.

NSPanel Pro already has all the necessary information:

manufacturer,

model,

modelID,

endpoint definitions,

measurement types (temperature, humidity, battery, etc.).

Publishing Home Assistant–compatible discovery messages for each entity would allow HA to automatically create descriptive, user‑friendly entities.

Example discovery payload:

homeassistant/sensor/snzp02p_1234_temperature/config
{
  "name": "SONOFF SNZB‑02P Temperature",
  "state_topic": "nspanelpro/zigbee/0x142d41fffe428404",
  "unit_of_measurement": "°C",
  "device_class": "temperature",
  "unique_id": "0x142d41fffe428404_temperature",
  "device": {
    "manufacturer": "SONOFF",
    "model": "SNZB‑02P"
  }
}

Benefits:

  • Home Assistant automatically creates clean, descriptive entity names.
  • Users no longer need to rename entities manually.
  • The integration becomes more polished and user‑friendly.
  • The experience becomes comparable to Zigbee2MQTT for supported devices.
  • Minimal development effort, since NSPanel Pro already has all required metadata.

Summary
NSPanel Pro already provides decent device‑level metadata. Adding MQTT Discovery for entities would complete the integration and significantly improve usability, especially for Sonoff/eWeLink devices that the panel already recognizes.

1 Like
215

I apologize for the issue you encountered during use. If the device did not turn off after 8:30, you can change the thermostat’s Actuator State to “OFF.”

image
image613×1296 50.7 KB

The crash issue has been identified and is expected to be resolved in an upcoming version as soon as possible.

217

Something I noticed after a power outage, when both NS Panel PRO and Zigbee Card are energized together, the card comes back with all it outputs off, even when once NS Panel PRO finishes turning on, shows some thermostat zones in heating. If I power cycle only the relay card it updates status correctly. Seems that if the zigbee card connects before the thermostat service start it does not get an initial synchronization performed., what would be the expected behavior.

Please let me know if you need further information or testing.

218

Are you referring to the Zigbee device card? Could you please record a short video demonstrating the specific issue you encountered?

219

To follow this path, I’m not sure if the MQTT discovery protocol can link created devices to other integrations: it seem that the MAC address is used to link serval integrations to the same device in HA…

220

Hi Milk, here is the video showing the remaining anomaly, happening only after a power outage…, related to the NS Panel PRO Thermostat and 4channel Zigbee cards.

221

First of all, thank you very much for your detailed and constructive feedback. We truly appreciate the time and thought you’ve put into analyzing the Home Assistant integration. With that in mind, we’d like to discuss a few points with you and hear your thoughts in more detail.

1. About entity_id readability

From your examples (e.g. sensor.0x142d41fffe428404_temperature), it seems the main concern is the readability of the entity_id.

From our understanding of Home Assistant’s design:

  • entity_id is intended to be a stable, machine-oriented identifier
  • It is referenced by automations, scripts, and templates
  • Changing it may cause breaking changes to existing setups

For user-facing clarity, Home Assistant already provides entity_name / friendly_name, which is fully supported, user-editable, and does not affect stability.

Given this, we would like to better understand:

  • In which scenarios is improving entity_id readability essential, rather than relying on entity_name?
  • In particular, we are interested in understanding how you typically work with:
    • entity_id in automations, templates, or scripts
    • entity_name / friendly_name in daily usage
    • Other metadata (such as device_class, area, or grouping) when organizing and maintaining your setup

This would help us better understand where current limitations are most impactful in real-world usage. Concrete examples would be very helpful.

2. Comparison with Zigbee2MQTT

You mentioned that the experience would become comparable to Zigbee2MQTT.

From our internal usage, Zigbee2MQTT also commonly uses IEEE address + expose name for entities. At least at the entity_id level, the behavior appears similar.

image
image2149×356 49.1 KB

image
image1694×932 90.1 KB

Could you clarify what Zigbee2MQTT does better in practice?

  • Default naming?
  • Additional metadata?
  • Auto-generated friendly names?
  • Or something else in the overall experience?

3. Stability and future direction

Changing entity_id during integration upgrades or entity rebuilds can introduce real breaking changes, and this is something we want to handle very carefully.

For this reason, our current thinking is:

  • In the short term, keeping the existing entity_id strategy unchanged for already supported devices helps protect stability and backward compatibility.

At the same time, this is not a closed decision for the long term. We will continue to review and optimize the underlying technical approach, and we also welcome further discussion and suggestions on how usability can be improved while preserving stability and backward compatibility.

Thanks again for the thoughtful discussion. We’re happy to continue the conversation and learn from your experience.

222

First of all, thank you for taking the time to look into this. I hope my comments don’t come across as just me venting, but actually help improve the software, even though they are (of course) a subjective point of view.

You are correct that Zigbee2MQTT also uses the IEEE address in the entity_id.
However, the practical experience is very different because Zigbee2MQTT publishes full MQTT Discovery payloads for every entity. NSPanel Pro does not publish any entity‑level discovery.

To illustrate the difference clearly, here is a comparison. Zigbee2MQTT provides:

  • automatic friendly names
  • automatic icons
  • automatic device_class
  • automatic state_class
  • automatic suggested_area
  • automatic entity category (diagnostic, config, measurement)
  • consistent naming conventions
  • human‑readable default names
  • full entity metadata in MQTT Discovery

NSPanel Pro currently provides:

  • device metadata only
  • no entity metadata
  • no friendly names
  • no icons
  • no suggested areas
  • no entity categories
  • no naming conventions
  • raw entity IDs shown in UI

Therefore, manual renaming required for every entity.

image
image1638×701 49.4 KB

Practical result in Home Assistant

Zigbee2MQTT:

  • Entities appear with clean, readable names immediately.
  • Device pages are organized and easy to navigate.
  • Automations are easy to build because entities have human‑readable names.
  • No manual renaming required.

NSPanel Pro:

  • Entities appear as raw technical IDs (e.g., sensor.0x142d41fffe428404_temperature).
  • Device pages show unprocessed, machine‑level identifiers.
  • Automations are confusing because all entities look the same.
  • Manual renaming is required for every entity.

The key point is this: even though both systems use IEEE addresses in the entity_id, Zigbee2MQTT provides a complete, polished user experience because it publishes entity‑level discovery. NSPanel Pro does not, and that is the entire difference.

I fully agree that entity_id must remain stable, changing is dangerous, and backward compatibility is important. But discovery payloads can include:

"unique_id": "0x142d41fffe428404_temperature"
"object_id": "0x142d41fffe428404_temperature"
"name": "SONOFF SNZB‑02P Temperature"

Home Assistant will:

  • keep the same entity_id,
  • but automatically assign a friendly name,
  • and populate metadata.

This preserves full stability. I am asking for MQTT Discovery payloads to be published for each entity. This is:

  • fully backward‑compatible,
  • optional (HA handles it gracefully),
  • already standard in Z2M, Tasmota, ESPHome, Shelly, etc.,
  • low‑effort (NSPanel Pro already has all metadata),
  • a major usability improvement.

If any part of my explanation needs further clarification, I’m happy to elaborate. I tried to keep it as concise as possible so as not to bore anyone, and I may have unintentionally left out a detail or two.

Regards.

1 Like
223

I cannot go that technical nor I have ever used Zigbee2MQTT but my experience testing with NSPP and MQTT is exactly the same - I had to manually check and rename each device one by one. I and currently test with only 15-ish devices..

1 Like
224

I apologize for the delayed response. I noticed that your Zigbee switch returned to the “off” state after a power outage, even though it was originally turned on. May I ask if you have configured certain options? For example: “Power-Off Memory” or “Restore State After Power Failure”.

Alternatively, after you reproduce the issue, please promptly submit the logs from the NSPanel Pro and then send me the device ID separately.

225

Hi Milk, already submitted logs. Relay Card does not have “power on” options at all. Passing device IDs:

NS Panel PRO: 100243a76b
4ch relay zigbee: a4400369fb
SNZB02WD: a4400369d0

Please let me know if you need anything else from my side. Thanks !

226

Thank you for the logs. I will review them ASAP.

227

Thank you for the detailed feedback from the user, which is very helpful for us to optimize the product experience.

In order to accurately identify the areas for optimization, could you please assist in providing a set of comparison information: the complete MQTT discovery messages (Discovery Payload) generated when the same Zigbee device is synchronized to Home Assistant via Zigbee2MQTT and via NSPanel Pro.

Here are the steps to obtain the discovery payload messages:

1f5a3d60820747f2a02654c35d68b05e
1f5a3d60820747f2a02654c35d68b05e1299×610 35.1 KB

39804b11a7e544eba9521926d9d74a2a
39804b11a7e544eba9521926d9d74a2a1169×968 87.4 KB