Despite the issues I have with access to the Renovent Brink/ventilation, I wanted to check the connection with the bridge itself but I have the following error (OH3.1)
2021-08-13 22:36:55.317 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Initializing OpenThermGateway handler for uid openthermgateway:openthermgateway:c0be19d17c
2021-08-13 22:36:55.322 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Starting OpenThermGateway connector
2021-08-13 22:36:55.327 [DEBUG] [eway.handler.OpenThermGatewayHandler] - OpenThermGateway connector started
2021-08-13 22:36:55.327 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Connecting OpenThermGatewaySocketConnector to 192.XXX.X.XXX:25238
2021-08-13 22:36:55.338 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector connected
2021-08-13 22:36:55.344 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PR=A
2021-08-13 22:36:55.347 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PS=0
2021-08-13 22:37:00.354 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector disconnected
2021-08-13 22:37:00.357 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Scheduling to auto reconnect in 60 seconds
2021-08-13 22:37:00.363 [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:87) [bundleFile:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
2021-08-13 22:37:02.330 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Disposing OpenThermGateway handler
2021-08-13 22:37:02.332 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Cancelling auto reconnect task
2021-08-13 22:37:02.335 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Stopping OpenThermGatewaySocketConnector
I can access OTGW using its IP address. In the info I can see PIC connected : false but I think it shall not impact bridge connection?
Not sure whats going on there… but if the binding can’t establish a basic TCP socket connection then there is something wrong on the network or OTGW side. Check the IP address and port settings. Try connecting with the otmonitor tool. Don’t try to connect both the otmonitor and the binding at the same time (unless you use a serial to ethernet converter that supports multiple connections).
Then you mention something about the PIC controller not connected? I’m pretty sure that needs to be in place before any communication with the OTGW is possible.
In general: set things up properly, test it with the otmonitor tool and if all that works fine… then try to connect the openhab binding.
Hello Tomek,
I have tried with 3-way controller connected and without it and in each case when I set GW=1/Gateway in otmonitor (or I have Opentherm Bridge ONLINE/connected) my Brink Renovent does not work and it displays the following:
@RafalO - that means Brink is switched off.
Have you setup OTGW with AA commands? They are really essential to begin with.
Additionally please put OTGW into gateway mode and keep 3-way switch cable disconnected.
Once you have it in place. You should be able to send VS=xx command. That sets the ventilation control/set point.
VS=0 - switches off brink
VS=1 - switches on 1st level of ventilation which you have set for 3-way switch
VS=2 - switches on 2nd level
VS=3 - switches on 3rd level
In general for example VS=60, sets relative ventilation level to 60% of what the max level your Brink can achieve.
@RafalO - that’s interesting behavior - can you publish some longer log from what entries are being sent?
In general, I have cyclical messages/commands sent for 70, 71, 77, 80 and 82. In addition to that there is bunch of heating related messages which are not being suppressed.
No it’s not. It is exactly as documented The AA=71 stores data id 71 in the list of alternatives to be used as a substitute for unknown data id’s. In the log you see that data id 14 is sent, to which the Brink responds with ‘unknown data id’. And so the OTGW substitutes data id 14 (which it now knows is unsupported) with data id 71 from the list of alternatives.
Thank you both for help and pointing documentation, I have a better understanding of the protocol
My understading (and observation) is that the whole list of alternatives/AAs is sent in response to sending one unknown data id. In my case “trigering”/unknown id messages are 01, 25, 14 and they are generated by gateway itself therefore seems I do not need a special triggers like PM. (Not sure but I think PM triggers only one message? )
By the way I was trying to suppres some of them using IU command for example UI=14 but does not work or I am wrong how it shall work.
Question regarding Ventilation thing of the Opentherm Binding:
a) does the binding sets AA/command in the OTGW gateway after selecting a specific channel or
b) shall I first define alternative commands/AAs in otmanager then use only the channles for which commands were deifned in otmanager?
I think the answer seems b) and the intention is to trigger a channel by prior PM message?
What is your intention exactly with using the UI command? Because from the documentation, my understanding is that it will forcefully treat a data-id as being unknown, even if the unit may indicate otherwise. I assume that this will also result in the OTGW sending messages from the list of alternatives if such a data-id (which is set to being unknown by UI command) is received.
a) I am not sure what you mean by “selecting a specific channel” but in any case, the binding does not send any AA commands automatically. The only commands send automatically on establishing a connection are PR=A which is just for information purposes and PS=0 to make sure OTGW reports every message.
b) You could do that with otmonitor, but you could just as well use openHAB and the SendCommand channel of the binding to send AA commands… or any other command such as PM. Other than for testing, there should be no need to use otmonitor.
I can read data with openhab/otmanager except ID84 and ID85 which are Unk-DataId…?
[1] @Mephix
I have set up AA=71 which allows execuation of the VS command (in otmanager) . How can I change ventilation level via Opentherm binding? I have connected the channel Ventilation setpoint override R/W with an item. But when I change its value (setpoint from 0 to 100) Brink does not change its ventilation volume and ther is an error as follows:
2021-08-23 22:45:28.266 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.openthermgateway.handler.VentilationHeatRecoveryHandler@d25eeb': Unknown channel vh_ventilationsetpoint
java.lang.IllegalArgumentException: Unknown channel vh_ventilationsetpoint
at org.openhab.binding.openthermgateway.handler.OpenThermGatewayHandler.getGatewayCodeFromChannel(OpenThermGatewayHandler.java:268) ~[?:?]
at org.openhab.binding.openthermgateway.handler.OpenThermGatewayHandler.handleCommand(OpenThermGatewayHandler.java:87) ~[?:?]
at org.openhab.binding.openthermgateway.handler.BaseDeviceHandler.handleCommand(BaseDeviceHandler.java:79) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor487.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
at com.sun.proxy.$Proxy1514.handleCommand(Unknown Source) [?:?]
at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefault
Shall I use sendcommand with VS ? (if yes what for is the channel?)
[2] @TomoKRK
Also I am wondering how to read input/output duct preasure. You have mentioned about TSP to be used for such a purpose. I have 73 TSP available (see below) but not sure how to use them?
Summary
19:51:51.375945 Command: PM=88
19:51:51.450418 PM: 88
19:51:52.338165 R80580000 Read-Data Number of TSPs V/H (MsgID=88): 0
19:51:52.429132 BC0584900 Read-Ack Number of TSPs V/H (MsgID=88): 73
I don’t know much about the Brink units, but if the unit responds with Unk-DataId then I suppose those messages (exhaust and inlet fan speeds) are not supported. You may want to check the documentation for your unit.
Thanks for the feedback, it seems I forgot to map the vh_ventilationsetpoint to a gateway command (in this case VS). I corrected that and uploaded binding version 2.1.3. Feel free to give it a try and let me know if it works.
You can always use the basic SendCommand channel to send any command you want to the OTGW. Just think of R/W channels like the vh_ventilationsetpoint as convenience channels that make it easier to set values and map them to items. For example, setting vh_ventilationsetpoint to a value of 25 is the same thing as sending VS=25 to the SendCommand channel. And setting temperaturetemporary channel to 21 is the same as sending TT=21 to SendCommand.
I have submitted feature request #11202 and pull request #11203 to have support for the Ventilation/Heat Recovery merged into the main codebase.
Adding support for Solar Boilers is still on the todo list, but for this I need the OTGW to be updated first to get a complete set of channels and ideally someone that owns such a unit for testing.
I have been away from home for a long time but I am back.
Yes it works! thank you
I have issues with stability of connection/protocol between Brink Renovent and OTGW Gateway but it is outside of this forum.
I have made my own ‘hacked’ version of the OTGW, combining Schelte’s PCB with an ESP running Jiri Praus’ software - and this works I can see the communication between the boiler & thermostat. Hardware side is thus ‘done’, and now I’d like to be able to log/see/use it.
Using your plugin seems great, but I can’t seem to find any documentation on what the expected serial output looks like/what ‘api’ your plugin expects (i.e. looking through this forum & on the OTGW site, it looks like the plugin expects some functions of Schelte’s firmware, like giving commands like PS=1, but unsure if that is optional or not).
Could you give me some pointers as to
what the requirements are on the ‘messages printed to the serial connection’ that your plugin expects (i.e. what do I need my hacked device to output such that your plugin will succesfully parse the lines)
if my device ‘must’ give valid response codes to certain commands sent by your plugin?
Of course I do not expect ‘support’ for my hacked device, but a few pointers that prevent me from needing to reverse-engineer the gateway-plugin protocol would be greatly appreciated!
Thanks,
Jelle
PS based on the logs posted here, and my knowledge of the protocol from reading the documents, I understand that likely in the below the last two characters are the data bytes (1A = 26 & 66=102, 102 /256 = 0.3984). 1C before that = 28 which is the message type. But what is the BC0? B = ‘message received from boiler’? C0 = 192 =??
And should I just be printing these formatted strings to the serial output, or should there be something ‘around’ it too (extra characters that your library drops, but does expect as part of the original firmware messages)?
[eway.handler.OpenThermGatewayHandler] - Received message: BC01C1A66
2018-10-11 06:30:31.352 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'returntemp': 26.3984375
Documentation on the OpenTherm Gateway can be found on the OTGW website, including the meaning of the TBRAE codes and the available serial commands. Your device should acknowledge serials commands, just like the OTGW would (see documentation), otherwise the binding will continue resending the commands automatically.
OpenTherm protocol specifications 2.2 can easily be found on the internet. Those will explain how messages are build up, what each byte or bit means and how the various data types are represented.
Other than that, there is no extra data required like a message envelope or something. You simply write the TBRAE + hex value to the socket stream and terminate it with a newline.
Thanks @Mephix! I had used the OTGW site to build my ‘hacked’ version, but I missed the specific section which explains the formatting. Thanks for confirming it’s ‘just a single line per message’ & that it should acknowledge commands, that helps a lot with debugging.
Hi! I am using NodoShop.nl Opentherm Gateway with NodeMCU, and Openhab and binding version 3.2.0.M5 (i.e. latest milestone version), and I have the same problem as previously mentioned in this thread:
The binding connects to the gateway initially, requests some data and almost immediately loses connection, never trying to reconnect afterwards, despite of "Connection Retry Interval
" is set to 60 in Thing config. It reconnects once only when I disable and re-enable the Thing from UI, then loses connection again.
Here is a piece of log:
2021-12-16 16:58:41.228 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Initializing OpenTherm Gateway handler for uid 'openthermgateway:otgw:faf2b5e278'
2021-12-16 16:58:41.228 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Starting OpenTherm Gateway connector
2021-12-16 16:58:41.230 [DEBUG] [eway.handler.OpenThermGatewayHandler] - OpenTherm Gateway connector started
2021-12-16 16:58:41.232 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Connecting OpenThermGatewaySocketConnector to 172.16.0.80:8080
2021-12-16 16:58:41.250 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector connected
2021-12-16 16:58:41.251 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PR=A
2021-12-16 16:58:41.251 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PS=0
2021-12-16 16:58:41.925 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Received command confirmation: PR: A=OpenTherm Gateway 5.1
2021-12-16 16:58:41.930 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Received command confirmation: PS: 0
2021-12-16 16:58:42.025 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'controlsetpoint': 85 °C
2021-12-16 16:58:43.075 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'servicerequest': OFF
2021-12-16 16:58:43.076 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'lockout-reset': OFF
2021-12-16 16:58:43.076 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'lowwaterpress': OFF
2021-12-16 16:58:43.077 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'gasflamefault': OFF
2021-12-16 16:58:43.077 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'airpressfault': OFF
2021-12-16 16:58:43.077 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'waterovtemp': OFF
2021-12-16 16:58:43.078 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'oemfaultcode': 0
2021-12-16 16:58:44.050 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'modulevel': 48 %
2021-12-16 16:58:45.788 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'ch_enablerequested': ON
2021-12-16 16:58:45.789 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'ch2_enablerequested': ON
2021-12-16 16:58:46.021 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'ch_enable': ON
2021-12-16 16:58:46.021 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'dhw_enable': ON
2021-12-16 16:58:46.021 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'ch2_enable': ON
2021-12-16 16:58:46.022 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'fault': OFF
2021-12-16 16:58:46.022 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'ch_mode': OFF
2021-12-16 16:58:46.023 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'dhw_mode': ON
2021-12-16 16:58:46.023 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'flame': ON
2021-12-16 16:58:46.023 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'diag': OFF
2021-12-16 16:58:46.783 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'controlsetpointrequested': 85 °C
2021-12-16 16:58:51.784 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector disconnected
2021-12-16 16:58:51.784 [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) [?:?]
Connection from Opentherm Monitor is stable, and I am disconnecting from there before initiating connection from Openhab.
The latest version of the Opentherm Gateway binding is 2.1.3, in which (among other things) this problem is addressed. Can you try this version and see if it solves the issue for you?
The AA=71 stores data id 71 in the list of alternatives to be used as a substitute for unknown data id’s. In the log you see that data id 14 is sent, to which the Brink responds with ‘unknown data id’. And so the OTGW substitutes data id 14 (which it now knows is unsupported) with data id 71 from the list of alternatives.
I can see the communication between the boiler & thermostat. Hardware side is thus ‘done’, and now I’d like to be able to log/see/use it.