OpenTherm Gateway binding

Mephix · May 17, 2020, 5:36pm

The pull request to merge the initial version of the OpenTherm Gateway binding into openHAB’s set of addons has (finally) been approved.

Thanks everyone for testing this binding and providing me valuable feedback!

This topic continues to be the place to discuss the bindings features or any issues or questions you may have regarding the use of the binding.

jamesmelville · July 23, 2020, 10:44pm

Hi Arjen,

Thank you for all your hard work on the binding, it is working great for me. I had a couple of proposals I wanted to run by you for potential tweaks to the binding.

I’ve implemented a feature in OpenHAB where I can enable my heating, overriding the fact that my thermostat has it turned off. (basic rationale - I have motorised TRVs throughout the house except the bathroom and just want to warm the towel rail in the bathroom without going to the effort of installing devices in the room, working out the temperature in that room and setting a higher setpoint).

I have done this by sending a command of CS=40 to warm the towel rail, and CS=0 to stop it. Per the OTGW docs for the CS command, CS=40 overrides the Control Setpoint to 40C and also enables central heating (CH=1), and CS=0 returns control to the thermostat, removing the overrides from CH and CS. (I also added logic to return control to the thermostat if it does call for heat using information from the thermostat binding).

When not calling for heat, my thermostat sends a Control Setpoint of 35. When CS=0, this value is seen correctly in the binding, and is seen in OT Monitor as:

|21:46:32.790129|T90012300|Write-Data|Control setpoint: 35.00|
|21:46:33.096386|B50012300|Write-Ack |Control setpoint: 35.00|

When CS=40 is set, the channel state in the binding appears to flicker between the Control setpoint value sent from the thermostat, and that set in the override. e.g. the following in OpenHAB logs:

2020-07-23 21:45:32.030 [vent.ItemStateChangedEvent] - Boiler_Control_Setpoint changed from 40.0 °C to 35.0 °C
2020-07-23 21:45:32.033 [vent.ItemStateChangedEvent] - Boiler_Control_Setpoint changed from 35.0 °C to 40.0 °C
2020-07-23 21:45:40.013 [vent.ItemStateChangedEvent] - Boiler_Control_Setpoint changed from 40.0 °C to 35.0 °C
2020-07-23 21:45:40.022 [vent.ItemStateChangedEvent] - Boiler_Control_Setpoint changed from 35.0 °C to 40.0 °C

Similarly, this is the output of OT Monitor logs:

|21:46:17.181672|T90012300|Write-Data|Control setpoint: 35.00|
|21:46:17.182875|R10012800|Write-Data|Control setpoint: 40.00|
|21:46:17.737736|BD0012800|Write-Ack |Control setpoint: 40.00|
|21:46:17.739618|A50012300|Write-Ack |Control setpoint: 35.00|

This results in extra data written to my persistence layer and a squiggly line when charting it.

I can see that your code is reading the first character of the message (T/R/B/A explained here), but I can’t see anywhere it’s actually used, so assume this is caused by both “Write-Data” messages being used to update the state.

I was trying to think about how to best resolve this. I think there might be two options.

The simple solution might be to filter the messages based on the normal direction so that only the data reported to the recipient was recorded, not the value prior to override. e.g. For Control Setpoint, only update state from a B (boiler) Write-Ack rather than Write-Data. But I’ve not explored if other channels would require logic which inspected multiple messages (or if this is even a problem for other channels).
I think multiple channels could be exposed. In the example of Control Setpoint you might have 3:
a) Control Setpoint requested by Thermostat (read only) - this is always the value the thermostat asks for
b) Control Setpoint requested to boiler (read only) - when not overridden this is equal to a, when overridden equal to c. I suggest this should be the value of the existing channel.
c) Overriden Control setpoint - value of the last override sent to OTGW. When modified this triggers the command CS=<Value>, with null mapped to 0.

I think you have used this pattern (with a and b values merged?) alongside the TT/TC/OT/SW override codes, and also discussed this pattern previously:

