How to set thermostats to OFF mode if they are in a climate zone????

[Neo Andersson 230]

Hello guys
Sometimes customer needs to completly turn off his thermstats, so set them to OFF mode..
Kill me, but i could not find any reliable way to do it if the thermostat is present in any climate zone..Maybe someone can show me the way

problem is

If the thermostat is present in any climate zone, setting something on the thermostatdevice itself we just create an override of setpoint for a certain time or permanently, but not the mode ever..

So knowing that i thought, i can go and just turn off (set to OFF) the climate zone itself...well this doesn't work either, because although the schedule by itself will not trigger the upcoming changes, but the thermostat itself is still not in OFF mode..It still keeps the HEAT mode..Okay, i made one the step further..What if i set the climate zone to off (to avoid scheduled re-set to some heating setpoint) and then set the theremostat device itself to OFF....well there is still te problem of override, so the OFF mode holds only until the timer runs out and it jumps back to heat..even if the climate zone plan is set to OFF.

Well now i am in a situation, that i dont know how on earth just simply set all the thermostts to OFF mode pemanently, or all the climatezones to OFF (and so the thermostats too)...(until user decides he wants to HEAT again)

 

So anyone has some clever solution???

 

Thanks ahead

 

[marczu_83 29]

From the top of my head.. maybe try to disable device? the hint says "the gateway will not communiate with disabled devices

[MAC71 10]

I took my thermostats out of climate zones and control them via scenes

[Łukasz997 120]

My experience with thermostats assigned to a "climate zone" is exactly the same - they cannot be fully controlled. This happens regardless of whether the zone itself is enabled or disabled. I could suggest a way out of this situation, but I should say upfront that it is not immediate and does require some work.

 

So, why do not write your own climate zone controller?

The main obstacle is the lack of a reasonable way to create a custom user interface. But then again - why not reuse an interface that already exists?

- remove all thermostats from the "climate zone", leaving the schedules intact

- in our application, copy the zone data into our own data structures

- our framework then takes over and performs the actual control

 

I have to admit that I have not tested whether data copying from climate zones is actually possible. Knowing the general capabilities of the Fibaro API, I assume it is. This capability is fundamental if you want to achieve real ease of use.

Algorithmically this is simple. Yo will no longer need additional plugins like heat activators. What is invaluable is that you fully understand what is happening inside - shape the logic freely, do not guess. Also, such a framework could expose its own API to external QuickApps that want to influence the climate - for example, temporarily disabling certain radiators because a window has been opened in a room. Or you could just build this kind of automation directly into the framework itself - why not?

It seems like interesting idea to me. There have already been some attempts in this direction by users, but in my opinion they were rather simplistic - more like a band-aid solution. Here you could actually tackle the problem properly, end to end.
 

It’s tempting to take this on as a continuation of my series of programs that nobody actually needs...  
So I’m putting it next in the queue - but before that, there will be something completely new: the LiceMan.

[marczu_83 29]

Getting back to my idea, I just ran a test: I set the thermostat to off, then disabled it and updated the schedule for that thermostat and two others. The two were updated with the new setting, while the disabled one stayed off.

Cytat

- remove all thermostats from the "climate zone", leaving the schedules intact

The first issue is that the schedule requires a thermostat, so you’d need to bypass this with a virtual device.

Cytat

It’s tempting to take this on as a continuation of my series of programs that nobody actually needs...  
So I’m putting it next in the queue 

Cant wait

 

[Neo Andersson 230]

I would not go for a custom scheduler, just becuase of the lack of UI representation..I cant create a professional look for any custome scheduler for mobile app usage, as we are so hardly limited in CSS, HTML etc..
When you remove the thermostat from a schedule (like you wrote) that schedule won't exist anymore. You can't have a climate zone created wihtout a thermostat included..so this is not possible
However, meanwhile i think there is a workaround. We have to put the zone into OFF entirely, and it puts the thermostat itself to OFF mode. But what i noticed, there are some strange UI looks, when you actually return all zones to schedule..Anyway, thanks for the suggestion.
I just hope, that one daay Fibaro will realise, that giving more freedom for more experienced users to create some nice QAs with some really nice UIs will eventually help not only users but Fibaro itself. I dont really understand, for what reason did the not make that step..this is beyond my comprehension..

 

 

