Sync Zigbee Sub-devices to Home Assistant

[demonizator]

After resolving the connectivity issues in the released v4.3.2, I started exploring the MQTT feature. I successfully set it up and exposed my Zigbee devices to Home Assistant, including my NSPanel Pro. However, I noticed that from time to time the MQTT connection drops (Device Settings > Home Assistant > Sync Zigbee Sub-devices becomes Not Connected). When this happens, I have to manually enable it again in order for it to start working. I’ve already submitted feedback - my Device ID is 1002201c89.

==========================================

I’ll use this topic for one more general consideration.

Currently, I use SonoffLAN (GitHub - AlexxIT/SonoffLAN: Control Sonoff Devices with eWeLink (original) firmware over LAN and/or Cloud from Home Assistant) to control ALL my Sonoff/eWeLink devices in Home Assistant, regardless of protocol. I’ve had absolutely no issues so far.

In v4, the newly introduced exporting/syncing/exposing devices via MQTT (@jam3, please, excuse my uneducated and ignorant technical vocabulary, I’m just a mere end user ) is a great feature, but:

1. It’s still not stable enough; and more importantly,
2. It supports only Zigbee devices.

I noticed that the iHost team recently released the eWeLink Smart Home Add-on for Home Assistant (GitHub - iHost-Open-Source-Project/hassio-ihost-addon: This repository contains a set of Home Assistant add-ons developed specifically for SONOFF iHost.), which reportedly exposes ALL devices (not only Zigbee) to Home Assistant via MQTT. Out of curiosity, I installed it. I don’t own or use an iHost (so I’m not even sure it’s intended to work in my case), but I still managed to successfully expose and control two of my Wi-Fi devices (DualR3 and M5-3C) without any issues.

Additionally, the new Matter bridge feature also aims to expose ALL devices to other Matter ecosystems.

So my question to @MichaelLearnsToCode and everyone involved is:

Is exposing ALL devices (not only Zigbee) to Home Assistant via MQTT technically possible for non-iHost/NSPanel-only users, and on your road map? Either through the new eWeLink Smart Home Add-on, or in some other way?

=================

My use-case scenario

I use an NSPanel Pro 86 with ~15 Zigbee devices, ~15 Wi-Fi devices, 3-4 eWeLink Remote devices. All of them are currently exposed to Home Assistant via SonoffLAN. It’s an absolutely great piece of software, and for me it’s as seamless and stable as one could reasonably expect. It supports ALL my Sonoff devices. Its developer, AlexxIT, is also extremely helpful. As I mentioned earlier in this forum, he even implemented the (then missing) NSPanel Pro support within a few hours, based on my input and remote testing on my device.

(I also have another location with a ZBBridge-P and ~10 Zigbee sensors, but that’s not my main focus - at least until summer )

Now, with v4 and MQTT, I can see that my devices expose more entities to Home Assistant compared to SonoffLAN - especially the NSPanel, which thankfully gives me more control. However, even if I move all my Zigbee devices to MQTT (assuming it becomes stable enough), I still have to rely on SonoffLAN for all my other devices.

Ideally, I’d prefer using one single method, and especially an officially supported one - provided it’s at least as stable and functional as the third-party solution

[jam3]

@demonizator

Ideally, I’d prefer using one single method

MQTT does indeed expose more entities than SonoffLAN, but a large portion of them are just noise - technical flags, internal states, debug values that have no real use in Home Assistant. We’ve talked about this more than once: the fact that something shows up as an entity doesn’t mean it’s actually useful. In the latest firmware things are somewhat more organized, but still pretty messy - especially on the TRVZB.
I’ve personally decided to use the MQTT broker in production because it’s finally stable enough, but there’s still plenty of work to be done. As you noticed yourself, NSPanel Pro is by far the best‑implemented device in this whole circus when it comes to MQTT control.
In my opinion, you can switch to MQTT, but do it carefully: observe how your devices behave and don’t rush to get rid of SonoffLAN
As for the ‘It supports only Zigbee devices’ part - nothing more is going to appear there, simply because NSPanel Pro handles only Zigbee devices locally. Wi‑Fi devices rely on the eWeLink cloud, and the panel doesn’t act as a local MQTT bridge for cloud‑based Wi‑Fi devices. MQTT on NSPanel Pro is strictly a bridge for the local Zigbee network, not for the entire eWeLink ecosystem.

