firewalling 3m50 causes issues

[rcgates]

If I set my router to not allow the 3M50 to connect to the cloud, after a couple days it will start having issues being controlled using the api via curl, I get a return status of -1 and any data retrieval returns wrong results, mostly '-1''s.

If I remove the block on my router, after a few minutes, the curl api starts working again.

I have two 3m50's, one is running 1.04.64, the other 1.04.69, if I remember correctly, it was the unit running 1.04.69 which had the fault.

[rcgates]

after blocking my two 3m-50's from talking to the cloud, I did daily checks to see if the problem would reproduce.
I could get tsat fine every day, today, day 7 I did a program cycle via the api of my two 3m-50's and that worked, but then I was no longer able to get a tstat status from either one. Each attempt to get a tstat status would give me a failure to connect.

I unblocked my firewall and all started working fine after several minutes.

There is a bug in the 3m-50 code that is causing these to fail if they can't talk to the cloud after several days.
This is irritating since I really don't wan't my thermostats sending my heating data to the cloud.

If I watch my router logs, I see both 3m-50's try and do a UDP connect to the could every 30 seconds.

[Lbendlin]

you may want to try the alternative way of blocking the cloud stuff. Rather than firewalling, set the authkey to blank. (Make sure to back it up first)

-1 stuff mostly happens when the web server is overwhelmed. Make sure you're not curl'ing too often.

[rcgates]

thanks, I'll give that a try.

BTW, I'm not pulling status off the units very often, when I want to look, but not frequently.
Once I finish my house monitoring code, I don't plan on pulling data off more often that once per day to get the usage
and then any other data pull will be "on demand" by me vs frequently scheduled/polled.

[Lbendlin]

You have to be careful with that. Once per day may backfire, especially when you get a dud response back. At the very least validate the data and retry if you see -1's

[wwsp]

I also have set my firewall to prevent my 3m-50 from contacting the cloud. And I also have intermittent issues with the thermostat either failing to respond in a reasonable time (15s to 20s) or else returning in time, but with an "error" response. However, I do not believe the two are related. I think the thermostat's little web server just sometimes doesn't respond.

One other comment: I have used a packet sniffer (wireshark) and tested this:
Browse to the thermostat's "/home" page and setting its "Cloud URL:" to empty, then click Submit.
The thermostat no longer makes TCP connections to anywhere--at least not that I have noticed in wireshark.
I notice that the blank display of "Cloud URL:" does not seem to stick, it goes back to
"http://ws.radiothermostat.com/services.svc/StatIn" on its own after "a while". But wireshark is still not detecting any TCP connects. Instead of blank Cloud URL, I also tried a non-existent IP and also put the local IP of the router. All the above "worked" in the sense that wireshark shows the thermostat attempting to connect to the bogus IP and failing.

After watching the system work per factory installation for a while, I decided I am not willing to allow my thermostat to advertise to the radiothermostat website what its settings are. I am obviously an old man not of the Facebook generation. On the other hand, I do want to be able to control my thermostat from the internet side of my firewall. I have setup an openssl server on an old laptop that runs 24x7 inside my firewall such that from outside I can make an ssh connection and tunnel inside. Until someone figures out how to crack ssh, I am pretty confident that nobody else can get into my thermostat or tell anything about it by sniffing my internet packets.

Wayne

[Lbendlin]

as I said above clearing the authkey seems to be a much more robust option.