Similarly it’d be really helpful to break this out for the ch_enable channel in my use case so that I can detect when my thermostat is requesting heat, rather than the request being from the OTGW, and revert the boiler to thermostat control so that the thermostat heating algorithms are not affected as mentioned in the docs. I am doing this already via the thermostat binding but that polls every 60s whereas OTGW provides a more frequent update.

So I’m wondering if you or others had any comments on these ideas before I start poking about in your code to create a pull request. I’m slightly nervous about breaking existing functionality, and my boiler and thermostat both appear to only handle a small subset of the Opentherm spec, making it difficult to test on anything bar this use case, so I’d probably focus on only these two scenarios (CS/CH) unless you recognise this as a more general problem.

Regards,

James

Mephix · July 24, 2020, 8:44am

Hi @jamesmelville,

I think you are correct in that filtering messages based on code (TRBA-E) is not fully implemented, simply because up until now there hasn’t been any need to. Without overriding, the messages sent to the boiler aren’t altered by the gateway so the values should all be the same and don’t cause any issues.

When overriding, things start to get a bit more complicated as you already pointed out. That’s the reason why there are multple temperature setpoint channels to report the current setpoint and to allow temporary and constant overriding.

The situation you describe with control setpoint is a little different though. With temperature setpoint, there is only one channel bound to the actual setpoint, with no filter on BA (this is what you described as merging, but it’s actually a lack of filtering).

So, right now the channels are linked to a message id through a mapping table found in DataItemGroup.java. An option would be to add TRBA levels to this channel-binding, so that individual channels can be linked to T, R, B, A or any combination of the four (in case it doesn’t matter and you simply want to ‘combine’ them to one channel). You mentioned two options, but I think they are really just 2 parts of one solution first allow for filtering to distiguish between TRBA, then seperate into channels when needed.

It seems you already have a general idea of what the code does and what needs to be changed… so I’d say: have a go at it. You can fork it from https://github.com/ArjenKorevaar/openhab-addons/tree/otgw so that we can workt together on a solution, before merging it back to the upstream openhab repo.

Regards,
Arjen

thicknesss · November 9, 2020, 7:23pm

Goodday all,
I’m a newbee to openhab and have found most of my answers in this community.
I’m migrating from Pimatic home automation, which also supports the OTGW.
I’ve the same issue as mentioned above.
I use the CS=40 command to start the boiler when the bathroom floor gets to cold.
in Pimatic i’ve altered the module code to split the T an R for CS.
this way I can stil monitor the request from the thermostat (T), and cancel my override as soon as the livingroom needs heating.
When I use the Sendcommand channel to set the CS to 40 I get this in
events.log

    2020-11-09 12:00:42.758 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:43.340 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:43.367 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:43.852 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:43.873 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:44.297 [vent.ItemStateChangedEvent] - ControlSetpoint changed from 40.0 to 10.0
    2020-11-09 12:00:44.306 [vent.ItemStateChangedEvent] - ControlSetpoint changed from 10.0 to 40.0
    2020-11-09 12:00:45.062 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:45.076 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:46.164 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:46.190 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:46.669 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:46.685 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:47.256 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:47.285 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:47.759 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:47.786 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:48.370 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:48.383 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:48.872 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:48.881 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF
    2020-11-09 12:00:49.302 [vent.ItemStateChangedEvent] - ControlSetpoint changed from 40.0 to 10.0
    2020-11-09 12:00:49.313 [vent.ItemStateChangedEvent] - ControlSetpoint changed from 10.0 to 40.0
    2020-11-09 12:00:49.966 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from OFF to ON
    2020-11-09 12:00:49.977 [vent.ItemStateChangedEvent] - CentralHeatingEnabled changed from ON to OFF

Also in the openhab.log i’ve got this error when de CS=40 command is active.

2020-11-09 10:51:27.323 [ERROR] [sistence.rrd4j.internal.RRD4jService] - Could not create rrd4j database file '/var/lib/openhab2/persistence/rrd4j/CentralHeatingEnabled.rrd': null

