Sorry for the delay in responding.
The only ways that the TCP session is being closed is either a reset packet sent from the T3 or TStat in the case of a network hiccup, or with a proper FIN ACK termination hand shake initiated from my software. I currently have my reconnect interval in my software set to 60s, so when I lose a connection I will attempt to reconnect on that interval. During the period that they are down I receive only a reset packet from them anytime I try to initiate a new connection with a SYN packet (aka connection refused).
I’ve spent the last while looking for any signs that anything else is connecting to these devices but I’ve seen nothing over days of sniffing packets with a wireless adapter in monitor mode. I also setup a network bridge (and firewall rules to forward) between the wired interfaces on my Linux workstation and connected a T3-TB. There was no communication to the T3/TStat devices from anything other my workstation where I’ve been running my testing and development of our hvac control system from. I’ve monitored with netstat what the Linux kernel is reporting for TCP sessions between my workstation and these devices and it shows only one session established to each device. Subsequently If I terminate my polling software the session is no longer listed. I’ve also tried using other 3rd party modbus masters (modpoll on linux workstation, mdbus with my windows laptop) to see If I could replicate the effects and I have so its not just limited to my software implementation.
I haven’t been able to find the Temco source code for the devices that utilize the ESP-07, but I am assuming it utilizes the Espressif AT command set. If it was a case of a half closed connections, I would expect it to terminate after at most 7200 seconds which is the maximum timeout that is supported with the AT+CIPSTO command unless the time parameter is set to 0 which is an infinite timeout (I am assuming that its not set to 0 since that would be a terrible practice). So I really don’t think its half closed connections or erroneous connections since there is zero evidence of it occurring.
Polling rates and size of polls really seem to play no part in the behavior that I am experiencing. I am polling only what I need for registers (which honestly isn’t much. The Tstats for example are only input 9 for the temperature and the related calibration/filter registers + the temperature setpoint) and they’re always performed as grouped as I can get them. My software only ever initiates a write when it receives an event from MQTT (Which haven’t been occurring since I am not running my control application yet). I’ve tried 5s, 10s, 15s, 30s, 60s, 2m, 5m poll rates and they all lead to the same problem.
–Important—
I’ve also done some port scanning on the devices and it seems that all ports on the device are closed when it dies not just port 502. For example Bacnet on 47808 is also non functional, Port 1234 which is open on the my hardwired test device is also dead on the wireless device.
–Important—
It also seems like I am not the only one with this issue as @christopher.cook
has mentioned and @jason.kania from this thread last year exhibiting the exact same problem. We really need a solution to this problem.