Room setpoint/Return temperature glitch

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

Moderator: hvxl

Post Reply
dr.knor
Starting Member
Starting Member
Posts: 9
Joined: Tue Nov 21, 2017 11:34 am

Room setpoint/Return temperature glitch

Post by dr.knor »

I am happily using the OTGW together with a Honeywell Round Connected Modulation thermostat and Atag I series 36EC boiler for a number of years now, still using 4.2.5 FW (slightly modified to use the SB feature to change the control setpoint). I use Domoticz to monitor the setup.

It is all working fine, but since the beginning I noticed that a few times per day the Room setpoint as shown in Domoticz shows a glitch where instead of the Room Setpoint, the Return water temperature is reported (for one sample).

I never paid much attention to it, but recently while playing with OTmonitor for another reason, I happened to capture such an event in the log (I noticed it in the Statistics tab, very useful!). Apparently, what happens is that the OTGW requests the Return water temperature, and the boiler appears to respond with a Read-Ack Room setpoint. The exchanged value is the Return Water Temperature. From this last part I deduce that the boiler has correctly received the initial request.

So no big deal, as the actual Room Setpoint is not modified.

I am just wondering, would this glitch be due to the boiler messing up the return message (2 bits flipped?), or is the OTGW misinterpreting the (presumedly correct) message? I find it somewhat remarkable that it only (be it very rarely) seems to happen on the Read-Data Return water temperature request, which is made by OTGW (the thermostat itself does not request this). I don't see it happening on other configured requests (e.g. CH water pressure).

A longer log shows a few dozen Error04 (only faulty boiler messages) and a few Error03 per hour but the thermostat does not seem to be bothered by it, and just repeats its requests when this happens.

Code: Select all

09:14:03.546191	T10010A00	Write-Data	Control setpoint: 10.00
09:14:03.745354	BD0010A00	Write-Ack 	Control setpoint: 10.00
09:14:04.525794	T80000200	Read-Data 	Status: 00000010 00000000
09:14:04.769469	BC0000204	Read-Ack  	Status: 00000010 00000100
09:14:05.591393	T00110000	Read-Data 	Relative modulation level: 0.00
09:14:05.796422	BC0110000	Read-Ack  	Relative modulation level: 0.00
09:14:06.613831	T00090000	Read-Data 	Remote override room setpoint: 0.00
09:14:06.614861	R801C0000	Read-Data 	Return water temperature: 0.00
09:14:06.817805	BC01036E0	Read-Ack  	Room setpoint: 54.88
09:14:06.818900	AC0090000	Read-Ack  	Remote override room setpoint: 0.00
09:14:07.536894	T00050000	Read-Data 	Application-specific flags: 00000000 0
09:14:07.867884	BC0050000	Read-Ack  	Application-specific flags: 00000000 0
09:14:08.563962	T80190000	Read-Data 	Boiler water temperature: 0.00
09:14:08.867806	Error 04
09:14:08.869103	E401138E0
09:14:09.584520	T80190000	Read-Data 	Boiler water temperature: 0.00
09:14:09.648395	B401938E0	Read-Ack  	Boiler water temperature: 56.88
09:14:10.503820	T10010A00	Write-Data	Control setpoint: 10.00
09:14:10.636331	BD0010A00	Write-Ack 	Control setpoint: 10.00
09:14:11.527933	T80000200	Read-Data 	Status: 00000010 00000000
09:14:11.648617	BC0000204	Read-Ack  	Status: 00000010 00000100
09:14:12.452603	T00110000	Read-Data 	Relative modulation level: 0.00
09:14:12.757461	BC0110000	Read-Ack  	Relative modulation level: 0.00
09:14:13.476312	T00090000	Read-Data 	Remote override room setpoint: 0.00
09:14:13.477240	R00780000	Read-Data 	Burner operation hours: 0
09:14:13.783821	BC078093C	Read-Ack  	Burner operation hours: 2364
09:14:13.784737	AC0090000	Read-Ack  	Remote override room setpoint: 0.00
09:14:14.497323	T900E6400	Write-Data	Maximum relative modulation level: 100.00
09:14:14.702151	B500E6400	Write-Ack 	Maximum relative modulation level: 100.00
09:14:15.522384	T80190000	Read-Data 	Boiler water temperature: 0.00
09:14:15.726916	BC01938C0	Read-Ack  	Boiler water temperature: 56.75
Attachments
Statistics.jpg
Statistics.jpg (86.98 KiB) Viewed 1776 times
hvxl
Senior Member
Senior Member
Posts: 1965
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: Room setpoint/Return temperature glitch

