Varying room temperature during the day

[CeSinge]

How can I configure the IRC or maybe other function blocks to have the temperature vary over the day, like for example:

• 20.5C between 8h and 9h
• 18C during the day, 9h to 18h
• 21C from 18h to 20h30
• 22C 20h30 to 22h50
• 14C at night

It seems Loxone knows only about two temperatures, Comfort and Economy (and a manual Warmer Operating mode that cannot really be controlled), while even a simple Honewell wall thermostat allows to vary the temperature by the quarter of an hour.
Not having some flexibility is either a serious waste of energy or a lack of comfort: physiologically, most people want more heat in the evening than in the morning.

I searched quite a bit for this but found nothing hinting at a way to do this. Is this somehow possible? Should I consider other components, or look for another solution altogether (losing my investment)?

[duncan]

use the old v1 'intelligent room controller' instead of v2 'intelligent room control'

it has 5 options for the temperature - increased (warmest), comfort, party, economy and house in deep sleep (was frost protection, coldest)

[CeSinge]

Thank you, duncan. I'll try that out and post back for the interest of others when I've something that works.
By the way, do the numbers in front of the Operating Modes have a function? As far as I can see, they have no real impact, they cannot be changed and seem more or less randomly assigned.

[duncan]

they are assigned by the config software - i dont think they have any significance

[Hudla]

I looked exactly for the same functions...I cant believe that v2 has only two modes? Are there any significant differences between V1 and V2? Duncan thank you very much for sharing.

[Christian Fenzl]

Easiest way would be a Timer block outputting the required temperature per time span, and use Tm (with mode M=3 or M=4) to manually set the temperature.

[pawel.urban]

Wait a sec... are you saying that I cannot have multiple temperature settings in Loxone, based on the schedule?

[CeSinge]

Indeed. I searched a lot to make this work, because I found it a hard to believe limitation. I also contacted Loxone and they confirmed that this is the case.

In essence, for all the sofistication they have in their software, the setting of temperature basically comes down to a single comfort temperature, that you can set per room, and the lower 'non-comfort' temperature. So you set the comfort temperature at 21C. Then - but that's only making life harder; it's not a limitation as such - instead of working with a second 'low' temperature like 15C, they work with deltas, a permitted deviation, meaning that you allow the temperature to drop by 6C. It would be clearer to simply say that the lower temperature is 15C, but that's not what they do... Likewise, you can set an upper deviation if you have a cooling system. That's it. (OK, you can set a frost protection temperature, as well).

Obviously, you can change temperatures manually, in the app or via a switch, but that's not the goal of home automation, I think.

For me, this is way too limiting. As I mentioned above, I want the ability to heat a bit in the morning, say to 19 or 20, not much during the day, gradually more towards the end of the day to 20-21, and a cosy 22-23 during the evening. Temperature should be an evolving curve in a decent system. Not possible.

