Intelligent room controller: input current operating mode

[J V]

Hello,

I'm trying to configure an Intelligent Room Controller block to work in cooperation with my Gira Pushbutton Sensor 3 Plus thermostat. So far, I can input the current temperature and current setpoint temperature from the Gira thermostat into the Intelligent Room Controller block. I quite sure I can also output the setpoint temperature to the thermostat.

The thermostat has operating modes, defined as Comfort, Standby, Economy and Building protection. These include a pre-set setpoint temperature (on the thermostat, they resemble Home, Night, Away and Protection). The Intelligent Room Controller also has this internally, but there seems to be no input nor parameter to set the current operating mode in this one. It is not the one of the inputs Am or As.

Is there an input like this (e.g. indirectly, by only setting the value of the appropriate T parameter)? Or a way around it?

Thanks,


Jörg

[J V]

The more I search, the more I'm beginning to think it is not possible. It looks like the Intelligent Room Controller is really meant as the control point, to it sets the operating mode. But what is the output AQhm on http://www.loxone.com/enen/service/documentation/loxone-config/function-blocks/intelligent-room-controller.html?shorturl=true ? The example is not very clear on that... Is it the current operating mode?


Jörg

[duncan]

i tried to integrate the set point of knx thermostats but it really doesnt work well. the best way i could get full integration was the following:

you can use the knx thermostat operating modes to select the IRC operating mode - create some loxone operating modes for that particular room eg eco/setback, comfort temp, higher temperature and set them to the desired temperature for 24hrs within the IRC, then map the knx modes via knx sensors to select one of the operating modes. that way you can use the knx modes to select eco/setback, scheduled (no additional operating mode selected), comfort and higher temperature. use a timer to reset the knx room thermostat back to whichever of its modes you have used for normal schedule. now cycling through the knx operating modes will cycle the IRC between normal schedule, eco/setback, comfort and higher temperature.

feed back the current temperature and target temperature to the kxn thermostat via knx outputs, and if the knx thermostat can display messages then send custom messages back about which mode has been selected by using the output of a state block

ive dont this with the MDT glass room thermostat and it works very well - it normally shows the target and current temp, and pressing the heating mode button selects one of the non-scheduled options and displays the chosen heating mode via a knx text output. - it also includes a fan mode which ive mapped to control the mvhr system boost level, and 2 general buttons which ive used to select lighting scenes, so only 1 device needed in most rooms

[J V]

My idea was to have the KNX thermostat exhibit some normal schedule (eg day/night cycle), and then optionally allow the Miniserver to override it. I still consider the Miniserver as an addon to provide a user interface or some added functionality, but don't want my system to depend on it. I'm not good at KNX, so am avoiding at the moment to change much in that programming.

I managed to feed the current KNX operating mode (comfort, standby, eco or protection) to the IRC block, by "abusing" the motion sensor (this sets it to comfort); early exit (this triggers eco) and window sensor (this triggers protection) and setting the timeouts Tsc and Tss both to 1. The standby mode is when no other mode is active. I also managed to feed it the current temperature and current setpoint temperature. I could do this as I have not motion or window sensor.
In this configuration, the IRC reflects my Gira thermostat when it comes to operating mode.

But your solution to define custom modes in the Loxone is much more elegant! I'll do that first... Thanks.


The following is still to do:

For the setpoint temperature shift; I will add the functionality that the IRC switches to manual mode and then takes the setpoint temperature from the input, if the setpoint shift is not equal to 0.

The other way around for the operating mode is more complicated, as the IRC does not output its operating mode. My current idea is to check the target temperature it outputs, compare that to the fixed setpoint temperatures of comfort, eco, standby and protection and if it matches to switch the thermostat to the operating mode that has this temperature (this should also switch the IRC to that mode). If it does not match anything then the thermostat stays in its current mode with the setpoint shift set.

This should make both intelligent room controller and thermostat synchronized and it should respect both timers. I then plan to add something that the miniserver can override the timer of the thermostat (either by re-sending the intelligent controller settings when the thermostat changes it, and/or disabling some inputs).

With a radio button block, I can set the KNX operating mode and with a +-pushbutton I can set the temperature shift.

Still some work to do, but I think it will work.

[duncan]

i tried something similar, but ended up with either a negative feedback loop where the modes wouldnt change, or a positive feedback loop where they constantly changed/cycled, hence my sticking to the preset range of temps within the IRC.

the logic around the IRC gets a lot simpler if you use some operating modes rather than using the window/early exit options - and the visu represents whats going on properly as well. This is a view of the logic around my IRC to add control from the mdt room controller.

the IRC mode memory flag on input Am is just there to override the heating/cooling periods - it causes no end of confusion during testing because of the cooling targets, and since we are unlikely to have cooling in the uk then i usually have all the IRCs set the auto heat only via this flag.

There is also a global operating mode used for all the IRCs which sets them to setback/eco temp 24hours a day. This is applied via a radio switch to turn the heating off in summer without upsetting the IRC learning, but enables any of the local room operating modes to override this with a boost mode by having these higher up the operating mode ranking - so the heating is off, but the knx room controller can override this with a boost operating mode if it gets a bit chilly.

