Hi, I would like to control my ventilation unit (Wolf CWL-400 which is actually by Brink) with the OTGW and OpenHab. In otmonitor (Opentherm Monitor, Windows Applicaton) I am able to adjust the ventilation rate by sending VS=xx under Options/Miscellaneous/Free format command. Is it possible to send commands like this with the OpenTherm Gateway binding?
Many thanks!
Drchandra (Michael Hax)
In OH Milestone 3 we introduced a new version of the binding, which has Things and Channels to support ventilation and heat recovery.
It also supports sending free form commands (although that is not new to the M3 version, and is on prior versions too).
Have a look at the official OH Addons documentation for the binding. Select the latest version via the tab button at the top left of the page.
Hi,
it took some time, but meanwhile the binding is installed and seems to work pretty well. What I still don‘t understand: how can I send a command like „VS=xx“? I can read all values easily, but I still don‘t know what to do, if I want to change the ventilation setpoint. Can you help me?
Thanks in advance
Michael
There is a channel called ‘sendcommand’ which accepts a text input. Just enter the command in it.
But for the specific case of the boiler setpoint, there is a channel called ‘controlsetpointoverride’ which you can manipulate direct via the UI.
Thanks!
I wrote a rule with the target „Ventilation Setpoint“ and the value „100“ - it worked!
But there ist still a problem: after changing the VS with OpenHAB the ventilation unit cannot be controlled manually by the thermostat anymore. I had to reboot OpenHAB to be able to control the device manually again. Is there a way to get the best of both worlds?
Michael
Hi Michael,
I am afraid that’s how the OpenTherm gateway firmware works. From the OTGW website:
Ventilation Setpoint - Configure a ventilation setpoint override value. Clear the setting by specifying a non-numeric value.
So it seems to me that as long as there is a numeric value set, that value is sent to the ventilation unit overriding the thermostat value. The only way to switch back to the value set by the thermostat, is to set VS with a non-numeric value (VS=AA or something). Perhaps that is something you can use together with rules to get the desired behaviour ?
Another option would be to submit your question to the Domotica Forum. I noticed you are already familiar with that site and had some luck with the creator of the OTGW device 
Hello, I had a conversation with Schelte Bron, developer of OTGW. He suggested to try it with otmonitor. Indeed, with otmonitor it works: you can send as many commands like VS=10, VS=20 …. as you want, and the ventilation rate changes to the desired values. After sending a command like this you cannot control the unit by the thermostat anymore - not before you have sent a command with a non-numeric value like VS=XX or VS=AA. After that the unit switches back to the ventilation rate that was set by the thermostat before, and you can control the unit with the thermostat again. But this works only with otmonitor! With the OTGW Binding it won‘t work. In my opinion there must be a bug in the OTGW binding.
Michael
Hi Michael, the SendCommand channel is a rather low-level way of sending raw commands to the OTGW. There is little to no interpretation or processing logic by the binding that would interfer with message sent to the OTGW and it should work the same as sending it through OT monitor or any other serial interface.
I don’t own an HVAC and can’t test the actual working of the Ventilation Setpoint (VS) setting, but when I send a VS=21 to the SendCommand channel of the OpenTherm Gateway bridge, I see a message in the logs from the OpenTherm Gateway VS: 21 meaning the command is received succesfully and Ventilation Setpoint is now set to 21.
If I then send VS=XX to the SendCommand channel, I see a VS: - response which would indicate that the VS setting is reset and the value from the thermostat should now be passed through to the HVAC.
Can you post your things, items and rules configuration ? Also some debug logging of the commands sent to and received from the OTGW would be helpfull to further analyze what’s going on.
I agree with Mephix. … Why don’t you do it the “normal” way and connect a normal OH thing/channel/item to the data point that you want to command?
I’ve spent quite a bit of time on opentherm for Brink ventilation and my conclusion is that both the OTGW hardware/solution has bugs and significant limitations but also the quality/availability of opentherm signals varies among Brink versions 
Therefore, I have developed my own solution that allows Brink control to the maximum extent.
Thanks! I‘ll try to do it „the normal way“, but this is something I have to learn before. I‘m a simple orthopaedic surgeon, but no technician. It may take some time for me to find out what is the „normal way“.
In respond to Mephix: I‘ll check the logs again to see if there is a difference between the OTmonitor way and the Binding way.
Michael
I think you are using a cooling/ventilation system. My own setup is for a heating boiler system, but my configuration below might give you some clues. Obviously you need to change the thing type boiler and possibly the channel ids controlsetpoint etc. But I am sure you can figure it out…
Things…
Bridge openthermgateway:openthermgateway:g24 "OpenTherm Gateway" @ "Kitchen" [ipaddress="192.168.1.234", port=20108, connectionRetryInterval=60] {
Thing boiler viessmann "Boiler" @ "Kitchen"
}
Items…
Number:Temperature Boiler_CH_Setpoint "Boiler CH Setpoint [%.1f %unit%]" <temperature> {channel="openthermgateway:boiler:g24:viessmann:controlsetpoint"}
Number:Temperature Boiler_CH_Setpoint_Override "Boiler CH Setpoint Override [%.1f %unit%]" <temperature> {channel="openthermgateway:boiler:g24:viessmann:controlsetpointoverride"}
Switch Boiler_CH_Enable "Boiler CH Enable [%s]" <switch> {channel="openthermgateway:boiler:g24:viessmann:ch_enable"}
Switch Boiler_CH_Enable_Override "Boiler CH Enable Override [%s]" <switch> {channel="openthermgateway:boiler:g24:viessmann:ch_enableoverride"}
Note: when the OTGW accepts external set point override commands, the override remains valid only for a few minutes, and then the OTGW reverts to an internal safe value. This is to prevent unsafe situations where (say) OH might send a very high or very low temperature, and then OH crashes. For this reason you need to send the set point override commands repeatedly via an OH rule (see example below)…
Rules
rule "41: Boiler OpenTherm Controls (run every 30 seconds)"
when
Time cron "10,40 * * ? * * *"
then
val setTemp = 50.0|"°C"
Boiler_CH_Setpoint_Override.sendCommand(setTemp)
Boiler_CH_Enable_Override.sendCommand(ON)
end
I’m trying your solution, but from the beginning there’s a problem: while trying to upload Brink_hr_bypass to the D1 mini I get error messages like
stray ‘#’ in program
and
expected unqualified id before ‘<’ token.
Can you tell me what I’m doing wrong?
Thanks
Michael
Hello, as this forum is for OpenTherm gateway binding, please put your question directly in the Brink Renovent HR - openHAB full integration topic.
Ps.
Please provide a bit more details. Have you managed to load any other program/code on Wemos D1?
Hello, I’m trying to set the clock of the thermostat. I’m using the sendcommand channel in the bridge and sending the string “SC=22:14/4”. Unfortunately nothing happens and in the openhab log this error is logged:
An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.openthermgateway.handler.OpenThermGatewayHandler@16ce045': Unsupported gateway code 'SC'
Is there something I can do to fix this?
Hi @jarnob,
I looked into this and it seems there is an error in the code.
I created issue 14423 on Github to fix this error.
FYI,
Yesterday I updated to openHAB 4.0.1. I noticed that the OpenTherm Gateway Binding throws errors every couple of seconds:
2023-07-30 13:35:03.533 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: UID segment '0x00:5' contains invalid characters. The last segment of the channel UID must match the pattern '[\w-]*|[\w-]*#[\w-]*'.
at org.openhab.core.thing.ChannelUID.validateSegment(ChannelUID.java:136) ~[?:?]
at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:76) ~[?:?]
at org.openhab.core.thing.UID.<init>(UID.java:66) ~[?:?]
at org.openhab.core.thing.ChannelUID.<init>(ChannelUID.java:59) ~[?:?]
at org.openhab.core.thing.internal.ThingImpl.getChannel(ThingImpl.java:126) ~[?:?]
at org.openhab.binding.openthermgateway.handler.BaseDeviceHandler.receiveMessage(BaseDeviceHandler.java:96) ~[?:?]
at org.openhab.binding.openthermgateway.handler.OpenThermGatewayHandler.receiveMessageTask(OpenThermGatewayHandler.java:157) ~[?:?]
at org.openhab.binding.openthermgateway.handler.OpenThermGatewayHandler.lambda$0(OpenThermGatewayHandler.java:142) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
Haven’t noticed it to cause any problems except for it clogging up the openhab.log file.
Hi @Fork,
I haven’t updated openHAB yet, so haven’t had this issue myself. But from looking at the code: based on incoming messages the binding tries to find a corresponding channel so that it can update the value.
In previous versions, if such a channel was not found by the getChannel function, it would simply return null and the binding would skip updating the value. Basically just ignoring it.
Apperantly there has been a change in the getChannel function where a warning (not an error btw) is shown when the name of the channel being searched for doesn’t match a certain pattern. Which I assume is used to check for valid channel names.
This could be solved either by removing bogus channel names such as ‘0x00:5’ from DataIteGroups (which originate from the OpenTherm specification documents), or by adding the same validation before calling getChannel to prevent calls being made with invalid channel names.
Either way, I’ll try to find some time soon to work on a fix, in the mean time you could consider changing the loglevels to prevent this warning from clogging up your logfiles.
Hi @Mephix,
Thank you for the quick response and the suggestion to adjust the log level.
I have now redirected the log messages from the class that generates the error (org.openhab.core.internal.common.WrappedScheduledExecutorService) to a seperate file. And afterwards set the level to ERROR to avoid unnecessary writes to the SSD.
Sounds like you already figured out the problem. Hope you find a good solution for the OT gateway add-on.
If you haven’t upgraded yet, the OH4 upgrade is not quite painless I’m sorry to say. It broke some things for me, of which the error logging by the OpenTherm Gateway binding was actually the least troubling. I have a handful of rules that use javascript and I use the Debounce marketplace add-on in combination with motionsensors for my lighting. Those all stopped working. The changes are all well documented in the release notes and here in the community forum. But it is good to reserve some time for reconfiguring your OH setup when you upgrade.
You’re welcome, please see issue 15346 for further details on fixing this issue. I may DM you to test a new version, as I am not yet ready to update my setup to 4.0.1
Edit: created PR #15355 to fix this issue. Thanks to @Fork for testing the pre-release version!
Edit: PR completed, will be released with 4.0.2