OpenTherm Gateway binding

That’s brilliant, I’m running it now on my box.

Hi Arjen, getting these errors now:

==> /var/log/openhab/events.log <==

2021-02-23 02:44:52.410 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from OFFLINE: Disconnected to UNKNOWN: Connecting

2021-02-23 02:44:52.420 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from UNKNOWN: Connecting to ONLINE

2021-02-23 02:44:52.602 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from ONLINE to OFFLINE: Disconnected

==> /var/log/openhab/openhab.log <==

2021-02-23 02:44:57.603 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Starting OpenTherm Gateway connector

2021-02-23 02:44:57.605 [DEBUG] [eway.handler.OpenThermGatewayHandler] - OpenTherm Gateway connector started

2021-02-23 02:44:57.605 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Connecting OpenThermGatewaySocketConnector to

2021-02-23 02:44:57.622 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector connected

2021-02-23 02:44:57.626 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PR=A

2021-02-23 02:44:57.628 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PS=0

2021-02-23 02:44:57.701 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Received command confirmation: PR:  A=OpenTherm Gateway

2021-02-23 02:44:57.756 [WARN ] [rnal.OpenThermGatewaySocketConnector] - Connection to the OpenTherm Gateway lost (Connection reset)

2021-02-23 02:44:57.759 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Automatically reconnecting in 5 seconds

This will keep looping indefinitely.

EDIT: I found that this was caused by running otmonitor and the addon at the same time.

Great, that’s exactly what it is supposed to do! Thanks for testing :wink:
Did the binding reconnect as expected after you stopped OTmonitor?

It is working great now. 1.3.1 is recovering every time when there is a glitch in the wifi connection.

Arjen, first of all, great job on this binding. I have just integrated control and steering for my heat recovery unit (Brink/Renovent) into my OH installation. The integration is very basic through the SendCommand channel where I just send VS command to change the level/speed of ventilation.

I have (I assume) pretty unusual setup as I don’t have OpenTherm thermostat and don’t have any OpenTherm heating, just heat recovery and ventilation unit. Currently the binding is very focused on heating/hot water control and there is not much option for retrieving and controlling ventilation devices.

So I was wondering if there is a plan (or perhaps you could plan :)) for enhancing the current functionality with the heat recovery functions, so that i.e. inlet or exhaust air temperatures, filter check, etc where available in the biding?

For reference, I am putting here the list of the all V/H message IDs from OpenTherm protocol:
It’s a copy from German forum ([LAN-Anbindung für BSB-Bus (Brötje, Elco Thision etc.)])

; New ID for ventilation/heat-recovery applications

70,“STATUS V/H”,READ,FLAG,00000000,FLAG,00000000,Yes
72,“FAULT FLAGS/CODE V/H”,READ,FLAG,00000000,U8,0,255,0,Yes
73,“DIAGNOSTIC CODE V/H”,READ,U16,0,65000,0,Yes
74,“CONFIG/MEMBERID V/H”,READ,FLAG,00000000,U8,0,255,0,Yes
75,“OPENTHERM VERSION V/H”,READ,F8.8,0,127,“2,32”,Yes
76,“VERSION & TYPE V/H”,READ,U8,0,255,1,U8,0,255,0,Yes
79,“CO2 LEVEL”,READ,U16,0,10000,0,Yes
79,“CO2 LEVEL”,WRITE,U16,0,10000,0,No
80,“SUPPLY INLET TEMPERATURE”,READ,F8.8,0,127,“0,00”,Yes
85,“ACTUAL INLET FAN SPEED”,READ,U16,0,10000,0,Yes
88,“TSP NUMBER V/H”,READ,U8,0,255,0,U8,0,0,0,Yes
89,“TSP ENTRY V/H”,READ,U8,0,255,0,U8,0,255,0,Yes
89,“TSP ENTRY V/H”,WRITE,U8,0,255,0,U8,0,255,0,No
90,“FAULT BUFFER SIZE V/H”,READ,U8,0,255,0,U8,0,0,0,Yes
91,“FAULT BUFFER ENTRY V/H”,READ,U8,0,255,0,U8,0,255,0,Yes

If that would be possible it would be great and I can commit to help in testing.

Hi Tomek,

Since one month I have an OpenTherm gateway running with the Openhab binding. I use this to monitor my Intergas boiler with Honeywell thermostat. Last Summer I soldered together an eBus monitor and monitor my Brink Renovent with the OpenHab eBus binding:
eBus binding.

