Correct use of TT and TC overrides

This Forum is about the Opentherm gateway (OTG) from Schelte

Moderator: hvxl

Correct use of TT and TC overrides

Postby cville » Wed Dec 04, 2019 8:27 pm

I'm using an OTGW with an iSense thermostat. I'm running into a problem issuing TT and TC overrides and hope someone can enlighten me.

Objective: send a command to the iSense every day at 16:00 that raises the room setpoint from 21.0 degrees to 21.5 degrees [this is just an example]. My Python program successfully sends the required commands via MQTT and they are executed correctly. Here's my problem though: I would expect the room setpoint to change like this:

room setpoint: 21.0
room setpoint: 21.5

This is not what happens in reality:
room setpoint: 21.0
room setpoint: 19.5
room setpoint: 21.5

19.5 is the thermostat fallback setpoint; it could just as easily have been something else. This is really problematic as it has the following consequences:
1. the room setpoint drops significantly below the room temperature
2. the control setpoint drops to its safety value, in this case 6 degrees
3. the boiler notices that the boilerwater temperature is way above the control setpoint
4. the boiler switches off and enters into the anti-pendle mode

Thus a request increase the room setpoint results counter intuitively in switching the boiler off.

I have not found a way to get around this problem; not by changing settings nor by programming around it. Any help would be appreciated.

I've included a partial logfile below, showing the period from just before the TC command to when the boiler switches off:

Code: Select all
18:27:32.591108  T80000100  Read-Data   Status: 00000001 00000000
18:27:32.742215  B4000010A  Read-Ack    Status: 00000001 00001010
18:27:33.595834  T10012D00  Write-Data  Control setpoint: 45.00
18:27:33.746951  BD0012D00  Write-Ack   Control setpoint: 45.00
18:27:34.091003  Command (via websocket from 2001:981:9ceb:1:8c1e:f10:fc35:d5ca:63866): TC=21.5
18:27:34.111721  TC: 21.50
18:27:34.600326  T00110000  Read-Data   Relative modulation level: 0.00
18:27:34.752702  BC0110F00  Read-Ack    Relative modulation level: 15.00
18:27:35.605195  T80190000  Read-Data   Boiler water temperature: 0.00
18:27:35.761195  BC0192B80  Read-Ack    Boiler water temperature: 43.50
18:27:36.608558  T00090000  Read-Data   Remote override room setpoint: 0.00
18:27:36.619551  R801C0000  Read-Data   Return water temperature: 0.00
18:27:36.760816  BC01C2880  Read-Ack    Return water temperature: 40.50
18:27:36.771815  AC0090000  Read-Ack    Remote override room setpoint: 0.00
18:27:37.611564  T00090000  Read-Data   Remote override room setpoint: 0.00
18:27:37.623915  R801C0000  Read-Data   Return water temperature: 0.00
18:27:37.765053  BC01C2880  Read-Ack    Return water temperature: 40.50
18:27:37.777418  AC0090000  Read-Ack    Remote override room setpoint: 0.00
18:27:38.616051  T00090000  Read-Data   Remote override room setpoint: 0.00
18:27:38.627037  R801C0000  Read-Data   Return water temperature: 0.00
18:27:38.770663  BC01C2880  Read-Ack    Return water temperature: 40.50
18:27:38.781666  AC0090000  Read-Ack    Remote override room setpoint: 0.00
18:27:39.619300  T00090000  Read-Data   Remote override room setpoint: 0.00
18:27:39.630285  R801C0000  Read-Data   Return water temperature: 0.00
18:27:39.770169  BC01C2880  Read-Ack    Return water temperature: 40.50
18:27:39.781194  AC0090000  Read-Ack    Remote override room setpoint: 0.00
18:27:40.623540  T10101380  Write-Data  Room setpoint: 19.50
18:27:40.769778  BD0101380  Write-Ack   Room setpoint: 19.50
18:27:41.628407  T00630000  Read-Data   Message ID 99: 0
18:27:41.639393  R801C0000  Read-Data   Return water temperature: 0.00
18:27:41.777901  BC01C2880  Read-Ack    Return water temperature: 40.50
18:27:41.790275  AF0630000  Unk-DataId  Message ID 99: 0
18:27:42.632647  T80700000  Read-Data   Message ID 112: 0
18:27:42.645015  R801C0000  Read-Data   Return water temperature: 0.00
18:27:42.778515  BC01C2880  Read-Ack    Return water temperature: 40.50
18:27:42.789500  A70700000  Unk-DataId  Message ID 112: 0
18:27:43.635630  T00000000  Read-Data   Status: 00000000 00000000
18:27:43.787995  BC000000A  Read-Ack    Status: 00000000 00001010
18:27:44.640498  T10010600  Write-Data  Control setpoint: 6.00
18:27:44.796609  BD0010600  Write-Ack   Control setpoint: 6.00
18:27:45.643988  T00110000  Read-Data   Relative modulation level: 0.00
18:27:45.796358  BC0110000  Read-Ack    Relative modulation level: 0.00
cville
Starting Member
Starting Member
 
