Interesting episode. Iād already been wondering whether to replace my HOOBS server running on my Raspberry Pi with Home Assistant (running on the same Raspberry Pi, just switch out the SD card), but now David and Robert have me wondering as to whether I should do that using HA as the ācontrollerā or the āobserverā. Iāve done an initial set up and been blown away/overwhelmed by the detail and information that HA makes available from the devices it has found - this could be both a blessing and a curse. Does anyone know of a good comparison article/review between the 2 systems, and in which mode to run it?
Weāre a MacOS/iOS household who run our TVās with FireTV devices and have mostly Echo devices - with 1 HomePod Mini to act as our HomeHub. Iāve been using HOOBS to bring Ecobee, Ring, Wyze, Govee, MyQ, SamsungTV, Wiz and Alexa into HomeKit.
Definitely worth planning before jumping in.
Last question is easy - HOOBS is a simplified user interface on top of HomeBridge. HomeBridge/Hoobs is a ādriver boxā - it simply allows non-HomeKit hardware to be exposed as pseudo-HomeKit devices using a software translation layer.
That function is also built into HA (but HA does a lot more).
A first step would be to replace HOOBS/HomeBridge only for your non-HomeKit devices. Get that working and stable, and then explore your options from there.
Essentially, the oberver vs controller decision is moot for any non-HomeKit device. You must use some translation layer (HOOBS/HomeBridge, HA, or something else), so no decision to make (yet) for non-HomeKit devices.
In the near future, Matter certification on hardware will essentially make HOOBS/HomeBridge obsolete, but not HA.
(To be clear, there are subtle differences in how HomeBridge vs HA expose or translate some of the non-HomeKit device unique features and map that back, or not, into HomeKit, so if you are using more than just basic controls of the device in HomeKit, youāll want to drill down into all the specifics and make sure HA is a superset of what you are using now.)
David:
In the episode you mentioned some issues with the Home Assistant / HomeKit links when you added your Kia.
My guess is that you hit the maximum number of entities that you can provide to HomeKit through a single Home Assistant bridge.
The HomeKit Accessory Protocol Specification only allows a maximum of 150 unique accessories (
aid) per bridge.
(See Device Limit for more details.)
I remember thinking āthereās no way I have 150 entitiesā but they start to add up when a single device may expose multiple pieces of data.
If thatās the issue, you can set up more than one bridge, but Iāve never gone down that route so Iām not sure how to do it. Instead, I set up my bridge to use an inclusion list instead of an exclusion list. Now I only see the devices and sensors in HomeKit that I wanted to expose, and the limit is much smaller.
Also keep in mind a gotcha that Iāve noticed with this approach: if you donāt select an entity category on the first page, then all of the entities of that type get added to HomeKit. That means if you donāt select āmedia playersā on the category list, then all your media players get added, even though itās an inclusion list. For the best results, Iād select every category on the first page of configuration and then only check the devices/entities that you want in the second configuration.
This is the type of nuance that Iām struggling to get my head around. For example I added my Dyson fan to HA last night and it seems like there are a dozen or more entities associated with the 1 device (is the fan on or off, speed, temp, humidity, air quality, VOCs, filter life, oscillation, and on and on). Until the devices are in HA you donāt really know all of the entities that are going to get exposed and how you might want to leverage their use. Then when it comes to sharing them with HomeKit via a bridge I need to spend a bit more time understanding how to limit what gets shared and how I want to organize and name my bridges. Seems like this could be a pretty big rabbit hole that Iām about to fall down. I think I have the basics of my devices visible in home now and currently my automations are run by my devices 1st party apps (Lutron, Wiz and Wyze), but now that I can see things in HA I should hopefully be able to āknit togetherā automations from disparate sources.
Itās one of these instances where similar terms are used with different scopes and I need to learn and understand the differences between each system. No doubt there will be missteps, but hopefully not too much āripping it all out and starting overā due to me not organizing something well.
Key for me to understand I think is to how/when to name things in HA such that when they are exposed to Home that it makes sense without duplicating things - for example I have 3 Govee Temp and Humidity sensors, each in different locations. Do I include the location in the name or not as if I call them all the same, then when I expose them in Home I struggle to assign each one to a location, but if I do include the location in the name then it becomes duplicative.
Iāll get there - I just have to chip away and enjoy each victory 
.
Name collision is a challenge with all smart home systems, not just HA.
One subtle feature of Lutronās more advanced systems, but not the popular Caseta, is the ability to label every device with both a physical and a functional/logical name that is separate from the āroomā designation in the automation system itself.
e.g. A dimmer that controls the light in the kitchen might physically be in the outside hallway leading to the kitchen and not in the kitchen itself.
I find this a great way to organize and document setups once you get beyond a single room or just a handful of devices.
For devices like sensors and smart plugs where you may have a lot of them and might move them around to different places, I sometimes give-up and give each of them a primary sequential id as the canonical name.
Location or functional names are āhelpersā, but at least I can uniquely identify each device in an automation by the id (s1, s2, s3, plug1, plug2, etc.) and I also put a physical label on each device.
Sooner or later, you will lose track of sensors and smart plugs and want to avoid a treasure hunt or crawling behind all your furniture to find them 
Another very enjoyable and informative episode! Thanks Automators and Robert!
I only wish Iād heard it a year or two ago before buying a dozen or so WiFi bulbs which needed a reset constantly, until a pronged power outage seems to have obliterated their set ups completely and Iāve long since lost the QR codes and instructions for setting them up, not that I wanted to anyway. Not worth the headaches.
I will look into hub solutions.
It sounds like Aqara finally has a Matter hub coming! This time, Iāll (hopefully) do it right.
This was a great episode, and is well worth a listen. The emphasis on system stability, e.g. retiring WiFi for Zigbee / Z-wave, and building a user-friendly home is always worth repeating.
Regarding HomeKit, my journey started using HomeKit as the master, with devices paired directly to HomeKit, and using Home Assistant to make non-HK devices using Zigbee / Z-wave available in HomeKit. Over time, however, I have slowly migrated all my HK devices into HA as the master, with HK as the observer for select devices. HK only sees a subset of all devices, largely those I want to voice control using Siri
My wife, who reasonably insists on having one app to control all the devices she uses, is now using the HA app with a personalized dashboard showing the devices she uses. My only manual use of the HK app is for HomeKit Secure video.
Everyoneās use case is different, of course, but given how good Home Assistant now is at being both a source and consumer of HK devices, Iād recommend pairing HK devices to HA, and making HK the observer of those.