I have tied them together with rules: When bathroom light is on and Intergas boiler is delivering hot water -> set ventilation to maximum. Furtermore I get the temperature readings from the Brink via eBus and use them for several other rules (and push the outside temperature from the Brink to display on my thermostat).

Recently someone has added support for Wolf CWL (basically a German branded Brink Renovent). So going eBus could be another way to look at your Renovent.


hi Cor, thank you for suggestion, however I am afraid it would not work for me - you are right that Brink/Wolf and Wiessmann Vitovent are the same/similar devices - at least that’s my understanding, however I think this “compatibility” is across specific generation of the devices. So I have old Brink Renovent Large from year 2011 - and it has OpenTherm interface/socket. While newer devices i.e. Renovent Excellent(+) they have eBUS so I assume you must have rather newer device than mine and hance you can use eBUS.


Hi Tomek, a new day, and I learnt something new again. I was not aware of the history of Brink :wink: In my world there was only the Renovent Excellent that I researched the last six months.

Good call on asking to expand Opentherm binding with more functions / messages.

Hi @TomoKRK,

Good to hear you like the OpenTherm Gateway binding! I don’t mind adding new channels to the binding to support these message id’s. I do need some time to sort out the details though, since the OpenTherm Association doesn’t want to share their ‘open’ protocol specifications.

Also, I am considering splitting the channels in multiple devices or Things within the binding. That way instead of having just one Thing with dozens of channels, we can have multiple Things with a subset of channels like a Boiler or a Heat Recovery Unit, etc. Taking things a bit further, I could then treat the actual OTGW device as a Bridge, supporting multiple Things as devices on a single OpenTherm bus.

Anyway, enough Things to consider. I’ll see if I can work on adding the extra channels this weekend.

Hi Arjen, thank you so much for fast reply, I appreciate it. I agree that splitting this into separate logical modules makes a lot of sense. Yes, I already found out that OpenTherm association is not very open as the available information regarding the OpenTherm protocol are very scarce and limited and pretty much everything is based on the reverse engineering :slight_smile:
Having said that, I really appreciate your willingness to enhance this binding. I think the tricky part here will be how to handle TSPs (in my view and perhaps I am wrong here) but the thing which I noticed is that some of the TSPs for ventilation carrying i.e. volume/speed of ventilation are split into two separate TSP messages so reading and writing could be a bit tricky I guess.

Here is the example from the OTGW log of my setup:
// This parameter carries information about the speed of ventilation for REDUCED level - which is 120 m3/h
16:06:11.848921 BC0590078 Read-Ack TSP setting V/H (MsgID=89): 0 120 <<- lo byte
16:06:12.872990 B40590100 Read-Ack TSP setting V/H (MsgID=89): 1 0 <<- hi byte

// This parameter carries information about the speed of ventilation for NORMAL level - which is 180 m3/h
16:06:13.952750 B405902B4 Read-Ack TSP setting V/H (MsgID=89): 2 180 <<- lo byte
16:06:18.072314 BC0590300 Read-Ack TSP setting V/H (MsgID=89): 3 0 <<- hi byte

// This parameter carries information about the speed of ventilation for MAX level - which is 280 m3/h
16:06:20.156607 B40590418 Read-Ack TSP setting V/H (MsgID=89): 4 24 <<- lo byte
16:06:21.248965 B40590501 Read-Ack TSP setting V/H (MsgID=89): 5 1 <<- hi byte

Anyway perhaps it’s something you already know as you are much more familiar with OpenTherm than I am.

To finish, again I am more than happy to help you with any analysis, testing and debugging etc. perhaps even with coding if and as needed.

Best regards,

Hi Tomek,

I have created version 1.4.0 of the OpenTherm Gateway binding with the channels you requested. The version is available for download here. It’s a first step to add support for Ventilation / Heat Recovery units. You can easily find the new channels as they all start with vh_.

As I mentioned, it’s quite a puzzle without the proper documentation. I can find bits and pieces on the web, but they are often incomplete and (worse) inconsistent. For example message id 86 REMOTE PARAMETER SETTINGS V/H is documented as a status field with 2x8 flag bits (0/1) which would translate to switches (on/off), but when I search for the meaning of each individual bit, I get two one-byte values:

ID86:HB0: Remote ventilation / heat-recovery parameter transfer-enable: Nominal ventilation value
ID86:LB0: Remote ventilation / heat-recovery parameter read/write : Nominal ventilation value