I’m willing to put some time in this but don’t know where to start.

Regards André

Mephix · November 10, 2020, 8:46am

Hi @thicknesss, welcome to openHAB

This issue is a little tricky. When messages are overridden by the OTGW, both the original message and the override message are received. The thing is though, that once the original message is received, there is no way of knowing if or when an override is received. So what’s the real setting of ch_enable? It’s the value set by the thermostat (in case of CS override), until it’s overridden by the OTGW … which may or may not happen at some point later on.

I am not yet sure how to solve this. Splitting original and override messages into seperate channels seems llike it’s getting very complex to deal with using rules in openHAB. Another solution may be to add a delay and wait for a possible override before updating the channels status.

One other way would be to only look for WRITE-ACK since that should hold the value that is actually written, regardless of multiple WRITE-DATA messages being sent by (in this case) thermostat or OTGW. However, OpenTherm specification states on WRITE-ACK: “Note that DATA-VALUE may be modified by the slave in some circumstances” so I am not sure if it’s always true that the actual written value is returned. This also seems part of the solution though, since WRITE-ACK message can also be overridden?

Perhaps you can check with @jamesmelville solution, since he already worked on this issue.

Regards
Arjen

thicknesss · November 11, 2020, 4:07pm

Hi Arjen,
Thanks for yor answer.

I think @jamesmelville agree that we only need to spilt the CS and CH channels into a T and R variant.
As most other users are (probably) only interested in the T variant you/we can decide that the current channels for CS en CH will be filled with the T data. This won’t break to many (hopefully not any) existing setups.

For those who don’t have the special (Remeha) thermostat that listens to the temp. override and / or constant override we can use the CS= command via the command channel and use the 2 new channels (with target = R) to monitor the boiler.

As @jamesmelville mentioned the “code” is already known to the script.

best regards André

Mephix · November 11, 2020, 4:54pm

Hi André,

It shouldn’t be too difficult to split those two up in separate channels. @jamesmelville already did some work, however I lost track of that since I had to re-create my fork from openhab-addons. So if James still has his work ready we can have a go with that. Otherwise I will create the new channels and add the filtering on T/R.

Regards
Arjen

jamesmelville · November 11, 2020, 10:14pm

Hi André and Arjen,

The work I did on this is here:

To be honest, I did this work, and whilst it worked for my scenario I realised it wasn’t quite perfect, or maybe not a “proper solution” (I can’t remember exactly why, but it’s mainly around the subject of Arjen’s comments in the thread about how you really need to cross reference the different messages, i.e. wait to see whether an override message exists when you process the boiler message, which would take some more significant refactoring) and TBH I’ve been focusing on other things. Obviously if you want to work further on a solution to this please take my tweaks to Arjen’s code as starting point. I’d be happy to test it out and give feedback.

If I remember right I did issue a pull request to Arjen’s repository which might have contained some more detailed commentary around this, but because the repo has been nuked and recreated the PR is gone - I don’t suppose you have any history to this in email notifications @Mephix?

James

thicknesss · November 13, 2020, 6:07pm

Hi James / Arjen,
As far as I understand I’ve checked James his work on this.
This would for sure fill my wishes.
How can I test it?
can i just copy the modified files to a location in the OH2 config?
I haven’t found yet where and how bindings are located and stored on my (PI-raspbian) system.

jamesmelville · November 13, 2020, 7:39pm

Hi both,

I’ve remembered what was wrong with my code - and it’s basically what you were talking about with the T and R messages. When the override is present, then there are two messages sent from OTGW to openHAB with the status. The first being the request from the thermostat to the boiler, which has been intercepted by the OTGW, and secondly the tweaked message actually sent from the OTGW to the boiler. But when no override is present, there is no R message. So this code reads the overrides and will set an item state based on it, but when the override is gone it doesn’t reset to null.

As an interim measure to fix this the expire binding could be attached to the override items to clear the state after a short time. But ideally the binding would know that the message is missing and clear the state.

