147: Smart Home Automation with Robert Spivack


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.)

1 Like


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 :stuck_out_tongue_winking_eye:.

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 :slight_smile:

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.