Sever Addresses outside of the USA

I am trying to understand if it is intentional that the Rachio is sending data to servers outside of the United States. While I understand that AWS servers run around the globe, I find it odd that my Rachio is sending data to servers in countries like:

  • Russia (
  • Czechia (
  • Armenia (
  • Bulgaria (
  • Belarus(
  • Pakistan (
  • Turkey (
  • Ukraine(

all in the last seven days.

I am asking the question because I want Rachio to understand if there something else going on that you are not aware of.
None of the other IoT devices I have in my house send data to these countries.


1 Like

Did you happen to capture the port the data initially goes out to? Rachio primarily uses secure MQTT connection to AWS (port 8883).
Theoretically controller should connect to one of these:

Anyway you can (wireshark) capture what is happening during bootup?

— Likely answer —

Searching through the IPs you’ve listed, a lot of them seem to be a part of the (have not checked the complete list to be completely sure). In any case seems that your controller is trying to get it’s time from one of the European NTP servers… Data should not be encrypted, meaning that wireshark or packet capture should provide a definete confirmation.

1 Like

Yes all of the IP’s I supplied have destination ports of 123 (NTP). The controller does ping US and non US based NTP hosts. I do not see any non-NTP requests outside of the US.

It makes no sense to me why NTP requests would be going over seas. Seems to me it defeats the purpose of time syncing when there is so much latency when sending to IP across so many other countries.
It also worries me that NTP DDOS could be possible, if the Rachio is sending NTP request to a set of NTP servers it really isn’t configure to talk to.


1 Like

Good question. As far as I know controller itself is not aware of the position data, all of the processing is done on the Rachio server. It’s possible that US and European NTP servers are hardcoded (have to reboot mine to confirm) and data from the server with lowest latency is used.

What generation of Rachio controller do you have? 1,2 or 3?

Because it’s simpler to just query than to figure out which zone would be appropriate for a given controller.

Also, it’s more robust; if a zone were taken out by an attack, the controller would still eventually pull the correct time.

First order, latency doesn’t degrade accuracy because the delays in each direction are very closely matched.

Just for laughs, I tried:

# ntpdate -q
server, stratum 2, offset -0.008044, delay 0.03348
server, stratum 2, offset -0.002144, delay 0.07866
server, stratum 2, offset -0.000468, delay 0.06360
server, stratum 3, offset -0.004388, delay 0.09660
27 Dec 11:03:08 ntpdate[15876]: adjust time server offset -0.008044 sec

# ntpdate -q
server, stratum 2, offset -0.002064, delay 0.18588
server, stratum 2, offset 0.000933, delay 0.17934
server, stratum 1, offset 0.002737, delay 0.17409
server, stratum 2, offset 0.000045, delay 0.18059
27 Dec 11:03:44 ntpdate[15998]: adjust time server offset 0.002737 sec

The European servers were actually somewhat closer to my system clock.
But in any case, given Rachio’s job, a time offset of even a second or two would not be an issue. Accurate time is mostly useful for debugging, when you need to compare activities in controller, app and back end.

1 Like

Good point @Stewart, just because IPs were found in, doesn’t mean that Rachio is not using a genetic which may return european servers to spead the load accross avaialble servers. I think you nailed it.

:cheers: on your point that delays in the NTP transmittion are taken into account. :+1:

@Stewart I agree on the time syncing latency. There isn’t anything so time sensitive on the Rachio to require low latency syncing, which is part of the point I was making. I wouldn’t expect time drift of the microcontroller to be that bad. Also the mobile app could also be used to help with they syncing.

I also can appreciate the generic approach, but the Rachio does have geo location data available, since the configuration sent to the controller at setup is required for the weather and advanced features.

My ntpdate results for kicks:

ntpdate -q
server, stratum 2, offset -0.001426, delay 0.07809
server, stratum 2, offset -0.001496, delay 0.05060
server, stratum 2, offset -0.000619, delay 0.08731
server, stratum 2, offset 0.001958, delay 0.05566
27 Dec 13:37:53 ntpdate[29728]: adjust time server offset -0.001496 sec

ntpdate -q
server, stratum 2, offset 0.002301, delay 0.19128
server, stratum 2, offset 0.002226, delay 0.21710
server, stratum 1, offset -0.002491, delay 0.18414
server, stratum 2, offset 0.000347, delay 0.18605
27 Dec 13:38:07 ntpdate[29730]: adjust time server offset -0.002491 sec

Have a nice holiday season.

Rachio controller itself is pretty straigtforward schedule tracker. Time is kept on the dedicated timeclock IC with battery backup and the controller only knows upcomming schedule it should adhere to.

Controller itself does not know the location, moisure levels or weather info, instead the server keeps track of everything and sends updated schedule on the regular basis. This allows Rachio to make adjustments and improvements to the weather tracker on the server & not have to do firmware updates to implement them on the controllers.

@Gene @Stewart @jdcalus

Just kidding. Cool that there are a few of you in here with deep networking knowledge!

1 Like

It’s pretty straighforward, once you realize it’s simply a series of tubes…