[Łukasz997 120]

10 minut temu, Neo Andersson napisał:

I would not go for a custom scheduler, just becuase of the lack of UI representation..I cant create a professional look for any custome scheduler for mobile app usage, as we are so hardly limited in CSS, HTML etc..

But I actually don’t want a new interface at all - I want to reuse the existing one, which is not that bad. The workaround for the “schedule not existing” issue due to the lack of a thermostat was mentioned by @marczu_83.

It’s true that I’m not fully addressing your problem. Sorry about that - I was simply thinking aloud about something new. And I have to admit that I got quite excited about it, because the room for improvement is significant. This is probably the only upside of Fibaro’s shortcomings - they give me some room to play around.

Edited December 19, 2025 by Łukasz997

[Brors94 115]

10 hours ago, Łukasz997 said:

 

I like your idea with a custom controller, and have the logic in a QA. And just add a "Termostat QA" that you hide in each room to make the Zone that the user can controll the timers with.
I know the api gives you all the timers from the zone control and event when you update them that the QA can act on  
So it is possible to make it


 

[Christb 33]

On 12/19/2025 at 8:51 PM, Brors94 said:

know the api gives you all the timers from the zone control and event when you update them that the QA can act on

The api for Climate zone is very powerful and you can get all needed information to control any climate device.

Be carefull, there are some hidden rules about setPoints and Heat & Cool or Auto modes...I discover them by testing ->error -> correction. 

Using it I have been able to create a QA which using a single UI view enabling any change of any climate zone parameters.

Will be easy to add a child in charge of managing Thermostats with your own way.

For your information, the QA UI looks like that in YUBII:

Please login or register to see this image.

/monthly_2025_12/image.png.943677722386df4e393e8e4cfaaac411.png" />

 

[Neo Andersson 230]

yes, we know that,,i can create easily powerfull quickapp for it , if it worked.
See the picture. We put the zone into permanent OFF mode, but the thermostat still remains in HEAT mode

Please login or register to see this attachment.

Edited December 21, 2025 by Neo Andersson

[Łukasz997 120]

 

I agree with @Neo Andersson, with one reservation: it’s not so much that it doesn’t work, but that it does NOT ALWAYS work. My whole house is based on Fibaro heads, and I’ve “suffered a lot” with them. Luckily, I still have a beautiful, wood fueled tiled stove…

 

After careful observation of how this mechanism works (Heads + Heat Activator plugin), I’ve come to the following conclusions:

- boiler activation is event-driven

- there is something like PID controller “hidden” inside the heads, with unknown and non-editable settings

- the plugin itself has a fixed hysteresis and relies on the “heat required” information (not exactly groundbreaking…)

- there are communication issues between the heads and the controller in roughly 10%+ of cases (most often: boiler is activated, heads closed, half of a day of that...)

- there's no access to the head valve state (% of open)

 

As a whole, it works, but it’s unreliable. For me, there’s absolutely no doubt that the “event” model is not 100% reliable. I have plenty of evidence for that - for example, a water meter/virtual leak guard implemented on a Smart Implant, which loses between 600 and 1000 events per month!

After some very preliminary thoughts, born somewhere between the vacuum cleaner and a cleaning cloth (Christmas cleaning; a creative moment for a still-sane man), I came to the conclusion that heating in Fibaro needs not evolution, but a revolution.

- control should be based on a “closed loop”

- the PID + PWM (not sure about that) should live in a QuickApp, with access to and the ability to change parameters. This directly implies a closed loop, because a PID must receive data at regular intervals. Why I expect PID to be better than simple the hysteresis? It's usage is somewhat limited, because we cannot (at least I can’t) modulate boiler power. But we can optimize (I hope) the number of boiler start-ups and its runtime. That alone is already a lot, and it’s extremely important for boiler longevity! Besides, virtually every boiler already has something like a heating curve built in.

