Hello I have a few TRVZB valves managed by a NS Panel Pro and paired with SNZB-02B sensors. I noticed that they spontaneously go to boost mode and stay there with a very high set point. This makes them completely useless.@milk I need an urgent fix or I am forced to uninstall all valves.
Oh my! Before uninstalling all your TRVZBs, I think it’s worth investigating what actually triggers Boost mode. 
@milk I’ve been using TRVZBs for a long time and have never seen them spontaneously switch to Boost. Whenever I’ve encountered unexpected behaviour, there has always been something external behind it. Of course, the firmware isn’t perfect (I know that very well) so I’m not ruling out a firmware bug. But I’d investigate more deeply before jumping to conclusions.
Since you’re managing the valves through NSPanel Pro and using SNZB-02B external temperature sensors, I’d start by checking the panel configuration and logs. There have been reports of TRVZBs entering Boost after an NSPanel Pro restart, so that’s one possible lead worth investigating. A few questions might help narrow it down:
- Do all valves enter Boost at the same time, or does it happen randomly?
- Does it happen after an NSPanel Pro restart?
- Have you verified the actual state on the TRV itself, rather than relying solely on what the phone app displays?
- Have you checked the external temperature sensor assignments and the relevant logs?
- Are the TRVZBs paired directly with NSPanel Pro, or are they connected to another Zigbee gateway, such as iHost, with NSPanel Pro only being used to manage and control them?
The screenshot shows Boost enabled and a 35°C setpoint, but it doesn’t tell us what triggered the mode. Could it have been enabled manually, or activated by a command from NSPanel Pro or another rule?
And honestly, threatening to uninstall all the valves won’t help identify or fix the problem. You’d be the one losing the convenience of the system, while the actual cause could remain unresolved. As we say, “cutting off your nose to spite your face.” 
I understand the frustration, but a few logs and some systematic troubleshooting would be a much better starting point than an ultimatum. It would be a shame to replace perfectly good valves before establishing whether the problem lies with the TRVs, NSPanel Pro, or the way they interact.
Love & Peace 
Hi, I’ve received your feedback, but I couldn’t find any submitted logs for the device ID you previously provided.
Could you please submit the NSPanel Pro logs as soon as possible after the issue occurs again, and also let us know the approximate time when the abnormal behavior was triggered? This will help us locate the relevant records more quickly.
Thank you again, @jam3 for the detailed additional information.
Well, at least we know the feedback button works! 
Now let’s see if the logs tell us what actually happened.
Hello jam3 thanks for your fast reply.
If the thermostatic valves go to maximum temperature uncontrollably, I spend a fortune. Since the central heating is still turned off I have a week or so to solve the issue. Just to be clear, this isn’t a threat; it’s a desperate move. 
No one wants to reinstall the old valves less than I do (especially since the Sonoff ones have served me well so far).
Regarding your questions:
Do all the valves enter “Boost” mode simultaneously, or does it happen randomly?
I noticed that the thermostatic valves (TRVs) switched to “Boost” mode twice on different days. I found all TRVs in the same state. I just checked again and found only one valve in Boost mode, exactly as shown in the screenshot. Looking at the device, I see that the flame icon isn’t lit, which makes me think it isn’t actually open. Is there any other way to verify the actual open state of the valve?
Does it happen after an NSPanel Pro reboot?
No, there hasn’t been a reboot.
Have you checked the actual status directly on the valve, rather than relying solely on what is displayed in the app?
I was able to check it right now and if I am not mistaken it seems that the boost mode doesn’t open it but I cannot be sure sinche the centra heating is still off.
Have you checked the external temperature sensor assignments and their logs?
They seem fine, but to reduce complexity, I have unlinked the external thermometers. Where can I find the logs?
Are the valves paired directly with the NSPanel Pro, or are they connected to another Zigbee gateway (like iHost) while the NSPanel Pro is used only to manage and control them?
They are paired directly with the NSPanel Pro.
Good, at least we’re narrowing things down! The important distinction here is whether the TRV actually opens or merely displays Boost mode. A screenshot can tell us what the app reports, but not necessarily what the valve is physically doing.
Just to mention - I do have one TRVZB (of four), which reports state as “Idle” in eWeLink on mobile phone, but is heating. So, it works as expected, but report wrong state. Have no idea why… Connected via ZBBPro, so it is not related to NSPP.
I just tried few times to close/open valve (set temperature low/high) and it is OK now. So thank you everybody for your help. :-)))) It works now.
Sounds like the TRV might simply have gone back to sleep before updating its reported state.
TRVZBs are notorious sleepyheads, and in ZHA we sometimes see their reported state lag behind reality, too. The valve may be doing exactly what it should while the app is still catching up. Glad it’s working now!
All TRVs in Boost again? That’s quite a coincidence!
Disabling Adaptive Mode is a reasonable troubleshooting step, but it would be interesting to find out what is actually triggering Boost rather than just disabling features one by one. Hopefully, the logs will finally shed some light on this mystery.
I agree. Since it was released in spring, I would like to try the adaptive mode. I hope that the logs will give us a glimpse of what’s happening.
It’s not the adaptive mode. I just found a trv in boost mode. Again. It seems closed. Pushing the button it shows OF and LC
Hi, based on the logs, the issue may be related to abnormal status reporting from the TRV device. We’re currently arranging further testing and verification with the relevant team.
To avoid unnecessary energy consumption in the meantime, you can temporarily remove the TRV from NSPanel Pro. Its existing schedules can still run normally, so this should not affect the device’s normal use.
I’ll keep you updated as soon as we have the test results.
Same issue for me, 4 of 7 goes randomly boost mode 
What happens if you leave them disconnected from the network, so that they are completely isolated / offline?
@Milk
How do Gen1 and Gen2 devices function when there is no connection to the bridge or the cloud? Do they store schedules and settings locally, and do they have an internal clock?
If they have an external temperature sensor configured, do they switch to the built in one when there is no network connection?
Yes, the do. If there’s no connection, they go locally. At least those of mine do.
Hi, could you please submit the NSPanel Pro logs as soon as you notice the issue again?
You can submit them by going to:
Swipe down on the screen > Settings > About > Feedback > Submit
We’ve carried out some simulation tests, but the issue did not occur on our test devices, so we’re still investigating the possible cause.
If you remove them from the Zigbee network, the schedules stored on the TRV itself can still continue to run for a while.
However, any configured external temperature source will stop working, because that data needs to be forwarded through the gateway. In that case, the TRV will fall back to its built-in temperature sensor and use its own temperature reading to trigger the schedules.