Sorry for reporting this in stages, but there’s one more aspect I’ve just noticed in the HA logs.
Home Assistant is generating hundreds of warnings due to MQTT discovery configs published by NSPanel Pro using the deprecated object_id field. The log message states that object_id should be replaced with default_entity_id, as support for object_id will be removed in HA Core 2026.4. This affects many entities (400+), causing excessive logging and potential future breakage. Please update the firmware or MQTT discovery mechanism to publish default_entity_id instead of object_id, in line with current HA standards.
Got the 4.1.0 update after installing its show a new software update ready to be installed but its 1.13.3 i guess its a dumb question but am i supposed to install it or its going to revert the main firmware to 1.13.3, or this is update for cube which is now at 1.13?
this is update for cube which is now at 1.13?
Exactly. It’s the update for CUBE (Zigbee2CUBE, the wrapper for zigbee-herdsman and zigbee-herdsman-converters)
1 Like
Installed 4.1.0 since few hours and noted a couple of things to be fixed already:
1 - zigbee devices gets discovered by home assistant, but with a strange id, which doesn’t resemble original id nor given description in ewelink
2 - after few hours devices gets offline on homeassistant and you need to re sync them from ewelink to recover them, the same happen if you reload mqtt broker on homeassistant
1 Like
Zigbee devices show up with “strange” IDs in MQTT because:
- MQTT uses hardware addresses like IEEE or MAC, not friendly names from eWeLink.
- Home Assistant doesn’t access cloud metadata from eWeLink, so it can’t pull original names or descriptions.
- The IDs are technical but unique, which makes them look odd or unreadable.
- You can rename devices manually using friendly_name in MQTT or aliases in Home Assistant.
they don’t actually disappear. I’ve run a series of tests and confirmed that once devices announce themselves via MQTT, they work and update reliably. The issue arises when the MQTT broker in Home Assistant loses connection to the NSPanel — and MQTT, by design, is highly sensitive to connection quality and stability. Even brief network interruptions can break the session and make devices temporarily “vanish.” If this happens without restarting HA or the broker, it usually points to WiFi problems. It’s worth checking not just the signal strength, but also its consistency and stability 
Additionally, eWeLink and MQTT sync in completely different ways. MQTT is a local protocol with no cloud memory — after a broker restart, it forgets device states unless the retain flag is set. Unfortunately, NSPanel doesn’t set this flag, so Home Assistant just waits for devices to report in… which can take a while, especially for battery-powered Zigbee devices that love to sleep.
It’s also worth mentioning the Last Will and Testament (LWT) mechanism. MQTT can notify HA when a device disconnects, but only if the client (in this case, NSPanel) is properly configured to use it. Without that, HA has no idea whether the device is gone or just silent.
Without addressing these issues, stable integration with HA is wishful thinking. And if you’d read the thread (just saying), you’d know I already reported this, and the eWeLink team said they’re working on it.
Since the eWeLink team is already aware of the MQTT situation and confirmed they’re working on it, all we can do now is exercise a bit of patience. This isn’t the kind of thing you fix in half an hour over coffee, as you’ve probably guessed. But hey, the folks over there are doing their best, and sooner or later they’ll surely come up with a solution. Fingers crossed and WiFi stable!
Not a dumb question at all! It actually makes perfect sense once you know how NSPanel Pro’s software layers work:
- App Version 4.1.0 is the main user interface - what you see and interact with.
- Cube Version 1.13.3 is the backend service layer (eWeLink Cube) that handles things like Zigbee, MQTT, and automation logic.
- OS Version is the underlying Android-based system, usually updated less frequently.
So no, installing the 1.13.3 update won’t downgrade your firmware, It’s just updating the Cube component, not the App or OS. You’re safe to install it, and it’s likely meant to match or support the new App version you just got. It’s not a rollback, it’s just the backend catching up.
1 Like
MQTT is a local protocol. It has no access to cloud-based data from eWeLink, such as device names, descriptions, or locations. Home Assistant uses MQTT discovery, which requires each device to send its own name, unique_id, device_class, etc. in a configuration message. NSPanel Pro (and eWeLink Cube) don’t transmit this cloud metadata, only local IDs and entity types are sent.
You can’t “force” the MQTT broker to fetch data from the eWeLink cloud. It simply doesn’t have that capability. NSPanel Pro doesn’t include cloud-based names in its MQTT messages (unless eWeLink adds such a feature in the future).
It’s a similar story with the well-known HACS integration Sonoff LAN, it also doesn’t pull names. Even when sharing devices through Matter, metadata like names often gets lost or simplified.
Ultimately, solving this would require a custom integration specifically designed for NSPanel Pro that bridges MQTT with eWeLink’s cloud metadata. Until then, manual naming or hybrid setups are the only real options.
Thanks
My pleasure!
Thanks for the explanation, I’ll wait for however, I just wanted to give my contribution on the bug raising
I understand, but note that it’s very tricky to give the right name to a device on HA which has any reference from the original one, and when you have dozen of those it’s a very time consuming and error prone task, I was wondering if there is some way to maintain some kind of reference to the original devices inside mqtt messages.
I have also sonoff lan integration, which is cloud based and I was waiting for a long time to replace it with a local alternative such as this one, but I can’t remember of this kind of troubles when I activated sonoff lan time ago, maybe I’m wrong, but it created the devices in HA with the same friendly name assigned from ewelink or at least with some reference to their zigbee id.
With the HACS SonoffLAN integration, it often (but not always) retrieves the device name (e.g. Kitchen lamp) from the eWeLink cloud, but it doesn’t use it as the entity_id in Home Assistant. Instead, entities are created using technical names, such as switch.sonoff_1000abcd01, where 1000abcd01 is the device ID from eWeLink. The friendly name may appear in the device description (device name), but it doesn’t affect the entity’s name (entity_id).
From the official SonoffLAN GitHub repository: “Load devices list from eWeLink Servers (with names and encryption keys) and save it locally (optional)”
This means the integration can fetch the name, type, and other data from the eWeLink cloud - but only if you have an active cloud connection (i.e., not operating in LAN-only mode).
Unfortunately, this kind of behavior isn’t possible with MQTT. I can’t really imagine a clean workaround, since the broker itself doesn’t have any function to fetch cloud metadata. You’d likely need to write a script that bridges the gap, ideally as a dedicated NSPanel Pro (or CUBE) integration for Home Assistant.
Note that every IoT platform stores friendly names in a local database and doesn’t save them directly on the devices, since those have their own unique IDs. Otherwise, things would get messy.
In MQTT, fortunately, assigning a friendly name is usually a one-time task and tends to last a long time. So it’s not particularly burdensome. Things are quite similar with Matter, as the import of friendly names there is poorly handled. Sometimes you also need to take a closer look and make manual corrections.
The NSPanel Pro v4 update has not yet arrived.
You need to join through the NSPanel Pro v4.xx Beta Test Application Tool.
I don’t mean to be snarky, but searching the forum isn’t all that complicated. It was already posted in the topic by @jojo in a reply on Nov 6, 2025, and repeated at least a few times.
I see it too. Every time I send a message, I get a message saying the testing hasn’t started on NSPanel 86 models and we need to wait. It says the testing is being done on 120 models.
Selim ÜNVER
9 Kas 2025 Paz 16:18 tarihinde Jam3 via eWeLink Forum <notifications@ewelinkforum.discoursemail.com> şunu yazdı:
DM your Device ID to @MichaelLearnsToCode and @JoJo to include your device to the rollout list. That’s what I did, I’m with Type 86 and have been receiving all the new updates.
Sorry for the issue. Please send me the Device ID of your NSPanel Pro through private message, or post a screenshot of the error message you saw on NSPanel Pro V4.x.x Beta Testing Application Form.
With the 4.1.1 update, the 86 NsPanel feels faster and works better in Android apps.
The Android settings are perfect, and now “Screen OFF” also works in Home Assistant with the Android display settings.
But there is one major problem. If you change the display font size, the NsPanel app no longer starts on the device. The app loads endlessly.
However, I was able to reset the NsPanel via the EWE app.