OpenTherm Gateway binding

binding
opentherm
gateway
Tags: #<Tag:0x00007fd3226f1470> #<Tag:0x00007fd3226f1330> #<Tag:0x00007fd3226f11c8>

(Arjen Korevaar) #1

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
http://otgw.tclcode.com/firmware.html#configuration

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.


(Angelos) #2

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?


(Arjen Korevaar) #3

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?


(Angelos) #4

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)


(Arjen Korevaar) #5

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.


(Joe) #6

@Mephix, @Dim

Hi,

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

https://pure-knowledge.nl/2017/02/21/openhab2-otgw-and-mqtt/

https://www.vleeuwen.net/2016/01/opentherm-gateway-for-the-win

https://www.finalist.nl/techblog/2016/12/openhab-a-java-smart-home/

and

https://github.com/githubcdr/opentherm2mqtt

Perhaps it helps a little bit.

Joe


(Arjen Korevaar) #7

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.


(Joe) #8

Hi @Mephix,

have you seen this Link?
http://www.palebluedot.nl/jml/index.php/projects/arduino/24-openthermmon

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

Joe


(Arjen Korevaar) #9

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 https://www.domoticaforum.eu/uploaded/Ard%20M/Opentherm%20Protocol%20v2-2.pdf.

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.

Regards
Arjen


(Daniel) #10

Cool, my link is up there too (https://pure-knowledge.nl/2017/02/21/openhab2-otgw-and-mqtt/) :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…