We are currently hitting an issue where the TStat10 disappears from the WiFi network after some time. The TStat10 has no indication on the screen that the signal is poor or that it has lost connection. From the T3000 software, the Health shows as 0. We then need to reboot the thermostat to restore contact. Following reconnection, the signal shows as strong on the thermostat and the T3000 software shows Health as being in 95+% range.
We have tried with 2 different routers placed within 3 meters of the thermostat and the problem occurs after a day or so.
This, in addition to the very slow and unstable MODBus connection prevents our deployment of the thermostat to customer sites.
Can you confirm that you are using the latest & greatest firmware please. We have done some recent updates regarding wifi connectivity. If you have trouble updating over Wifi you can temporarily connect over RS485 to complete the update. If you end up with a partial update and then get locked out you may have to perform the ‘unbricking’ procedure which you can learn about searching this forum for unbrick, basically you cycle power and use the ISPTool program to load firmware over RS485 in the first few seconds after power up.
We are indeed using the latest firmware as we needed it for the fixes that Fandu made to the protocol so that both ICC Modbus and the Modbus software libraries that we use could communicate with the module.
What we see is that the thermostat just disappears off of the network but is showing fully WiFi strength on the indicator. Immediately on reboot, the connection is back and is strong. It is as if the thermostat gets some connection failure and doesn’t try to reconnect.
I did some connection monitoring over the last week and the problem seems to be that no ports are held open after some time, suggesting the server on the TStat10 is no longer connected to the port. I can ping the thermostat in 90% of the tests that I tried after it becomes unavailable so the TStat10 is on the network, but in each situation, no other ports are alive.
The following is the capture for open ports on the TStat10 and the second is for an ethernet to modbus adapter that we use:
vs
If there are some other ports to test, let me know and I can test those.
Ping isnt a very reliable test of connectivity, ping is a low priority task which can be missed if the CPU is busy with other things like modbus and bacnet communications. A better test of connectivity will be to set up a poll using a few modbus registers. Log that data over an extended period using our usual MBPoll tool and compare that with your CC polling tool. I think that test will show some good insights.
To clarify, what I found was that only ping could contact the TStat10 units when the issue of the thermostat not being accessible occurs. No Modbus tools such as MBPoll, ICCModbus or Modbus code libraries could connect with the TStat10 and the 502 port was not active on the unit from the network standpoint.
Would it be possible to create a firmware image that displays some connection status info in the scrolling text area of the thermostat? I am finding that the thermostat becomes nonresponsive after 12 to 18 hours and the only remedy is to reboot it. In most cases that thermostat can be pinged but doing a port scan shows no ports open.
One piece of information that we also noted is that the screen shifts from showing the IP address of the thermostat to showing the current date when it disappears from the network whether or not we can access it via ping or not.
I received no response on this item in the last week so wanted to check if this is being actively worked or if there is any other information we can collect on our end to assist. We are happy to do testing if some additional information can be provided in the scrolling text with regard to connection status to better diagnose the issue.
The screen shifts: We have not seen that, please share more details, photos.
Loss of connection: We have not been able to reproduce any loss of connection. If you can send us a method to duplicate your environment here we can try to repeat the issue. If that is not so convenient perhaps we can pick something up from a wireshark log at your site.
Watchdog: There are both hardware level and communications level watchdogs active on the Tstat10, it has a decade of history in the field under all sorts of demanding conditions so you can trust that its kind of a ‘known good’ platform. That said, we’re always on the lookout for issues and are standing by to help.
For the screen output changes for the situation where the TStat10 is accessible and when it is not, the difference is as follows:
beforehand, the IP address is being scrolled on the screen and we have MODBus access to the TStat10.
after the MODBus port is lost, it is the date information that is being scrolled. (Does this possibly mean the wifi module is not seen anymore?)
We don’t know what the underlying reason for the change is, so that is why I was asking about getting a load that displays more details on the screen for debugging.
We didn’t end up getting anything from the Wireshark messaging. We tried several tests involving sending MODBus messages to the TStat10 every 5 minutes to check status and all that happens is that on one of these interval messaging requests, the TStat10 no longer responds. When we notice that situation, we do a port scan on the TStat10 and no ports are found to be open whereas beforehand, the 502 port was open. The device remains ‘pingable’, however.
Regarding the communication watchdog functionality, does it attempt to send any messages periodically? Does it monitor the MODBus server specifically? I ask because we don’t see any regular outgoing messages so I am wondering if the TStat10 is monitoring only whether the communication hardware is alive and reporting connectivity. If the server on a particular port is being lost, that might not be detected as something requiring watchdog handling. Such a scenario would match what we see where the device is ‘pingable’ but the MODBus port is unavailable.
Chelsea has set up a test and not been able to see any of the issues mentioned. I asked her to post screen shots of a long term trend of a few modbus registers.
Another finding from our testing was noticing that prior to WiFi connection such as during startup, the TStat10 scrolls the current date on the display and only after getting the IP address does it switch to displaying the IP address. This could be an indicator that internal communication with the WiFi module gets lost or the WiFi module might be resetting in some way.
I’ve been testing according to your feedback over the last few days and haven’t found anything unusual. Our latest firmware is rev64.1.
As for the scrolling display, the time is displayed when there is no wifi. From the situation you described, it does seem that the WIFI connection has been lost, the device will automatically reconnect by default.
In my test, I have logged REG94,95 which is the running time of the device, the time is stored in the two registers, the units are in seconds. ( 1 * 65536+23356) / 3600 = 24hour time format.
We are using the latest firmware revision, but we are definitely not getting WiFi reconnection in this situation. It is only after we reboot the TStat10 that it reconnects and stays connected for some 24 t to 36 hours before losing the connection permanently until the next manual reboot. Without intervention it seems no attempt is made to reconnect or the connection attempts are unsuccessful.
Is there something that could be added to the code to show some connection state in the display because without connectivity we have no way to determine what is happening?
If you had a wireshark capture, especially of during the period when the Tstat10 is offline that would really help. All our devices have logic to try to reconnect if connectivity fails so I would expect to see some packets from our device reaching out…