I’m afraid I can’t find a compiled copy of the jar which you’ll need to test it, to make it yourself you’ll need to check out my branch, install the right versions of java and maven, and maybe some other dependencies installed - the easiest way might be to follow the guide to setting up an IDE https://www.openhab.org/docs/developer/. I should be able to compile it here quite quickly but won’t be tonight I’m afraid.

James

jamesmelville · November 17, 2020, 10:38pm

Hi André,

I’ve uploaded a compiled version of the binding here:

against the code it’s compiled from.

James

thicknesss · November 26, 2020, 9:09pm

HI everyone,
I managed to get mvn (maven) working on my PI box, compiled the snapshot version from @jamesmelville and got the snapshot version working with the input from the FAQ

Added the new channels to my Items file

//new
Number ControlSetpointrequest "Control setpoint T [%.1f °C]" <temperature> (gOTGW) { channel="openthermgateway:otgw:37cd033e:controlsetpointrequested" }
Number ControlSetpointoverride "Control setpoint B [%.1f °C]" <temperature> (gOTGW) { channel="openthermgateway:otgw:37cd033e:controlsetpointoverride" }

and added the items to the sitemap:

        Text item=ControlSetpointrequest icon="temperature" label="Control setpoint T [%.1f °C]"
        Text item=ControlSetpointoverride icon="temperature" label="Control setpoint B [%.1f °C]"

the items show up in the sitemap but are not updated.
Then I used the Karaf console to set the logging of the org.openhab.binding.openthermgateway TO DEBUG.
This showed channel updates of all channels:

2020-11-26 21:22:37.429 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'controlsetpointrequested': 10.0 °C
2020-11-26 21:22:37.550 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'controlsetpoint': 10.0 °C
...
2020-11-26 21:22:40.201 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'ch_enablerequested': OFF
2020-11-26 21:22:40.363 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'ch_enable': OFF

and when the CS override is active:

2020-11-26 21:44:47.311 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'controlsetpointrequested': 10.0 °C
2020-11-26 21:44:47.322 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'controlsetpointoverride': 9.0 °C
2020-11-26 21:44:47.502 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel 'controlsetpoint': 9.0 °C

I see no errors in my log.

Restarted the binding via the console, and restarted openhab2 as service, but no change.

Can anybody point me in the right direction to solve this?

Mephix · November 30, 2020, 7:38am

Hi @thicknesss, I’m not sure what the problem is… based on the log it receives an update with (what I assume to be) the correct value so it should be updated on the item as well.

Does the item show up in PaperUI and reflect the correct value ?

thicknesss · November 30, 2020, 4:00pm

Hi Arjen @Mephix, thanks for your reply.
in the PaperUI/Configuration/Things/OpenTherm Gateway I don’t see the new channels:

In PaperUI/Configuration/Items I DO see them, but fields are “Grayed-out”:
Knipsel1

I thought this was because this a (manually installed) snapshot version of the binding.
(with manually created items)
Reading your reply I assume that the Thing should show all the channels.

I"ll try what happens when i remove the binding (via console), restart OH wait for al the startups to finish and the drop the “.JAR”'s (Both??) in the addon folder again.
If that doesn’t help I’ll need to try the Clear Cache option between restarts to be sure that “old” stays in place.
This will take some nights, but i’ll get back with the answers.

Mephix · November 30, 2020, 4:16pm

Hi @thicknesss, in reaction to your comment about putting both .jar files in the addons folder: James provided a link to the sources and a compiled snapshot version (jar file). You can either use the sources and compile it yourself using maven, or use the compiled version James posted. So either way, you end up with one .jar file.

The fields should not be greyed out… this might be due to a version conflict, where you defined items in the .items file that the version of the binding you run doesn’t support. I am not entirely sure about this. Using the console, you can retrieve a list of bindings with their version numbers and status (bundle:list). This should tell you which version of which binding is loaded.

Maarten_Srednas · November 30, 2020, 8:51pm