[J V]

Yes, I also encountered some negative feedback loop (thermostat showed on the display: setting discarded).

Before your post, I did not realize I could add custom operation modes in Loxone Config. I already added them, but am a bit stuck with some smaller things now: sending the operation mode and sending the setpoint to my thermostat.
Sending the operation point works consistently for 3 out of 4 modes. When selecting the third one in the loxone interface, it switches to the 4th one when the previous mode was the second. It switches correctly to the third one when the previous one was the fourth. Probably some small mistake somewhere. The setpoint temperature also is not received by the thermostat, but I suspect it is related to the DPT types.

Thanks for posting your config, and thanks for the suggestions!

[J V]

Ok, I have the hell of time trying to send the operation mode (via a radio button block) to the KNX thermostat... This is the documentation:
-
KNX status operating mode
Name D.Input controller extension
Type 1 byte
DPT 20.102
Flag C, W, T, (R) 1 Description 1-byte object for that the display of the controller extension can use to switch between the Comfort, Standby, Night and Frost/heat protection operating modes. Only when "Controller status" = "KNX compliant".
-

The controller is set to KNX compliant.

DPT 20.102 according to the KNX documentation is PDT_ENUM8 or PDT_UNSIGNED_CHAR., bit encoded (values 1, 2, 4 and 8 for the 4 modes).

Loxone doesn't seem to have a matching datatype: http://www.loxone.com/enen/service/documentation/loxone-config/eibknx/data-types.html
I can read the value using a KNX sensor with type EIS6 and scaling from 0-100 to 0-255: the last 4 bytes are then ok and represent the modes. The 5th byte is also true, which I gather from the KNX documentation is not impossible.

However, sending the value is proving difficult. This is the documentation:
-
Function Operating mode switchover
Name R.Input
Type 1 byte
DPT 20.102
Flag C, W, T, (R) 1 Description 1-byte object for switchover of the operating mode of the controller according to the KNX specification. This object is only available in this way when the operating mode switchover is to take place over 1 byte (parameterdependent).
-
If I send the same value to the bus as an EIS6 type and appropriate operations to scale it, I can set the system to modes 1,2 and 8. I cannot set it to mode 4. I have also tried with an Extended actuator for each mode, with x/y/z:4%, but it also fails for mode 4. I can see in the liveview that the mode gets set and immediately after that it is switched to 8. I have no idea why.... and why only this mode...
I know that 4 is the 3 bit, and 8 = 2^3, so I am thinking something there is wrong, but everything looks fine. Other option is something with the EIS datatypes. Is there a better why of dealing with DPT 20.102?

It also affects setting the thermostat to mode 3: it then says "setting discarded" and switches to mode 4. This seems to indicate some feedback loop, but I cannot figure out why only this mode. Any hints on how to debug this?

Thanks,

Jörg

[duncan]

i didnt bother getting the visu to update the knx thermostat icons, just the other way round. in my design the visu is only used for whole house boost modes, where as the individual rooms will only be controlled by the knx wall thermostat. since the feedback or mood change is by text back to the knx device, the on-screen text always shows the current mode anyway

[J V]

Yes... I'm a bit puzzled why it responds correctly to modes 1, 2 and 8. The reaction it gives to mode 4 is that it switches to 8, so it makes me think that it gets a value of the correct type (otherwise it ignores), but with a wrong value. I'll try to see if I can find it. The reason that I got the setting discarded before was due to a feedback loop. So I will look a bit further to see if I can send a value that sets it to night, and then how to avoid the feedback loop (have some ideas already).

Thanks!

[J V]

Small update: I figured out why the modes do not work correctly. Getting the current operation mode from the thermostat results in an object with values 33, 34, 36 or 40 (1,2,4,8; each +32). Setting the mode on the thermostat can be done by sending values 1,2,3 and 4. No idea why there is this difference, it may have to do with some type conversion, but this way it works. To solve the loop problem, I used an analog memory that updates when the current mode differs from the desired mode.

So I currently have a radio button that allows me to set the mode of the thermostat, and that updates correctly when the mode on the thermostat is changed.

Duncan's idea of using custom modes in the intelligent room controller works. Each mode has a number (unfortunately hardcoded and not changeable), and this is the number that is found on the AQhm output of IRC. So I can also already have IRC set the mode of the thermostat. Now just to get the current mode into the IRC...

And then make the setpoint shift work (should be similar to the approach for the radio button for the mode)... More to follow... :-)

[J V]

There still are some issues... there was a loop still, but I redesigned and and will have to test again. The new app also shows comments such as "window open" in the IRC, so also not ideal to use them to set things. For now, I'm omitting the IRC and focussing on getting the radiobuttons nicely synchronized without loop. I have some ideas for the IRC but will wait with that one.

[abel1303]

The Intelligent Room Controller maintains a set room temperature level as well as immediately changes in between home heating and air conditioning. retro bowl