Apple HomeKit, iOS/iPadOS, and the Rachio 3 (and other networking notes)

Apple HomeKit, iOS/iPadOS, and the Rachio 3
(And other networking notes)

There are some misunderstandings about the relationships between Apple HomeKit, HomeKit accessories, and iOS/iPadOS (hereinafter simply “iOS”).

An iOS device need only be present and active for the purpose of adding an accessory to HomeKit. And, of course, personal interaction with HomeKit. Thereinafter, HomeKit communicates back-and-forth with the accessory without the need for an iOS device being present. It has to be that way, otherwise how would HomeKit Automation work?

Crude “ASCII art” drawing of the relationship:

iOS device(s) <-> HomeKit <-> accessories

Furthermore: All documentation says “on the same WiFi network.” In reality they all need merely be on the same network, during setup–wired or wireless, 2.4Ghz or 5GHz wireless, not necessarily the exact same physical network. E.g.: I initially set up HomeKit to run on the Apple TV in our computer room. That ATV has an Ethernet connection. So, too, does our Lutron Casèta Smart Bridge. All our other ATVs are on WiFi, as is our Ranchio 3 irrigation controller.

When I write “same network” I mean the same flat network. I.e.: No intervening routing, VLAN isolation, etc. Otherwise the network discovery protocol (protocols?) they need to remain aware of one another won’t work, because those protocols don’t cross routed boundaries or VLANs. (See also notes about “mesh WiFi,” below.)

Here’s a neat thing: If you have multiple HomeKit-capable hosts on that flat network (multiple ATVs, HomePods): If the one serving as HomeKit controller goes off-line, another takes over for it.

E.g.: Screen-shot of our HomeKit Hubs & Bridges:

You’ll notice “Computer Room ATV” is connected, and the others are on standby or disconnected. Now I unplug the Computer Room ATV:

Now “Family Room ATV” is running the show.

For those who may be wondering: Yes, our Rachio 3 remained connected to HomeKit through this–I turned a zone on/off from my iPhone.

Some Notes On WiFi Networking
(and mesh networks, in particular–some copied from an earlier post of mine)

Here are things I’ve seen cause problems with WiFi networks:

  • Poor WiFi router/access point equipment–particularly “all-in-one” routers/switches/APs
  • Poor WiFi router/access point siting (e.g.: WiFi router/AP located in one corner of a structure)
  • WiFi repeaters (aka: “range extenders”)
  • WiFi mesh products (often little more than WiFi repeaters with dubious “smarts”–more detail below)
  • WiFi routers/APs with client isolation enabled
  • WiFi routers/APs with band steering enabled–particularly in multi-router/-AP installations
  • WiFi routers/APs that are placed too-closely to one another, creating overlapping coverage, resulting in devices “flapping” between them

I’ve often seen WiFi mesh networks, in particular, to be the culprit in problems with devices that are meant to maintain persistent connectivity, because they often have designed-in “smarts” meant to transparently “improve” network performance. Unfortunately, sometimes those “smarts” aren’t so smart, because they block network service announcement or discovery protocols such devices need to work. (E.g.: MDNS/Bonjour.) Sometimes you can’t turn those “smarts” off.

Even worse: I witnessed one WiFi mesh network product that would allow network service advertising/discovery protocols, then later decide to filter them out as “unnecessary noise.” This resulted in devices working, then, later, mysteriously failing. (Even worse yet: This behavior was not documented and the product’s own tech support people were not aware of it. It was discovered via network traffic analysis.)

(WiFi mesh products aren’t necessarily the only guilty parties. I’ve seen incidences of other WiFi routers and APs that do the same thing–though usually you can turn that stuff off in those.)

That’s all I can think of at the moment. I’ll update this post, as necessary, as long as the forum software will allow me, following which I’ll add updates as additional posts.,


Problems With Network Device Discovery

Networked devices often use what are called “network service advertisement” and “network service discovery” protocols. Two of these are mDNS (multicast Domain Name Service), aka: “Bonjour,” and SSDP (Simple Service Discovery Protocol).

It is absolutely necessary these service protocols be propagated through your network so various devices that need to discover one another can do so. If they’re not, devices simply won’t find one another.

I have seen several situations in which these protocols are interfered with.

  • WiFi routers used to separate a wired LAN from a wireless LAN - these protocols are not routable
  • WiFi routers or Access Points with client isolation enabled–preventing wireless clients on the same WiFi network from “seeing” one another
  • WiFi routers, access points, or mesh products that attempt to optimize network bandwidth by blocking broadcast traffic

In one documented case, a certain mesh WiFi product would allow the network discovery broadcasts through, then later decide that traffic was superfluous, and block it, causing devices to appear, then mysteriously disappear.

Detecting Network Advertisement/Discovery Protocol Problems

One way to find out if network service advertisement/discovery protocols are being interfered with on your network is by the use of a network traffic analyzer. One popular tool, available on Linux, Unix, Mac OS X, and Microsoft Windows, is Wireshark.

I’m not going to give you a tutorial on how to use Wireshark. There are plenty of them on the 'net. What I will share with you are some Wireshark Filters that will look for the protocols in which we’re interested.

We’re interested in (service name, port, and IP type):

  • mDNS 5353 UDP
  • Bonjour 5353 UDP (same as mDNS)
  • SSDP 1900 UDP

And the IPv4 broadcast addresses:


Here’s a Wireshark filter that will catch them all:

ip.addr eq || ip.addr eq || upd.port eq 1900 || udp.port eq 5353

If you wish to limit what you see to only broadcasts from a specific device:

ip.src eq and (ip.addr eq || ip.addr eq || upd.port eq 1900 || udp.port eq 5353)

Or limiting what you see to what’s broadcast from all devices in a sub-net:

ip.src eq and (ip.addr eq || ip.addr eq || upd.port eq 1900 || udp.port eq 5353)

which will show you everything broadcast by through

(Of course, you have to use your own network addresses in place of 192.168.0… I simply used those addresses for example purposes.)

Caveat: Just because you see these protocols on your desktop, laptop, or whatever, connected to your wired LAN, doesn’t mean they’re seen everywhere. In the case of the mysteriously appearing/disappearing devices I mentioned, above, the service discovery traffic was being filtered from the wireless network mesh node with which the device in question was associated. So it may be necessary, if it’s a wireless device that isn’t being discovered or is going missing, to be able to connect a laptop to the same wireless node, to make sure the network service discovery/advertisement protocols are getting through to it.

Here is an example of the kind of thing you’ll see in Wireshark when the protocols listed above are seen: