Thank you for tips, they were usefull! I was not able to upgrade PIC firmware (as you have indicated about 5.1) via nodeMCU. Maybe the reason is that I have flashed NodeMcu with program I have compiled in Arduino IDE instead of using ready to use bin/exe code? In order to move forward I have upgraded PIC using FDDI/USB then keeping serial communication (USB) I have started otmonitor. I can see some data but not sure if the behaviour is OK as follows:
When I click “Gateway” in Configuration/Miscellaneus tab, the GW=1 command is sent and ot monitor present some data but in addition Brink stops operations/ventilation and displays some strange symbol.
When I send comand AA=71 (Brink does not work as above) I can see the following data - click Log below
Log
18:19:22.767557 Command: AA=71
18:19:22.787661 AA: 71
18:19:23.248832 R00120000 Read-Data CH water pressure (MsgID=18): 0.00
18:19:23.402591 BF0120000 Unk-DataId CH water pressure (MsgID=18): 0.00
18:19:24.287407 R00000000 Read-Data Status (MsgID=0): 00000000 00000000
- CH enable: disabled (0)
- DHW enable: disabled (0)
- Cooling enable: disabled (0)
- OTC active: not active (0)
- CH2 enable: disabled (0)
- Summer/winter mode: winter (0)
- DHW blocking: unblocked (0)
18:19:24.402631 BF0000000 Unk-DataId Status (MsgID=0): 00000000 00000000
18:19:25.319678 R80190000 Read-Data Boiler water temperature (MsgID=25): 0.00
18:19:25.394015 B70190000 Unk-DataId Boiler water temperature (MsgID=25): 0.00
18:19:26.351861 R10010000 Write-Data Control setpoint (MsgID=1): 0.00
18:19:26.505297 B70010000 Unk-DataId Control setpoint (MsgID=1): 0.00
18:19:27.389719 R80460000 Read-Data Status V/H (MsgID=70): 00000000 00000000
- Ventilation: disabled (0)
- Bypass position: close (0)
- Bypass mode: manual (0)
- Free ventilation mode: not active (0)
18:19:27.504713 B40460000 Read-Ack Status V/H (MsgID=70): 00000000 00000000
- Fault indication: no fault (0)
- Ventilation mode: not active (0)
- Bypass status: closed (0)
- Bypass automatic status: manual (0)
- Free ventilation status: not active (0)
- Diagnostic indication: no diagnostics (0)
18:19:28.422691 R00110000 Read-Data Relative modulation level (MsgID=17): 0.00
18:19:28.495993 BF0110000 Unk-DataId Relative modulation level (MsgID=17): 0.00
18:19:29.454793 R80460000 Read-Data Status V/H (MsgID=70): 00000000 00000000
- Ventilation: disabled (0)
- Bypass position: close (0)
- Bypass mode: manual (0)
- Free ventilation mode: not active (0)
18:19:29.597482 B40460000 Read-Ack Status V/H (MsgID=70): 00000000 00000000
- Fault indication: no fault (0)
- Ventilation mode: not active (0)
- Bypass status: closed (0)
- Bypass automatic status: manual (0)
- Free ventilation status: not active (0)
- Diagnostic indication: no diagnostics (0)
18:19:30.490573 R90470000 Write-Data Control setpoint V/H (MsgID=71): 0
18:19:30.606939 B50470000 Write-Ack Control setpoint V/H (MsgID=71): 0
18:19:31.428648 Command: GW=0
18:19:31.452126 GW: 0
18:20:35.394802 OpenTherm Gateway 5.1
18:20:35.422682 Thermostat disconnected
Then when I click “Monitor” in the Configuration/Miscellaneus tab, the GW=0 command is sent and Brink starts operations/ventilation.
Could you please comment if the above is OK /similar to your experience?
@RafalO - that situation reminded me of one more important thing. You need to unplug from the Brink unit that other connector/cable to that manual 3-way controller. Unfortunately they can not be connected at the same time.
All the other steps I highlighted above are still in tact and valid especially putting OT gateway into gateway mode GW=1
Well, I actually got stuck Before I had some readings of ventilation (my post above). But now I can see only standard/boiler readings (with zero values of course) and nothing from Brink regardless if I have 3position switch connected or not. And all that for serial/FDDI.
I have no clude what happend that I have no longer Ventilation lines at all. I have loading PIC with recent firmware again but without result.
First, i would try to re-add entries to be sent by OTGW to Brink - I mean all AA=xx including temperature readings. And see if that helps.
Once you start seeing comms with Brink but with zero responses especially for temp readouts I would look at the serial communication settings.
I am not sure if I can help more as I am using NodeMCU and not serial comms with OTGW
I am using FDDI/serial to connect from otmanager (running on PC) with Gateway. I was not able to do it from NodeMcu so far.
When I send command AA=71 the Gateway`s response is AA:71, but no data related to Brink (as I had in the past) Therefore I think the issue is in Brink (I might somhow changed its setting, is there any setting to restore Brink?) or in gateway serving Brink . Maybe in some time I will find a root cause…
Please check the function of the AA command. As I understand, it is used to add an alternative to a list of data id’s that is used as a substitute for data id’s that are found to be unknown to the device.
As an example: if the thermostat sends data-id 99 and the boiler responds that 99 is an unknown data-id, then the next time this message is sent by the thermostat, the OTGW will substitute it by a data-id from the stored list of alternatives.
So AA=71 by itself doesn’t do anything other than adding 71 to the list of alternatives. Confirmed by the AA:71 response. It then relies on some unknown message to be sent by (for example) a thermostat to be able to substitute this message with one of the id’s from the list of alternatives. So as long as no message is initiated and sent to the boiler (or in your case the Brink), there is nothing there for the OTGW to replace.
I am not sure how this should work, but you will need something that initiates the messages to the Brink device. WIth a thermostat/boiler setup this would logically be the thermostat. In your case it would have to be some rule from openHAB or the OTGW device itself (using PM ?) that triggers messages. But that won’t happen automatically from the AA list.
Hi Arjen, I have a favour to ask finally after several months I was able to spot the “filter check” condition. I was assuming based on some info found on the Internet, that this is being carried in TSP no 23, which is incorrect.
However, it’s much simpler than I thought as it’s a part of the response to PM=70 (V/H Status) which makes perfect sense.
Anyway, below are the examples of response from Brink - with filter check on and off.
This information is carried in the 6th bit of the lower byte
Filter check ON
10:49:54.171447 BC04600A2 Read-Ack Status V/H (MsgID=70): 00000000 10100010
Filter check OFF
14:33:14.630718 B40460082 Read-Ack Status V/H (MsgID=70): 00000000 10000010
So I was wondering if you could enhance the binding by adding a new channel to support it?
Also, I am wondering if you already published the version of the binding with the reconnect functionality?
I have changed quite a few things, but I need to find some time to wrap it up and test it. Adding the channel you requested is little work, so I will surely get that in for the next version of the binding.
I am not sure when I will be able to work on it again though… summer months aren’t the best months for me to spend inside programming
Hi @Mephix - I fully understand the situation re summer months , I don’t think it’s anything urgent given i have just replaced filter so we have several months to go
Thanks a lot for your work - and enjoy the rest of the summer!
Take care,
Tomek.
It took a while before I found the time to write a rule that saved the running log to a new file so that the state was saved at the time the Thing went offline. Since two days now my opentherm bridge Thing is in OFFLINE status but is still receiving and sending from/to the OTGW and I can use the values received and send outside temperature to the thermostat, so it is no real offline.
Below the end of the log at the time the thing went offline (or do you want a few seconds after this as well? In that case I need to adjust my rule):
2021-08-10 20:59:49.042 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - Received update for channel 'ch_enable': OFF
2021-08-10 20:59:49.043 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - Received update for channel 'dhw_enable': ON
2021-08-10 20:59:49.043 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - Received update for channel 'fault': OFF
2021-08-10 20:59:49.043 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - Received update for channel 'ch_mode': OFF
2021-08-10 20:59:49.044 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - Received update for channel 'dhw_mode': OFF
2021-08-10 20:59:49.045 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - Received update for channel 'flame': OFF
2021-08-10 20:59:49.212 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - Stopping OpenTherm Gateway connector
2021-08-10 20:59:49.212 [DEBUG] [rmgateway.internal.OpenThermGatewaySocketConnector] - Stopping OpenThermGatewaySocketConnector
2021-08-10 20:59:49.213 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - Starting OpenTherm Gateway connector
2021-08-10 20:59:49.214 [DEBUG] [g.openthermgateway.handler.OpenThermGatewayHandler] - OpenTherm Gateway connector started
2021-08-10 20:59:49.214 [DEBUG] [rmgateway.internal.OpenThermGatewaySocketConnector] - Connecting OpenThermGatewaySocketConnector to 10.0.0.206:25238
2021-08-10 20:59:49.219 [DEBUG] [rmgateway.internal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector connected
2021-08-10 20:59:49.220 [DEBUG] [rmgateway.internal.OpenThermGatewaySocketConnector] - Sending message: PR=A
2021-08-10 20:59:49.220 [DEBUG] [rmgateway.internal.OpenThermGatewaySocketConnector] - Sending message: PS=0
2021-08-10 20:59:49.286 [DEBUG] [rmgateway.internal.OpenThermGatewaySocketConnector] - Connection closed by OpenTherm Gateway
2021-08-10 20:59:49.286 [DEBUG] [rmgateway.internal.OpenThermGatewaySocketConnector] - Stopping OpenThermGatewaySocketConnector
2021-08-10 20:59:49.287 [DEBUG] [rmgateway.internal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector disconnected
I have uploaded binding version 2.1.2 with quite a few changes.
Rebased onto upstream main branch, which is currently targetted at openHAB 3.2.0. It works with 3.1.0 as well (that’s what I am running) but it might cause issues with earlier versions.
Automatically create TSP and FHB value channels, based on TSP or FHB size messages. Removed the numberOfTSPs configuration setting.
Removed sendPMIntervals configuration setting. The logic of periodically sending PM commands to the OTGW is much better done using openHAB rules.
Added channel vh_filtercheck for the Ventilation / Heat Recovery.
The auto reconnect logic was already changed quite a bit in previous versions. I have made some slight modifications but that should not affect the logic.
Testing is still an issue for me, as I don’t own a ventilation / heat recovery unit and I don’t have any connection issues I can test some things using fake OpenTherm messages or pulling a power or ethernet cable but that may not cover all situations.
So feel free to try this version and let me know if you run into any issues.
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?
as follows:
Before I had some readings of ventilation (my post above). But now I can see only standard/boiler readings (with zero values of course) and nothing from Brink regardless if I have 3position switch connected or not. And all that for serial/FDDI.
finally after several months I was able to spot the “filter check” condition. I was assuming based on some info found on the Internet, that this is being carried in TSP no 23, which is incorrect.
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.