Hello all,
I have an issue that maybe someone else has as well.
Running openhab 2.5.10 in a docker environment. Also running otmonitor in docker as a relay server for openhab messages.
Setting up the binding in OH works fine but I have occasional permanent disconnects which can only be resolved by changing the bindings connection setttings (e.g. wrong port and back to the otmonitor port) or situations where the binding is reporting offline in paperui and frontial where I still see the binding functioning and processing data.
I managed to get some logging in frontail, see below. Does anyone have a clue on what is happening here? Thanks Maarten

2020-11-30 21:48:52.174 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 57.0 °C to 56.597656 °C

2020-11-30 21:48:56.956 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 56.597656 °C to 56.19922 °C

2020-11-30 21:49:01.857 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 56.19922 °C to 55.898438 °C

2020-11-30 21:49:07.229 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 55.898438 °C to 55.69922 °C

2020-11-30 21:49:12.106 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 55.69922 °C to 55.5 °C

2020-11-30 21:49:16.904 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 55.5 °C to 55.398438 °C

2020-11-30 21:49:18.779 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from OFFLINE: Disconnected to UNKNOWN: Connecting

2020-11-30 21:49:18.788 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from UNKNOWN: Connecting to ONLINE

2020-11-30 21:49:18.845 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from ONLINE to OFFLINE: Disconnected

2020-11-30 21:49:21.782 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 55.398438 °C to 55.19922 °C

2020-11-30 21:49:25.580 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_ch_enable changed from OFF to ON

2020-11-30 21:49:25.948 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_controlsetpoint changed from 10.0 °C to 90.0 °C

2020-11-30 21:49:27.160 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 55.19922 °C to 55.097656 °C

2020-11-30 21:49:27.672 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_ch_mode changed from OFF to ON

2020-11-30 21:49:31.958 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 55.097656 °C to 55.69922 °C

2020-11-30 21:49:34.164 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flame changed from OFF to ON

2020-11-30 21:49:36.857 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 55.69922 °C to 62.898438 °C

2020-11-30 21:49:37.228 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from OFFLINE: Disconnected to UNKNOWN: Connecting

2020-11-30 21:49:37.238 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from UNKNOWN: Connecting to ONLINE

2020-11-30 21:49:37.270 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from ONLINE to OFFLINE: Disconnected

2020-11-30 21:49:42.229 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 62.898438 °C to 68.5 °C

2020-11-30 21:49:45.020 [ome.event.ItemCommandEvent] - Item ‘openthermgateway_otgw_047bd1af_outsidetemp’ received command 9.16

2020-11-30 21:49:45.023 [nt.ItemStatePredictedEvent] - openthermgateway_otgw_047bd1af_outsidetemp predicted to become 9.160156 °C

2020-11-30 21:49:47.047 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 68.5 °C to 69.296875 °C

2020-11-30 21:49:51.927 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 69.296875 °C to 68.5 °C

2020-11-30 21:49:56.624 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_controlsetpoint changed from 90.0 °C to 73.0 °C

2020-11-30 21:49:57.323 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 68.5 °C to 66.09766 °C

2020-11-30 21:50:00.915 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_controlsetpoint changed from 73.0 °C to 71.0 °C

2020-11-30 21:50:02.120 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 66.09766 °C to 64.796875 °C

2020-11-30 21:50:05.785 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_controlsetpoint changed from 71.0 °C to 69.0 °C

2020-11-30 21:50:07.015 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 64.796875 °C to 64.09766 °C

2020-11-30 21:50:08.848 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from OFFLINE: Disconnected to UNKNOWN: Connecting

2020-11-30 21:50:08.861 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from UNKNOWN: Connecting to ONLINE

2020-11-30 21:50:08.874 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from ONLINE to OFFLINE: Disconnected

2020-11-30 21:50:12.192 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 64.09766 °C to 63.796875 °C

2020-11-30 21:50:15.838 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_controlsetpoint changed from 69.0 °C to 68.0 °C

2020-11-30 21:50:17.003 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 63.796875 °C to 63.69922 °C

2020-11-30 21:50:21.889 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 63.69922 °C to 63.5 °C

