Home Automation Domotica Forum Europe, Bwired Forum

Hi All,

I have a Honeywell Vision Modulation thermostat with (opentherm)support for ventilation systems.
After enabling ventilation support in the installation-menu it's requesting data-id's 70 (Status V/H) and 71 (Control setpoint V/H).
My boiler answers with 'unknown'. After that ventilation options are no longer available on the thermostaat (until next boot).

I would like to show the status of my ventilation system on the thermostat.
Is it posible to 'fake' the anwers on these data-id's and answer directly from the gateway?

Hello Irritanterik,

I've got the same thermostat and the same wish. I've got a copy of the sourcecode and am editing it, but is a slow process because I 'm no assembly programmer and I've got others things to do.
Our thermostat (and the Honeywell Touch Modulation) supports more ID's, it also supports cooling Data-ID's.

PS. I uploaded my logfile http://www.tclcode.com/opentherm/matrix.cgi#thermostats
Greetings,

Templar

Obviously the gateway will have to know the ventilation system's information to be able to fake the messages. How do you envision that? Are you planning to provide this information to the gateway via one or more serial commands?

Adding support for these messages should not be too hard now that I have restructured the code for the upcoming version 4.0 of the firmware.

I wonder how many people would want this feature, though. Due to the limited resources available in the PIC, I have to be careful about using up resources for things that will only benefit a few users.

Maybe a generic solution is possible for faking messages.
Possible by reserve a few (up to 5) 'slots' and support code's like
- FM=1/70/50 (use slot 1 for fake message 70 with value 50)
- FM=1 (clear slot 1)

Unfortunately i'm no assambly programmer, I can not judge whether this is a viable solution, given the limited resources...

@Templar: if you succeed in your process i'll be happy to take advantage of your hard work

Your idea sounds quite nice, but there is more to it than just filling in the data bytes. The gateway needs some additional knowledge about the messages. For example: In DataID 70, the thermostat will already provide the data in the most significant byte. The gateway is only supposed to fill in the least significant byte and should not modify the high byte. The data in DataID 71 is completely provided by the thermostat and the gateway would only have to acknowledge it. But for DataID 72 (should you want to use that one too) the gateway has to come up with both data bytes. As you will understand, this complicates things.

Schelte, thanks for your explanation. I understand this is no "kattenpis" and for me this is just a nice-to-have. How many properties per DataID are there? If there are too many parameters to make it configurable, I hope Templar will find a way with his custom made version.

I implemented a slightly modified version of your suggestion in firmware version 4.0a3 (see http://www.tclcode.com/opentherm/development.html).

First of all, 5 slots doesn't fit well in a binary world, so I made it 8 slots. I also decided it wasn't necessary for the user to specify which slot to use. If a DataID is already present, specifying a new value for that DataID will replace the existing value. If the DataID is not yet present, it will be stored in an empty slot, if available. And finally, I used the commands 'SR' (set response) to set the values to return in a response to the thermostat, and 'CR' (clear response) to clear the slot used for the specified DataID.

The first message in this topic seems to suggest that the thermostat will stop requesting the DataID's if it gets an Unknown-DataID response. For this reason I store the slot assignments in non-volatile memory. So after a power failure, the gateway will still know which DataID's it should fake. However, the data values do not survive a power outage. So until new values have been provided via serial commands, the gateway will respond with Data-Invalid. Hopefully that will make the thermostat continue to request the information.

Some examples:

You want the gateway to respond to the thermostat that the ventilation mode of the ventilation/heat-recovery system is active, the bypass is open and set to automatic. This can be achieved with the command: "SR=70:14".

You want the gateway to acknowledge DataID 71, which doesn't require any data values to be filled in by the slave. Just specify a data value of 0: "SR=71:0"

You have some external way to measure the pressure in the central heating system and want to provide that information to the thermostat. To return a pressure of 1.9 bar, you would use the command: "SR=18:1,230"

Now that this possibility exists, I wonder if it would be possible to measure the central heating water pressure with a sensor like http://www.conrad.nl/ce/nl/product/502103/

Schelte, this looks great!
In the weekend I'll test it with my thermostat.

This looks great indeed

I am testing gateway-4.0a3.hex right now.

I've send the commands SR=3:7, SR=79:600 and SR=71:0.
According to Opentherm Monitor the OTG accepts the commands. But when the Thermostat requests the DATA-ID the Boiler responds and the OTG does not replace the data value.

But the OTG does respond with command SR=70:14.

Normally DataID 3 is only requested by the thermostat once after power-up. So you may not see it after that. The SR=79:600 command should not have been accepted because 600 doesn't fit in a byte. You should have received an OR (out of range) response. If you want to set the CO2 level to 600ppm, use SR=79:2,88. If the 70 works, I would also expect the 71 to work.

With the current implementation, if the boiler provides an answer, it does not get replaced. This feature is intended to provide fake responses. I decided that a fake response is not necessary if a real response is available. If the general consensus is that it should be possible to override the answers from the boiler, then I can make that modification.

If this doesn't explain what you are seeing, please provide logs.

hvxl wrote: With the current implementation, if the boiler provides an answer, it does not get replaced. This feature is intended to provide fake responses. I decided that a fake response is not necessary if a real response is available. If the general consensus is that it should be possible to override the answers from the boiler, then I can make that modification.

- I tested Data-ID 3 to see if the thermostat responded well. I have to go through a trail-and-error phase to test the ventilation flags (Data-ID 70 & 74). And I wanted to properly document the Data-ID's of my Honeywell Vision Modulation and upload it into the Equipment matrix.

hvxl wrote:The SR=79:600 command should not have been accepted because 600 doesn't fit in a byte. You should have received an OR (out of range) response. If you want to set the CO2 level to 600ppm, use SR=79:2,88.

- Correct, I misread the Log.

hvxl wrote:If the 70 works, I would also expect the 71 to work.

- I am running gateway-4.0a5.hex but the OTG doesn't replace the 70 Data-ID. I tried SR=70:5, because that's what the thermostat sends in a Read-Data request. The boiler answers with a Unknown-Data-id message.

hvxl wrote:If this doesn't explain what you are seeing, please provide logs.

- Provided by mail.

Thanks for the log. That allowed me to identify the problem. It only happens when there are no alternative DataID's to send to the boiler. I will fix it the next version.

For the moment you can work around the problem by specifying a least one alternative that your boiler supports, for example: AA=25

hvxl wrote:For the moment you can work around the problem by specifying a least one alternative that your boiler supports, for example: AA=25

Yes, that worked. I've managed to reverse-engineer some of the flag bits of Data-ID 70 and 74.