OTM : automatic reconnect to OTGW via network

[antst]

I have setup where my OTGW embeds ESP8266 and automatically attach to AP, which is provided by RPi used for home management (separate from normal WiFi family uses).And last night I got situation when OTM stopped to receive information from OTGW. I restarted OTM and it works OK again. I suspect that it lost connection to OTGW for whatever reason. It would be nice if OTM, for network connection, would keep automatic reconnection attempts, till succeed.

[hvxl]

It already does that. But if the ESP8266 didn't cleanly disconnect, OTMonitor may not be aware that the connection is gone. Did the icon in the status bar indicate that it thought it was connected (green) or disconnected (red)?

If the connection isn't properly closed, but silently disappears, OTMonitor won't detect that until it tries to send something. You can enable automatic clock updates (Options->Thermostat (F2) "Automatically update the gateway clock"). That will cause OTMonitor to send a command to the OTGW every minute. If the connection then breaks, it should be detected within a minute.

[Templar]

Did the icon in the status bar indicate that it thought it was connected (green) or disconnected (red)?

I also have an ESP8266 attached to my OTGW setup flashed with the esp-link firmware and have experienced OTmonitor not receiving data. The statusbar icon doesn't indicate disconnected when that happens. However, in the esp-link Microcontroller Console I still can see data being transferred.

[antst]

If the connection isn't properly closed, but silently disappears, OTMonitor won't detect that until it tries to send something. You can enable automatic clock updates (Options->Thermostat (F2) "Automatically update the gateway clock"). That will cause OTMonitor to send a command to the OTGW every minute. If the connection then breaks, it should be detected within a minute.

I have this enabled, and this is what I see in the message log

Code: Select all

13:50:26.653073  T90013B00  Write-Data  Control setpoint: 59.00
13:50:26.654488  B50013B00  Write-Ack   Control setpoint: 59.00
13:50:26.655633  T00090000  Read-Data   Remote override room setpoint: 0.00
13:50:26.656488  R00770000  Read-Data   DHW burner starts: 0
13:50:26.657309  BC077FFFF  Read-Ack    DHW burner starts: 65535
13:50:26.658213  AC0090000  Read-Ack    Remote override room setpoint: 0.00
13:51:00.001003  Command: SC=13:51/3
13:52:00.001281  Command: SC=13:52/3
13:53:00.000541  Command: SC=13:53/3
13:54:00.000746  Command: SC=13:54/3
13:55:00.001002  Command: SC=13:55/3
13:56:00.001253  Command: SC=13:56/3
13:57:00.000476  Command: SC=13:57/3
13:58:00.000680  Command: SC=13:58/3
13:59:00.000883  Command: SC=13:59/3
14:00:00.001169  Command: SC=14:00/3
14:01:00.001442  Command: SC=14:01/3
14:02:00.000689  Command: SC=14:02/3
14:03:00.000860  Command: SC=14:03/3
14:04:00.001052  Command: SC=14:04/3
14:05:00.001284  Command: SC=14:05/3
14:06:00.000508  Command: SC=14:06/3
14:07:00.000799  Command: SC=14:07/3
14:08:00.001015  Command: SC=14:08/3
14:09:00.001198  Command: SC=14:09/3

And then silence.

[hvxl]

If you get into this situation again, please create an html directory next to your otmonitor executable if it doesn't yet exist. Unzip the attached file in there. If necessary, enable the web server. Then direct your browser to http://<ip>:<port>/connection.html and report what it produces.

[Templar]

If you get into this situation again, ......... Then direct your browser to http://<ip>:<port>/connection.html and report what it produces.

It happend again. Opentherm Monitor ver. 4.3.0.2 (windows executable) running on a 64 bit Windows 10 machine stopped receiving information. The statusbar indicates that it still has a connection and the esp-link Microcontroller Console still transfers the OTGW data packets.

Code: Select all

Socket information

Socket sock0597F250:

        IP address: ::1
        Hostname: DESKTOP-xxxxxx
        Remote port: 58080
        Local port: 8080
        Translation: crlf/crlf
        Encoding: cp1252
        Pending: 0/0
        Blocking: 0
        Buffering: full 

Socket sock0409D588:

        IP address: 192.168.1.70
        Hostname: OTGW.lan
        Remote port: 23
        Local port: 49741
        Translation: crlf/cr
        Encoding: binary
        Handler: receive
        Pending: 0/0
        Blocking: 0
        Buffering: line 

Last error

can't read "gui(chwsetpoint)": no such element in array
    while executing
"expr {$float != $gui($name)}"

Hmm, I F5-ed the page several times and something was happening with the Encoding on the receiving side, it changed from cp1252 to binary.

Code: Select all

Socket information

Socket sock05BE12E0:

        IP address: ::1
        Hostname: DESKTOP-xxxxxx
        Remote port: 56410
        Local port: 8080
        Translation: crlf/crlf
        Encoding: binary
        Pending: 0/0
        Blocking: 0
        Buffering: full 

Socket sock0409D588:

        IP address: 192.168.1.70
        Hostname: OTGW.lan
        Remote port: 23
        Local port: 49741
        Translation: crlf/cr
        Encoding: binary
        Handler: receive
        Pending: 0/0
        Blocking: 0
        Buffering: line 

Last error

can't read "gui(chwsetpoint)": no such element in array
    while executing
"expr {$float != $gui($name)}"

[antst]

BTW, I think ESP-link is a bad choice of firmware for OTGW. It has thing of automatic inactivity disconnect. And while it should be not an issue, as OTGW normally flows enough of information, I think that something like ESP-bridge is better suited.

[hvxl]

Everything on the OTmonitor side looks exactly as it should. And since this problem only seems to happen with esp-link, the most likely reason is that esp-link stops sending data to OTmonitor, despite what esp-link Microcontroller Console says. Then again, that console uses a different TCP connection and is only designed to show what happens on the serial line, without any guarantee that the same information is also sent to any other TCP connection. To be sure where the problem lies, I suggest you use wireshark to monitor the actual traffic between esp-link and OTmonitor.