2020-11-30 21:50:27.305 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 63.5 °C to 63.19922 °C

2020-11-30 21:50:27.328 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from OFFLINE: Disconnected to UNKNOWN: Connecting

2020-11-30 21:50:27.330 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from UNKNOWN: Connecting to ONLINE

2020-11-30 21:50:27.350 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from ONLINE to OFFLINE: Disconnected

2020-11-30 21:50:32.145 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 63.19922 °C to 63.0 °C

2020-11-30 21:50:36.953 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 63.0 °C to 62.796875 °C

2020-11-30 21:50:41.145 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_controlsetpoint changed from 68.0 °C to 67.0 °C

2020-11-30 21:50:41.836 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 62.796875 °C to 62.69922 °C

2020-11-30 21:50:44.978 [ome.event.ItemCommandEvent] - Item ‘openthermgateway_otgw_047bd1af_outsidetemp’ received command 9.16

2020-11-30 21:50:44.991 [nt.ItemStatePredictedEvent] - openthermgateway_otgw_047bd1af_outsidetemp predicted to become 9.160156 °C

2020-11-30 21:50:47.023 [vent.ItemStateChangedEvent] - openthermgateway_otgw_047bd1af_flowtemp changed from 62.69922 °C to 62.597656 °C

2020-11-30 21:50:58.880 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from OFFLINE: Disconnected to UNKNOWN: Connecting

2020-11-30 21:50:58.892 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from UNKNOWN: Connecting to ONLINE

2020-11-30 21:50:58.972 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from ONLINE to OFFLINE: Disconnected

Mephix · December 1, 2020, 7:14am

HI @Maarten_Srednas, there are quite a few things that may cause issues with your setup and the logs don’t show enough info to work with.

What is the reason you have otmonitor in between the OTGW and openHAB? Can you somehow connect it directly, even if temporarily to troubleshoot? Can you give some more details on what type of OTGW and connection module you are using?

Also, you may want to set the loglevel to DEBUG for org.openhab.binding.openthermgateway, this will hopefully show more useful information about what is going on when connection is lost.

thicknesss · December 1, 2020, 4:30pm

HI @Mephix and @jamesmelville,
I got the snapshot working…

Now I can SET the Controlsetpoint form OH, while monitoring the Controlsetpoint send from the thermostat. So when the Thermostat want to heat the Livingroom, I stop the intervention.

I think that in my first try to install the snapshot version I didn’t clean-up all of the 2.5.10 official version.
Now i’ve removed the Thing from PaperUI, removed the binding via console, restarted, clear-cache, restarted moved both the Jar files to:

/usr/share/openhab2/addons/org.openhab.binding.openthermgateway-2.5.6-SNAPSHOT-sources.jar
/usr/share/openhab2/addons/org.openhab.binding.openthermgateway-2.5.6-SNAPSHOT.jar

After one other restart (to start without the start-up errors due to clear-cache) the PaperUI detected 2 OpenTherm Things (this didn’t happen in the first try), i just installed the first one.
Then the new Thing with new ThingID was visible in the PaperUI.

The last thing I needed to do was a search and replace of the old ThingID in my otgw.items file.
Now i’ts up dan running like a charm. Happy

Is there anything more I need to or can do to get this merged in the next version?
Thanks again for your effort en patience.

Mephix · December 1, 2020, 6:00pm

Strictly speaking, I dont think that’s necessary… you can have multiple versions of the same binding installed and just one being active. But I’m glad you got it working now!

As for getting this merged into the next version, after changes on the openhab-addons repository, my fork lost track and I ended up re-creating it. It’s probably best if James creates a pull-request to merge straight into the upstream repository.

Maarten_Srednas · December 1, 2020, 10:25pm

