Thank you for the detailed description. I will review the logs as soon as possible. If I need any additional information, I will confirm with you. I will contact you again once there are any updates.
Regarding this suggestion, I would like to ask if you are using a single temperature source to control multiple actuator devices in your home?
Sorry for the issue. I am trying to understand your setup here:
Central heating, but you can’t find dry-contact Zigbee relay for Bolier actuator, right?Thank you for your suggestion; it’s very useful. We will consider adding this feature to the device side in future iterations. We welcome you to share more ideas and suggestions with us.
Just about now (10:35) i saw all NSSP connected devices off-line, for a moment. Submitted log again.
It happens repeatedly, but in recent days it can last even few hours, when I am not able to control devices or see sensor data.
Yes, I would like to do that. Now there is one Temperature sensor in each floor(ground and first). Each temperature sensor controls a zigbee relay to turn on/off the heating(circulation pump). On the ground floor there are only radiators without any smart valve, so it is simple as is. On the first floor there are 3 fan-coils. In every fan-coil is a MINI-D relay, turning it on or off. So in order to heat the first floor, must be turn on the circulating pump and all 3 fan-coils at the same time. I can manage it with a smart scene in the ewelink app, but i would prefer to do it locally by the NSPP.
So if the thermostat could control the zigbee relay and the 3 MINI-D relays at the same time, it would be perfect.
Unfortunately the NSPanel Pro through MQTT doe not synch with HA alarm.automations as well.
After failing to use Alarmo, I tried using HA automations to make the NSPP act as an alarm panel and at the same time respond and synch with alarm commands from other entities related to the alarm system. The NSPP was unresponsive.
Interestingly it works well with SonoffLAN. For now I have reverted to Sonoff LANfor alarm synch triggers and actions.
Perhaps when NSPP entities start to be exposed through Matterbridge it will.work?
Short answer: No, Matter will not give NSPanel Pro the kind of alarm synchronization you’re hoping for. Even in the latest Matter specification (1.4.x), there is no application cluster for an alarm/security system:
Matter does support things like Door Lock, contact/occupancy sensors and various safety sensors (smoke, CO, etc.), but these are just individual devices. There is no standardized “alarm_control_panel” equivalent that could mirror Home Assistant’s alarm entity. Because of that:
So if you currently rely on SonoffLAN for alarm synchronization with NSPanel Pro, that’s not a temporary workaround = it’s effectively the only architecture that actually supports this use case today. Matter won’t change that unless the standard itself gains a dedicated alarm/security system cluster in the future.
NSPanel Pro does expose a MQTT entity like select.*_security_mode , but this is only a local mode selector, not a real alarm interface. It doesn’t publish alarm states and it doesn’t react to Home Assistant alarm commands.
That’s why your attempt to sync NSPanel Pro with Alarmo or HA automations didn’t work — the panel simply doesn’t expose its internal alarm logic over MQTT.
Only SonoffLAN can sync the alarm, because it uses the native eWeLink API where the full alarm functionality is actually available. Matter won’t fix this either, since the Matter standard has no alarm/security system cluster at all.
If eWeLink ever added full alarm support to MQTT, NSPanel Pro could synchronize with Alarmo and HA exactly the way you expect. But this would require major firmware changes, and eWeLink clearly isn’t moving in that direction. That’s understandable — NSPanel Pro was never designed to be a Home Assistant alarm panel. Everything eWeLink already provides for HA users is, frankly, more than generous. I’ll stop here, because the rest of the explanation probably wouldn’t be something you’d enjoy hearing.
The reason it “works well with SonoffLAN” is simply because SonoffLAN talks to NSPanel Pro using the native eWeLink API, where the full alarm subsystem actually exists. MQTT and Matter don’t have access to that alarm logic at all (Matter doesn’t even have an alarm cluster), so they can’t synchronize the alarm the way SonoffLAN can.
Hello @jam3 , I am not an expert like you and my comments are probably incomplete, but allow me to share a suggestion that I mentioned in idea 2 in another forum (https://forum.ewelink.cc/t/nspanel-pro-roadmap-and-co-created-future/206240/216) that may be helpful in this matter you are discussing.
From a complete lack of knowledge, would it be possible to create “virtual entities” (selectors, buttons or similar) that would serve as a bridge between the HA Alarm programming and the NSPP’s “Smart Security” module?
I do not know if it is possible or how it would be done technically, but if my idea is feasible, I believe it would be easy for the NSPP team to implement and would allow the NSPP modules to be managed from HA, and vice versa.
Your idea actually makes sense, and in theory “virtual entities” could work as a bridge between Home Assistant’s Alarm Control Panel and the NSPanel Pro Smart Security module. HA can already expose helpers like selectors or booleans, so the concept is valid.
However, in the current state this simply isn’t possible. The NSPanel Pro has no mechanism to receive or subscribe to external entities from Home Assistant. Even MQTT doesn’t solve it — the panel can publish some data, but it cannot reliably subscribe to HA topics or bind its Smart Security module to external MQTT states, not even with the beta firmware.
@Milk @MichaelLearnsToCode So the idea is feasible in principle, but the panel is missing the required communication channel. If the eWeLink team added MQTT subscribe or any API to read external values, your proposal would become completely realistic. However, NSPanel Pro was never designed to be a Home Assistant alarm panel. That’s why such a solution will probably not appear anytime soon, if it ever appears at all. Considering the huge number of other feature requests on this forum, implementing all of them in the NSPanel Pro would exceed the technical capabilities of the device. You simply can’t turn this panel into an all‑purpose super‑controller! It’s time to be realistic.
Based on your description and the logs, the NSPanel Pro lost its network connection at 10:32 and continuously attempted to reconnect until 10:35 without successfully re-establishing the connection. I also noticed that long-term connections at other times were somewhat unstable. You might consider changing the Wi-Fi channel for the NSPanel Pro to see if it improves the situation.
Maybe you could implement feature that we could get notification that there are issues with network? Because I have ubiquiti with very good coverage but nspanels pro seems sometimes to be very sensitive if there are crowded network
I have a Mikrotik and it has a strong signal. The whole street is covered, only the nspp has occasional problems with the wifi signal even for me.
I completely agree with you, but based on the idea of “virtual entities”, I can think of a way to implement them generically that would not consume many NSPP team resources and would offer HA users a wide range of possibilities. Furthermore, if this is feasible, you would avoid having to enable that communication channel to external entities that you mention, which seems much more elaborate and complex to programme.
My idea is to generate some “generic virtual entities” in NSPP so that they can be read via MQTT in HA and NSPP.
On the NSPP side, each customer should be able to assign these entities as sensors and actuators in the different NSPP modules as they wish, for example, “generic binary sensor 1” in “Smart Security” and “generic binary sensor 2” and “generic switches 1 and 2” in “Thermostat”. And on the HA side, each user could manually link these entities to their own devices through their own virtual entities or custom automations.
In this way, NSPP would be limited to a few pre-designed “generic virtual sensors and switches” that you can configure to the module that each user wants, and then in HA you could link them to specific devices or automations within HA.
Thanks for the clarifications. At least for now SonofLAN syncs the HA/Alarmo alarm status well through HA Automations.
Tuya has some very interesting physical Alarm Panels solutions. Unfortuntely they work thriugh the internet and Tuya Local SDK exposes very few alarm entities.
It is old house and wifi is far from perfect. But in the same room as NSPP, I do work on my (laptop) computer and have internet radio playing all day - both work without any issues.
So NSPP is the only device with any problem. Also, it might collect data from sensors (even if offline) and then send them in one file. Because zigbee should be fine even if wifi is not.
Keep in mind that the antenna in the NSPanel Pro has a lower gain (it’s a printed PCB antenna), and the device itself is most likely sitting inside a wall box. You can’t compare that to a laptop or a media player. By definition, the signal strength and connection quality are worse. When it’s mounted inside a wall, the signal is also partially attenuated, which is completely normal.
What is the point of collecting Zigbee data and then sending it somewhere? For what purpose is this supposed to happen?
I understand the idea, and technically it’s a clever workaround qith a small set of generic virtual entities that users can map however they want in HA. But this still doesn’t change the core point I was making: once you start adding generic sensors and switches just to let users repurpose them, you’re effectively turning the panel into a universal controller by the back door.
It may look simple on the NSPP side, but it shifts complexity to the user and blurs the boundaries of what the panel is actually designed to do. My comment was precisely about avoiding this kind of “implicit extensibility”, even if the mechanism itself is lightweight.
