OpenTherm Gateway binding

An official version of this binding is now included in openHAB.
Feel free to use this topic for support and discussion on further development.

Test versions

Original post:

Hi all,

I’ve recently moved from Domoticz to openHAB and would like to control my heating using the OpenTherm Gateway like I did in the past with Domoticz. However, it seems like there is no Binding for openHAB to control the OTGW.

There are some alternatives, like using OTmonitor and an MQTT broker, or using a serial to ethernet converter and openHAB’s TCP binding, but they require additional programs or even hardware and a lot of configuration.

So, I’m planning to write an OpenTherm Gateway binding for openHAB, that allows direct integration of the OTGW in openHAB and expose it’s values as Items. Communication to the OTGW will be through a serial to ethernet converter first, since that’s what I am using. But through an OpenTherm connector interface, other connectors such as one for USB or COMx would be easily added.

The full command set can be found here

The first version of the binding should at least provide periodic information from PS=1 (summary with all values) and allow the user to set temporary, constant and outside temperatures.

I have set up my dev environment and although it’s been a while since I last developed using Java (last years have mostly been .NET) the skeleton project and other bindings such as Toon are really helpful.

I am currently trying to find some openHAB examples of opening sockets to TCP or Com ports etc.

Anyway, would like to hear your opinion on developing an OTGW binding for openHAB ! Any ideas, tips etc would be very much appreciated.


I am not a developer, but I will be one of the first testers/users (and biggest supporters) when you publish the beta :slight_smile:

I have a use case: OpenTherm Solution?

Hi Angelos,

Thanks for the offer to help testing! I will certainly need people with OTGW in different setups such as COM or USB, maybe different OS-es running openHAB, etc.

From what I understand from your topic, you won’t be able to use OT at all because of the TopTronic controller?

Correct. I hit a wall with my current setup… but… I am planning to invest in the latest generation of TopTronic controllers (replace the existing with a newer one) that will allow multiple OT devices, so this will let me to play with my setup :slight_smile:

Replacement SKU: 6037312 - TopTronic E ZE1 (sold by Hoval, but really a Honeywell product)

Ok, a little status update on this…

I’ve read through the OpenTherm specifications and wrote a Java program that connects to the serial to ethernet converter and reads and parses messages sent by the thermostat, boiler and gateway. So I guess all the ingredients are there to create an openHAB binding.

I tried to fork the openhab repo, but only found the openhab2-addons repo. However, when I create a fork and clone it, I can open the projects in Eclipse but get compile errors on missing openHAB classes (such as BaseThingHandler, ThingTypeUID etc).

Earlier, I followed the IDE setup guide, which gives me a working environment with everything in it and no compile errors, but then it’s not based on my own fork :S so I’m not completely sure how to set things up.

Update: never mind, found out that after importing Existing projects into Workspace, I had to also import Oomph projects into Workspace and then add the openHAB Development and openHAB2 Add-ons. Still getting to know this environment…

Another thing would be threads. I need a TCP socket listener (or in a future version Serial port comm) and in my tryout app I run this on a background thread. I read that starting own threads need to be avoided and instead schedulers need to be used. I don’t see how to run a continously running process such as a TCP socket on a scheduled task though. I did see quite a few other bindings use threads, but if there is a better way of running this socket, I would gladly use that.

1 Like

@Mephix, @Dim


I’ve found three reports of successful open therm solutions:


Perhaps it helps a little bit.


1 Like

Hi Joe,

Thanks for response. The solutions you refer to are all based on using an MQTT broker which is something I try to avoid by creating a native openHAB binding for the OpenTherm Gateway.

Regarding that binding… I’ve made some very good progress up untill a couple of weeks ago, but I’m having difficulties finding the time to finish it up. I will definitely continue to work on it though.

Hi @Mephix,

have you seen this Link?

Based on an Arduino this guys try to encode the opentherm-protocol.


Hi Joe,

I’m using the OpenTherm Gateway to handle all the sending and recieving of signals on the line. So I don’t really need to worry about voltages, length of pulses etc.

Communicating with the gateway is all about reading and writing bytes to the serial interface. A specification of what each byte (or bit) does, is available at

Since the OpenTherm Gateway adds information to the frames, a binding that is written to work with this gateway will probably not work with other solutions such as using an arduino. At least, not without some modifications to deal with the differences in frames.

That said, if I can isolate the added frames into the implementaion of the connector interface and have it return just the OpenTherm information, it wouldn’t be too difficult to write different connectors for other solutions, making the binding eventually a more generic “OpenTherm” binding instead of a specific “OpenTherm Gateway” binding. I will keep this in mind when designing the interface.