Post by hvxl »

I agree that it is extremely unlikely that a two bit transmission glitch would regularly happen to the same two bits of a particular message. A firmware bug is a more reasonable explanation. Whether that bug is in the boiler or the OTGW, I'm not sure. I don't think it's in the OTGW, but I don't completely rule it out.

Maybe the OTGW should check that the MsgID in the response matches the request. (And report Error05 if it doesn't?) The weird thing is that the Opentherm specs don't actually mention this as a definite requirement. They only imply it. I know of at least one thermostat that has a special future that can only work by violating this implied rule.
Schelte
dr.knor
Starting Member
Starting Member
Posts: 9
Joined: Tue Nov 21, 2017 11:34 am

Re: Room setpoint/Return temperature glitch

Post by dr.knor »

Thanks for your comment. I see what you mean.

I had a brief look at the Opentherm Protocol (version 2.2). It says that all slave responses should contain the same data ID that was included in the master request.

And further down it states that "in case of errors" the incoming frame should be rejected. But indeed, it does not define what these "errors" are supposed to be. I guess you could think of a couple more than the ones which were "selected" in the OTGW.

But I understand that it does not make sense to overly constrain here, especially when it is not giving any issues. As you point out, a bug can also become a feature.
hvxl
Senior Member
Senior Member
Posts: 1965
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: Room setpoint/Return temperature glitch

Post by hvxl »

Can you point me to exactly where in the Opentherm protocol version 2.2 it says that "all slave responses should contain the same data ID that was included in the master request"? I cannot find it and neither can the search function of my PDF viewer.

I also started wondering if the OTGW should produce a response to the thermostat when it detects an error in the response from the boiler. That would then probably have to be a Data-Invalid message. On the other hand, the current behavior doesn't seem to cause any problems.
Schelte
dr.knor
Starting Member
Starting Member
Posts: 9
Joined: Tue Nov 21, 2017 11:34 am

Re: Room setpoint/Return temperature glitch

Post by dr.knor »

In the Conversation details section, on page 20-21. It does not literally say it should be the *same* data ID, but, as you mentioned, it implies this by stating that the slave should respond with the (a?) data ID. A very loose interpretation of this could be that it is allowed to send any data ID. But that would not make a lot of sense.
dr.knor
Starting Member
Starting Member
Posts: 9
Joined: Tue Nov 21, 2017 11:34 am

Re: Room setpoint/Return temperature glitch

Post by dr.knor »

Follow up: also notice the wording""(Note that DATA-VALUE may be modified by the slave in some circumstances.)". This also suggests that the DATA-ID should *not* be modified. Although this is only mentioned for the Write-Data and Writing invalid data sections. Not in the Read-Data section. Probably the text was not meant to be read with this level of scrutiny.
hvxl
Senior Member
Senior Member
Posts: 1965
Joined: Sat Jun 05, 2010 11:59 am
Contact:

Re: Room setpoint/Return temperature glitch

Post by hvxl »

Well that's not a good way to write a protocol specification. Everything should be defined without room for different interpretations. Because otherwise someone will come along at some point and do something weird that breaks interworking of equipment and you have no leg to stand on to make them fix it. And that is a very important purpose of a specification.
Schelte
Post Reply

Return to “Opentherm Gateway Forum”