Possible to restrict access to smart thermostat to local connections only (not from the WAN)

I do not want my smart thermostat (Honeywell T10) to be accessed from IP addresses outside of my home network. The manufacture of the app and of the thermostat told me this is not possible. Since the device is not a direct connect like some security cameras (ie. https://10.1.10.102), I do not believe this is possible. I believe there is some cloud-based setup which manages the connections.

I am asking for suggestions.

  • The device is on an IOT VLAN with firewall forwarding policy denying access to the WAN.
  • I created a traffic rule allowing the IP of the thermostat to port 443 on the WAN (required for using the app).

When I inspect pi-hole logs from the thermostat, I see it resolving DNS entries for:

fwuprod.clouddevice.io
provprod.clouddevice.io
weather.clouddevice.io
lcc-prodsf-lcc02sf-iothub.azure-devices.net

My thought is to change the the traffic rule from allowing 443 to all addresses to just the IP corresponding to weather.clouddevice.io and see what happens.

The use of a cloud service is not uncommon, and the system may or may not actually have any means of local control.

A point of clarification here: the firewall of any proper router (OpenWrt and others) will always block access from the WAN, except for connections opened by devices on your LAN (i.e. established or related sessions). With cloud services, these tend to be a connection brokerage situation -- your thermostat connects to the cloud service to say "I'm here", then the cloud service actually brokers a connection between the app (wherever the device may be in the world) and your thermostat.

EDIT (for clarity): in some cases, this brokerage literally sets up a direct connection from your app to your thermostat. In other situations, the cloud service may be a relay -- it takes command from the app and sends it to the thermostat, then reads the status from the thermostat and sends it to the app.

I see where you are going, conceptually. I don't think this will work, though, because it's not as simple as just redirecting the traffic -- you need to actually have services running that mimic that of what is running on those cloud servers.

You need to figure out if the app itself has any means of local connection/control. If your app doesn't have a place for you to enter a local IP address to connect to your thermostat, you've likely got a dead end. Often, the app will connect to the cloud server and present login credentials, and your thermostat is connected to that account by some means during your initial setup. Without the cloud in the mix, you need to be able to make a direct connection by IP -- does the app have any way of doing that?

If the app itself doesn't support this, maybe a 3rd party app or automation environment can bridge the gap here (keeping in mind that the cloud server may still be required for brokerage). So, to find out if it is even possible, you can scan the thermostat's IP for any open ports/services -- if it is listening on any ports, maybe an app or automation system (like Home Assistant) could theoretically connect. But if there are no open ports, I think that's game over.

1 Like

No, the app and the device both use a broker/cloud based middle-man. There is no option for local anything. I believe your suggestion that I would need to mimic the communication on my own relay is correct, unfortunately. It is very disappointing.

It seems like there are two ports required for functionality: 443 and 5671. Without 5671 opened up, the device will not detect the internet as being connected. The app also will shows "offline" and you cannot adjust settings/is worthless.

The traffic on 443 seems to be needed for a minimum getting the outside weather (needed if you have a humidifier) and some other connections to cloud-based services. From auditing my pi-hole logs, here are the four domain names it caught over the past few days:

      2 fwuprod.clouddevice.io
     85 provprod.clouddevice.io
    281 lcc-prodsf-lcc02sf-iothub.azure-devices.net
    343 weather.clouddevice.io

Since I only want this in order for the humidifier on the furnace to work, I will try removing access on 5671 and only allowing 443 to connect to weather.clouddevice.io to see what happens.

Good luck with the experiments. Depending on the situation, you might be able to replace your thermostat with one that is controllable by local automation systems and doesn't require cloud access. I'm not personally familiar with the various products on the market, so I can't recommend anything (and besides, your HVAC system itself may or may not present compatibility issues/questions).

Let us know what you find once you've got some results from your testing.

And if/when your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
(in truth, your problem may never be 'solved' but you can mark it as such and include an explanation of your findings -- still could be useful for future readers)

Yeah, I agree with you. I will change the status once I have some more data and conclusions. The particular thermostat I purchased is pretty popular so others may find this thread useful if I spend some time to document my findings.

Speaking of that, I'd like to share an information rich link to an amazon review about this thermostat and its workings but I cannot figure out how to directly link the review. I am pasting the contents of it here in hopes it will be useful for others.

amazon review found by browsing to the product's page and searching for 'firewall' in the reviews

Great Thermostat but Archaic WiFi Implementation and Lousy Support

By Liam Sarsfield on January 18, 2021

This is the best Honeywell t-stat on the market in terms of functionality. I replaced a Honeywell VisionPro 8000 that took a hit during an electrical storm. My system is dual-fuel with Heat Pump and propane auxiliary heat. I had my HVAC guy install the T10 which took all of a half-hour. It immediately started to control my system without any fuss. then the trouble started.
After a while it kept calling for back-up gas heat at temps well about the crossover temp the installer set up (30F). It would take over a month to get the installer back given the backlog so I called Honeywell for help. They company used to he helpful - now you wait an hour to talk or chat with a person that has no clue about the thermostat. If you ask a technical question they say 'oh, we can't answer that question because it would void the warranty'. Gee, they never made that claim in the past. I guess Honeywell hires more lawyers than techs these days. If you need any help beside punching buttons you are SCREWED. If it gets cold, too bad for you.
Then there's the WiFi business. A total mess. And boy does Honeywell want cloud access. We are to believe that a smart thermostat has to phone home for intelligence. Fortunately, the WiFi setup is terrible that you'll probably give up anyway.

The installer left the WiFi connected - I know why! I have a fairly sophisticated secure gateway network setup but I'd read that these thermostats required access to a fairly simple WiFi connection to work. So, I set up a separate sub-network just for the T10. It found it and logged in quickly and I thought I was off to the races... nope! The t-stat informed me that though it connected it could not reach "the cloud". I checked the connection using several other devices and none had a problem. I reset the t-stat and did the log-in again only get the same result. So I used Honeywell's technical chat line and was sent the following list of requirements:

  • Distance between the router and the thermostat or any wireless device should be within 30 feet ideally (distance would change depending upon construction).
  • Connect directly to the router signal – Not recommended for use with signal booster, satellites, extenders or access points.
  • Verify the Wi-Fi network's settings are compatible with the requirements below:
  • Make sure the network is broadcasting on the 2.4 GHz and 5 GHz B, G, and N bands.
  • 2.4GHz Bandwidth and 5GHz with separate SSID and password (Simultaneous 2.4 and 5GHz networks that share a name or SSID are not recommended and can cause thermostat to lose connectivity).
  • Make sure there isn't a limit to the number of devices that can connect to the network.
  • Make sure the router is set up for dynamic addressing (DHCP) and not static.
  • Gateways or Network switches can block some traffic to Honeywell and are not supported.
  • Make sure the network is using one of the following security protocols: OPEN, WEP_PSK, WPA_TKIP_PSK, WPA2_AES_PSK, or WPA2_MIXED_PSK.
  • Make sure ports 443 and 80 are open.
  • Make sure ports 5671, 5672 are not blocked
  • UPnP / P2P Enabled
  • Band-Steering Disabled
  • If there is a firewall, make sure the thermostat can connect to the following IP addresses:
  • Tccprod01.honeywell.com 199.62.84.151
  • Tccprod02.honeywell.com 199.62.84.152
  • Tccprod03.honeywell.com 199.62.84.153
  • Tcccntrl01.honeywell.com 199.62.84.144
  • Tccdata01.honeywell.com 199.62.84.128
  • Tccdata02.honeywell.com 199.62.84.129

Those are a whole lot of requirements that are not stated in the manual or installers guide. Thanks Honeywell for telling me after my purchase. For me, the takeaway is that the WiFi setup of this state-of-the-art t-stat is very old school. Every other WiFi device in my home has no problem connecting - only this device. I'm not about to enable things like UPnP. Switches are not supported! What? My WiFi AP is downstream of a switch - I'm supposed to tear my network apart just so Honeywell won't be put out.

To be clear, the t-stat doesn't really want internet access - it wants "cloud access", naturally to Honeywell's cloud servers. Well... no. I do access a cloud server but only over a secure encrypted link. Honeywell might intend to employ cloud services to help utilities better plan for efficient energy use and other noble causes but their clunky implementation of network software on these devices does not inspire confidence nor trust. Honeywell has some terrific mechanical and electrical engineers, but their network software engineers are asleep at the switch.

The t-stat will display a red warning dot and say it can't get to the cloud, but it is connected to the internet. The main reason for its failure to make the connection to the Honeywell cloud is DNS. It seems to assume that everyone has their router/gateway parked at 192.168.1.1. I don't, nor should anyone else. So even if you comply with all of the fancy settings Honeywell requires it won't matter because the device is trying to route signal to a DNS address that might not exist.

That said, if you install a mobile app you can connect with the t-stat successfully. If you're purchasing this or other smart devices to control a t-stat in a rental property or vacation home this mobile app-to-t-stat might be enough to provide control... not sure. When the mobile app connects to the t-stat the red light disappears which is all I wanted. I blacklisted Honeywell's IP addresses since I have no interest in their cloud services.

UPDATE: Returning to a positive note, and if this helps anyone else, I finally sorted out how to get the T10 to integrate with an ERV. For those with a ventilator (ERV or HRV) and want to control them through a T10 take note. The T10's "U" connectors can be wet or dry, this is explained in the Installer Manual which only a "pro" gets to read (unless you use Google). Wet means the T10 will send voltage to a single U terminal; dry means it will close the two U terminals to complete a circuit, no voltage from the t-stat applied. The T10 typically takes 24vdc from the heating/cooling system transformer. In a wet system this would send 24vdc to your endpoint - an ERV, humidifier, etc. In may case I want it to control my ERV which has 12vdc controller electronics. This means I had to set the T10 to a dry connection - basically to control the ERV the T10 just throws a switch to connect the two "U" terminals. When the T10 wants to power up the ERV it completes a circuit linked the two "U" terminals. You have to determine which wires from your ERV power it up. In my case, a Bryant/Carrier ERV, this meant taking only the black (B) and green (G) wires from the ERV and connecting them directly to the T10s "U" terminals. YMMV depending on your setup. The T10 can control an ERV in multiple ways. I just needed it to ventilate my house as I have other means of humidity control. The ERV was controlled by a wall controller (humidistat) which was mostly useless. I was able to eliminate this wall controller and use the T10s timer feature to ensure that the ERV runs a fixed percentage of an hour to ensure that my tightly-sealed house gets fresh air year round. The T10 is smart and runs the ventilator in unison with the HVAC's operating system, but if that system doesn't need to run it will fire up the ventilator to accomplish whatever ventilation requirement you've set. Importantly, this simple 'contact closure' feature will spin the fan in the ERV/HRV at only one speed; in many cases these devices have two fan speeds. For my system, connecting the B and G wires put the ERV in high-speed mode which is fine. However, if you insert a 3.9K Ohm resistor in series on this line the motor will operate in low-speed mode. ERV/HRV controls are typically triggers by different voltage signals that tell the unit which fan speed to set, whether it should be continuously or intermittently on. etc. Resistors are used to generate various voltages so its a matter of looking through system documents or chat rooms to figure out what size resistor accomplishes the fan speed change. The ERV uses less power and is a bit quieter on low-speed which still moves a whole lot of air - to me it was worth slowing it down a bit. Take these notes as hints only - check your system carefully to avoid burning up an expensive circuit board or the T10. The T10's ability to control other devices is a powerful feature, you just have to be very careful how you use them.

The T10 is a good thermostat that can accomplish a lot, but dealing with Honeywell and being forced to keep bringing back HVAC techs to address problems with no recourse sucks. Honeywell, once a great American company, is not just another consumer-unfriendly mess run by suits.
Honeywell needs to step out of the 5th century and start putting out smart devices that really are smart. I realize that the T10 demands a professional installation and all that jazz. All I can say is good luck with that idea. I did have mine installed by a pro. But how many HVAC installers moonlight as network engineers? And many simply do not understand the operation of devices like the T10. And how many are really familiar with inner workings of devices like ERVs and HRVs?
As a thermostat it works. But dealing with Honeywell and a tragic network setup isn't worth the effort.

2 Likes

I have this thermostat in its own VLAN like you do. I have also blocked egress for all traffic from this to the internet. I don’t use the vendor’s app but actually use Home Assistant + HomeKit Bridge to interface over the local API. Been working fine for the last week.

Note that you don’t have to have an Apple device, HomeKit is the protocol and there exist several options that leverage it. Of course the simplest is if you have an iPhone, you can just add it to the Home app and be done.

I never heard of Home Assistant or HomeKit Bridge. Can you describe the setup? What functionality do you have with your setup? Thanks

Home assistant is a really cool open source automation software package. HomeKit Bridge helps bring other systems into the Home Assistant environment (among other things)

Blocking access to your lan from internet US easy, in you router firewall.

Indeed most firewalls are configured to block all ports except those you open intentionally.

So the answer to your strict question is yes.

But most of these devices do not exposed ports to internet, they do not provide a service for others to connect.

They connect to a server in internet and publish there the info they provide. You configured them with a user and password to the cloud server.

Then you access that info or interact with the device using that cloud service and the provided app or a web Explorer.

So using the firewall to block incoming requests does not work.

You have to block outgoing connections from the device.

You can do that with a firewall blocking all outgoing traffic from that device.

But It is easier and more secure to put all devices in an isolated vlan and a firewall zone with no access to internet.

The problema.is that usually the app provided by the vendor won't work as they usually do not access the device locally, but through the cloud service.

I am looking for zigbee heater valves that could be accessed locally to control them, and investigating about using homeassistamt or openhab to control heating, multizone system with independant temperatures and a central switch to Connect or disconnect heating when some zone is under the stablished temperature.