Cool, my link is up there too ( :stuck_out_tongue:

The reason I went the MQTT route is that I wanted to decouple my logic and transport as much as possible. I’m currently in the process of migrating the transport of all my components to MQTT and have my applications consume the data from there.

The fact that there has been an attempt in the past to write a binding for OTGW but it kinda died in the process didn’t really help…

any progress on the binding?

I haven’t felt much need to work on the binding during the summer months, but now that temperatures are slowly dropping I started working on it again…

The connection to the opentherm gateway is working now, the logs shows all the messages received from the gateway. The next step is to define all the channels in the binding and have them updated with the correct values from the gateway. I kinda struggle to have the channels defined correctly. This should be pretty straight forward, but for some reason the channels don’t show up in OH. Anyway, hope to have that fixed soon.

So… got that fixed as well. Turns out you really need to remove the binding and add it again to update the channels in OH. It’s now a matter of adding all the channels needed and the option to set values such as the room temperature setpoint.

You’re welcome to have a look at and provide me with some feedback :wink:

So, I’ve got a first version running and I’ve included a screenshot in the readme at (scroll down to Channels)

I also have a snapshot package available for testing. If you’re interested please send me a message. Would really like to have some feedback to further develop the binding.


Do you have a compiled Jar of your binding?

I’ve looked and can’t seem to find one.

Many thanks.


I’m not sure how this is normally done, but I have published the jar file in a separate repository.

Please have a look at

As stated before, this binding currently only supports connecting to the OTGW through a TCP socket connection, since that’s what I am using. If you use a different way of connecting to the OTGW, please let me know so that I can add support for that as well.

1 Like

Hi Arjen,

Are you using this OTGW: with the Ethernet Module?


1 Like

Hi Micha,

Yes, I am using the OpenTherm Gateway designed by Schelte Bron. The link you posted seems to be the SMD version of the print, with the option to add an ethernet module directly onto the pcb. Mine is the normal (non-SMD) version and I use it with a Moxa NPort serial to ethernet converter.

The two versions of the OTGW use the same type of components and PIC controller, so I would expect them to work in exactly the same way.

Also, the ethernet module simply converts between TCP/IP and RS232 and so it should not matter which converter is used.

Of course the only way to really tell is to test it. So if you have this SMD version running, I am very interested in your findings when trying to control it through the OpenTherm Gateway Binding!


Hello Arjen,

Thanks for your great work !
The binding works perfect, I can monitor all the items in OpenHAB.

I use the original OTGW with a serial to ethernet converter for more than a year without any problem.

Unfortunately the (temporary) setpoint override function doesn’t work jet in my configuration.
Any suggestion how to manage this feature in OpenHAB ?

It would be also nice to override the domestic hot water (DHW) setpoint
I have a solar boiler and heating up the boiler with the gas burner is always disabled, except when the DHW temperature drops and there is no sun …
Is it possible to add the DHW setpoint and the override function for the DHW in the binding ?
This nice function is available in the original otmonitor software.

Kind regards and thanks in advance !

Hi Peter,

Thank you for your reply. This kind of feedback is exactly what I need to further develop the binding! Changing the override room setpoint using the same channel as the current room setpoint turned out to be difficult, because it takes a while before the TT (or TC) command overrides the actual setpoint. By then, the original value is re-read from the gateway and updated (so basically ‘resetted’) in the binding. Therefor, in the new version of the binding the override setpoint is available as a separate channel. Once you update that, it takes a couple of seconds (to max a minute or so) before the actual setpoint is updated by the gateway and reported back to the binding.

Regarding the DHW setpoint, I have added two channels, one for reading the current DHW setpoint and one to override it (for the same reason as above). I have tested it up to the point where I can see the commands being sent and received by the gateway, but my boiler doesn’t seem to actually support it so please give it a try and let me know if it works correctly. Also, I found that if you set the DHW override setpoint to values lower than 40 or higher than 60, I get a BV (bad value) response. Not sure if this is standard or just my setup. I haven’t yet found this min/max in OpenTherm specifications or OTGW documentation. If you can let me know the min/max your setup supports (easily verified by looking at the actual DHW setpoint being updated or not) I can perhaps add a min/max value restriction on this channel to prevent out of bounds values to be entered.

The new version of the binding is available at:


Hmm re-reading your post (and looking at the screenshot) I guess the version of the binding you use already has the split room temperature setpoint channels. One for reading, one for overriding. I did however change a few things in the way the commands are sent to the gateway, so please try the latest version.

If it still doesnt work, can you enable debug logging for “org.openhab.binding.openthermgateway” and set the override setpoint again? In the log, you should see something like:

Sending message: TT=21
Received message: TT: 21.00