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 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.
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.
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:
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.
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.
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.
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.
The error seems to be caused by a translation from a channel to a OpenTherm Gateway command. For instance, if you want to write to the TemperatureTemporary channel, then it gets translated to the OpenTherm Gateway command TT=<value>
In this case, it seems something is trying to write to the dhw_mode channel, but there is no corresponding OpenTherm Gateway command, which is why it throws an error. This is also the reason the dhw_mode channel is defined as read-only: it is not supposed to be written to.
Can you please check if you have some script trying to update the dhw_mode channel? And if not, can you set the loglevel to DEBUG to provide me with more detailed information as to what is going on?
I am not sure what caused this issue. I tried to add some extra logging but found that the main branch, which is version 3.1.0, is nolonger compatible with openHAB 3.0.x. So, I had to rebase the binding onto the 3.0.x branch and made a few adjustments to make it work again.
Anyway, during this rebase-work I somehow seem to have fixed the issue with dhw_mode (and I believe with ch_mode as well).
17:02:54.427 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_BoilerWaterTemperature' changed from 48.5 to 48.91797
17:02:56.433 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_DomesticHotWaterMode' changed from OFF to ON
17:02:56.439 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_FlameMode' changed from OFF to ON
17:03:00.494 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_RelativeModulationLevel' changed from 0.0 to 50.0
17:03:01.491 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_BoilerWaterTemperature' changed from 48.91797 to 56.289062
17:03:05.493 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_RelativeModulationLevel' changed from 50.0 to 54.0
17:03:06.473 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_BoilerWaterTemperature' changed from 56.289062 to 54.777344
17:03:10.473 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_RelativeModulationLevel' changed from 54.0 to 67.0
17:03:11.470 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_BoilerWaterTemperature' changed from 54.777344 to 57.91797
...
17:03:13.475 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_DomesticHotWaterMode' changed from ON to OFF
17:03:13.480 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_FlameMode' changed from ON to OFF
17:03:17.446 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_RelativeModulationLevel' changed from 67.0 to 0.0
17:03:18.446 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenThermGateway_BoilerWaterTemperature' changed from 57.91797 to 54.757812
Hi All, I started to be troubled with OpenTherm binding disconnects lately again and as a result of it I started digging into this issue more. Looks like the binding goes off-line as soon as there is some network connectivity issue between OTGW and my OpenHab instance. That can happen on multiple occasions i.e. power outage, WIFI access point restart etc. That has been the case with me as I have been doing some maintenance work on my home network and I spotted this behaviour.
I have downloaded the code for binding and after some analysis it looks like there might be some problem in the logic and specifically handling the disconnects (explicitDisconnect flag in class OpenThermGatewayHandler). In the connect method there is a call to disconnect method and essentially the flag explicitDisconnect is set immediately to true, that in turn prevents from scheduling reconnectTask as the flag is always set to true, hence when I click save in OpenHab I guess connect is explicitly called and connection gets restored.
Is there any logic/reasoning behind explicitDisconnect flag? I am not clear exactly on the logic when this flag should be set to true/fals, however it looks like the call to disconnect in connect is not necessary or if it’s necessary to perform some cleanup, definitely the explicitDisconnect flag should not be set there to true when in the normal connect flow.
I have had another look at the auto reconnect logic and the explicitDisconnect var. On second thought, I suppose some sort of state flag is needed for the disconnected() callback handler to know whether the binding should attempt to automatically reconnect (normal circumstances) or not (handleRemoval or dispose).
The call to disconnect is necessary, because disconnect has the logic to disconnect (obviously) and also remove any existing connection threads or (something I have changed now) reconnect tasks. The disconnect is called by connect so that the connect logic can then assume that there are no existing connections or reconnect tasks. So it’s to make sure everything is reset before attempting to make a new connection.
Anyway, I did feel like renaming the explicitDisconnect variable to autoReconnect and more or less reverse the logic behind it: as long as autoReconnect is true, attempts will be made to automatically reconnect, otherwise it won’t. It somehow was more logical to me.
The position of setting this variable to true (or previously: setting explicitDisconnect to false) in the connect() method, as you pointed out, did indeed seem incorrect. It should be set after the call to disconnect, and not before. So that’s another thing I’ve changed.
Anyway from these changes I created a new snapshot version 2.0.2. Can you give this one a try and let me know your findings?
In my world there was only the Renovent Excellent that I researched the last six months.
Consider discussing test results in private to prevent cluttering this topic.