[demonizator]

Very interesting and helful, thank you.

@jam3

..and don’t rush to get rid of SonoffLAN

Oh, by no means I plan to do so. As I said, it works flawlessly. I’m just genuinely curious to 1) understand MQTT, and 2) why Sonoff/eWeLink don’t provide officialy such an integration themselves

@jam3

..NSPanel Pro is by far the best‑implemented device

Yes, indeed, currenty MQTT supports couple of extra features compared to SonoffLAN when it comes to NSPanel, that are quite valuable for Scenes and Automations in HA. That’s why I’ll continue to use SonoffLAN to handle all my devices, and only expose NSPanel via MQTT for the extra features. And I’ll reach out to AlexxIT to try to implement these extra features (if possible) in SonoffLAN

@jam3

As for the ‘It supports only Zigbee devices’ part - nothing more is going to appear there, simply because NSPanel Pro handles only Zigbee devices locally. Wi‑Fi devices rely on the eWeLink cloud, and the panel doesn’t act as a local MQTT bridge for cloud‑based Wi‑Fi devices. MQTT on NSPanel Pro is strictly a bridge for the local Zigbee network, not for the entire eWeLink ecosystem.

This is the part I honestly don’t get, in general. I mean - I do understand that NSPanel handles directly only Zigbee devices, but then as far as I understand it exposess ALL devices via Matter Bridge, right? And then, it exposes the devices to all other Matter ecosystems - except for HA, why? Then we have the Smart Home Add-on that exposes ALL devices to HA.. I’m little bit lost here..

Anyways, as I said - I’m just curious. I’m finally extremely happy with my HA/NSPPv4/SonoffLAN setup right now (hoping and trusting the devs here will resolve the known issues we all report, that is)!

[jam3]

@demonizator

I’m little bit lost here..

Don’t be It’s not as complicated as it looks. If you want a good starting point, read a bit about MQTT as a transport layer - it’s an open standard, unlike the proprietary cloud protocol used by eWeLink/Sonoff. Also remember that Sonoff’s Wi‑Fi “LAN mode” is a closed and limited local control channel that works in parallel to the cloud. It’s not an open local API, and it doesn’t give full access to the device - which is exactly why Tasmota was created in the first place. The developer of the SonoffLAN integration also had to reverse‑engineer quite a lot to make it work at all. Anyway, let’s go back to the point.

NSPanel Pro handles only Zigbee devices locally, and only those appear in the Matter Bridge. Wi‑Fi devices won’t ever show up there because the panel has no local API for them. Guys at eWeLink are unlikely to add support for that - it’s unjustified and expensive to implement, unless I’m completely wrong about eWeLink’s intentions. Besides, we’re entering the era of Matter (over Wi‑Fi), and features like this simply won’t be needed anymore. No point wasting resources.The Smart Home Add‑on is a completely separate path. It exposes all devices to HA, but through the cloud, not Matter. In general, Matter wasn’t designed for this kind of tricks. We use it this way only because sometimes there’s no other option.

[MichaelLearnsToCode]

@demonizator @jam3 as always, thank you very much for sharing your ideas.

Let me try to explain a few things:

• NSPanel Pro and eWeLink Smart Home Add-on are managed by different product teams who have different goals for their products.

• The goal of eWeLink Smart Home Add-on is NOT to replace SonoffLAN, it is designed to replace the legacy eWeLink Smart Home. It relies on eWeLink Cloud and it is an add-on, not integration like SonoffLAN. It does provide many similar features like SonoffLAN, and it is going to be the official way to integrate eWeLink/SONOFF devices to Home Assistant.

• The initial goal of NSPanel Pro is to be the Display/Screen to control eWeLink/SONOFF devices. Now the goal is a bit fuzzy as @jam3 has pointed out several times. NSPanel Pro could be:

  1. The Display/Screen for Home Assistant (running Home Assistant compaion app).
  2. Matter Bridge for eWeLink and Home Assistant devices.
  3. Matter Hub for matter devices (not works very well right now, even for iHost).
  4. Zigbee Hub (Adapter) or Router for Home Assistant (through HA MQTT Discovery protocol).
  5. Thermostat: Central heating, and Single room heating (already in design).
  6. Security alarm system
  7. Local system with a built-in web console, less rely on or even without eWeLink Cloud.
  8. and more…