Hi Arjan, @Mephix,
Thank you for you response.
I am using an OTGW from Nodoshop running ESPEasy R147 on a NodeMCU. I put otmonitor in the middle so I could use otmonitor as well. The issue with the connection remains though even when I shutdown otmonitor and have a direct connection to otgw.
With log level DEBUG the pattern below repeats about every 10 to 20 seconds. From what I can test with plain telnet the connection gets lost after a short while. Already checked with my unifi ap but wifi experience is reported to be good (no suprise as the OTGW within a few meters from the AP). So, digging deeper but it seems to be a nodemcu/otgw issue. Will keep you updated.

2020-12-01 23:14:43.349 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘fault’: OFF

2020-12-01 23:14:43.351 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘ch_mode’: OFF

2020-12-01 23:14:43.353 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘dhw_mode’: OFF

2020-12-01 23:14:43.356 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘flame’: OFF

2020-12-01 23:14:43.713 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘controlsetpoint’: 10.0 °C

2020-12-01 23:14:44.246 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘roomsetpoint’: 16.0 °C

2020-12-01 23:14:44.794 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from OFFLINE: Disconnected to UNKNOWN: Connecting

2020-12-01 23:14:44.799 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from UNKNOWN: Connecting to ONLINE

2020-12-01 23:14:44.882 [hingStatusInfoChangedEvent] - ‘openthermgateway:otgw:047bd1af’ changed from ONLINE to OFFLINE: Disconnected

2020-12-01 23:14:44.779 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Stopping OpenTherm Gateway connector

2020-12-01 23:14:44.784 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Stopping OpenThermGatewaySocketConnector

2020-12-01 23:14:44.786 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Starting OpenTherm Gateway connector

2020-12-01 23:14:44.789 [DEBUG] [eway.handler.OpenThermGatewayHandler] - OpenTherm Gateway connector started

2020-12-01 23:14:44.791 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Connecting OpenThermGatewaySocketConnector to otgw.sandersatkins.nl:6638

2020-12-01 23:14:44.798 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector connected

2020-12-01 23:14:44.799 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PR=A

2020-12-01 23:14:44.800 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PS=0

2020-12-01 23:14:44.879 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Connection closed by OpenTherm Gateway

2020-12-01 23:14:44.880 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Stopping OpenThermGatewaySocketConnector

2020-12-01 23:14:44.880 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - OpenThermGatewaySocketConnector disconnected

2020-12-01 23:14:44.912 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Resending command: org.openhab.binding.openthermgateway.internal.GatewayCommand@4c31da24

2020-12-01 23:14:44.912 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PR=A

2020-12-01 23:14:44.913 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Resending command: org.openhab.binding.openthermgateway.internal.GatewayCommand@42f63dd2

2020-12-01 23:14:44.914 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PS=0

2020-12-01 23:14:44.924 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘flowtemp’: 57.296875 °C

2020-12-01 23:14:44.954 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Received command confirmation: PR: A=OpenTherm Gateway 4.2.5

2020-12-01 23:14:45.322 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Resending command: org.openhab.binding.openthermgateway.internal.GatewayCommand@42f63dd2

2020-12-01 23:14:45.324 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Sending message: PS=0

2020-12-01 23:14:45.437 [DEBUG] [rnal.OpenThermGatewaySocketConnector] - Received command confirmation: PS: 0

2020-12-01 23:14:45.438 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘ch_enable’: OFF

2020-12-01 23:14:45.439 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘dhw_enable’: ON

2020-12-01 23:14:45.442 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘fault’: OFF

2020-12-01 23:14:45.444 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘ch_mode’: OFF

2020-12-01 23:14:45.446 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘dhw_mode’: OFF

2020-12-01 23:14:45.447 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘flame’: OFF

2020-12-01 23:14:46.030 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘ch_enable’: OFF

2020-12-01 23:14:46.031 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘dhw_enable’: ON

2020-12-01 23:14:46.033 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘fault’: OFF

2020-12-01 23:14:46.034 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘ch_mode’: OFF

2020-12-01 23:14:46.036 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘dhw_mode’: OFF

2020-12-01 23:14:46.040 [DEBUG] [eway.handler.OpenThermGatewayHandler] - Received update for channel ‘flame’: OFF