OTGW Manipulate the control setpoint works only once (Tado v3-Quatt v1.5)
(1) By Rombo (Rombow) on 2025-10-22 12:41:28 [link] [source]
Hi there. I have a TADO V3 thermostat and a Quatt v1.5 heat pump. I have OTGW version 6.6. I have a wired OT connection between thermostat and heatpump. I try to override the setPoint temperature using the "CS=24.134" command. This never worked until I discovered, after many hours of debugging, that it DOES work directly after the OTGW board has been reset (with the reset buton). Then the log (below) shows the success and for a short while the setpoint override takes effect in the boiler (Quatt). However next time the thermostat talks to the Quatt, the override does NOT work anymore. At first I figured this must be the built in overriding expiration mechanism. But that's not the case since even if I repeat "CS=24.134" every 20 seconds it fails to override a second time. Experimenting further I discovered directly after reset OTGW reports "CH=0" later when things have stopped working it reports "CH=1". So now I figured that must be the problem. I tried turning "CH=0" by manual command. But that never lets OTGW report CH=0 later. I know others are also desperate to get Tado to work since Tado is stopping support for their REST api. any help would be appreciated how to override CS. (log fragments below) #reset the OTGW board #PS=1 reports CH=0 .. 11:53:18.001548 Command (via websocket): CS=24.134 11:53:18.026666 CS: 24.13 .. 11:53:27.389878 T10012B00 Write-Data Control setpoint (MsgID=1): 43.00 11:53:27.392916 R10011822 Write-Data Control setpoint (MsgID=1): 24.13 11:53:27.755030 BD0011822 Write-Ack Control setpoint (MsgID=1): 24.13 11:53:27.758155 AD0012B00 Write-Ack Control setpoint (MsgID=1): 43.00 .. 11:53:55.583774 Command (via websocket): CS=24.134 11:53:55.609038 CS: 24.13 .. 11:54:11.938596 Command (via websocket): CS=24.134 11:54:11.963766 CS: 24.13 .. 11:54:36.384200 Command (via websocket): CS=24.134 11:54:36.409083 CS: 24.13 .. 11:54:44.947026 T90012A00 Write-Data Control setpoint (MsgID=1): 42.00 11:54:45.312232 B50012A00 Write-Ack Control setpoint (MsgID=1): 42.00 .. #PS=1 reports CH=1
(2) By otgw on 2025-10-22 21:05:54 in reply to 1 [link] [source]
The procedure you describe is supposed to work to continuously override the control setpoint. The part of your description that is unclear to me is how PS=1 reports CH=0. PS=1 only reports numbers (with some punctuation), nothing like CH=0 or CH=1
There are only two things I can imagine that stop the CS command from working:
- The gateway resets for some reason, which makes it forget the CS command. But if you repeat the CS command every 20 seconds, that may make it skip an override once or twice. But it should recover after that. Unless it keeps resetting frequently.
- The gateway somehow gets switched from gateway mode to monitor mode. But that setting is stored in EEPROM. So then a manual reset would not put it back into gateway mode.
To further investigate the issue, please execute the command DP=34. This will continuously report the variable that holds the units of the specified control setpoint in hex, or 80 if no override control setpoint is active. So, for your example of 24.134, it should report 034=18. Now one of a few things can happen:
- Things mysteriously start working correctly (Heisenbug).
- The OTGW stops reporting the value at address 0x034. The PIC must have reset. Use the PR=Q command to find out the reason for the reset.
- The report changes from 034=18 to 034=98, i.e. the high bit gets set. Examine the log around the time this happens for a possible reason. If you cannot find anything, enter command DP=5f. Now, after every repeated CS command, you should find that bit 1 of the reported value is set.
- The report continues to indicate 034=18, yet the override no longer happens. Check the mode with the PR=M command.
(3) By Rombo (Rombow) on 2025-10-23 07:55:37 in reply to 2 [link] [source]
Thank you for your time!
Thank you for your great reply!!
First, about the "PS=1" command reporting not numbers but beautifully decoded and fomatted text,
I obtain that by toggling "Include detail of bitfields" in the config-tab\logging of the webpage.
The output then looks like:
09:36:23.488855 PS: 1
09:36:23.649414 00000000/00000000,0.00,00000000/00000000,0.00,0.00,100.00,0/0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,12.44,13.39,0.....
- CH enable: disabled (0)
- DHW enable: disabled (0)
- Cooling enable: disabled (0)
..
..
- Free ventilation status: not active (0)
- Diagnostic indication: no diagnostics (0)
09:36:23.665174 Command: PS=0
09:36:23.680863 PS: 0
Next I used the command that you suggested to "debug a pointer" "DP=34" and that works great. Now I continuously see the value
of the CS override value. and more importantly ... when it gets lost!!! :
09:17:41.969480 034=18
09:17:42.331848 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00
09:17:42.334781 034=18
09:17:43.595947 <EOT>OpenTherm Gateway 6.6
09:17:43.599199 Command: SC=09:17/4
09:17:43.601199 Command: SR=21:10,23
09:17:43.603203 Command: SR=22:7,233
It seems (indeed like you suggested) a reset is happening since the <EOT> and the following welcome message "OpenTherm Gateway 6.6"
"PR=Q" then tells me reason is "L". Manual says : "Stuck in a loop (same message received 64x)"
aha!
So would I be correct that my thermostat (TADO v3) is driving the OTGW nuts by repeating certain commands many times ?
I do see many, many repeated commands (2x per second), that are also annoyong myself but not to the point of resetting myself ;-)
09:17:32.093251 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00
09:17:32.096310 034=18
09:17:32.264591 T10394600 Write-Data Max CH water setpoint (MsgID=57): 70.00
09:17:32.267421 034=18
09:17:32.632252 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00
09:17:32.635201 034=18
09:17:32.803666 T10394600 Write-Data Max CH water setpoint (MsgID=57): 70.00
09:17:32.806365 034=18
Is there any way to avoid that, perhaps blocking the MsgID=57 ?
I don't think that is a very important message from Thermostat to Boiler in my case.
Thanks in advance for any further advice!
(4) By Rombo (Rombow) on 2025-10-23 08:58:32 in reply to 3 [link] [source]
Turns out there is a way to turn "Flow Temperature Optimization" to value "None" in the TADO V3 app. That prevents my "Stuck in Loop" reset problem! I think the OTGW may have been correctly resetting itself because the more meaningful messages (setting room temp etc) from thermostat to boiler now appear every 12 seconds (not every 2 mins). There was something odd about the boiler requesting anyways: T10394600 Write-Data Max CH water setpoint (MsgID=57): 70.00 the boiler would always reply with value of 70.00 regardless of requested value. perhaps that drove the thermosat to keep re-requesting it ????? anyways I think this issue can be marked as resolved, unless you like to pursue this further. Thanks a lot!
(5) By otgw on 2025-10-23 10:17:56 in reply to 3 [link] [source]
This looks to me like there either is a bug in your boiler or in the OTGW. When the thermostat sends a Write-Data message, valid responses are Write-Ack, Data-Invalid, and Unknow-DataID. So not Read-Ack! That was probably the reason the Tado repeats its request over and over; it didn't get a valid response.
If the boiler really responds to a Max CH water setpoint Write-Data message with a Read-Ack, then that's a bug in the Quatt. On the other hand, I can't completely rule out that the OTGW somehow changed the Write-Data message into a Read-Data message. It is supposed to report any changes it makes to a message and reverse the change on the response. But I won't claim that it's impossible there's a bug in the OTGW firmware. Although it would be surprising if you're the first person to notice this issue.
You can verify which device is the culprit by putting the OTGW in monitor mode (GW=0). If the boiler then still responds with a Read-Ack to a Write-Data message, the bug is in the boiler. If you now see a Write-Ack or Data-Invalid response, the bug is in the OTGW and I need to fix it.
(6) By Rombo (Rombow) on 2025-10-23 11:00:12 in reply to 5 [source]
I put OTGW in monitor mode and set TADO "max-flow-temp" to 30.0 degrees celcius. The log file repeats (for about 2 minutes) this pattern: 12:39:29.414429 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:29.559532 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 12:39:29.952254 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:30.091053 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 12:39:30.494885 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:30.637527 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 12:39:31.032740 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:31.176526 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 12:39:31.577940 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:31.715553 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 12:39:32.120706 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:32.262049 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 12:39:32.658284 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:32.800901 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 12:39:33.196020 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:33.339902 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 12:39:33.733965 B40394600 Read-Ack Max CH water setpoint (MsgID=57): 70.00 12:39:33.871388 T90391E00 Write-Data Max CH water setpoint (MsgID=57): 30.00 So I guess its a bug in the Quatt. Oh well. I will turn off the Tado optimization by setting "Flow Temperature Optimization":"Maximum flow temperature" = "None" After that I can even override the Room Setpoint Temperature with "BS=22"! OTGW works! This gives me plenty of opportunity that start deceiving the Quatt, which was my plan to begin with. A bit of background.... My Quatt, and I think many others have the same problem, has a nervous and impatient demeanor and typically overreacts to the thermostat's delta-T (RoomSetPointTemperature - RoomTemperature). Many have tried to work around this. I had a reasonable hack using the TADO REST Api (controlling the TADO-RoomSetPoint). Alas, that solution will be discontinued, at least TADO now wants 6 euro/pm for up to 20000 REST calls. :-( And that's not always enough. Thanks again, OTGW rocks!
(7) By otgw on 2025-10-23 15:17:26 in reply to 6 [link] [source]
Thanks for testing. This is good news for me because I don't have to fix the OTGW. It's less good for you because it will be much harder to get the Quatt fixed. At least you have a work around. And if you do run into the problem again, you can tell OTGW that the boiler doesn't support ID57 (UI=57).
The Opentherm specification document indicates that a boiler is supposed to be controlled via the Control Setpoint (ID1) and Maximum relative modulation level setting (ID14). If the Quatt acts on Room Setpoint (ID16) and Room temperature (ID24), that's another misbehavior.
Good luck with your efforts to deal with the vicious change of policy by Tado.