Posts: 5
Joined: January 2018

Re: Correct use of TT and TC overrides

Postby hvxl » Thu Dec 05, 2019 9:34 pm

You don't indicate how the initial room setpoint of 21.0 in your scenario was set and your log is too short to see it. I suspect it was also done through a TC or TT command. Otherwise the OTGW would have sent 21.5 degrees in the message at 18:27:36.771815.

My experiments showed that the iSense would not pick up a change of the override setpoint. Once the setpoint is overridden, the iSense keeps that setpoint regardless of the value being sent in subsequent override messages. The only way I found to change the override setpoint on an iSense is to first switch back to the scheduled temperature. Then on the next cycle the new override setpoint can be set. There is special code in the OTGW firmware to detect if the thermostat is an iSense and then perform this work-around. Unfortunately this causes the effect you describe.

So this behavior is due to a bug/quirk of the iSense. The OTGW is handling that the best way I could come up with. But if you can think of a better way, let me know.
Schelte
hvxl
Senior Member
Senior Member
 
Posts: 1223
Joined: June 2010

Re: Correct use of TT and TC overrides

Postby cville » Fri Dec 06, 2019 1:26 pm

hvxl wrote:You don't indicate how the initial room setpoint of 21.0 in your scenario was set and your log is too short to see it. I suspect it was also done through a TC or TT command. Otherwise the OTGW would have sent 21.5 degrees in the message at 18:27:36.771815.

You're right; it was a TT command. I used to let the iSense run a program but realized that it was much easier to let my code run the program. That way I never have to use the iSense UI to activate/change a program. To allow this I've set the thermostat to a constant temperature but as you've explained below, this has an undesired side effect.

My experiments showed that the iSense would not pick up a change of the override setpoint. Once the setpoint is overridden, the iSense keeps that setpoint regardless of the value being sent in subsequent override messages. The only way I found to change the override setpoint on an iSense is to first switch back to the scheduled temperature. Then on the next cycle the new override setpoint can be set. There is special code in the OTGW firmware to detect if the thermostat is an iSense and then perform this work-around. Unfortunately this causes the effect you describe.


That certainly explains the noted behaviour and this fully explains why I can't program around it. Thank you for sharing this.

So this behavior is due to a bug/quirk of the iSense. The OTGW is handling that the best way I could come up with. But if you can think of a better way, let me know.

If the iSense requires you to drop back to a programmed temperature, I see no other solution than to change my code to again make use of an iSense program. Using my own code to run a thermostat program is convenient but not absolutely necessary. The main reason for using an external program to drive the iSense is to improve the finicky anti-pendle behavior of my boiler but I can do this without letting it run the thermostat program.

Thanks for your support.
cville
Starting Member
Starting Member
 
Posts: 5
Joined: January 2018


Return to Opentherm Gateway Forum

Who is online

Users browsing this forum: No registered users and 0 guests