It seems it’s doing its job though… every time connection is lost or failed, a schedule is set to reconnect after 5 seconds. The Already connecting... is caused by the logic that the Connect() function itself first calls Disconnect() to make sure any existing connection is closed before creating a new connection. During that time the disconnect function should not schedule another reconnect task.
Depending on the stability of the connection, you may see more or less reconnection attempts.
Anyway, I’ll wait a couple of days before submitting the PR to let others test and report their findings as well.
First thank you for your work on the binding.
I’m currently using your Opentherm binding in my OH2.5 with OTGW from NodoShop, last hardware revision, and NodeMCU.
As others I experience a quite unstable behaviour from the NodeMcu, I checked on it and I lost sometimes the ping to the device, even though the binding reconnects after the lost connection. I’m using esp-easy mega-20190607, which to be honest, I don’t know if it’s the recommended version. If someone can bring a bit of light of the recommended version/conf for the NodeMcu it would be great. I have already configured the I2C 38 as Nodoshop told me.
All in all I think the Ethernet version should be more stable, but I can’t get to the boiler with an ethernet cable, so I need to make it stable with the wifi version.
One more thing, I use my openhab as Virtual thermostat to control the boiler(heating+DHW). To activate it, I create an item to invoke the (SendCommand CS=52 for ON/ CS=0 OFF) and I have another item+rule created to send the Domestic water Setpoint(SW). I used for both cases the SendCommand option, as there is no channel to just “sent/set” the value. I don’t know if it can be added as channel or if it does not make sense for others that use a physical thermostat.
We do see a lot of issues with using the NodeMCU. I did make some changes recently to improve the reconnect logic of the binding but can only do so much to compensate for the unstable wifi connection of the NodeMCU. I use a Moxa RS232 to ethernet converter myself and that has proven to be a very stable solution, but yes… it does require an ethernet connection.
As for the SendCommand, the OTGW supports a lot of commands. Most of them aren’t used much, so they’re not linked to a channel, but can still be used through the generic SendCommand channel.
Now, as for the CS command, there is actually a Control Setpoint Override channel, added by James Melville. Keep in mind though that it is rather difficult to write a heating algorithm that is efficient, comfortable and uses things like modulation. There is a lot more to it than simply turning on the burner and pump when it gets cold en turning them off again when its warm. I would advice to let an actual thermostat handle that part.
@Nauttor I’m sorry, but I have little experience with the NodeMCU and don’t have one currently laying around to test. ESP Easy may be a bit bloated if you are just hooking it up to the OTGW but my guess is that wifi instability has more to do with the hardware than with the firmware. With the new version of the binding with its improved code for automatically reconnecting… the problem may be reduced to unnoticable or acceptable level. And it’s not like you need an update on the room temperature every second. Apart from using the latest version of the binding, you could try to load other firmware onto the NodeMCU as well.
Edit: I just noticed Schelte has developed it’s own NodeMCU firmware. You might give that a try.
@robr57 actually the latest version would 1.1.1. The code of 1.0.4 should be more or less the same though, since it was rebased onto the main branch of the openHAB repository where an increase in version number was needed as that one was already update to 1.1.0 due to the added Diagnostics channel.
I haven’t tried the new firmware of the OTGW, I just learned there is a new firmware (actually 2) Based on the changelog, I would expect no issues with the OTGW binding. The binding doesn’t use PS=1, it actually sets PS=0 by default when connection is established. Of course the new features such as support for a second heating circuit are not implemented in the binding yet, but that shouldn’t cause any problems. The rest seem like improvements to the firmware that don’t affect the serial interface.
So, go ahead and update to 5.0 and if you do run into issues, just let me know and I can probably fix it quickly.
Arjen, thanks. 1.0.4 is up and running (through .jar into addons directory), how can I get 1.1.1 ? I am on OH 3.0 stable in docker, cannot find a way to upgrade bindings to latest versions from the formal repository…
I have 1.2.0 installed on Openhab 3.0 and have 5.0 firmware.
Occasionally the timeouts still occur, but for some reason the plugin does not always recover from this and the OTGW Thing gets into an error state.
However, it seems that the channels continue to operate, but writing to InfluxDB is stopped.
If I disable the the Thing and restart, then it works again for some days.
It is always the same info in the log. Can it be that there is somewhere a counter that keeps track of number of failures and stops when it cannot connect ? This counter is probably not resetted when the reconnect attempt succeeds…
2021-02-13 02:01:26.466 [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:185) ~[?:?]
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:834) [?:?]
I suggest if you do not see an immediate solution, that we await OH 3.1 .
That in itself is expected and not something that can be fixed. The log you provided does show that the connection is lost, but as long as the binding automatically reconnects, that shouldn’t be an issue.
it seems that the channels continue to operate, but writing to InfluxDB is stopped.
If the channels continue to operate, than that is an indication that the connection is restored. That doesn’t explain though why writing to InfluxDB is stopped.
Can it be that there is somewhere a counter that keeps track of number of failures and stops when it cannot connect.
No, there is no such counter. It should continue to try to reconnect indefinitely. Unless of course there is some unforeseen state that causes it to stop reconnecting, but it’s not ‘by design’. And given that you say the channels continue to work, I doubt that the auto-reconnect logic is infact the issue.
You mentioned that the binding gets into an error state? Can you elaborate on that, perhaps with some more logging or screenshots? Is there also information about why logging to InfluxDB is stopped? Or is that somehow related to this ‘error state’ the binding is in?
I did make an analysis error, sorry for that. I noticed in events log that there were still Items being updated, but next time I have to check the date and time. It was a different date… sorry. So writing to Influx for OTGW Things was stopped as well.
This is the log entry in events : 021-02-13 02:01:26.456 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from ONLINE to OFFLINE: Disconnected
And this is the entry in openhab.log
2021-02-13 02:01:26.466 [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:185) ~[?:?]
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:834) [?:?]
Then when I stop and restart in events.log : 2021-02-13 18:15:42.417 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from OFFLINE: Disconnected to UNINITIALIZED 2021-02-13 18:15:42.491 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from UNINITIALIZED to UNINITIALIZED (DISABLED) 2021-02-13 18:15:43.967 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from UNINITIALIZED (DISABLED) to INITIALIZING 2021-02-13 18:15:43.980 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from INITIALIZING to UNKNOWN: Initializing 2021-02-13 18:15:43.982 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from UNKNOWN: Initializing to UNKNOWN: Connecting 2021-02-13 18:15:43.991 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openthermgateway:otgw:1' changed from UNKNOWN: Connecting to ONLINE 2021-02-13 18:15:44.230 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'BoilerWaterTemperature' changed from 48.898438 to 53.5 2021-02-13 18:15:44.786 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CentralHeatingActive' changed from OFF to ON
etc.
So, the question is why OTGW goes to Disconnected and does not retry, but this is not always the case.
I suggest to pause the problem for now until I have more details. It is curious, and I don’t have full insight in OH architecture to understand how this can happen.
As I said, the fact that it disconnects on a SocketTimeoutException is expected and ‘normal’ behaviour as long as it automatically tries to reconnect after a number of seconds… which, as you indicate, it sometimes doesn’t.
This line may be useful information to what happens:
2021-02-13 18:15:42.491 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘openthermgateway:otgw:1’ changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
Apperantly, the binding gets put into a disabled state. This is not something the binding does by itself so I guess this is done by OH. I am not sure why it does that, perhaps in a reaction to the SocketTimeoutException… I’ll need to further analyze this. In the meantime, if it happens again and you can provide me with more information and logging, please let me know.
Edit: @robr57 please set the log level for OpenTherm Gateway to debug. That should provide more detailed information on whats going on.
Just to let you know that the feature for diagnostic indication works perfect! Tested it today as my service guy did a usual maintenance. After that the flag switched to OFF.
I have created feature request #10198 on Github. I’ll probably be able to work on it this weekend. I am not sure if my boiler supports these OpenTherm messages and I am currently migrating from openHAB 2.5 to 3.0… so I’ll ask you to test it.
Edit: I am not sure about Unsuccesful burner starts, do you happen to know the OpenTherm message id ? Never mind, I found it in OpenTherm specification 3.0… it should be message id 113.
Based on the changelog, I would expect no issues with the OTGW binding. The binding doesn’t use PS=1, it actually sets PS=0 by default when connection is established. Of course the new features such as support for a second heating circuit are not implemented in the binding yet, but that shouldn’t cause any problems. The rest seem like improvements to the firmware that don’t affect the serial interface.