My Classification of Smart Home Products

I've got a bone to pick with a lot of smart home tech. And mostly it boils down to what I think does and does not constitute being "smart". When I look at products, I look at them through a very specific lens and break them into 2 broad categories (though some can be both). "End devices" and "controllers". End devices are things like light bulbs. They are elements of a smart home ecosystem, but they don't control other devices.

Controllers on the other hand are devices designed to control other devices. Like hub devices.

And then, within that I break things down further.

For End Devices for example I have the following categories:

• Dumb device
• Platform extension
• Smart enabled
• Smart

For Controllers I would break them down as:

• User initiated (Dumb)
• Blueprint capable
• Scriptable

And to dive a bit deeper...

Dumb Devices

This is any device which cannot be controlled directly by a Smart Home Controller of any kind.

Platform Extension

If the device works in only one ecosystem or uses a proprietary communication standard for example, I don't care how "smart" it seems. It is not a proper smart device. As I've mentioned before, a truly smart home is capable of assimilating inputs from a wide range of devices. The notion that any one company will have the best solution for all possible use cases is absurd. It is even more foolish to assume that any one company would even cover all possible device types in the first place. So, I don't care how fancy your device(s) may be. 

There is of course, also the problem with companies going out of business or exiting the smart home industry. If the products play nice with other ecosystems, the risk is mitigated, if not eliminated. But, as we've seen many times now, almost all exits from the industry from proprietary systems end with bricked devices. This alone, for me, is enough to justify calling these out devices in their own sub-standard category.

Smart Enabled

A device is "smart enabled" if it is not a Platform Extension device and is able to be controlled and report state remotely. These devices require a controller to be smart in any capacity. But, so long as all important functions and metrics are exposed to the controller, these devices could behave in a "smart" capacity if the controller had sufficient capabilities and were configured to do so. 

As an aside here, I don't want to make a point of saying that there must not be any special 1st party API. For it to be truly smart enabled all metrics and commands should available over standard protocols. I won't dive in my arguments here. But they do exist.

Smart

A truly smart device is Smart Enabled but also contains some "local intelligence". Nest Thermostats, if they functioned the way people thought they did would fall in this category. Which is to say, the Nest Thermostats use prior information about their own state to allow them to make decisions on climate control for you. If this all happened on the device itself, then it would be deserving of the moniker "smart". 

Now, I don't have anything against a device reaching out externally for information. What makes the distinction is WHERE the decision is made. If it is made on the device then it counts. If it is made by a computer in the cloud, then there is simply another controller driving those actions and it is the controller supplying the smarts and not the device.

Now, as you might gather, I don't think that there are any "true" mainstream smart devices. So, what makes a smart home truly smart is the controller.

User Initiated (Dumb)

This is a controller which in my opinion is not actually "smart". It is a controller where the only commands supported or the bulk of them are those issued directly by the user. Think early Google Home and Alexa. You could turn lights on or off with your voice or via an app. 

But, that isn't any different than being able to turn a light on via a light switch. You are still the one deciding when the action should happen and initiating it yourself. It might be a tad more convenient some times or a little cooler. It is not, however, smart. 

I will also include things like time of day or motion based triggers even though these may feel like they belong in the next category. 

Why? We've had dumb analogs capable of these things for decades. Why would we start calling the same functionality "smart" now? Though, I would be tempted to include anything which mix triggers from a variety of sources. 

Blueprint Capable

Here is where things get interesting. A controller is "blueprint capable" when it allows for the creation of structured, rules based events triggered by state changes in smart enabled devices. In short, when data from a network of connected devices can be used to drive state changes in other connected devices. Then you start enabling functionality which would have been difficult or impossible to achieve through other conventional approaches.

For instance, I have an automation which unlocks the man-door to the house from the garage when the garage itself opens. Garage door and home lock manufacturers are not typically one in the same. So, unsurprisingly the two don't play nice together out of the box. Both are smart enabled devices however. As such, I am able to use the state change of the garage to detect when it opens and use that to drive a state change in the door lock to unlock it for me. 

Another example is my stairwell lights. The lights at the top and bottom of the stairs are on different breakers and the ones at the bottom are (perplexingly) linked to yet another set of lights at the front entranceway. I could hire an electrician to fix this stupid design, but that is clearly not a cost effective or mainstream solution. To complicate things, there are times when I want just the upstairs or downstairs lights on or at an adjusted level of brightness. 

I won't go deep into the details, but there is a mix of automations and scenes to get everything to my liking here. And needless to say, even if you consider hiring an electrician every time you hit a silly wiring decision to be reasonable, it would still not enable what I have achieved here.

The bar however is not that high. For me, all a system requires to meet this standard is that you provide a structured, event or polling based system which allows reading the state of at least one smart enabled device and using that to issue a command to another smart enabled device. 

Scriptable

This is like blueprints without boundaries. What is necessary here is an SDK/API/Programming Language allowing access to the retrieval of all state information and access to all commands for all connected smart enabled devices.

This will likely always be the enthusiasts playground only. Firstly, it is overkill for most situations. And even when it isn't, if it is a common enough situation, then someone will eventually find a way to distill it into a blueprint. 

Nonetheless, this complete freedom allows you unfettered control your smart home. The ability to custom tailor automations to your specific configurations or to do things so obscure that no one would ever create an blueprint covering it. 

In short, if your controller doesn't meet this capability, I wouldn't necessarily call that a mark against it. I think Home Assistant has shown that structured configurations and blueprints can still cover pretty much any reasonable request. On the flip side, early Google actions in the Home app were pretty lackluster. So, it really boils down to refined the blueprint functionality is in a given controller.