OpenTherm Gateway binding

[Mephix (Arjen Korevaar)]

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

[drchandra (Peter-Michael Hax)]

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

[Mephix (Arjen Korevaar)]

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.

[AndrewFG (Andrew Fiddian-Green)]

@Mephix

the SendCommand channel is a rather low-level way of sending raw commands to the OTGW.

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?

[RafalO (Rafal)]

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.

Brink Renovent HR – openHAB full integration

The integration of Brink Renovent HR with openHAB leverages OpenTherm protocol to communicate with ventilation appliance and MQTT to communicate with openHAB. Below is my UI (first 4 items are from addtitional sensors): [RenoventHRLarge] You can find all details (including programs) of my project at: Key features: • It works as it is designed only for Brink Renovent HR integration! If you have a heating appliance based on OT as well you can use other solutions or you can extend/add heatin…

[drchandra (Peter-Michael Hax)]

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

[AndrewFG (Andrew Fiddian-Green)]

@drchandra

‘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“.

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

[drchandra (Peter-Michael Hax)]

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

[RafalO (Rafal)]

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?

[jarnob (Jarno Boks)]

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?

[Mephix (Arjen Korevaar)]

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.

[Fork (FB)]

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.

[Mephix (Arjen Korevaar)]

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.

[Fork (FB)]

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.

[Mephix (Arjen Korevaar)]

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