- I have no hesitation in claiming that thermostat settings can be completely ignored! The “heat required” bit not only can but must be ignored. There is nothing more unreliable in Fibaro than “heat required”.

- of course, thermostats still need to be controlled, but only on a simple basis: open, close. ALL the logic behind this should be clearly described and configurable in the QuickApp.
*
My evaluation of the whole issue was premature; this problem is more complex than it initially seemed. And I'm not so sure if I can proceed with it.

[Neo Andersson 230]

We have never ever used the Heat Activator plugin. We have our own developed, very dynamic, flexible plugin for that. It not only manages boiler->thermostat relations but also heat pumps if there are any. It also monitors ventils (if any) linked to a thermostat, and monitors the temperature trend (user can see actually how the tmperature changed over the time) and most imprtantly user can see if the zone is actually heating or not. (using heatRequired property from fibaro heads, and other known properties from other brands, and if theres no such property it falls back to temperatue+hysteresis vs setpoint logic).

So that part is working like a charm for us. The only part that is not reliably working is the sync between the modes. It is obious, that putting the schedule into OFF mode might, or should not mean, to set OFF the thermostats. That i can understand. Because setting a schedule to OFF should mean, that fibaro takes aways its hands from setting any setpoints on thermostats. However, if user has thermostats included on climate zones, so he has some schedules running, there can be some moments, when he wants entirely turn off the heating, so set all the thermostats to OFF mode. In this case setting the zone to OFF doesnt help. The only way to achieve this is to set zones to manual-> permanent OFF..Thats the only way. However, calling this on 15 zones manytimes ends in failures on some zones. Some of them remains in HEAT, some of them gets to OFF. So we decided to call these manual OFF commands with some delays. We will test this approach , but it seems that this solves the puzzle.

 

Please login or register to see this image.

/monthly_2025_12/image.png.5d9f0211d590a4bd2bff8c52397bb779.png" />

 

 

[Łukasz997 120]

Tell me please if you base on events to manage all this, or rather on closed loop (examine values every x min.)? Or hybrid?

[Neo Andersson 230]

No, never loops..Everything is based on events..Its very reliable. 

[Neo Andersson 230]

the biggest problem for us is, that setting a zone to permanent OFF is not possible from any UI. Neither from the mobile APP nor from the web UI, so we are doing it by LUA code..It is a shame, that such a basic functionality is not possible from any UI.

[Łukasz997 120]

W dniu 21.12.2025 o 20:31, Neo Andersson napisał:

Its very reliable. 

I wish I could say the same about my system.

*

To conclude the topic of the new heat activator: after some reflection, I must admit that my initial conclusions were wrong. A PID controller cannot be applied in a situation where none of the system components can be smoothly modulated (all is only on or off - in such case, a simple temperature hysteresis is sufficient).

So, in principle Fibaro-based heating setup is architecturally correct: the plugin acts as a boiler switch, and heat modulation is achieved via the radiator valves. As for the practical implementation, my experience is as described above.

[Mike MJ 3]

This is how I finally worked out how to manage Heating Zones reliably. I have 14 heating zones in a new house. Each one has a thermostat formed by linking a temperature measuring device ( mostly Fibaro Motion Sensors… FGMS-001) to a switch that turns the heat on or off … mostly Fibaro FGS213) . That process has established 14 zones on the HC3.  I could adjust those zones within the HC3 but I could not find any way to permanently turn them OFF . What I do now is that once the zones are established within the HC3 I do all my management from the Yubii Mobile App. From that user interface I can set up a schedule, I can temporarily override the schedule  and I can permanently turn each zone OFF.   

Hope this helps. It did take me a long time to discern the 2 methods of controlling the zones and to understand that 1. Use the HC3 to establish a zone and 2. Use the Yubii App to manage them.