🎁 Join the NSPanel Pro New Feature Experience Survey Now, Share Your Insights, and Win Zigbee Sensor!

Ideas & Suggestion
,
5

Hello,

@MichaelLearnstoCode After spending quite a bit of time living with the current idea of integrating NSPanel Pro with Home Assistant, I wanted to share a few observations from both an architectural and user‑experience perspective, and explain why I eventually stepped back from it all, mostly to avoid unnecessary stress.

The current concept, based on MQTT, essentially boils down to a one‑way export of device states, without a coherent data model and without any real ability to manage Zigbee from HA. In practice, Home Assistant receives a large collection of loosely defined entities, while the user has no control over the Zigbee network — only a passive view. It looks great in marketing materials, but it doesn’t address what users actually need.

I’ve discussed these issues in several threads already, so I won’t repeat the entire analysis here — anyone interested can easily find my earlier posts using the Search function. Still, it’s worth noting that despite repeated feedback from the community, the current integration concept is being pursued with admirable persistence… even though it doesn’t really lead to a stable or complete Zigbee experience in HA.

A more promising direction

  1. Local Zigbee API Provide a local REST/WebSocket API that allows HA to communicate directly with the Zigbee layer. This doesn’t require a revolution — just separating Zigbee into a component that can be accessed locally.
  2. Consistent device model Instead of sending raw data, the panel could expose a structured device description (e.g., JSON) defining entities, capabilities, and supported commands. This would eliminate chaos and redundant entities.
  3. Bidirectional communication The integration concept should support not only receiving states but also sending commands and configuration. Without this, HA can’t act as a controller — only as a spectator.
  4. Hybrid mode: eWeLink + local API NSPanel Pro could operate simultaneously in cloud and local layers - just like Philips Hue or Aqara. Users wouldn’t have to choose between cloud convenience and local control.
  5. Open specification + simplicity for everyday users The HA community can build the integration if provided with API documentation and device models. But many users expect a true “plug and play” experience. MQTT will never deliver that - it doesn’t solve the lack of Zigbee control or the absence of a consistent device model. And let’s be honest: the average user won’t survive configuring a broker, topics, permissions, and entity mapping. It’s simply not something that can be marketed as “easy”, no matter how nicely it’s presented.

Summary

The current MQTT‑based idea is inherently limited and cannot provide full Zigbee integration with Home Assistant. If NSPanel Pro is meant to replace an external coordinator, what’s needed is an architectural solution: a local Zigbee API, a consistent device model, bidirectional communication, and a hybrid mode. This would make NSPanel Pro an open, stable, future‑proof device - beneficial both for advanced users and for those who just want things to work without a headache.

5 Likes