Is exposing ALL devices (not only Zigbee) to Home Assistant via MQTT technically possible for non-iHost/NSPanel-only users, and on your road map? Either through the new eWeLink Smart Home Add-on, or in some other way?

Technically, NSPanel Pro could do all the things that eWeLink Smart Home Add-on is doing. It’s just software, right? But since we’ve already renewed eWeLink Smart Home Add-on, we has no intent to do those same things again on NSPanel Pro.

@demonizator I think you don’t have to choose between eWeLink Smart Home Add-on and NSPanel Pro, you should be able to use them at the same time.

[massimo.baschieri]

Hi MichelLearnsCode,

I understand and somewhat agree with Sonoff point of view, better to rely on a homeassistant addon in order to integrate wifi gears to home assistant than to rely on another piece of hardware, such as nspp, which may be bricked.

Different story is for zigbee devices.

However it may become confusing for average users to be forced to manage two different tools in order to integrate different devices from the same vendor, best should be to have nspp to do the same things addon is doing.

[MichaelLearnsToCode]

@massimo.baschieri

Different story is for zigbee devices.

However it may become confusing for average users to be forced to manage two different tools in order to integrate different devices from the same vendor, best should be to have nspp to do the same things addon is doing.

Thank you very much for your feedback.

From the perspective of installation, eWeLink Smart Home Add-on is much easier than NSPanel Pro because it can utilize Home Assistant’s add-on mechanism to install and configure dependencies automatically, such as Mosquitto MQTT Broker, MQTT integration. On the contrary, users have to install and configure MQTT Broker manually if they want to export/expose/bridge NSPanel Pro and its Zigbee devices to Home Assistant.

Users can run eWeLink Smart Home Add-on and NSPanel Pro at the same time. They just need to unselect NSPanel Pro in eWeLink Smart Home Add-on so that eWeLink Smart Home Add-on won’t export NSPanel Pro and its Zigbee devices to HA.

Maybe we could optimize this flow if eWeLink Smart Home Add-on is in the same LAN with NSPanel Pro. Then eWeLink Smart Home Add-on could also discover, configure, and control NSPanel Pro automatically and locally.

[jam3]

@MichaelLearnsToCode

Users

One way or another, all these solutions assume at least a basic level of IoT literacy - not the glossy brochure kind where everything “just works,” but the real‑world kind where devices have moods, protocols act like tricksters, and integrations behave like a cat that technically lives with you but still does whatever it wants. Especially when someone starts mixing platforms that were never designed to cooperate. Even with experience, it’s easy to fall into traps, because hardware and software are made by humans - and humans, as we all know, are fully capable of producing both brilliant ideas and spectacular disasters.

And yes, I realize this will irritate those who expect “easy solutions” and then flood forums with their contradictory expectations. It’s always the same story: “Why doesn’t this work,” “Why do I have to configure anything,” “Why isn’t this plug‑and‑play.” The answer is simple: because you’re trying to marry systems that not only weren’t designed to work together - they don’t even acknowledge each other’s existence.

Now add the classic headache of trying to combine closed ecosystems like Sonoff/eWeLink with open platforms like Home Assistant. Closed systems have their own APIs, limitations, business priorities, and marketing strategies. HA tries to unify all of that into one coherent interface. It’s a bit like trying to form a choir out of people who not only sing in different languages, but each insists that everyone else is off‑key.

If you want solutions that are easy, predictable, and drama‑free, stick to one platform. Seriously. Don’t improvise. And if you do improvise, don’t complain when you end up in a dead end - that’s not eWeLink’s fault, it’s the natural consequence of mixing a closed world with an open one and hoping nobody notices.

And yes, in a way I’m saying things the eWeLink dev team could never say out loud. They can’t exactly admit: “Hey, our devices aren’t meant to work outside our cloud — that would ruin the business model.” But you can. And sometimes it’s worth saying, before someone once again acts surprised that IoT isn’t a theme park of universal compatibility, but a landscape of interests, limitations, and compromises - with a bit of magic, but only if you actually know what you’re doing.