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?
Arjen, thank you for this update and all makes sense to me - it looks like the new logic works like a charm I tested it with several scenarios and the connection to OTGW has been restored from OH3 within that default 15s reconnect period.
I had however to revert the addon to the version I use snapshot 3.1 as there are differences between the available channels and names of them so my sitemap stopped working.
I’m on OH version 3.02. Today my OTGW thing went OFFLINE. However, the channels still get updated from the OTGW with correct values. So it appears as if the thing still is Online. Manually checking the ESPeasy page of the ESP also shows the hardware and wifi is still functioning as intended.
Furthermore I am trying to push the outside temperature to the bridge, but since OH 3.02 it is no longer showing on my Honeywell chronotherm touch. I am measuring the temperature from my ventilation unit and the OTGW outside temperature channel is set to follow that item. But it no longer shows on the thermostat. Should the thing be configured a certain way to push the temperature correctly to the OTGW? Should it be dimensionless (e.g. “19.8”) or does it require units to write it to the OTGW, e.g. “19.8*C” (cannot find the degree symbol on my ipad)?
Hi @Chiuaua79, the outside temperature should accept values with decimals. I copy the outside temperature from openweathermap to OTGW without dimensions but it should accept a value with dimensions as well. However, if the Thing appears offline (or rather when it considers the background connection thread to be in disconnected state), it will probably not attempt to write to the OTGW. You should be able to see that in the logs, if set to DEBUG. This is something that I will look into though, if any data is received by the background thread, it’s pretty obvious that the connection with the OTGW is established. So regardless of what events happened before that lead to a Offline state, it should then switch back to Online.
Hi Arjan,
Disabling/enabling the Thing resulted in a true Offline, no more data received. Had to reset (power down/power up) the gateway and disable/enable of the thing once more to get communication working again. Except for the putside temperature display, but I used that more as a gimmick to easily see if the gateway was offline or not and needed the reset (the DHW_active is used in setting the bathroom ventilation, so is one of the most important signals in my automation).
Have to play around more to get the outside temperature to work, but playing around usually means unplanned rebooting and so on to get the system stable again
Today my opentherm thing was alternating between OFFLINE, INITIALIZING and ONLINE very fast. Supposing the outside temperature not reading might be a contributing factor or even main reason that the gateway is behaving badly, I had another look at it. I noticed that the temperature item from the ventilation unit is formatted as “23.8*C”, where other temperatures are formatted wih a space between number and UoM (23.8 *C).
So I changed the outside temperature source to openweathermap, gave the gateway a power down/up, reestablished connection from the binding and outside temperature is displaying on my thermostat . Next thing is trying to find out why the ventilation unit temperature is being formatted as such, which does not need discussion in the opentherm topic.
just moved to OH 3.1 and the OTGW version from the OH release (1.3.0).
After couple of hours , the old problem of disconnecting has come back
In de OH log :
2021-07-03 12:30:06.953 [WARN ] [rnal.OpenThermGatewaySocketConnector] - Unable to connect to the OpenTherm Gateway.
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method) ~[?:?]
at java.net.SocketInputStream.socketRead(SocketInputStream.java:115) ~[?:?]
at java.net.SocketInputStream.read(SocketInputStream.java:168) ~[?:?]
at java.net.SocketInputStream.read(SocketInputStream.java:140) ~[?:?]
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) ~[?:?]
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) ~[?:?]
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) ~[?:?]
at java.io.InputStreamReader.read(InputStreamReader.java:181) ~[?:?]
at java.io.BufferedReader.fill(BufferedReader.java:161) ~[?:?]
at java.io.BufferedReader.readLine(BufferedReader.java:326) ~[?:?]
at java.io.BufferedReader.readLine(BufferedReader.java:392) ~[?:?]
at org.openhab.binding.openthermgateway.internal.OpenThermGatewaySocketConnector.run(OpenThermGatewaySocketConnector.java:94) [bundleFile:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
In Event.log:
2021-07-03 12:30:06.954 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘openthermgateway:otgw:1’ changed from ONLINE to OFFLINE: Disconnected
After this, the OTGW thing remains OFFLINE. If I switch it to DISABLED and then to ENABLED it goes to online again.
In Event.log:
2021-07-03 17:42:22.794 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘openthermgateway:otgw:1’ changed from OFFLINE: Disconnected to UNINITIALIZED
2021-07-03 17:42:22.831 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘openthermgateway:otgw:1’ changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2021-07-03 17:42:25.673 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘openthermgateway:otgw:1’ changed from UNINITIALIZED (DISABLED) to INITIALIZING
2021-07-03 17:42:25.684 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘openthermgateway:otgw:1’ changed from INITIALIZING to UNKNOWN: Initializing
2021-07-03 17:42:25.685 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘openthermgateway:otgw:1’ changed from UNKNOWN: Initializing to UNKNOWN: Connecting
2021-07-03 17:42:25.717 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘openthermgateway:otgw:1’ changed from UNKNOWN: Connecting to ONLINE
It seems that the automatic reconnect (set to 120 seconds) no longer works ?
Based on your description and the logs, it looks like this is the same issue that was reported earlier by other users. This issue was fixed in version 2.0.2.
Apart from this, a lot of other things have changed as well, such as the use of a separate Bridge for the connection to the OTGW and Things for devices like boilers, heat recovery units and solar panels and energy storage. This is still a work in progress though, so consider upgrading or accepting the auto reconnect bug for now.
Arjen, thanks, I think I have to deal with the reconnect bug for now as the 2.0.2 version doesnt load
It gives this error in the log
2021-07-04 16:43:11.034 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.openthermgateway [290]
Unresolved requirement: Import-Package: javax.measure; version=“[1.0.0,2.0.0)”
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1781) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.16.200.jar:?]
I tested it with several scenarios and the connection to OTGW has been restored from OH3 within that default 15s reconnect period.
. Next thing is trying to find out why the ventilation unit temperature is being formatted as such, which does not need discussion in the opentherm topic.