So what is it? Status bits? Unsigned 8 bit integers? Without proper documentation and without an actual device to test things, I’m really just guessing here and will rely on you for testing :slight_smile: Consider discussing test results in private to prevent cluttering this topic.

Please note that for writing we are limited to the commands supported by the OpenThem Gateway device (or rather it’s firmware). The fact that a OT message id supports reading and writing, doesn’t automatically mean we can write to it using the OTGW.

Hi @Chiuaua79 and anyone else with a ventilation or heat recovery unit,

With many thanks to Tomek for testing and providing feedback, I have made some changes to the OpenTherm Gateway binding to add support for Ventilation / Heat Recovery units.

Bridge and Things
The binding now has a Bridge that is used to connect to the OpenTherm Gateway device and separate Things for boilers and ventilation units with their own set of channels and configuration parameters. In the future, additional Things may be added to support other OpenTherm devices such as solar panels and storage units.

Transparent Slave Parameter channels
The ventilationheatrecovery thing has a configuration parameter to set the number of TSP channels for your particular device. The channels are then created dynamically on initialization.

Priotity Messages
To have the ventilation unit report any data, READ-DATA requests need to be sent by the OpenTherm Gateway. Using a configuration parameter, intervals can be defined to send PM=xx comands to have the gateway request data from the ventilation unit.

Ventilation Setpoint
A writeable channel is added to the ventilationheatrecovery thing to allow setting the Ventilation Setpoint (VS=xx command).

The sources and documentation (not fully updated) are available here.
The test version can be downloaded here.

If you have any questions or feedback, let me know.

I’m new to openhab and opentherm, although I have a long history in programming and computers…
I’ve added an opentherm gateway to my openhab (3) running on a Pi 4. Changes originating from the Thermostat (Honeywell Chronoterm) are visible in openhab as expected. But when I change a setpoint through openhab, it takes a couple of minutes before the Thermostat shows the new setting. Is this expected behavior, or can I somehow speed this up?

Thank you all who contribute to this wonderful integration!

Hi Karel,

I have the same experience with a Remeha iSense thermostat. If I send a TemperatureTemporary (TT) command, it takes a while before the thermostat shows the new value. I wouldn’t say it takes minutes on my setup, but more like up to one minute or so. If you look at the logs, you will see that the binding sends the request immediately, and so does the OpenTherm Gateway. So I guess the delay is caused by the thermostat and there is not much that can be done to speed it up. At least, not from the openHAB binding’s perspective.

On the other hand, it never really bothered me. Central heating is a relatively slow process that doesn’t require realtime communication or actions. In comparison: it is not uncommon for things like thermal actuators to take 5 minutes or more to open or close.

Thanks Arjen for your swift reply!

Hello, interesting binding! I have just order the OTGW kit to try your binding with my old Brink Renovent HR Large . My understanding is that the binding works with OH3.x only (?) so I will need to find more time to migrate from OH2.5 (which is a stable one and I have quite a few bindings and rules files)

I have a question about bypass (the one built in). Is there any way to change bypass position via Opentherm? Manually I can adjust U3 and U4 temperature parameters based on which Brink decides to open/close bypass. Is it possible to change these parameters via Opentherm? Or another way?

Rafal, currently there is no possibility to change any of the configuration parameters through the OTGW. The binding supports only ventilation speed control/adjustment and read out of configuration and operational parameters.
Yes, the binding works only with OH 3.0 per my understanding, so you would need to upgrade your installation.
I have contacted creator of OTGW and asked him to consider enhancements to firmware, so perhaps in the future we will see more robust support for ventilation devices i.e. Brink, however I would not expect it any time soon.
For the time being the setup I have works pretty stable and I am pretty happy with it, but of course I would welcome more functionality available.

I’ve used this binding on 2.5 before.
You could just check in your 2.5 setup to see if the binding is available from the paper UI.

I’ve been migrated to 3.0.1 to use an other binding which was only available on OH3.
was quite a struggle, especially with time based rules.

The OpenTherm Gateway binding is available for openHAB 2.5 but thats an older version. Newer versions, such as the one with support for ventilation units, are indeed only available for openHAB 3.

Hi @Mephix,

After upgrading to the latest version, domestic hot water mode doesn’t work any more. I got this error in the logs:

2021-05-03 07:40:49.530 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.openthermgateway.handler.BoilerHandler@786bb86’: Unknown channel dhw_mode
java.lang.IllegalArgumentException: Unknown channel dhw_mode

Removing the items, reboot and then add them doesn’t solve it, when i go back to the binding from 3.0.2. it works again.