The smart home can be a wonderful thing once everything works, nothing changes, and everyone “behaves” as the “smart home automator” anticipated. And then there is the cruel reality torturing us with breaking changes due to software upgrades, hardware failures, network brainteasers, and a general lack of automation in what usually is just our hobby project.
My Intent
I had a very simple addition to my smart home setup in mind: I own a couple of Eve thermostats, which I very much like. Since I got them, I had them kinda “integrated” into my smart home via Apple Homekit, which essentially meant that I can control them from my Apple devices, but they are essentially uncontrollable from my smart home hub, Home Assistant. Although Home Assistant could see my Apple accessories through the Apple HomeKit integration, it’s a read-only integration. What I actually had in mind, though, was Home Assistant as the controlling instance for my thermostats.
Integrations To The Rescue?
Fortunate me, clever and assiduous developers came the Apple HomeKit Controller integration for Home Assistant. Even better, this integration claimed to allow integrating Thread-devices into Home Assistant! 🤯 “What a wonderful time to live in”, I thought and went straight to the integration.
The Complications
Initially, everything seems to run smoothly. To get Home Assitant to recognize my thermostats, I first had to remove them from HomeKit: I opened the Home app (either an Apple device of your choice), opened the setting of the thermostat to remove (long-press on iOS, right-click on macOS), scrolled to the bottom of the setting and selected Remove Accessory.
Now I headed to my Home Assistant installation and checked under Settings → Devices & Services → Integrations tab if the thermostat was listed there. I wasn’t immediately, hence I woke it up by simply touching any of its controls.
Being very happy and thrilled about the super smooth experience, I selected Add Integration, leaned back and waited for a couple of seconds… and got a timeout error. From what the UI showed and what I found in the Home Assistant logs it first appeared to me to be an IPv6-related problem. This could have made sense as Thread is indeed an IPv6-based protocol. Having had a very technical view of the problem, I spent a couple of hours fiddling with the configuration of IPv6 subnets. And while I learned a bit about IPv6 through this journey, I missed one point which came to me only after putting my network problem aside for a day: My thermostats and Home Assistant don’t communicate directly but through Thread border routers, which in my setup are two HomePod Minis. And as my private network is IPv4 based, I likely tried to solve the wrong problem, or a symptom of it at best.
My Setup
To understand what has been the problem, let’s take a look at an excerpt of my home’s network topology:
What’s important here is that my HomePod Minis live in a VLAN different from my Home Assistant instance. This hasn’t been an issue with the Apple HomeKit integration, but hey, maybe it’s worth taking a second look into the documentation of the Apple HomeKit Controller integration.
The Actual Solution
Turns out, I should have indeed paid a bit closer attention to the documentation of the Apple HomeKit Controller integration (emphasis is mine):
In order to use HomeKit over Thread you need a working border router (like a HomePod mini). Your Home Assistant instance will need to be on the same VLAN as the border router.
Argh. 🤦♂️ This was actually an issue in my setup: I had to virtually move my HomeAssistant container into the same VLAN as my HomePods. I knew about inter-VLAN routing and VLAN tagging, but haven’t thought about how to let my Proxmox server send traffic to multiple VLANs via the single network interface it is connected with to my network. Lucky enough, other people had the same question and shared the solution: To move my HomeAssistant instance from its current VLAN to the VLAN my HomePods are part of, I had to configure the Linux Bridge to be VLAN aware and, most importantly, change the Bridge ports from <interface> to <interface>.<vlan-tag> :
Et voilà, this change did wonders:
Top comments (0)