hi @Mephix,
This is seriously fast and spot on! Everything works! Many thanks!!!
Well, apart from message id 113 for unsuccessful burner starts, all the code needed to exposes these channels was already there. I just needed to add the channels and link them to the correct OT messages, so that only took a couple of minutes really. Updating documentation, creating a branch, issue and pull request takes longer 
Anyway, I have created PR #10203 to merge the changes back into openhab addons repository.
@Nauttor, @Exeleration-G, @robr57, @Rakoon and others that have experienced automatic reconnection issues…
I have finally completed migration to openHAB 3.0 and spend some time on analyzing the reported connection issues. I changed the logic and did some code cleanup and I it seems to be working quite well now. I can disconnect the OTGW and the binding just keeps trying to reconnect every 60 seconds and once I reconnect the OTGW the connection from the binding is automatically restored on the next connection retry interval. I can repeat this process over and over again, without the binding getting put into a disabled state or stopping the automatic reconnection cycle.
I’ve uploaded version 1.3.1 and would like you to test it as well and let me know what you think.
Arjen, thanks, immediatly installed on OH 3.0.1 .
Is it correct that the filename is still org.openhab.binding.openthermgateway-3.1.0-SNAPSHOT.jar ?
I already did have that file in addons, so replaced it.
The Thing property shows that it is now 1.3.1 . So assume it is running with the new version.
That is correct. When building, the version of the binding (this goes for all bindings afaik) is set to the version of openHAB itself, which in this case is 3.1.0 since thats the current version on the main branch of the openHAB bindings Git repository.
I’ve added the thing property to create some sort of version number for the binding itself, so that I can at least tell different versions apart even if they are built for the same openHAB version. So yes, that’s why you see the same version number in the filename (3.1.0) but you’ll see me referring to the bindings own version number which I’ve added as a Thing property (1.3.1).
I am not sure how developers of other bindings do this, but I haven’t found any other way yet.
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 192.168.1.215:2323
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 4.2.8.2
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 
Did the binding reconnect as expected after you stopped OTmonitor?
@Arjen,
It is working great now. 1.3.1 is recovering every time when there is a glitch in the wifi connection.
Thanks.
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
71,“CONTROL SETPOINT V/H”,WRITE,U8,0,100,0,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
77,“RELATIVE VENTILATION”,READ,U8,0,255,0,Yes
78,“RELATIVE HUMIDITY”,READ,U8,0,255,0,Yes
78,“RELATIVE HUMIDITY”,WRITE,U8,0,255,0,No
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
81,“SUPPLY OUTLET TEMPERATURE”,READ,F8.8,0,127,“0,00”,Yes
82,“EXHAUST INLET TEMPERATURE”,READ,F8.8,0,127,“0,00”,Yes
83,“EXHAUST OUTLET TEMPERATURE”,READ,F8.8,0,127,“0,00”,Yes
84,“ACTUAL EXHAUST FAN SPEED”,READ,U16,0,10000,0,Yes
85,“ACTUAL INLET FAN SPEED”,READ,U16,0,10000,0,Yes
86,“REMOTE PARAMETER SETTINGS V/H”,READ,FLAG,00000000,FLAG,0000000,Yes
87,“NOMINAL VENTIALTION VALUE”,READ,U8,0,255,0,Yes
87,“NOMINAL VENTIALTION VALUE”,WRITE,U8,0,255,0,No
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.
Thanks,
Tomek
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.
Krgds,
Cor
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.
Regards
Tomek.
Hi Tomek, a new day, and I learnt something new again. I was not aware of the history of Brink 
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
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,
Tomek.
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 
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.
Hi,
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!
Regards,
Karel.
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!