Opentherm Gateway 4.0 alpha/beta testers wanted

[nlrb]

(You know there's no DD command, right?).

Actually meant to issue a DA command indeed .

[nlrb]

Can you clarify the description of the SR command? Currently the description says the following:

New serial commands 'SR' and 'CR' to set and clear responses towards the thermostat.

From testing it looks like you cannot override responses. E.g. SR=100:0,0 has no effect (neither for SR=25:1,1 as the boilers supports msg ID 25). It only seems to work for Unk-DataId responses that the Gateway does not handle. Is that as intended? If so, it might be good to add that to the description.

[hvxl]

The original idea was to only look for user provided responses for messages the boiler doesn't support to avoid overhead on every message. But considering that the "overhead" is about 150 instruction cycles (i.e. 150us) I guess there's not much harm in applying it to every message. The only thing is that the subroutine accesses EEPROM. So after a serial command that stores settings in EEPROM it may have to wait up to 4ms to get access to the data it needs. But even that should not be a big deal.

By the way, after this change SR=100:0,0 will still not have any effect since MsgID 100 already gets treated special by the gateway.

[nlrb]

The idea of an override would be that it would override the result in all cases (so also special messages like msgID 100). Example use case: I have problems with my Vision Modulation accepting the program change priority flag. To try out different flags I need to be able to override msgID 100.

[rpauw]

Hi,

I'm new here so first a little something about my setup:
Last week i installed a Nefit Trendline boiler including the EMS-OT conversion module and hooked it up to a Honeywell Chronotherm touch modulation.
Few days ago I added your great OTG (fw 4.0a10) to the mix and now i'm all exited about it.

First thing to notice is that i also experience the TT / TC thing others talk about, so if you need me to test anything i'm glad to.

Second (and last for now )
Would it be possible to monitor the DHW flow rate? (or is it already and i just missed it...)

Cheers,

Ralph

[hvxl]

Would it be possible to monitor the DHW flow rate?

The thermostat probably doesn't request this information. You can make the gateway ask for it in a free timeslot using the AA=19 command.

[hvxl]

Firmware version 4.0a11 has been released. It contains the following features and bug fixes:

• Ignore spikes shorter than 250us while waiting for a start bit.
• Data specified by SR command used to be applied only if the boiler did not support the message. Now it is applied to all messages (that are not already treated specially by the gateway).
• Fixed spurious output when unsupported messages were automatically being removed from the list of alternatives.
• After clearing the remote setpoint, the manual change priority bit in MsgID 100 was not cleared.
• Issuing the (non-existing) DD command would set the maximum modulation level, rather than give a NG error.
• Fix bug in the timer that determines when the line is idle.
• Don't start A/D conversion while receiving an opentherm message.

As usual, the firmware can be downloaded from the alpha/beta firmware page.

[RedNax]

Did something change in the serial routine of the gateway from version OpenTherm Gateway 4.0a10? OpenTherm Gateway 4.0a9.1 works fine with my PI/remserial setup. From 4.0a10 onwards i get a tsunami of SE's inbetween the OT-messages. Been strugglng with it for an hour without success. Going back to 4.0a9.1 solved it immediately.

EDIT: I've found that running and stopping otmonitor-ahf on the PI before starting remserial solves it. Does otmonitor set some special serial parameters?

[nlrb]

Running firmware version 4.0a11 some time now and it is working well.

I do have another question regarding the behavior of the SR command. See below example. I would have expected the OTG to respond with 00000000 00000000 in this case, but it doesn't. Is that as designed? And why does the response use '/' instead of ',' as a separator?

Code: Select all

16:35:40.798243	Command: SR=70:0,0
16:35:40.826873	SR: 70:0/0
16:35:40.903737	T80000200	Read-Data 	Status: 00000010 00000000
16:35:41.058222	B40000200	Read-Ack  	Status: 00000010 00000000
16:35:41.439580	T80000200	Read-Data 	Status: 00000010 00000000
16:35:41.582820	B40000200	Read-Ack  	Status: 00000010 00000000
16:35:41.965696	T80000200	Read-Data 	Status: 00000010 00000000
16:35:42.114754	B40000200	Read-Ack  	Status: 00000010 00000000
16:35:42.499436	T80000200	Read-Data 	Status: 00000010 00000000
16:35:42.652979	B40000200	Read-Ack  	Status: 00000010 00000000
16:35:43.030671	T80000200	Read-Data 	Status: 00000010 00000000
16:35:43.177365	B40000200	Read-Ack  	Status: 00000010 00000000
16:35:43.565213	T80000200	Read-Data 	Status: 00000010 00000000
16:35:43.709210	B40000200	Read-Ack  	Status: 00000010 00000000
16:35:44.092613	T10010A00	Write-Data	Control setpoint: 10.00
16:35:44.247394	BD0010A00	Write-Ack 	Control setpoint: 10.00
16:35:45.019849	T10010A00	Write-Data	Control setpoint: 10.00
16:35:45.167083	BD0010A00	Write-Ack 	Control setpoint: 10.00
16:35:45.550742	T80190000	Read-Data 	Boiler water temperature: 0.00
16:35:45.706738	B401939FF	Read-Ack  	Boiler water temperature: 58.00
16:35:46.083947	T80460500	Read-Data 	Status V/H: 00000101 00000000
16:35:46.241237	B70460500	Unk-DataId	Status V/H: 00000101 00000000
16:35:46.247285	A40460500	Read-Ack  	Status V/H: 00000101 00000000

[hvxl]

In MsgID 70 the high byte is the Master status. The gateway is designed to only modify the low byte (Slave status). So for this MsgID you are expected to specify only one byte in the SR command, e.g.: SR=70:10 (although SR=70:0,10 will do the same thing).

[guru]

Hi all,

I just build and installed an opentherm gateway in my house. Configuration is:

Boiler: Intergas Kombi Compact HR 36/30
Thermostat: Honeywell Chronotherm vision modulation
FW version 4.0a11

The opentherm gateway passed all the diagonistic tests except the bit timing of the boiler. Therefore I'm using FW version 4.0a11.

I will not use/test the otgw extensively the coming period as I'm still setting up the connections from the otgw to my local server (via Arduino/Raspberry Pi). But if I see strange behaviour I'll report it. Please let me know if I need to test specific things for the boiler/thermostat configuration.

Cheers!

[guru]

Hi all,

After one night running the opentherm gateway I see the first glitch in my setup. The thermostat was reporting "no communication" and the heating was obviously off (cold house, need to keep friends with the spouse ). Not sure if it's hardware/software or the combination. Here are more details:

My setup is:
Boiler: Intergas Kombi Compact HR 36/30
Thermostat: Honeywell Chronotherm vision modulation
FW version 4.0a11
TTL to USB converter cable with Prolific chip.

Overnight I let the otgw work "stand alone" (no computer connected to the USB cable). When I woke up this morning the thermostat was reporting "no communication" and the heating was off. To see what was going on I connected a laptop to the USB cable with realterm. When I made the connection the heating started again and thermostat started operating normally again (I don't remember if it happened when I connected the USB cable or when I openend Realterm). Realterm showed that the otgw was outputting repeatedly the following 4 bytes: 0x4F 0x70 0xFF 0x04 (no ascii but raw bytes). After disconnecting/connecting the USB cable, Realterm was showing opentherm messages in the usual ascii format again. And everything seems to be operating normal again. I kept it running and it's running now fine again for an hour or so.

Not sure if this is hw/sw or related to the open serial connection. But I'll keep it running and see if I can reproduce. Suggestions are welcome.

Cheers!

[casio]

First of all I would like to say: great job on the OTGW project!

Currently I'm running the gateway overnight save the log mainly for reliability test and during the evening debug the web control interface. I'm using the latest beta firmware 4.0a11 in combination with a Celcia 20 thermostat with the Quinta 35C boiler.

The amount of errors reported is very limited and seem only to occur when you press on of the buttons. It does not always happen but it seems like if a OT message is transmitted and at the same time a button is pressen the timing is not perfect anymore... Furthermore, I've had two times that the thermostat reported "Fout 203" code.

Not sure but just before things go err there is an error 3 reported on which the gateway reduces the power to medium followed by a second error 3. Afterwards it seems that there is only 0's going over and forth and subsequently the thermostat seems to give up. Below you see the relevant part of the log file:

Code: Select all

20:30:17.227672 T00390000 Read-Data  Max CH water setpoint: 0.00
20:30:17.347713 BF0390000 Unk-DataId Max CH water setpoint: 0.00
20:30:17.355679 AC0395A00 Read-Ack   Max CH water setpoint: 90.00
20:30:18.158779 T00000000 Read-Data  Status: 00000000 00000000
20:30:18.268875 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:19.170246 T10011700 Write-Data Control setpoint: 23.00
20:30:19.280410 BD0011700 Write-Ack  Control setpoint: 23.00
20:30:20.161835 T00110000 Read-Data  Relative modulation level: 0.00
20:30:20.271657 BC0110000 Read-Ack   Relative modulation level: 0.00
20:30:21.233173 T80190000 Read-Data  Boiler water temperature: 0.00
20:30:21.343183 B40191800 Read-Ack   Boiler water temperature: 24.00
20:30:22.154515 T801B0147 Read-Data  Outside temperature: 1.28
20:30:22.264510 BE01B0100 Data-Inv   Outside temperature: 1.00
20:30:23.106036 Error 03
20:30:23.127661 Medium power
20:30:23.177585 Error 03
20:30:24.157413 T00000000 Read-Data  Status: 00000000 00000000
20:30:24.267451 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:25.168748 T00000000 Read-Data  Status: 00000000 00000000
20:30:25.278749 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:26.160240 T00000000 Read-Data  Status: 00000000 00000000
20:30:26.270195 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:27.161599 T00000000 Read-Data  Status: 00000000 00000000
20:30:27.271746 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:28.233228 T00000000 Read-Data  Status: 00000000 00000000
20:30:28.333212 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:29.164611 T00000000 Read-Data  Status: 00000000 00000000
20:30:29.274589 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:30.156010 T00000000 Read-Data  Status: 00000000 00000000
20:30:30.266019 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:31.157444 T00000000 Read-Data  Status: 00000000 00000000
20:30:31.277498 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:32.149025 T00000000 Read-Data  Status: 00000000 00000000
20:30:32.268829 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:33.160293 T00000000 Read-Data  Status: 00000000 00000000
20:30:33.270303 BC0000000 Read-Ack   Status: 00000000 00000000
20:30:34.221874 T800500CB Read-Data  Application-specific flags: 00000000 203
20:30:34.332708 BC00500FF Read-Ack   Application-specific flags: 00000000 255
20:30:35.253405 T800500CB Read-Data  Application-specific flags: 00000000 203
20:30:35.353219 BC00500FF Read-Ack   Application-specific flags: 00000000 255
20:30:36.244792 T800500CB Read-Data  Application-specific flags: 00000000 203
etc.

This can be resolved by a GW=R command. The data that the thermostat sends "T800500CB" is a fixed pattern so you could e.g. scan for this every so and so and send a reset command... However, not an ideal scenario

Finally, I noticed that with the Celcia 20 if you use TT=xx the thermostat programmed timer is not picking up. Is this related to the fact that the TT command is actually a TR command under the hood after the gateway detected that the thermostat is a Remeha Celcia?

Cheers,
Cas

[strake1]

Hello,

A little question, what's wrong about these settings:

Updated to 4.0a11 form 3.4
Script 02L

Config file changed to telnet=true ip and port.
And the first command goes wrong and all values stays on 0.

The application monitor works well. But in homeseer:


13-11-2013 23:35:59 info OTWG monitor, Parameters used: PS=1
13-11-2013 23:36:02 info OTWG monitor, Parameters used: PR=All
13-11-2013 23:36:02 debugOTGW not recognized command:
13-11-2013 23:36:02 debugOTGW not recognized command:
13-11-2013 23:36:03 debugOTGW not recognized command:
13-11-2013 23:36:03 debugOTGW not recognized command:
13-11-2013 23:36:03 debugOTGW not recognized command:
13-11-2013 23:36:03 debugOTGW not recognized command:

With debug 3 :
13-11-2013 23:41:05 debugOTGW Debug Level: 3
13-11-2013 23:41:05 debugOTGW2 SendMessage;Message: PS=1
13-11-2013 23:41:05 debugOTGW3 SendMessageTelnet;Message: PS=1
13-11-2013 23:41:05 debugOTGW2 OTCommand: PR OTValue: all
13-11-2013 23:41:05 debugOTGW2 Send Openthermcommand: PR=all
13-11-2013 23:41:05 debugOTGW2 SendMessage;Message: PR=T
13-11-2013 23:41:05 debugOTGW3 SendMessageTelnet;Message: PR=T
13-11-2013 23:41:05 debugOTGW1 Reply: P
13-11-2013 23:41:05 debugOTGW not recognized command:
13-11-2013 23:41:05 debugOTGW2 Reply on PRC command: :
13-11-2013 23:41:05 debugOTGW2 SendMessage;Message: PR=M
13-11-2013 23:41:05 debugOTGW3 SendMessageTelnet;Message: PR=M
13-11-2013 23:41:06 debugOTGW1 Reply: P
13-11-2013 23:41:06 debugOTGW not recognized command:
13-11-2013 23:41:06 debugOTGW2 Reply on PRC command: :
13-11-2013 23:41:06 debugOTGW2 SendMessage;Message: PR=V
13-11-2013 23:41:06 debugOTGW3 SendMessageTelnet;Message: PR=V
13-11-2013 23:41:06 debugOTGW1 Reply: P
13-11-2013 23:41:06 debugOTGW not recognized command:
13-11-2013 23:41:06 debugOTGW2 Reply on PRC command: :
13-11-2013 23:41:06 debugOTGW2 SendMessage;Message: PR=O
13-11-2013 23:41:06 debugOTGW3 SendMessageTelnet;Message: PR=O
13-11-2013 23:41:06 debugOTGW1 Reply: P
13-11-2013 23:41:06 debugOTGW not recognized command:
13-11-2013 23:41:06 debugOTGW2 Reply on PRC command: :
13-11-2013 23:41:06 debugOTGW2 SendMessage;Message: PR=W
13-11-2013 23:41:06 debugOTGW3 SendMessageTelnet;Message: PR=W
13-11-2013 23:41:06 debugOTGW1 Reply: P
13-11-2013 23:41:06 debugOTGW not recognized command:
13-11-2013 23:41:06 debugOTGW2 Reply on PRC command: :
13-11-2013 23:41:06 debugOTGW2 SendMessage;Message: PR=L
13-11-2013 23:41:06 debugOTGW3 SendMessageTelnet;Message: PR=L
13-11-2013 23:41:07 debugOTGW1 Reply: P
13-11-2013 23:41:07 debugOTGW not recognized command:
13-11-2013 23:41:07 debugOTGW2 Reply on PRC command: :
13-11-2013 23:41:07 debugOTGW2 SendMessage;Message: PS=0
13-11-2013 23:41:07 debugOTGW3 SendMessageTelnet;Message: PS=0

Good suggestions are welcome.

[hvxl]

This looks to me like a question about the homeseer script for the opentherm gateway rather than an issue with the alpha firmware. It would be more suitable in the Opentherm gateway and script integration into Homeseer topic.