After the latest NSPanel Pro firmware update, I expected improvements in how the panel integrates with Home Assistant via MQTT. Unfortunately, nothing has changed in this area. The dev team seems to have focused mainly on optimizing the F‑Droid experience. Maybe there are impressive results on that front, but I haven’t had time to explore it yet.
What hasn’t improved is MQTT data quality. NSPanel Pro still publishes raw, unfiltered Zigbee DP values for every Sonoff device. This results in Home Assistant creating a large number of useless MQTT entities, many of which never receive valid data. HA then floods the logs with warnings such as:
Template variable warning: 'dict object' has no attribute 'temperature_compensation'
Template variable warning: 'dict object' has no attribute 'humidity_compensation'
Template variable warning: 'dict object' has no attribute 'real_time_mode_continue'
This happens with every Sonoff Zigbee device connected through NSPanel Pro. Examples:
SNZB‑02D R2 – lots of unused fields published
TRVZB – especially messy, generates many meaningless DP values
All other Sonoff Zigbee sensors behave the same way
What’s surprising is that Aqara Lumi devices are filtered correctly by NSPanel Pro and do not generate any junk entities. This clearly shows the issue is specific to how NSPanel Pro handles Sonoff Zigbee devices.
Home Assistant’s MQTT Discovery simply exposes whatever the panel publishes, so the root cause is the lack of filtering on the NSPanel Pro side.
Suggestion: If NSPanel Pro is intended to integrate with Home Assistant via MQTT, it should filter out unused or empty DP fields and publish only meaningful values. This would prevent unnecessary entity creation and eliminate log spam.
@MichaelLearnsToCode Perhaps the ability to run the Home Assistant Companion App on the NSPanel Pro (via F‑Droid) is enough to make someone truly happy — who knows. But judging from the grand promises of “a new chapter,” nothing particularly inspiring has materialized so far. And unfortunately, this whole topic has been quietly tiptoed around by the dev team in recent weeks. As if it simply didn’t exist.
HA Companion App, by default, uses local darkmode/lightmode preferences. On NSPanel, go to your HA app > Settings > Companion app > Theme. Set Theme to Dark.
For the “regular” end-user, wouldn’t it be a good idea to plug the “classic” screen saver settings to the system-level settings?
Yes, that’s a good idea. We’ll put it on our roadmap.
Another small pain point: when you slide down the menu via the touch button, if you slide up just after that (or after changing a setting),we go back to home screen
I am sorry I don’t quite understand. Could you please be more specific? What is the menu, the Top drop-down menu? What is the touch button, the Assistive Button? Could you also provide some photos to demonstrate the issue?
Hi, it will it be possible to add zigbee/matter devices from other platforms to nspanel pro. Specifically, it concerns the aquara Curtain Driver E1 so that they can be controlled naively via ewelink/nspanel pro?
Regarding the warnings from the log, we’ll optimize it. It won’t cause any trouble in daily use, so don’t be panic.
But judging from the grand promises of “a new chapter,” nothing particularly inspiring has materialized so far. And unfortunately, this whole topic has been quietly tiptoed around by the dev team in recent weeks. As if it simply didn’t exist.
I don’t know what you are talking about, or you just ignore the facts:
Matter Bridge chapter 2: NSPanel Pro will be able to bridge eWeLink devices including Wi-Fi devices, Zigbee devices connect to other eWeLink Zigbee Hub, locally or through eWeLink cloud in this version.
This is what we have delivered in v4.2.0. We believe it’s fair to call it chapter 2.
Thanks for the explanation but I think we’re still talking about two different things. I’m not referring to Matter Bridge chapter 2. I’m aware that this part was delivered, and I’m not disputing that. What I meant was the previously mentioned idea of dedicated integration with Home Assistant via a local MQTT broker. That was the feature many users understood as part of the “new chapter” for the NSPanel Pro - a more open, local, HA‑friendly direction. Since then, this topic has disappeared from communication, and no updates were provided.
So yes, Matter Bridge chapter 2 exists. But it doesn’t address the expectations around local MQTT‑based HA integration, which is what my comment was about.
And to be fair, maybe my earlier message came across a bit. I do appreciate the amount of work the dev team has put into the project. I understand the pressure, the limited resources, and how easy it is to lose track of certain threads when juggling so many moving parts. My comment was shaped by that frustration, ans perhaps expressed a bit too bluntly
Hi, I apologize that public documentation for this part is not yet available. However, I have checked the model you reported (Aqara Curtain Driver E1) and can confirm that it is supported by the NSPanelPro, including its core functionalities.
Could you clarify if you are experiencing abnormal behavior after adding the device? If so, here are the specific steps to help us investigate:
After adding the device, please submit the logs from your NSPanelPro immediately.
Then, provide me with the Device ID.
I will prioritize locating the issue for you as soon as I receive this information.
v4.1.0 already supports Export Zigbee devices to Home Assistant, and v4.3.0 is going to support Export NSPanel Pro itself to Home Assistant. Can’t these features be considered a more open, local, HA‑friendly direction?
v4.2.0 has nothing to do with Home Assistant, why are we talking about dedicated integration with Home Assistant via a local MQTT broker?
We know there are warnings in HA’s logs. We are going to fix it ASAP.
Thanks for the update and for acknowledging the HA log warnings — it’s good to know they will be fixed soon.
Let me clarify the core point I’ve been trying to raise, because it seems to have drifted away in the discussion. Since the NSPanel Pro now has a dedicated “Home Assistant” section in the eWeLink app, including the ability to create an MQTT broker and export Zigbee devices, it’s natural for users to expect that the MQTT communication will be structured, consistent, and aligned with Home Assistant conventions.
Right now the MQTT output is noisy, unorganized, and filled with payloads that create clutter in HA rather than providing meaningful, usable data. From a user perspective, this doesn’t feel like a complete or HA‑friendly solution. Beyond filtering and formatting on the panel side, there is a clear need for a proper integration layer — something that channels and normalizes what the broker publishes so that HA can consume it cleanly, ideally following MQTT Discovery standards.
Exporting Zigbee devices (v4.1.0) and exporting the NSPanel Pro itself (planned for v4.3.0) are definitely steps in a more open direction, and I appreciate the work behind them. But they don’t address the underlying issue of MQTT structure and HA‑oriented design, which is what might be understood as part of the “new chapter.”
Oh, I understand what you mean, and I feel sorry for the confusion.
The Assistive Touch button (we renamed it to Accessibility Button) works as follows:
Single press: Go back to NSPanel Pro App (Home screen by default).
Double press: Show recently used apps as cards for quick switching or closing. The same function as Android navigation bar’s Recents button.
Long press/Hold: Toggle the underlying Android system’s navigation bar.
So single press Accessibility Button does not slide down the Top drop-down menu. You see it because Top drop-down menu is where you left NSPanel Pro App.
thank you for your guidance. Please find the requested information below.
Matter Hub Device ID:ac68000159
(Aqara Matter Hub where the Aqara Curtain Driver E1 is connected)
NSPanel Pro Device ID:1001e37fa5
Current behavior:
The Aqara Matter Hub is added successfully to the eWeLink / NSPanel Pro environment.
However, no child devices are exposed (device count = 0).
The Aqara Curtain Driver E1 works correctly in the Aqara app, but it does not appear in eWeLink or on the NSPanel Pro.
I have attempted the pairing multiple times with the same result.
Please let me know if you require the NSPanel Pro logs or screenshots to proceed with the investigation. I can provide them immediately after another pairing attempt if needed.
A good feature for NS Panel PRO thermostat function would be to allow on/off and target temperature setting via SCENES and Alexa / Google home app / voice commands.
That is a basic function available in mostly all smart thermostats and a hard to sell missing function on Sonoff line of products.
Today the only way I can offer that to my customers is via generic ewelink thermostats or complex home assistant configuration what requires a cloud subscription.
Hope you find this interesting to be included into the NS Panel PRO roadmap….
o clarify your request: Are you looking to set up the Click/Double-click/Long-press actions in an HA component to open a specific URL, so that tapping the component quickly launches the NSPanelPro app?
If so, you can also use the Assistive Touch ( Single press) to return directly to the NSPanelPro interface.
If that doesn’t match what you’re trying to achieve, could you please describe your use case in more detail?
but I can try to explain better with good terms ((I’m not at home right now so no photo):
)