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:?]
Version 2.0.2 of the binding was developed for OH 3.0. As mentioned in my post on may 14 I get an error when running against openHAB 3.1. At the time of writing that, the main branch of the openhab-addons repository was still build for 3.0.
Anyway, I’ll try to find some time soon to finish the new binding design which includes the Bridge and Things and also the fix for the auto reconnect.
I have migrated from OH2.5 to OH3.1. I have installed OpenThermGateway binding 3.1.0 from openhab addons repository (by Schetle Bron) but seems there is no thing/channels for Brink ventilation
Is this another binding for OpenthermGateway? Is there a binding available for 3.1 with ventilation/Brink channels?
Please note that the OpenTherm gateway device is designed by Schelte Bron, but he has not been involved in the development of the binding for openHAB.
Heat recovery and ventilation units are not officially supported yet. If you want to control them using openhab, you can download a test version of the OpenTherm Gateway binding here. This version was build for OH 3.0.3, but I would expect it to work just fine for OH 3.1. Documentation can be found here.
Hi Tomek, Have you connected Brink Renovent with OH3 using Nodo Opentherm Getway? Which socket/connector to connect with Brink: Boiler or Thermostat? Have you experienced any issues?
Ah right, there was an issue indeed with javax.measure package. The main reason why I switched from 3.1 to 3.0 (main) branch at the time. I’d rather stick to one version of the codebase, so until the new version is finished and made official it will only work for 3.0.
@RafalO - yes, I did have some “configuration” pains however through some experimentation I have solved them. Here are a couple of points/solutions I have identified.
Connect Brink/Renovent to Boiler socket on OT Gateway board
Please ensure you have latest PIC firmware v5.1 loaded onto gateway as well as latest Nodo NodeMCU firmware. It’s important as with previous firmwares there were problems with stability.
You need to install OpenTherm monitor program from OTGW website, and connect it to your gateway over IP connection.
In order for OTGW work for ventilation (as that’s currently supported only to limited extent you need to configure gateway accordingly otherwise you will see no communication from Brink and OT gateway will be restarting every minute or so.
Here are the steps in OT Monitor:
Connect to OT Monitor in browser to configured IP/port
Go to “Configure” tab and then “Miscellaneous” section here do the following
enable Gateway mode - can be also done using GW=1 command which can be typed in the input line below
Then issue following commands one-by-one so that specific data could be read/processed from Brink and OTGW will issue them on regular basis
AA=70 (this queries the status of ventilation unit - required)
AA=71 (this controls setpoint for ventilation speed - required)
AA=77 (this returns current relative ventilation in % or level pre-set on the brink - optional)
AA=80 (this reads the current air supply temperature - optional)
AA=82 (this reads current air exhaust temperature - optional)
That would be it for the basic operation - after this you can verify your setup in OT Monitor checking the tab “Messages” where you will see the commands being issued at regular intervals. I.e. command VS=xxx (where xxx is a number) can change the ventilation levels.
There is also whole thing about reading TSPs, which is also interesting as you can read current air volume in m3/h or air input/output duct pressures, the binding supports it, but it’s a bit tricky to handle and you don’w want to read TSPs more often than every 5 mins.
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
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.