The best workaround I could find is to have a Schedule block for each room. In that block, you can define schedules, and associte a 'value', the desired temperature, to each green schedule period. That value is output on AQ of the timer/scheduler block and input into Tm (Temp Manual) of an IRC. The temperature of your heating valve is input into Ti of the IRC and a constant value 4 is set to M (meaning the IRC works fully manually, piloted by the scheduler's AQ output). This way you can have different temperatures per day, as one would expect.

The drawback is that the IRC is now on Manual, meaning that you you lose all of it's internal logic: no preheating, no adaptation to the rate/speed of heating. When the scheduler tels the IRC to heat, at that time only will it turn the valve open and heat fully until the valve tells it that the temperature is reached. Given the heat energy still in your radiators at that point, the temperature in the room will continue to rise, and overschoot the desired 21C: that is precisely what the IRC avoids in automatic mode.
It is also hard to maintain, in part because there are many schedule blocks, one per room probably, and the schedule editing is buggy, clumsy to do.

This works, but is not ideal - also the reason why I stopped investing in Loxone completely. The fact that they stopped working with and selling to end-users directly was another reason.
I hope the above is a bit clear.

[Christian Fenzl]

A side notice to your explanation, about the modes:
You still can use the Mode=1 for automatic heating, and use parameter Tc to externally control the comfort temperature. This doesn't disable the PI controller. In the schedule of the IRC everything needs to be defined as comfort temperature.

[pawel.urban]

But, for example:

If I'd have my schedule to change temperature from 16*C to 21*C today at 16:00, it would start heating at 16:00, not reach it at 16:00 as I'd expect from my intelligent system

[Christian Fenzl]

I didn't raise this to question.
I answered CeSinge that the PI controller isn't disabled in the mentioned configuration (regarding to overshooting).

[pawel.urban]

Sure, that is without doubt.

[CeSinge]

pawel.urban Yes, this is indeed what happens in my config. Heating starts at 16:00.

Christian's approach is interesting. I've changed it right now to see what that gives, so I'll have to wait until tomorrow to see how that worked.
But thinking about it, I think that this solution implies to have two schedules for each room: one, the one I have in the schedule block, should be changed so that it changes the comfort temperature 1 or 2 hours before I want that temperature; and a second schedule in the IRC, that tells the IRC when that temperature is actually to be reached.
- at 16:00, the Schedule block sets the Comfort temperature to 20C on the Tm of the IRC. With that, the IRC still does nothing
- in the IRC, that second schedule, the one in the ORC, is set to 18:00. So about one hour earlier, the IRC will begin heating so that the new Comfort temperature is indeed reached at 18:00 (without overshoot etc).

Not only this is hard to maintain because of the 2 schedules; but I think that it will also become problematic if we want to increase the temperature to 20C at 20:00. When to change the Comfort temperature then? Given the IRC is then already in a 'heating/Comfort phase' it will change immediately to the newly set comfort temp, as soon as the scheduler changes it.

I know that at the time I searched a lot on this issue, because I could not accept the reality that Loxone cannot vary the temperature over the day (even not when their support confirmed it...).

[Christian Fenzl]

You have ONE schedule in the Schedule block, and FULL comfort temperature in the IRC. ("Everything needs to be defined as comfort temperature")

[Christian Fenzl]

BTW Overheating has nothing to do with pre-heating!!
The internal logics are completely different parts.
Pre-heating calculates a negative time offset.
Temperature control is done by a PI controller.
Overheating is a problem of _your_ heating system with to high flow temperature.

[pawel.urban]

It has, because Loxone is advertised to learn heating/cooling curves and adapt to that. That would mean, even if my source is maxed out, Loxone should know the inertia and close the valves prematurely. This is how I understood the IRC;

[Christian Fenzl]

And again, overheating has nothing to do with pre-heating.
Time to start (pre-heating) has nothing to do with temperature. control of a PI controller.

https://en.m.wikipedia.org/wiki/PID_controller

Don't mix up expectations and assumptions with facts.

[CeSinge]

I'll have to come back on this after the weekend: in my first quick attempt I'd left the IRC 'empty', so obviously it was not very hot here, yesterday evening - I corrected that finding out what Christian indicated at the same time as you wrote it...

As for the the pre-heating, you are correct, Pawel, and it is also what happens: if the IRC is used, it pre-heats in due time, before the time the set temperature is to be reached. The difference is indeed in the terms. But when not using the IRC but merely a schedule that dictates the manual temperature, then there is overheating, because the heating starts full speed at the set time, and stops only when the set temperature is reached. The inertia, the energy then stored in the radiators, creates overheating at that point - quite a bit actually.

The Loxone IRC indeed adapts, but from my experience, they start the preheating to reach the set temperature very early, sometimes about 2h before the temperature must be reached. That guarantees a very smooth increase, and no overheating, but in rooms where you do not heat except one hour a day (bathroom, bedrooms, ...), you're gradually heating for two hours for nothing.

[Paul Sinnema]

I wanted the same thing and have solved it this way. I added a clock module (I use the Dutch language, don't know the exact name in Config in English) and added 2 timezones (you can add as many as you need). Each zone has it's own value.





Turn off 'use as digital output' turning it into an analog value on AQ.



And finally use an 'Addition' module to add the temperature to use as set temperature.




I made the image on Sunday around 11:30 so the Clock value = zero. At 17:00 the value will be 1.00. Added that would set the temperature to 21.6.